Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Redundant Core switch: EIGRP Peering and Best practices


One of our clients have a 6509E switch to which 15 edge switches are connected via trunk links.This 6509 is connected to a 3620 WAN router to which 20 remote sites connect via Frame relay and ISDN. The connection of the 6509E to the WAN 3620 is via Vlan 2.Now EIGRP is the routing protocol used throughout (across the WAN also.).Now we have to introduce a new core switch in to the Network (for redundancy). The plan is to have a layer 2 etherchannel between the two core switches. The WAN router has just one Fast ethernet and this has to be given to two Cores. So we plan to introduce a Layer 2 switch in between. Also we would like to have a network in between the cores and only this network will be allowed on the etherchannel. All the interfaces (including the Vlan interfaces) would be made passive EXCEPT for the ones connecting the two cores (etherchannel) and the one connecting the cores to the WAN router.

We want core1 to peer with core2 and both cores should peer with the WAN router. If we do as in above paragraph, will the cores peer with each other more than once, since hellos will be seen through both the etherchannel Vlan and also Vlan connecting the cores to the WAN router? And assuming it does, will there be any issues?

Could someone please explain the best practises for the above scenario.

Thanks in advance



Hall of Fame Super Blue

Re: Redundant Core switch: EIGRP Peering and Best practices

Hi Sonu

There are a number of issues here.

1) Is the 6509E responsible for any inter-vlan routing for vlans on the edge switches ?. If so you would want to run HSRP/GLBP between the 2 6500's for redundancy and as such you would need to allow this vlan traffic across your layer 2 etherchannel as well.

2) More importantly the key problem with your proposal is that you have introduced another single point of failure with the L2 switch between the 6500's and the WAN router. I'm not sure what benefit you would get. If you lose that L2 switch you have lost all WAN connectivity.

So your existing 6509E switch - does it have one supervisor or dual supervisors. In order of preference i would

1) Upgrade your Wan router to have 2 fast ethernet connections. Connect one to one of the 6500 switches and one to the other. Configure the connections as L3 links so from the WAN router there are 2 equal cost paths to all the 6500 vlans.

2) If you have dual sups in your 6500's just connect the WAN router into one of the 6500's. Yes if that switch goes you have lost Wan connectivity but it will be far less likely to go than a standalone L2 switch.

3) If your 6500 switches only have single sups then yes you could insert a switch in between but if you connect the 6500's with a L2 trunk then you don't really need it unless you are factoring in downtime on the 6500's ie. by using a L2 switch you can take down either of the 6500 switches and still have Wan connectivity.

You will have no issues with the EIGRP peerings using your above solution but as you asked for best practices thought it might be useful to point out the redundancy issues. Yes, make all vlan interfaces passive other than the peering vlan interfaces but again i would ask what you are doing about HSRP etc.

Perhaps if you came back with more details on the topology etc. we could help further.


New Member

Re: Redundant Core switch: EIGRP Peering and Best practices

Thank you Jon.

In fact we have 20 Vlans and the cores will be using routing between the Vlans. We will also be using HSRP with 10 Vlans active in core-1 and the rest in core-2.Its just that i forgot to mention it.

There will be dual uplinks comming from edge switches, one uplink to core1 and the other to core2. Core1 will be the primary root of spanning tree for 10 vlans and core2 for the other.Secondary roots will also be configured.

All the networks will be advertised via EIGRP on both cores. The Layer 2 etherchannel will have a Vlan and only this Vlan would be allowed across it. This Vlan interface will also be advertised in EIGRP. I am assuming thatEIGRP will work fine as it relies on multicast hellos.In short we are planning to have a "hop" ie a network in between the core switches. I am thinking in this way because the environment is "routed". Only the edge switches are at Layer 2.

Regarding the Layer 2 switch, i agreee its a single point of failure.This will be addressed in the future.

I am also concerned about the core switch peering. Will there be any issues if they peer more than once?

Thanks a lot.



Hall of Fame Super Blue

Re: Redundant Core switch: EIGRP Peering and Best practices


If the L2 etherchannel connecting your 6500's only allows one vlan how will HSRP work. Are you planning to use the access-layer uplinks to pass HSRP between the 2 6500's because that is what will happen.

What you could do is allow all vlan traffic across the L2 etherchannel but make them passive in EIGRP. That is one way we have done this on our 6500's. Create a vlan specifically for EIGRP peering between the 2 6500 switches and then make all the other vlan interfaces passive under EIGRP.

Thinking again about your EIGRP i haven't used this setup before so to give a definitive answer i would need to lab it up. But what you can do is simply make vlan 2 passive on the L2 etherchannel link. If you use a vlan specifically for EIGRP peering as mentioned above you can make all the others passive. You still allow them across the L2 etherchannel and so you still have redundancy.



Re: Redundant Core switch: EIGRP Peering and Best practices


Had the same design questions in 2004 when we went dual cores in our main campuses, and here is what worked best for us.

1) Dual home each closet and only use subnet per closet. Do not span vlans across multiple switches unless they are 3750 stackwise, and don't daisy chain 3550s.

2) Build V's and not Triangles to the edge. This means your HSRP/GLBP hellos flow down through the closet and you don't have the closet vlans trunked between the cores. Doing this removes any STP loops in the network and increases stabilty. You still want to run Rapid STP as a safety net just in case.

3) Use GLBP instead of HSRP. Simplifies your STP root placement and gets you out of the "even vlans and STP root goes right, odd vlans and STP root goes left" thing. GLBP is Active/Active and leverages your 6509 investment equally with less work on your part.

4) Build a L3 PtP/30 Etherchannel between your 6509 with all Supervisor ports. You'll want to count on this link being always up for deterministic convergence

5) Passive default all your Eigrp peering points, except your PtoP links.

6) Connect your WAN to both 6509 with PtoP/30. Make sure and double check the cost. You want the Core to Core traffic to traverse the L3 Etherchannel and not use the WAN router as a transit.

These are pretty good guides that explains most of this in greater detail.


New Member

Re: Redundant Core switch: EIGRP Peering and Best practices

Hi Dvr0,

I was really interested in your response and I wanted to look at the guides but Cisco must have moved them. Can you post a link to the new location or let us know what they were?



New Member

Re: Redundant Core switch: EIGRP Peering and Best practices

Thank you very much!!!