Solved: Design question, 6500 core (redundant uplinks to access)

l.mourits · ‎09-25-2007

Hi,

Just to verify my current thinking. If I have two catalyst 6500s with supervisor engine (PFC2/MSFC2) with a Gigabit Etherchannel between them, and all access switches connecting to both switches, or cascaded (where the first and last connect to the core switches).

Several vlans, spread out on all access switches. In this design, what is the recommended setup?

My current thinking is Gibit Etherchannel in trunk mode, configure one of the 6500s as root for one half of the vlans, and the other 6500 as root for the other half of the vlans, have the MSFC configured for HSRP, where they are active for the same vlans as the 6500 is root for.

Is this still the recommended design, or are there better options today?

Thanks in advance,

Leo

paul.matthews · ‎09-25-2007

That's pretty much what I would do - as Jon suggests one switch for odd, one for even and that is SPT root and HSRP active. For added elegance, tweak your routing protocol such that the active root/HSRP switch is the preferred route for incoming traffic!

If you can, manually prune the VLANS where they are not needed - it tidies the potential network for that VLAN and reduces the issues if you have spanning tree problems.

Also avoid using VLAN1 if you caan, just use it for control protocols, and block it from trunks.

Use UDLD if you have fibre links.

if available use RSTP. Configure all user ports as portfast, and use BPDU guard.

If you can use port security.

View solution in original post

Jon Marshall · ‎09-25-2007

Hi Leo

Sounds perfectly acceptable to me. This is still a common setup although some people argue that you should have STP root and HSRP active on smae switch as this simplifies config/troubleshooting. To be honest if you have odds on one and evens on another i don't think it complicates things that much.

Gigabit etherchannel trunk between 2 6500's.

As for access-layer switches, if you need to span vlans across multiple switches then yes use L2 trunks again. If you can contain a vlan within an access-layer switch you may want to consider a L3 access-layer although you don't say whether this is a campus/building design or a data centre design.

L3 in access-layer is fine for building/campus maybe not so good for datacentre.

Main advantage of L3 access-layer is each access-layer switch can be dualhoned to both 6500's and they are seen by your routing protocol as equal cost paths. In the event of a failure of one link there is also instantaneous packet forwarding as both paths were in use anyway. Key thing is you have eliminated STP from access-layer.

HTH

Jon

paul.matthews · ‎09-25-2007

That's pretty much what I would do - as Jon suggests one switch for odd, one for even and that is SPT root and HSRP active. For added elegance, tweak your routing protocol such that the active root/HSRP switch is the preferred route for incoming traffic!

If you can, manually prune the VLANS where they are not needed - it tidies the potential network for that VLAN and reduces the issues if you have spanning tree problems.

Also avoid using VLAN1 if you caan, just use it for control protocols, and block it from trunks.

Use UDLD if you have fibre links.

if available use RSTP. Configure all user ports as portfast, and use BPDU guard.

If you can use port security.

l.mourits · ‎09-25-2007

Paul/Jon,

Thanks for swift replies. The main reason for asking was that this is actually an existing network what I want to re-design, but that rose some discussion.

This is a campus network, several buildings with vlans spanning over differet buildings. I am planning for a complete network upgrade where we replace the access-layer with L3 switches and then limit the vlans per building (so get rid of the vlan spans and no STP recalculations), but that is on the long term.

Short term there are strange data paths right now, as there is no trunk between the two 6500s (I did not do original design ;-)) but just a vlan that just hold the link in between the two switches. As you will be able to conclude this only leads to a situation where STP instances for all other vlans have all ports in forwarding but then when routing takes place it sometimes traverses via cascaded links. Anyway, long story short, far from ideal and want to get rid of this setup.

Short term improvement proposed is the design I described in my initial question, which still seems to be valid when access-layer is L2 and vlans span across multiple switches/buildings (if I understand it correctly). UDLD is in place on all links allready, as well as backbonefast, uplinkfast, portfast and BPDU guard configurations but need to be checked/tuned as today this network seems a mess.

Only the vlans are running HSRP, there is a vlan which holds the wan routers running EIGRP, this vlan has no HSRP so both 6500s learn all routes and convergence should be pretty quick in case of link failure.

Again, thanks to both for quick reply, I will get you some ratings :-)

Leo

paul.matthews · ‎09-25-2007

Ah! That familiar position - a network that was not designed, but evolved!

You mention eigrp - are the core switches involved? If so you can control where routing often goes by using passive-interface for the links you do not want routing on - in a campus network I would normally put "user" vlans into passive for a few reasons - it controls where traffic will be forwarded, it improves security (nop one can join your routing if you are passive) and with some RPs the use of multiple VLANs can get round split horizon rules and lead to loops.

l.mourits · ‎09-26-2007

Yep, that position, LOL :-)

I agree on the passive interfaces, this is part of my plans allready ;-) I will have just one vlan for wan handoff and routing protocol exchange, all other vlans will be passive for eigrp on the two core switches.

But good that you mentioned it, others may learn from this as well.

Joseph W. Doherty · ‎09-25-2007

You might also consider using GLBP instead of HSRP and restricting VLANs to just the access switch (or cascaded switches) that connect to both 6500s.

You might want to review the following SRNDs for current and projected design thinking.

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns656/c649/cdccont_0900aecd804ab672.pdf

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns656/c649/cdccont_0900aecd804ab67d.pdf

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns656/c649/cdccont_0900aecd804ab689.pdf

Others can be found here: http://www.cisco.com/en/US/netsol/ns656/networking_solutions_design_guidances_list.html