[c-nsp] Re: cisco-nsp Digest, Vol 27, Issue 41
Erdem Sener
erdem.sener at borusantelekom.com
Wed Feb 9 16:54:34 EST 2005
Hi,
You might want to "carefully" try to switch vtp mode of 2950 to
'Server'
and see if it makes any difference.
In some cases, I've seen vtp information not being carried out within
the vtp
domain and had to add the vlan manually on the core using 'vlan
database'
command. Not sure this is the best way, though.
Cheers,
Erdem
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Alban Dani
> Sent: Wednesday, February 09, 2005 11:39 PM
> To: cisco-nsp at puck.nether.net
> Subject: :SPAM: [c-nsp] Re: cisco-nsp Digest, Vol 27, Issue 41
>
> Hi,
>
> here are some outputs:
>
> cat6509#sh interfaces gig 4/16 trunk
>
> Port Mode Encapsulation Status Native vlan
> Gi4/16 on 802.1q trunking 1
>
> Port Vlans allowed on trunk
> Gi4/16 1,5,8,13,17,21-22,27,41,43,63,68,70-71,73,76,83,101-102
>
> Port Vlans allowed and active in management domain
> Gi4/16 1,5,8,13,17,21-22,27,41,43,63,68,70-71,73,76,83,101-102
>
> Port Vlans in spanning tree forwarding state and not pruned
> Gi4/16 1,13,17,21-22,27,41,43,63,68,70-71,73,83,101-102
>
> *************
>
> cat6509.cc#sh vtp status
> VTP Version : 2
> Configuration Revision : 299
> Maximum VLANs supported locally : 1005
> Number of existing VLANs : 136
> VTP Operating Mode : Server
> VTP Domain Name : vtpdomain
> VTP Pruning Mode : Enabled
> VTP V2 Mode : Enabled
> VTP Traps Generation : Disabled
>
> *****************
>
> cat2950#sh vtp status
> VTP Version : 2
> Configuration Revision : 299
> Maximum VLANs supported locally : 250
> Number of existing VLANs : 136
> VTP Operating Mode : Client
> VTP Domain Name : vtpdomain
> VTP Pruning Mode : Enabled
> VTP V2 Mode : Enabled
> VTP Traps Generation : Enabled
>
> Maybe I have said this before but the show spanning-tree
> commands also show that everything is in order.
>
> I opened a tac case with cisco.. and I can feel its going nowhere.
>
> Alban
>
>
> On Wed, 9 Feb 2005 11:10:50 -0500 (EST),
> cisco-nsp-request at puck.nether.net <cisco-nsp-request at puck.nether.net>
> wrote:
> > Send cisco-nsp mailing list submissions to
> > cisco-nsp at puck.nether.net
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > or, via email, send a message with subject or body 'help' to
> > cisco-nsp-request at puck.nether.net
> >
> > You can reach the person managing the list at
> > cisco-nsp-owner at puck.nether.net
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of cisco-nsp digest..."
> >
> > Today's Topics:
> >
> > 1. RE: Vlans and catalyst 2950 (Oliver Boehmer (oboehmer))
> > 2. Re: Vlans and catalyst 2950 (Adrian Pirciu)
> > 3. Re: VPN failover / load sharing using IOS? (Luan Nguyen)
> > 4. Re: Cisco 3550 maximum number of routable interfaces limit?
> > (Matthew Crocker)
> >
> >
> ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Wed, 9 Feb 2005 16:33:59 +0100
> > From: "Oliver Boehmer \(oboehmer\)" <oboehmer at cisco.com>
> > Subject: RE: [c-nsp] Vlans and catalyst 2950
> > To: "Alban Dani" <albcisco at gmail.com>, "Adrian Pirciu"
> > <adrian.pirciu at rdsnet.ro>
> > Cc: cisco-nsp at puck.nether.net
> > Message-ID:
> >
> <70B7A1CCBFA5C649BD562B6D9F7ED78474CA3B at xmb-ams-333.emea.cisco.com>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Alban,
> >
> > Did you enable vtp pruning? Can you send a "show trunk x/y"
> (CatOS) or
> > "show int xxx trunk" (IOS) on your Cat6k/core switch? It
> could be that
> > the 6k incorrectly pruned Vlan41 from the trunk.
> Workaround: disable
> > vtp pruning..
> >
> > oli
> >
> > Alban Dani <> wrote on Wednesday, February 09, 2005 4:24 PM:
> >
> > > Hi there,
> > >
> > > we are using VTP. All the new Vlans are created on the
> 6509 which is
> > > the core.
> > >
> > > Here is the output of the show vlan on the cat2950:
> > >
> > > cat2950#sh vlan id 41
> > > VLAN Name Status Ports
> > > ---- -------------------------------- ---------
> > > ------------------------------- 41 Stevens
> > > active Fa0/6, Fa0/35, Fa0/46, Gi0/1 VLAN Type SAID MTU
> > > Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 ---- -----
> > > ---------- ----- ------ ------ -------- ---- --------
> ------ ------
> > > 41 enet 100041 1500 - - - - - 0
> > > 0 Remote SPAN VLAN ----------------
> > > Disabled
> > > Primary Secondary Type Ports
> > >
> > > cat2950#sh spanning-tree vlan 41
> > >
> > > VLAN0041
> > > Spanning tree enabled protocol ieee
> > > Root ID Priority 24617
> > > Address 0009.b799.a680
> > > Cost 28
> > > Port 49 (GigabitEthernet0/1)
> > > Hello Time 2 sec Max Age 20 sec Forward
> Delay 15 sec
> > >
> > > Bridge ID Priority 32809 (priority 32768 sys-id-ext 41)
> > > Address 000b.fd53.9540
> > > Hello Time 2 sec Max Age 20 sec Forward
> Delay 15 sec
> > > Aging Time 300
> > >
> > > Interface Role Sts Cost Prio.Nbr Type
> > > ---------------- ---- --- --------- --------
> > > -------------------------------- Fa0/35 Desg FWD 19
> > > 128.35 P2p
> > > Fa0/46 Desg FWD 19 128.46 P2p
> > > Gi0/1 Root FWD 4 128.49 P2p
> > >
> > > Port Fa0/35 is trunked and Vlan 41 never makes it up this trunk
> > > unless as I have explained I put a port on cat2950 on
> that vlan and
> > > get some traffic in it.
> > >
> > >
> > > Thanks,
> > >
> > > Alban
> > >
> > > On Wed, 09 Feb 2005 10:58:15 +0200, Adrian Pirciu
> > > <adrian.pirciu at rdsnet.ro> wrote:
> > >> Hello
> > >>
> > >> Alban Dani wrote:
> > >>> Hello Matthew,
> > >>>
> > >>> I also am having a very wierd issue with vlans and 2950-s.
> > >>>
> > >>> We are running pst+.
> > >>> We have a 6509 in the core and everytime we try to get
> a new vlan
> > >>> passed through a chain of switches( all connected via dot1q
> > >>> trunks) that has a 2950 in it, it does not work. The only
> > >>> workaround we found so far is to go to a port on the
> given 2950 ,
> > >>> set the port on the requried vlan and connect a machine
> to it and
> > >>> through some traffic. That makes the 2950 aware of that vlan.
> > >>
> > >> a 2950 will not pass traffic for the vlans not defined
> in its table.
> > >> When you put a port in a vlan, it automatically adds
> this vlan to
> > >> the config (sh vlan) and it starts forwarding traffic
> for that vlan
> > >> which explains the behaviour you describe.
> > >>
> > >> You can use VTP if you want to have a consistent vlan database
> > >> accross you network. Be careful though (there are some
> bat things
> > >> that can happen, read the documentation from
> www.cisco.com and they
> > >> are described).
> > >>
> > >>
> > >>>
> > >>> If this was not enough, if the vlan in question does not see
> > >>> traffic for a couple of days the 2950 totally forgets about it.
> > >>
> > >> I am not aware of anything resembling this behaviour. Anybody ?
> > >> Does the vlan apper on "sh vlan" when this happens ?
> > >>
> > >>>
> > >>> I am wondering if you ever found a solution to your
> problem and if
> > >>> so what was it?
> > >>>
> > >>> I have upgraded to the latest IOS but it did not help.
> > >>
> > >> i'm pretty sure it is not an IOS/switch related problem.
> > >>
> > >>>
> > >>> thanks,
> > >>>
> > >>> Alban
> > >>> _______________________________________________
> > >>> cisco-nsp mailing list cisco-nsp at puck.nether.net
> > >>> https://puck.nether.net/mailman/listinfo/cisco-nsp
> > >>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> > >>
> > >> --
> > >> adixor
> > >>
> > > _______________________________________________
> > > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Wed, 09 Feb 2005 17:46:22 +0200
> > From: Adrian Pirciu <adrian.pirciu at rdsnet.ro>
> > Subject: Re: [c-nsp] Vlans and catalyst 2950
> > To: Alban Dani <albcisco at gmail.com>
> > Cc: cisco-nsp at puck.nether.net
> > Message-ID: <420A304E.4060502 at rdsnet.ro>
> > Content-Type: text/plain; charset=US-ASCII; format=flowed
> >
> > try creating a new vlan on the 6500 and then use sh vlan to
> see if it
> > is created automatically on the 29xx. If not, there is a vtp
> > configuration mismatch somewhere.
> >
> > add some outputs of "sh vtp status" on the 6500 and 29xx if you can
> > please.
> >
> > Alban Dani wrote:
> > > Hi there,
> > >
> > > we are using VTP. All the new Vlans are created on the
> 6509 which is the core.
> > >
> > > Here is the output of the show vlan on the cat2950:
> > >
> > > cat2950#sh vlan id 41
> > > VLAN Name Status Ports
> > > ---- -------------------------------- ---------
> -------------------------------
> > > 41 Stevens active Fa0/6,
> Fa0/35, Fa0/46, Gi0/1
> > > VLAN Type SAID MTU Parent RingNo BridgeNo Stp
> BrdgMode Trans1 Trans2
> > > ---- ----- ---------- ----- ------ ------ -------- ----
> -------- ------ ------
> > > 41 enet 100041 1500 - - - - -
> 0 0
> > > Remote SPAN VLAN
> > > ----------------
> > > Disabled
> > > Primary Secondary Type Ports
> > >
> > > cat2950#sh spanning-tree vlan 41
> > >
> > > VLAN0041
> > > Spanning tree enabled protocol ieee
> > > Root ID Priority 24617
> > > Address 0009.b799.a680
> > > Cost 28
> > > Port 49 (GigabitEthernet0/1)
> > > Hello Time 2 sec Max Age 20 sec Forward
> Delay 15 sec
> > >
> > > Bridge ID Priority 32809 (priority 32768 sys-id-ext 41)
> > > Address 000b.fd53.9540
> > > Hello Time 2 sec Max Age 20 sec Forward
> Delay 15 sec
> > > Aging Time 300
> > >
> > > Interface Role Sts Cost Prio.Nbr Type
> > > ---------------- ---- --- --------- --------
> --------------------------------
> > > Fa0/35 Desg FWD 19 128.35 P2p
> > > Fa0/46 Desg FWD 19 128.46 P2p
> > > Gi0/1 Root FWD 4 128.49 P2p
> > >
> > > Port Fa0/35 is trunked and Vlan 41 never makes it up this trunk
> > > unless as I have explained I put a port on cat2950 on
> that vlan and
> > > get some traffic in it.
> > >
> > >
> > > Thanks,
> > >
> > > Alban
> > >
> > > On Wed, 09 Feb 2005 10:58:15 +0200, Adrian Pirciu
> > > <adrian.pirciu at rdsnet.ro> wrote:
> > >
> > >>Hello
> > >>
> > >>Alban Dani wrote:
> > >>
> > >>>Hello Matthew,
> > >>>
> > >>>I also am having a very wierd issue with vlans and 2950-s.
> > >>>
> > >>>We are running pst+.
> > >>>We have a 6509 in the core and everytime we try to get a
> new vlan
> > >>>passed through a chain of switches( all connected via dot1q
> > >>>trunks) that has a 2950 in it, it does not work. The only
> > >>>workaround we found so far is to go to a port on the
> given 2950 ,
> > >>>set the port on the requried vlan and connect a machine
> to it and through some traffic.
> > >>>That makes the 2950 aware of that vlan.
> > >>
> > >>a 2950 will not pass traffic for the vlans not defined in
> its table.
> > >>When you put a port in a vlan, it automatically adds this vlan to
> > >>the config (sh vlan) and it starts forwarding traffic for
> that vlan
> > >>which explains the behaviour you describe.
> > >>
> > >>You can use VTP if you want to have a consistent vlan database
> > >>accross you network. Be careful though (there are some bat things
> > >>that can happen, read the documentation from
> www.cisco.com and they
> > >>are described).
> > >>
> > >>
> > >>
> > >>>If this was not enough, if the vlan in question does not see
> > >>>traffic for a couple of days the 2950 totally forgets about it.
> > >>
> > >>I am not aware of anything resembling this behaviour.
> Anybody ? Does
> > >>the vlan apper on "sh vlan" when this happens ?
> > >>
> > >>
> > >>>I am wondering if you ever found a solution to your
> problem and if
> > >>>so what was it?
> > >>>
> > >>>I have upgraded to the latest IOS but it did not help.
> > >>
> > >>i'm pretty sure it is not an IOS/switch related problem.
> > >>
> > >>
> > >>>thanks,
> > >>>
> > >>>Alban
> > >>>_______________________________________________
> > >>>cisco-nsp mailing list cisco-nsp at puck.nether.net
> > >>>https://puck.nether.net/mailman/listinfo/cisco-nsp
> > >>>archive at http://puck.nether.net/pipermail/cisco-nsp/
> > >>
> > >>--
> > >>adixor
> > >>
> >
> > --
> > adixor
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 09 Feb 2005 10:41:27 -0500
> > From: Luan Nguyen <luan.nguyen at mci.com>
> > Subject: Re: [c-nsp] VPN failover / load sharing using IOS?
> > To: Brian Feeny <signal at shreve.net>, Rodney Dunn <rodunn at cisco.com>
> > Cc: Cameron.Dry at didata.com.au, cisco-nsp at puck.nether.net
> > Message-ID: <008601c50ebd$d1b62470$89902799 at entserver01>
> > Content-Type: text/plain; charset=iso-8859-1
> >
> > I put a sample config for you to look at. My definition of
> a VPN is
> > the IPSEC transport mode( or tunnel) over the GRE. So if you have
> > dual T1 with their own address from different ISP, then you could
> > build 2 VPNs, one for each link. The LAN side - most of
> the time will
> > be 1918 address? Then just use EIGRP or static to create 2
> routes equal cost over the 2 GRE tunnels.
> > If you only have one host talking to one host on the LAN side, then
> > there will not be load sharing per-destination. Per packet
> would do
> > the job though. These are T1 so you don't need that object
> tracking
> > thing. If you only have one host to one host then maybe do policy
> > base routing base on the type of traffics so you could load
> share somewhat.
> >
> > crypto isakmp policy 1001
> >
> > encr 3des
> >
> > hash sha
> >
> > authentication pre-share
> >
> > group 2
> >
> > crypto isakmp key connection1 address 1.1.1.1
> >
> > crypto isakmp key connection2 address 2.2.2.2
> >
> > !
> >
> > crypto ipsec transform-set TRANS esp-3des esp-sha-hmac
> >
> > mode transport
> >
> > !
> >
> > crypto map CryptoMap1 local-address T1_1
> >
> > crypto map CryptoMap1 1024 ipsec-isakmp
> >
> > set peer 1.1.1.1
> >
> > set transform-set TRANS
> >
> > match address ACL_1
> >
> > !
> >
> > crypto map CryptoMap2 local-address T1_2
> >
> > crypto map CryptoMap2 1024 ipsec-isakmp
> >
> > set peer 2.2.2.2
> >
> > set transform-set TRANS
> >
> > match address ACL_2
> >
> > !
> >
> > interface Tunnel1
> >
> > description *To 2nd router - T1_1*
> >
> > bandwidth 1544
> >
> > ip unnumbered fa0/0 <--------Could use static ip like
> a.a.a.1 on one side
> > and a.a.a.2 on the other
> >
> > !*UNNUMBERED TO PRIVATE LAN*
> >
> > ip mtu 1440
> >
> > tunnel source X.X.X.X
> >
> > tunnel destination 1.1.1.1
> >
> > crypto map CryptoMap1
> >
> > !
> >
> > interface Tunnel2
> >
> > description *To 2nd router T1_2*
> >
> > bandwidth 1544
> >
> > ip unnumbered FastEthernet0/0
> >
> > !*UNNUMBERED TO PRIVATE LAN*
> >
> > ip mtu 1440
> >
> > tunnel source Y.Y.Y.Y
> >
> > tunnel destination 2.2.2.2
> >
> > crypto map CryptoMap2
> >
> > !
> >
> > interface WAN1
> >
> > ip address X.X.X.X 255.255.255.252
> >
> > description *WAN 1*
> >
> > no ip redirects
> >
> > no ip unreachables
> >
> > no ip proxy-arp
> >
> > duplex full
> >
> > speed 100
> >
> > crypto map CryptoMap1
> >
> > !
> >
> > interface WAN2
> >
> > ip address Y.Y.Y.Y 255.255.255.252
> >
> > description *WAN 2*
> >
> > no ip redirects
> >
> > no ip unreachables
> >
> > no ip proxy-arp
> >
> > duplex full
> >
> > speed 100
> >
> > crypto map CryptoMap2
> >
> > !
> >
> > interface FastEthernet0.0
> >
> > ip address Z.Z.Z.Z 255.255.255.0
> >
> > description *LAN 2*
> >
> > no ip redirects
> >
> > no ip unreachables
> >
> > no ip proxy-arp
> >
> > duplex full
> >
> > !
> >
> > ip access-list extended ACL_1
> >
> > permit gre host X.X.X.X host 1.1.1.1
> >
> > ip access-list extended ACL_2
> >
> > permit gre host Y.Y.Y.Y host 2.2.2.2
> >
> > !
> >
> > router eigrp 1
> >
> > passive-interface FastEthernet0/0
> >
> > network Z.Z.Z.0 0.0.0.255
> >
> > no auto-summary
> >
> > eigrp stub connected
> >
> > !
> >
> > ip route 1.1.1.1 255.255.255.255 WAN1_gateway_address
> >
> > Ip route 2.2.2.2 255.255.255.255 WAN_2_gateway address
> >
> > Hope that help.
> >
> > Luan
> >
> > ----- Original Message -----
> > From: "Brian Feeny" <signal at shreve.net>
> > To: "Rodney Dunn" <rodunn at cisco.com>
> > Cc: <cisco-nsp at puck.nether.net>; "Luan Nguyen"
> <luan.nguyen at mci.com>;
> > <Cameron.Dry at didata.com.au>
> > Sent: Wednesday, February 09, 2005 10:09 AM
> > Subject: Re: [c-nsp] VPN failover / load sharing using IOS?
> >
> > >
> > > I haven't even gotten that information back yet. Are you talking
> > > about the SAA object tracking stuff?
> > >
> > > Since their would be load sharing one link could go down and it
> > > should be ok. In other words rather than a standby circuit, both
> > > circuits should be live. But since after the GRE's are
> up and even
> > > EIGRP in place, the actual IPSEC SA represents a single
> > > source/destination pair (as far as the level that GRE and
> EIGRP are
> > > at), then that will create a single flow over only one
> > > link.......which is fine I suppose. I may do up a
> diagram to give a
> > > clearer picture of what I am trying to accomplish. I am
> pretty sure
> > > whatever route I go the 1700's will work ok for this application.
> > >
> > > Brian
> > >
> > > On Feb 9, 2005, at 7:07 AM, Rodney Dunn wrote:
> > >
> > > > What are your ISP connections?
> > > > HDLC, PPP, *net, ?
> > > >
> > > > I've done a couple of desigs leveraging HSRP with
> Object tracking
> > > > of the wan links for failover also.
> > > >
> > > > Rodney
> > > >
> > > > On Wed, Feb 09, 2005 at 12:18:40AM -0600, Brian Feeny wrote:
> > > >>
> > > >> Actually, your right. But really the vpn is
> establishing a single
> > > >> source host to a single destination host, since whats really
> > > >> riding on top of the GRE layer is the VPN itself.
> Like you say,
> > > >> per destination balancing sort of makes it not work very well.
> > > >>
> > > >> Too bad cisco doesn't allow you to just define two vpn's and
> > > >> treat the result as two equal paths, that would be a
> bit better.
> > > >>
> > > >> Brian
> > > >>
> > > >> On Feb 8, 2005, at 11:59 PM, Luan Nguyen wrote:
> > > >>
> > > >>> It would work just like that I think. The router
> would just do
> > > >>> per-destination load share wouldn't it - unless you only have
> > > >>> one host talking to one host? In our environment we have one
> > > >>> spoke with dual GRE tunnels to 2 hubs with equal
> cost. Yours is
> > > >>> a little different but it should work for load balancing just
> > > >>> like that.
> > > >>>
> > > >>> Luan
> > > >>>
> > > >>> -----Original Message-----
> > > >>> From: cisco-nsp-bounces at puck.nether.net
> > > >>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Brian
> > > >>> Feeny
> > > >>> Sent: Wednesday, February 09, 2005 12:33 AM
> > > >>> To: Rodney Dunn
> > > >>> Cc: Cameron.Dry at didata.com.au; cisco-nsp at puck.nether.net
> > > >>> Subject: Re: [c-nsp] VPN failover / load sharing using IOS?
> > > >>>
> > > >>>
> > > >>> Rodney,
> > > >>>
> > > >>> I will definitely look into OER. But if I had 2 GRE tunnels,
> > > >>> why can't I just point statics like in my example, for each
> > > >>> remote subnet down the tunnels? Wouldn't that load
> balance AND
> > > >>> work for failover?
> > > >>>
> > > >>> Thanks,
> > > >>>
> > > >>> Brian
> > > >>>
> > > >>> On Feb 8, 2005, at 11:20 PM, Rodney Dunn wrote:
> > > >>>
> > > >>>> There are really on two ways to do this:
> > > >>>>
> > > >>>> a) you announce some subset of routes down
> > > >>>> one gre tunnel from the headend and prefer
> > > >>>> them and the other subset over the backup tunnel
> > > >>>>
> > > >>>> that way if one tunnel goes away you will have failover.
> > > >>>> The drawback there is the load sharing isn't dynamic.
> > > >>>>
> > > >>>> The only way you can get dynamic loadsharing in this type of
> > > >>>> setup is OER.
> > > >>>>
> > > >>>> b) Do OER at the spoke side and let it load balance
> > > >>>> the traffic back towards the headend.
> > > >>>>
> > > >>>> They were going to put a sample of that in the OER
> deployment
> > > >>>> guide but I'm not sure they have gotten to it yet.
> > > >>>>
> > > >>>> http://www.cisco.com/go/oer
> > > >>>>
> > > >>>> Rodney
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On Tue, Feb 08, 2005 at 10:31:43PM -0600, Brian Feeny wrote:
> > > >>>>>
> > > >>>>> thanks, although that looks to be for sites with multiple
> > > >>>>> routers and multiple links. Each of these sites is
> only going
> > > >>>>> to have one router, that takes in 2 T1's. I don't
> think that
> > > >>>>> will work in that scenrio.
> > > >>>>>
> > > >>>>> Brian
> > > >>>>>
> > > >>>>> On Feb 8, 2005, at 10:07 PM,
> Cameron.Dry at didata.com.au wrote:
> > > >>>>>
> > > >>>>>> Check out:
> > > >>>>>>
> > > >>>>>> http://www.cisco.com/en/US/products/sw/iosswrel/ps5012/
> > > >>>>>> products_feature_
> > > >>>>>> guide09186a00800ed370.html
> > > >>>>>>
> > > >>>>>> Cameron
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> -----Original Message-----
> > > >>>>>> From: cisco-nsp-bounces at puck.nether.net
> > > >>>>>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> > > >>>>>> signal at shreve.net
> > > >>>>>> Sent: Wednesday, 9 February 2005 11:50 AM
> > > >>>>>> To: 'cisco-nsp'
> > > >>>>>> Subject: [c-nsp] VPN failover / load sharing using IOS?
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Has anyone done any type of VPN failover and/or load
> > > >>>>>> balancing using IOS?
> > > >>>>>>
> > > >>>>>> For example something like a 2 1700 routers, each
> with 2 T1
> > > >>>>>> cards in them, Each T1 card would be connected to
> a different
> > > >>>>>> ISP, each with its own IP space (no BGP). Either
> T1 would be
> > > >>>>>> able to go down, and the VPN could re-establish
> itself over
> > > >>>>>> the remaining T1. Both T1's would be load
> balanced over for
> > > >>>>>> VPN connectivity.
> > > >>>>>>
> > > >>>>>> Is it possible to establish 2 VPN's, 1 over each
> link, with
> > > >>>>>> the same source/destination private networks defined, and
> > > >>>>>> have the router load balance these and also work
> in failover?
> > > >>>>>>
> > > >>>>>> Another thought, which is kind of ugly (but maybe
> not), is 2
> > > >>>>>> GRE tunnels, and then dual static routes over the tunnels:
> > > >>>>>>
> > > >>>>>> Router 1 T1 #1 <----------------------- GRE Tunnel #1
> > > >>>>>> -------------------> Router 2 T1 #1
> > > >>>>>> Router 2 T1 #2 <------------------------ GRE Tunnel #2
> > > >>>>>> -------------------> Router 2 T1 #2
> > > >>>>>>
> > > >>>>>> ip route <insert vpn endpoint ip> 255.255.255.255
> Tunnel1 ip
> > > >>>>>> route <insert vpn endpoint ip> 255.255.255.255 Tunnel2
> > > >>>>>>
> > > >>>>>> Then establish the VPN on top of the above. I don't
> > > >>>>>> particular like the idea of building a tunnel on top of 2
> > > >>>>>> other tunnels, so if anyone has experience in
> doing this type
> > > >>>>>> of setup, please share what you used to do it.
> > > >>>>>>
> > > >>>>>> Brian
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Brian Feeny, CCIE #8036, CISSP Network Engineer ShreveNet
> > > >>>>>> Inc.
> > > >>>>>>
> > > >>>>>> _______________________________________________
> > > >>>>>> cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > >>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > >>>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> *************************************************************
> > > >>>>>> *****
> > > >>>>>> **
> > > >>>>>> *
> > > >>>>>> **
> > > >>>>>> *******
> > > >>>>>> - NOTICE FROM DIMENSION DATA AUSTRALIA This message is
> > > >>>>>> confidential, and may contain proprietary or legally
> > > >>>>>> privileged information. If you have received this
> email in
> > > >>>>>> error, please notify the sender and delete it immediately.
> > > >>>>>>
> > > >>>>>> Internet communications are not secure. You should
> scan this
> > > >>>>>> message and any attachments for viruses. Under no
> > > >>>>>> circumstances do we accept liability for any loss
> or damage
> > > >>>>>> which may result from your receipt of this message or any
> > > >>>>>> attachments.
> > > >>>>>>
> *************************************************************
> > > >>>>>> *****
> > > >>>>>> **
> > > >>>>>> *
> > > >>>>>> **
> > > >>>>>> *******
> > > >>>>>>
> > > >>>>>> _______________________________________________
> > > >>>>>> cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > >>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > >>>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > >>>>>>
> > > >>>>>
> > > >>>>> Brian Feeny, CCIE #8036, CISSP Network Engineer
> ShreveNet Inc.
> > > >>>>>
> > > >>>>> _______________________________________________
> > > >>>>> cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > >>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > >>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > >>>
> > > >>> _______________________________________________
> > > >>> cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > >>> https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > >>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > >>>
> > > >>>
> > >
> > > Brian Feeny, CCIE #8036, CISSP
> > > Network Engineer
> > > ShreveNet Inc.
> > >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Wed, 9 Feb 2005 11:10:12 -0500
> > From: Matthew Crocker <matthew at crocker.com>
> > Subject: Re: [c-nsp] Cisco 3550 maximum number of routable
> interfaces
> > limit?
> > To: "Adam Greene" <maillist at webjogger.net>
> > Cc: cisco-nsp at puck.nether.net
> > Message-ID: <961cc76a582262da43ae00e4e48fee56 at crocker.com>
> > Content-Type: text/plain; charset=US-ASCII; format=flowed
> >
> > We use a 3550 to aggregate our T1 traffic. We have a
> Seranoa WANPort
> > (IPeX) which terminates channelized DS-3s into 802.1q
> VLANs. We take
> > the GigE from the Seranoa and run it into a 3550. The 3550
> config has
> > a 'interface VLAN' for each T1 customer, with ip subnet and static
> > routes assigned. The 3550 is a member in our OSPF area 0 announcing
> > customer routes. We have about 30 'Interface vlan'
> configured right
> > now passing about 16mbps of traffic without any problems. CEF is
> > running but I heard after 8 interfaces everything is punted
> to process
> > switched. We are at 1% CPU so I'm not sure about that
> either. I plan
> > on adding another 100 or so interfaces to this box, hopefully it
> > doesn't melt on me
> >
> > -matt
> >
> > On Feb 9, 2005, at 8:43 AM, Adam Greene wrote:
> >
> > > This has been quite useful to me, too. We shied away from
> purchasing
> > > 3550's a while back because we were looking to put up to
> 256 SVI's
> > > on whatever layer 3 switch we got. We went with the
> Extreme Summit
> > > series instead
> > > (200-24 and 48si).
> > >
> > > However, it's sounding like even with 256 SVI's, if I keep the
> > > routing table small (for example, our Extremes only have about 50
> > > right now), we could still consider 3550's. In fact, since we may
> > > need to upgrade our
> > > Summit200-24 soon, this puts the 3550 back on the map for me.
> > >
> > > Anyone else doing lots of SVI's in an OSPF environment with
> > > relatively few routes?
> > >
> > > ----- Original Message -----
> > > From: "Marcel Lammerse" <lammerse at xs4all.nl>
> > > To: "cisco-nsp" <cisco-nsp at puck.nether.net>
> > > Sent: Tuesday, February 08, 2005 12:26 AM
> > > Subject: Re: [c-nsp] Cisco 3550 maximum number of routable
> > > interfaces limit?
> > >
> > >
> > >> Thanks all, I know a lot more abot 3550 performance now :-)
> > >>
> > >> Marcel
> > >>
> > >> On Feb 7, 2005, at 9:46 PM, Mark Boolootian wrote:
> > >>
> > >>>
> > >>>> show sdm prefer only shows you the current template
> and numbers
> > >>>> from the published tables. I'm more interested in
> tcam resources
> > >>>> actually used/available on the live switches.
> > >>>
> > >>> You and me both. Surely you know about 'show tcam...'.
> I would
> > >>> prefer an interface that allowed me to say 'show tcam
> statistics'
> > >>> providing a matrix of utilization stats (including
> stats on routes).
> > >>> _______________________________________________
> > >>> cisco-nsp mailing list cisco-nsp at puck.nether.net
> > >>> https://puck.nether.net/mailman/listinfo/cisco-nsp
> > >>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> > >>>
> > >>>
> > >>
> > >> _______________________________________________
> > >> cisco-nsp mailing list cisco-nsp at puck.nether.net
> > >> https://puck.nether.net/mailman/listinfo/cisco-nsp
> > >> archive at http://puck.nether.net/pipermail/cisco-nsp/
> > >> ---
> > >> [This e-mail was scanned for viruses by Webjogger's AntiVirus
> > >> Protection
> > > System]
> > >>
> > >>
> > >
> > > ---
> > > [This e-mail was scanned for viruses by Webjogger's AntiVirus
> > > Protection System]
> > >
> > > _______________________________________________
> > > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > >
> >
> > ------------------------------
> >
> > _______________________________________________
> > cisco-nsp mailing list
> > cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> >
> > End of cisco-nsp Digest, Vol 27, Issue 41
> > *****************************************
> >
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
UYARI/NOTIFICATION:
***************************************************************************
Bu e-posta ve ekleri sadece gonderilen adres sahiplerine aittir. Bu mesajin yanlislikla tarafiniza ulasmis olmasi halinde, lutfen gondericiye derhal bilgi veriniz ve mesaji sisteminizden siliniz. BORUSAN TELEKOM bu mesajin icerigi ve ekleri ile ilgili olarak hukuksal hicbir sorumluluk kabul etmez. Gonderen taraf hata veya unutmalardan sorumluluk kabul etmez.
The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed.If you received this message in error, please immediately notify the sender and delete it from your system.BORUSAN TELEKOM doesn't accept any legal responsibility for the contents and attachments of this message.The sender does not accept liability for any errors or omissions.
***************************************************************************
More information about the cisco-nsp
mailing list