[c-nsp] Re: cisco-nsp Digest, Vol 27, Issue 41
Alban Dani
albcisco at gmail.com
Thu Feb 10 09:52:41 EST 2005
Hi,
I agree with your analysis.
The question that remains though is why the 6500 does not "un-prune"
the new vlan when
we put a port on that vlan in the switch that connects to the 2950 ?
It seems like the 2950 is not forwarding the "request" for the new
vlan down to the 6500.
Thanks,
Alban
On Thu, 10 Feb 2005 10:31:07 +0200, Adrian Pirciu
<adrian.pirciu at rdsnet.ro> wrote:
> Hi.
>
> I would disable VTP Pruning. It may be a good idea but sometimes it
> can bring problems like this one (basically, if you create a new vlan
> on the server but there are no ports in that vlan somewhere beyond the
> 2950, the 6500 will prune the vlan and not forward it to the 2950,
> thinking it is not needed there). As it can be seen, pruning is
> enabled and some vlans (5,8,76) are pruned. This can explain that when
> you are putting a port in the vlan (on the 2950) the 6500 "un-prunes"
> the vlan toward the 2950.
>
>
> Alban Dani wrote:
> > 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 pck.nether.neut <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/
>
> --
> adixor
>
More information about the cisco-nsp
mailing list