Solved: 3750 stack connectivity suggestion required between core and access

gautamzone · ‎08-27-2009

Dear Friends,

We have a stack of 3750-12S switches working at the core / aggregation layer and we have a stack of 3750-24PS-S (with 2 SFP slots each) switches working as an access switch stack in 3 floors.

We have etherchannels from core to the access layer with just 2 connections per stack. Now, we have got additional SFP's

and we need to utilize them.

The current core-access diagram is depicted in the enclosed visio.

We have atleast 2 additional SFP's per stack.

Do you have any recommendation on how do we utilize the additional SFP's?

Can we just keep adding these new ports into the current port-channels between access and core?

Looking forward to your kind recommendation.

Thanks a lot

Gautam

Joseph W. Doherty · ‎08-28-2009

Re: "Can you tell me what it means by port-channel hash? Do you have any pointers to this. "

http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtml#catalyst

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_50_se/configuration/guide/swethchl.html#wp1275731

Re: physical link connections between stacks

Yes, if you were to use all 6 gig ports, that would be fine. However, if you really needed 6 gig, you might start to consider the need to move to 10 gig links. Again, especially with non-3750G switches, dual gig links are probably sufficient (also for a user access edge).

e.g.

Switch 1 Port 1 -> Core 1

Switch 1 Port 2 ->

Switch 2 Port 1 ->

Switch 2 Port 2 ->

Switch 3 Port 1 ->

Switch 3 Port 2 -> Core 2

If you find you need more, and you want to stay symetric, you might jump to a 4 port channel.

e.g.

Switch 1 Port 1 -> Core 1

Switch 1 Port 2 ->

Switch 2 Port 1 -> Core 1

Switch 2 Port 2 -> Core 2

Switch 3 Port 1 ->

Switch 3 Port 2 -> Core 2

(NB: BTW, believe hash algorithms work best [distribution] with binary number of channels, that would be 2, 4 or 8.)

If the access stack was for servers, especially if using gig ports, we might want to do things differently.

For a server stack, you might consider, if possible, adding 3750G server switches to your core stack. The major disadvantage of doing this, you'll be unable to use the special SDM template unique to the fiber only 3750 switches.

Or, instead stacking the server 3750Gs, you might have each one as a standalone switch with dual or quad port channel to the core stack. The reason for this, Stackwise, unlike Stackwise+, places all traffic on the stack ring and also uses source deletion. I.e., in a very busy stack, the ring might be somewhat of a bottleneck, and assuming most traffic isn't between servers (excluding backups?), you might obtain better performance. (BTW, if you don't stack the 3750Gs for servers, you could then use the 3560Gs.) (Also BTW, the stack being a bottleneck with Stackwise would like be less of an issue with fewer stack members and more of an issue with more stack members. Improvements with Stackwise+ mitigate but not eliminate the problem of using a ring. For maximum performance, a true fabric would be best. It's really a question of matching performance to the requirement.)

PS:

From your diagram, there's a single 3750 switch with just one uplink for servers? If correct, you should also create a dual channel to the core. (You might consider other options, as noted above.)

PPS:

Something I only touched upon, if you route on the edge, especially for dual channels, you might keep them distinct and equal cost route across them instead of using port channels.

View solution in original post

Joseph W. Doherty · ‎08-27-2009

If your edge stacks are non -G 3750s, you might not need to really bother with more than two gig ports. How does usage currently look on the uplinks now?

I would insure, though, that the port channels cross stack members on both stacks (to insure a single stack member failure doesn't break connectivity).

I would also insure port channel hash is most appropriate for your usage.

If you do find that uplink usage needs more bandwidth, then you might add ports to the same port channel, to provide the extra bandwidth.

Also depending on your traffic flows, if data crosses subnets on the same edge stack, running routing on the stack at would keep this traffic from needing to transit up/down the uplinks.

Mohamed Sobair · ‎08-27-2009

Hi Gautam,

Could you please attach the drawing in Word Document format?

Thanks,

Mohamed

gautamzone · ‎08-28-2009

Dear Mohamed,

Please find enclosed the diagram in a word document.

Joseph: Thanks a lot for your response.

This is a new site and hence the users have not yet shifted in. However, i was trying to utilize the client SFP's here.

Can you tell me what it means by port-channel hash? Do you have any pointers to this.

So, do you suggest connecting a 3 access switch stack to the core stack as follows:

Switch 1 Port 1 -> Core 1

Switch 1 Port 2 -> Core 2

Switch 2 Port 1 -> Core 1

Switch 2 Port 2 -> Core 2

Switch 3 Port 1 -> Core 1

Switch 3 Port 2 -> Core 2

I have chosen this based on two SFP's per access switch

Joseph W. Doherty · ‎08-28-2009

Re: "Can you tell me what it means by port-channel hash? Do you have any pointers to this. "

http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtml#catalyst

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_50_se/configuration/guide/swethchl.html#wp1275731

Re: physical link connections between stacks

Yes, if you were to use all 6 gig ports, that would be fine. However, if you really needed 6 gig, you might start to consider the need to move to 10 gig links. Again, especially with non-3750G switches, dual gig links are probably sufficient (also for a user access edge).

e.g.

Switch 1 Port 1 -> Core 1

Switch 1 Port 2 ->

Switch 2 Port 1 ->

Switch 2 Port 2 ->

Switch 3 Port 1 ->

Switch 3 Port 2 -> Core 2

If you find you need more, and you want to stay symetric, you might jump to a 4 port channel.

e.g.

Switch 1 Port 1 -> Core 1

Switch 1 Port 2 ->

Switch 2 Port 1 -> Core 1

Switch 2 Port 2 -> Core 2

Switch 3 Port 1 ->

Switch 3 Port 2 -> Core 2

(NB: BTW, believe hash algorithms work best [distribution] with binary number of channels, that would be 2, 4 or 8.)

If the access stack was for servers, especially if using gig ports, we might want to do things differently.

For a server stack, you might consider, if possible, adding 3750G server switches to your core stack. The major disadvantage of doing this, you'll be unable to use the special SDM template unique to the fiber only 3750 switches.

Or, instead stacking the server 3750Gs, you might have each one as a standalone switch with dual or quad port channel to the core stack. The reason for this, Stackwise, unlike Stackwise+, places all traffic on the stack ring and also uses source deletion. I.e., in a very busy stack, the ring might be somewhat of a bottleneck, and assuming most traffic isn't between servers (excluding backups?), you might obtain better performance. (BTW, if you don't stack the 3750Gs for servers, you could then use the 3560Gs.) (Also BTW, the stack being a bottleneck with Stackwise would like be less of an issue with fewer stack members and more of an issue with more stack members. Improvements with Stackwise+ mitigate but not eliminate the problem of using a ring. For maximum performance, a true fabric would be best. It's really a question of matching performance to the requirement.)

PS:

From your diagram, there's a single 3750 switch with just one uplink for servers? If correct, you should also create a dual channel to the core. (You might consider other options, as noted above.)

PPS:

Something I only touched upon, if you route on the edge, especially for dual channels, you might keep them distinct and equal cost route across them instead of using port channels.

gautamzone · ‎08-28-2009

Thanks a lot Joseph. That was very helpful

Joseph W. Doherty · ‎08-28-2009

You're certainly welcome.

Hope you saw my whole post because it looks like you rated while I was making a few edits and adding a couple of postscripts.