Switch Design Input

david.santel · ‎04-09-2008

I have questions about the design of our companys switch fabric. We are questioning the design of the Medical IDF. The network is currently setup as in the attached Viso drawing.

1. Would it not be better to have a trunk going to each data switch and trunk between the two data switches?

Same with the 2 POE switches. Removing the trunk between the data and voice switch?

2. Also, isn't better to isolate the data and voice traffic?

Any suggestions?

Edison Ortiz · ‎04-09-2008

Based on the diagram, it seems you have dedicated switches for data (PCs) and for voice (IP Phones). Is that correct?

If so, you are wasting a lot of ports. You could've connected the phones to the switch and the PCs to the phone data ports. At the switch, you could've configured the port to accept both connections and both connections would go to separate Vlans.

Inter-switch links will have to be trunked as the switches will carry multiple Vlans (addressing question 1) and per the configuration I mentioned above both voice and data will ride on separate vlans (addressing question 2).

The configuration is rather simple:

david.santel · ‎04-09-2008

What you see in the diagram is how it is setup. It was setup that way before I got here. Yes we have 2 switches for data and 2 switches for Voip in every IDF. At this point I think its a bad design to have the data switches trunk into the data switches. I am going to to run a trunk to each data switch and a trunk between the data switches. Same for Voip switches. This way if a trunk fails the voice frames wont traverse through the data switches. Do you think this is a better solution to the way it is setup now.

david.santel · ‎04-09-2008

Correction: I meant to say...

At this point I think its a bad design to have the data switches trunk into the voice switches.

Edison Ortiz · ‎04-09-2008

Just to be clear, I believe we are using different definition for the word trunk.

In the Cisco world, trunk on a link means you are carrying multiple Vlans. I've seen others calling trunk when you have multiple inter-switch links for bandwidth aggregation.

I did not address etherchanneling (that's what's called in the Cisco world) in your post.

I see you have a problem with traffic from the data devices traversing your VoIP dedicated switches, so you rather have the data be down instead of traversing your VoIP switches in case they lose the link ? Hmm...

Again, I recommend using the same switches for both data and voice and the configuration I recommended in the switchports. That's how is done :)

__

Edison.

david.santel · ‎04-09-2008

This question is addressing the physical layout of our layer 2 infrastructure. Of course we are using seperate vlans for data and voice. Also etherchanneling is not really needed to address this question. I am looking for best practices advice. Is it better to have the 2 data switches and voice switches trunking back to the core. Or should I just leave it the way it is setup in the visio drawing.

Thanks for the advice.

Edison Ortiz · ‎04-09-2008

The physical layout belongs to layer1 and the Visio does not depict the layer2 information.

As for the layer1 information provided in the Visio, I don't see a problem with it. You have redundancy built-in from the data and voip switches back to the core. If the link from the data switches and/or the voip switches to the Core were to be broken, they can use each other as transit switches. Do you see anything wrong with that?

Again, you bring the word trunk yet I don't see where you are carrying multiple Vlans from the IDF back to the Core, therefore - I'm not even sure you are 'trunking' from the switches based on the Visio diagram.

You just provided a basic layer1 topology of your network. There isn't any layer2 or layer3 information to make any additional comments/suggestions on how things should be done.

david.santel · ‎04-09-2008

Also I am saying to have a trunk on each switch and trunk between the switches. This way we have the same redundancy without ever having to trunk through our dedicated voip switches.

lamav · ‎04-09-2008

David:

Is the 4507 doing all the inter-vlan routing? Maybe it's a good idea to provide some information regarding vlans and routing methodology.

Victor

david.santel · ‎04-09-2008

Yes the 4507 is doing all the inter-vlan routing. 1 Vlan for voice and 1 vlan for data going out the dot1q trunk.

Joseph W. Doherty · ‎04-09-2008

"Any suggestions?"

Replace the dual copper Etherchannel(?) between the "bottom" data and voice switch with single copper link. (Provides little benefit.)

(Optional) Add new copper link between "top" data and voice switches. Configure SPF weights so that this new link is preferred over "bottom" link. (This to avoid one extra switch hop if an uplink link fails.)

Insure QoS on all inter switch links provide priority for voice traffic.

If not already, dual links between data switches should be Etherchannel. Could also be done for dual data uplinks.

PS:

Analysis of the current design:

What's a little curious is selection of the 3560s. We see different models for data, 3560G, and voice, 3560 with POE. If routing is not used, one would think a L2 switch would be more cost effective. If future (edge) routing or other 3560 series features are desired, a stack of different 3750 models, perhaps, might have been a better choice.

The choice of using separate data and voice devices to backup the other, appears reasonable to minimize the number of uplinks. However, as noted above, QoS should be in place to guarantee voice is not delayed by data traffic if it must share a link with the data traffic. (I assume PVST is implemented such that voice normally uses just the voice uplinks and data the data uplinks.)

The use of dual links between the "bottom" data and voice switches provides almost no benefit. The only benefit would be if both the primary path failed and the individual port carrying the interswitch backup failed.

You can run links from your 4507 to each switch. This assumes you have the fiber runs in place and the extra 4507 fiber ports and SPFs for the 3560s. Keeping similar to what you have now, you need 3 more runs per IDF. One for the second voice switch and two for the second data switch. Likely all local IDF traffic, data or voice, will transverse the 4507 (keep in mind 4500's slot bandwidth capacity). Depending how the data link uplinks are connected to the 4507, you may still need a backup path somewhere in the IDF, also especially true for the voice switches if they continue to only have one uplink.

david.santel · ‎04-09-2008

Thanks Joe for your reply. We are using port-channel to the 1st data switch using SMF. Dual trunks to second data. Do you think its necessary for us to use port-channel as the uplink to the 4507. Its a hospital and mostly admin people.

I think a good design in this instance would be to seperate the data and voice switches. Each switch 2 data/2 voice having its own trunk back to the 4507 and a fiber link connectin data to data/voice to voice.

Am I wrong in the above thinking?

Joseph W. Doherty · ‎04-09-2008

Nothing wrong in your thinking, but you'll likely need to use some extra fiber links to do as you wish. Currently you have 3, but even one to each switch increases the count to 4. This avoids the need for QoS, since data is isolated from voice, during failovers, but besides the extra fiber run, you might lose a bit of uplink bandwidth to the data side (two distinct individual links might not perform as well as the current dual channel), and all inter switch IDF traffic, if any, transit the 4507.

One fiber to each switch is fine for the voice side, but on the data side you have 3560Gs. If you have data hosts using gig, you might want to provide at least a 2 gig uplink, which you now have on the one data switch. Doing this for both data switches, you would need 6 fiber links vs. the current 3.

PS:

If the dual links between the data switches are not channeled, you're losing advantage of the additional bandwidth if the second remains within a SPF blocked state.