Thank you for your response. You are correct, the DCU switches are layer 2 and the core switches are layer 3.

1. I could create an etherchannel, but would still want the traffic to flow per above.

2. The only reason I allov the core open to all vlans is that it makes configurations easier to manage. I let the core open and lock down each access switch to only permit the required vlans. If a new vlan needs to be added to a switch, I know that I only need apply the change to the access switch vs the access switch and both core switches.

3. I want to allow vlans 10,11,19,20,30-32 flow between the DCU switches because I have server farms sitting within these vlans which reside behind the DCU switches. VLANS 7 and 9 are simply used for mgmt and security, so their traffic only needs to flow back towards the core.

4. The only reason I want the aforementioned vlans to traverse the 20GB trunk is to reduce the number of hops on the network. This way a server on vlan 10 sitting behind DCU-01 can traverse the 20GB trunk and talk to another vlan 10 server sitting behind DCU-02 without going through the uplinks to the core.

Hi:

"1. I could create an etherchannel, but would still want the traffic to flow per above."

1. If you want 20G between DCU1 and 2, you must create the etherchannel, its not an option. Just clarifying...

"2. The only reason I allov the core open to all vlans is that it makes configurations easier to manage. I let the core open and lock down each access switch to only permit the required vlans. If a new vlan needs to be added to a switch, I know that I only need apply the change to the access switch vs the access switch and both core switches."

2. Im not sure I understand you. Do you mean that each access switch is carrying a separate set of vlans, ie DCU1-vlans 1-10 and DCU2-vlans 11-20? I don't think that's what you mean, but I just wan tot be sure. If so, you will not achieve L2 adjacency for those server vlans, which will impact network and application high availability. Moreover, if you add a new vlan on the access layer, you will have to also add it to the core layer. That core switch is routing between vlans and therefore a L3/routed SVI for that vlan must be configured on the core -- both cores, in fact, if you're running HSRP. You will also have to add the vlan to the STP domain at the core, if you want to rig the root bridge election for the vlan. So, either way, you will have to enter the core switches and do some configurations. Its also not a good practice to allow all vlans on one end and prune on the other end of the trunk.

"3. I want to allow vlans 10,11,19,20,30-32 flow between the DCU switches because I have server farms sitting within these vlans which reside behind the DCU switches. VLANS 7 and 9 are simply used for mgmt and security, so their traffic only needs to flow back towards the core."

OK, but you are allowing vlans 7 and 9 also, which is something you say you don;t want. That was the point I was making.

"4. The only reason I want the aforementioned vlans to traverse the 20GB trunk is to reduce the number of hops on the network. This way a server on vlan 10 sitting behind DCU-01 can traverse the 20GB trunk and talk to another vlan 10 server sitting behind DCU-02 without going through the uplinks to the core."

OK. So, what you're saying is that vlans 10,11,19,20,30, 31 and 32 are server vlans and you want to allow them on all trunks -- uplinks and the interswitch link? If so, that's fine.

I will tell you this, though, now that I know this is a server farm:

You are correct in wanting to keep L2 traffic off the core. The problem with the loop-free U topology, though, is that it will not scale well if you decide to deploy service modules, like the FWSM firewall or CSM for load balancing. I can get into the reasons for that later, if you want. In that case, the inverted U is better, but will extend the switch domain to the core.

HTH

If so, please rate my post.

Victor

Funny you mention the modules...I do have FWSM's as well as CSM modules on their way...would you suggest simply allowing the traffic to flow through the core switches if that is the case?

I see. So, I would:

1. Seriously reconsider the loop-free topology and look into a looped triangle topology (each access switch dual-homed to each core switch). This will provide L2 adjacency for your servers, load balancing, by making each routed layer switch the STP and HSRP primary for odd and even numbered vlans, respectively, and will also remove the possibility of black-holing your traffic and causing a "split brain" with your service modules.

2. Discuss with your chain of command the possibility of adding a routed distribution layer and getting rid of the collapsed core. Now, that is not absolutely necessary, and of course this is a considerable investment, but it scales much better and lays the foundation for a establishing a serious data center that has flexibility, scalability and high availability built in. I don't know how serious your organization is about that. And I also don't know the number of servers in your farm. Furthermore, if you are using this server farm core to route your campus traffic, too, than that would be another reason to get rid of the collapsed core.

Remember, typically, a core layer is supposed to do nothing more than HIGH speed L3/CEF switching between your different network modules (campus, server farm and edge distribution). The core is not the place to be implementing policy routing, traffic filtering, or service module-type activities, like firewalling, load balancing or SSL offloading. That is what a distribution layer is for.

HTH

Rate my post if it does.

Thanks

Victor

I see. So, I would:

1. Seriously reconsider the loop-free topology and look into a looped triangle topology (each access switch dual-homed to each core switch). This will provide L2 adjacency for your servers, load balancing, by making each routed layer switch the STP and HSRP primary for odd and even numbered vlans, respectively, and will also remove the possibility of black-holing your traffic and causing a "split brain" with your service modules.

2. Discuss with your chain of command the possibility of adding a routed distribution layer and getting rid of the collapsed core. Now, that is not absolutely necessary, and of course this is a considerable investment, but it scales much better and lays the foundation for a establishing a serious data center that has flexibility, scalability and high availability built in. I don't know how serious your organization is about that. And I also don't know the number of servers in your farm. Furthermore, if you are using this server farm core to route your campus traffic, too, than that would be another reason to get rid of the collapsed core.

Remember, typically, a core layer is supposed to do nothing more than HIGH speed L3/CEF switching between your different network modules (campus, server farm and edge distribution). The core is not the place to be implementing policy routing, traffic filtering, or service module-type activities, like firewalling, load balancing or SSL offloading. That is what a distribution layer is for.

HTH

Rate my post if it does.

Thanks

Victor