switch product choice, selection based on feature requirements

Answered Question

Dear collegues,


i am looking for linksys switches for a while. and i normally work with cisco 3750 and 6500 type of series.


but now i want to realise these functionalities in a linksys/cisco smb type of switch


- stack a switch with two units

- lacp/lag a trunked portchannel with two ports with one port in each switch


and ofcource have the abiliti to turn off a switch if needed / recover form a power failure in one powergroup. (or ofcource a unit failure) without downtime.


assumption are then that a stack shares all resources like a cisco 3750 stack would.


when i read the cheat sheet the  SGE2000, SGE2010 are stackable, but can they do the same job as a 3750 would?


i read some strange things on the forums with creating lacp trunked ports if that allready is giving a struggle i have a hardtime assuming it would work also with a lacp in a stacked switch with one cable in each unit.


anybody have experiance with this?

what model would i need?

Thanks in advance


Soul

Correct Answer by alissitz about 7 years 6 months ago

Cool, I did not want to waste anyone's time by going off on a tangent or covering info that is not requested.


Soul, if I can summarize my thoughts on this it is simply that the small business series switches are just that ... positioned and made for small businesses.  Can you make them work elsewhere?  Sure you can!  I believe in you!


This series of switches are not Cisco switches ... not the same thing and not meant to be.  Expect some limitations  when you position and sell these into high end customers or enterprises.


Cisco switches have awesome capabilities, features, and most any tweak you can think of.  They can get you into or out of most any network problem you face ... and can provide a solution in even very diverse environments.  I do not have to tell you this!  ;-)   The small business series does not have everything that Cisco does, and this is fine, they work very well too, but they are not Cisco switches.


I hope this is not too confusing ...


I cannot comment on the other posts where people have had trouble with the switches; I have not participated in the other posts.


If you can test these, I would think that this testing effort would go far.  You might find these switches to be a perfect fit for your customers, and help you win and maintain customer satisfaction.


As you mention in your last statement, this sounds right.  You can grow as needed, and move into the right product.


Kindest regards,


Andrew


PS - I like the web site!  ;-)  Very cool.

Correct Answer by alissitz about 7 years 6 months ago

Hello,


A couple of thoughts, forgive this if it is too rudimentary.


A LAG is going to offer load balancing, greater throughput and redundancy.  This is your best bet. Spanning tree will see these LAGs as a single link and run spanning tree across them as one.


If you have uplinks to different distribution layer switches, for example multiple LAGs going to different distribution layer switches, then running rapid or MSTP is a must.  Rapid or MSTP can understand an alternate link (the other link or the other LAG), and transition over to it very quickly; normally within a second.


LAG to a server - it should work, after all, the switches only knows what they know and learn from the far side.  Meaning, that the switches will see the server as a single instance, a LAG.  Assuming the server can function within the specs, there should be no problem.


In this configuration, I assume the server will have 'one' interface as well, with both interfaces in a LAG and appearing as one.


Can you test this first before going into production?  Will you have a maintenance window?  Can you also perform some tests such as pulling a cable out in the middle of a file transfer, shutting an interface, turning off a switch, etc ...?


I cannot speak for Christopher, however, it would be very hard for us to offer some guarantee within this forum except to say that the switches run standards based LACP.  LACP will run between the two devices and keep a misconfig from occurring.  If LACP does not agree, then the etherchannel will not come up.


As mentioned, running the two interfaces from the server in a failover scenario would probable also offer quick failover times.  If this is the choice you go with, then set both interfaces on the switch to portfast, and make sure the server is set up for active/backup scenario.


Does this help?  I hope I did not go too far off on a tangent.  Kindest regards,


Andrew

Correct Answer by chrcoope about 7 years 6 months ago

Soul,


I would say absolutely. The last time I assisted a customer with Virtual Infrastructure we instead used MSTP instances to provide redundancy. We did not have a stack though. I believe Link Aggregation, in conjunction with a stack, will provide a better high availability solution with greater potential throughput.


Regards,

Christopher

Correct Answer by chrcoope about 7 years 6 months ago

I was a bit tired and my laptop did not have enough power to present the way I wanted but here it is

. This file can be viewed with the WebEx player.


Regards,

Christopher

Correct Answer by alissitz about 7 years 6 months ago

As far as I understand it, we do support cross stack LAGs on the SGE series, although I have not tested it myself.  I am interested to see Christopher's testing or confirmation as well.


W/ the 3750s, the entire stack will appear as one switch, same with the SGEs.  With the case of the 3750s, they have a dedicated stacking interface w/ built in redundancy.  The SGE series uses the Gig interface ports.


You mention only two of these switches, so communication across the stack should not be too great.  Also to note, most traffic is normally going from the edge to the core, so for most application types, this means that most of the traffic will traverse the cross-stack LAG or the uplink.  This is good.


Multicast comes to mind however ... and it you have a lot of mcast traffic, then the 3750s and the higher throughput stacking would be the ideal way to go.  You would not want a lot of traffic replicated across the 1GB stack that the SGE would be a part of ...


Any thoughts on if you need SmartNet?


I am partial to the 3750s myself (as you can probably tell:-)) , mostly because you can do almost anything with them.  Very powerful, and flexible to fit into and fix most any problem. A nice switch.  Are you also considering the 3560 series or another product set for these installs?


I hope these comments help, kindest regards,


Andrew

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (5 ratings)
Loading.
chrcoope Mon, 11/16/2009 - 09:24
User Badges:
  • Bronze, 100 points or more

Soul,


I do not have experience stacking 3750s. Our SGEs should be able to do as you ask with copper. There will, in some instances, be packet loss. I will have to lab this request out and find out just how well our SGE can perform your specific request.


Regards,

Christopher

alissitz Tue, 11/17/2009 - 07:51
User Badges:
  • Silver, 250 points or more

Hello, I hope this finds you doing well.


For a good link on 3750 stacking, which adds a lot of information related to cross stack operations and QoS operations such as SRR:


http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps5023/prod_white_paper09186a00801b096a.html


For the SGE2000 reference guide:
http://www.cisco.com/en/US/docs/switches/lan/csbms/sge2000/reference/guide/sge_refguide.pdf


......
"when i read the cheat sheet the  SGE2000, SGE2010 are stackable, but can they do the same job as a 3750 would?"




Really, the 3560 series and above are quite powerful switches with full L2 and full L3 capabilities, and redundancy.


Concerning the stacking, the 3750 series has a 32Gig dedicated stacking cable; this can work bi-directionally for 64Gig throughput.


The  Cisco small business series, SGE series, uses the built in Gig ports with standard cabling.


Many of the features such as stack VLAN configurations, Spanning Tree, QoS configuratios etc ... are maintained and kept the same across the stack.  The SGE series does this nicely.    


It might be helpful to better understand the end to end installation a little better.  Will the SGE sereis work for you?  Possibly, however, it would help us to know more of what you want to do with the installation.  Would also be good to hear what support needs you might have and whether or not SmartNet is a requirement.


Hope these comments help.  Kindest regards,


Andrew

Christopher and Andrew


Thanks ofr you replies,


@Christopher, if this could be tested in a pratical usage then i would really appriciate it. (i dont want to claim a lot of your precious time of cource) (thanks in advance)


@ Andrew, the 3750 series are for me proven tehcnologie and it works, what i try to make sure is that i can have two switches of the linksys series in a stack and have a lacp/lag trunked etherchannel, and that it will work.. if a switch fails then that the most is a pingtimeout.. one 1 because of a re-arp. the docs show indeed that the 3750 series calls it a "Cross-Stack EtherChannel Connection"  if this could be done on the linksys series then i am happy and can buy it. if not i guess i need to do a bigger investment for my client.


Thanks in advance guys, and i hop cristher is able to verify and test if it works or not.


Soul

Correct Answer
alissitz Tue, 11/17/2009 - 13:52
User Badges:
  • Silver, 250 points or more

As far as I understand it, we do support cross stack LAGs on the SGE series, although I have not tested it myself.  I am interested to see Christopher's testing or confirmation as well.


W/ the 3750s, the entire stack will appear as one switch, same with the SGEs.  With the case of the 3750s, they have a dedicated stacking interface w/ built in redundancy.  The SGE series uses the Gig interface ports.


You mention only two of these switches, so communication across the stack should not be too great.  Also to note, most traffic is normally going from the edge to the core, so for most application types, this means that most of the traffic will traverse the cross-stack LAG or the uplink.  This is good.


Multicast comes to mind however ... and it you have a lot of mcast traffic, then the 3750s and the higher throughput stacking would be the ideal way to go.  You would not want a lot of traffic replicated across the 1GB stack that the SGE would be a part of ...


Any thoughts on if you need SmartNet?


I am partial to the 3750s myself (as you can probably tell:-)) , mostly because you can do almost anything with them.  Very powerful, and flexible to fit into and fix most any problem. A nice switch.  Are you also considering the 3560 series or another product set for these installs?


I hope these comments help, kindest regards,


Andrew

chrcoope Wed, 11/18/2009 - 17:49
User Badges:
  • Bronze, 100 points or more

All,


I have done the preliminary lab work. I should have a WebEx video of the lab results, including failure and recovery times, by this time tomorrow. :)


Regards,

Christopher

alissitz Wed, 11/18/2009 - 18:22
User Badges:
  • Silver, 250 points or more

You are the man Christopher!  I look forward to seeing this!

Correct Answer
chrcoope Thu, 11/19/2009 - 19:03
User Badges:
  • Bronze, 100 points or more

I was a bit tired and my laptop did not have enough power to present the way I wanted but here it is

. This file can be viewed with the WebEx player.


Regards,

Christopher

Attachment: 

Christopher,


Thanks you for you hardwork on the specific problem presentation..

so cross stack with channels is working very good as i see.. Thanks for that.

then i assume connecting a server like vmare with a trunked etherchannel with one connection in each switch will work also.

(as i see the stack connection works i assume this will work also)


see my attached picture that outlines the goal, that you confirmed now allmost perfect.

https://makeitwork.nu/linksysstackquestion.jpg




Thanks for the hard work. very much appriciated.


Soul..



ps: attaching files does not work so please click the link for the picture.

Correct Answer
chrcoope Tue, 11/24/2009 - 06:58
User Badges:
  • Bronze, 100 points or more

Soul,


I would say absolutely. The last time I assisted a customer with Virtual Infrastructure we instead used MSTP instances to provide redundancy. We did not have a stack though. I believe Link Aggregation, in conjunction with a stack, will provide a better high availability solution with greater potential throughput.


Regards,

Christopher

Christopher,


with two switches and spanningtree you can solve it... this would be my last resort. .. but in understand from your post that you can confirm it will be the best way to go with a stack (or even two if needed) to provide the physical redundancy. in a active lacp channel across two switch units in a stack..


in my view you would them allways use the two links.. and if one drops you will not feel it.. even if one switch fails...

(if having the switches also linked together with two or even 4 links in a lacp you will have max thrueoutput also..)


with vmware and a switch assisted etherchannel you will have max redundancy as shown in the previous jpg.


so i look for the last confirmation and them i am happy :) thx in advance ..

Correct Answer
alissitz Tue, 11/24/2009 - 09:08
User Badges:
  • Silver, 250 points or more

Hello,


A couple of thoughts, forgive this if it is too rudimentary.


A LAG is going to offer load balancing, greater throughput and redundancy.  This is your best bet. Spanning tree will see these LAGs as a single link and run spanning tree across them as one.


If you have uplinks to different distribution layer switches, for example multiple LAGs going to different distribution layer switches, then running rapid or MSTP is a must.  Rapid or MSTP can understand an alternate link (the other link or the other LAG), and transition over to it very quickly; normally within a second.


LAG to a server - it should work, after all, the switches only knows what they know and learn from the far side.  Meaning, that the switches will see the server as a single instance, a LAG.  Assuming the server can function within the specs, there should be no problem.


In this configuration, I assume the server will have 'one' interface as well, with both interfaces in a LAG and appearing as one.


Can you test this first before going into production?  Will you have a maintenance window?  Can you also perform some tests such as pulling a cable out in the middle of a file transfer, shutting an interface, turning off a switch, etc ...?


I cannot speak for Christopher, however, it would be very hard for us to offer some guarantee within this forum except to say that the switches run standards based LACP.  LACP will run between the two devices and keep a misconfig from occurring.  If LACP does not agree, then the etherchannel will not come up.


As mentioned, running the two interfaces from the server in a failover scenario would probable also offer quick failover times.  If this is the choice you go with, then set both interfaces on the switch to portfast, and make sure the server is set up for active/backup scenario.


Does this help?  I hope I did not go too far off on a tangent.  Kindest regards,


Andrew

no not atall i like goign indepth towards all aspects..


if the config is on one site, and one stack onle.. then running the two switches in a stack with servers and lag to the servers with one link in each switch will work fine.. i assume  that tagging is supported also on the lag..


the reason why i ask this in depth is that i read things on other forums related to this, and people havving a hard time to get it working.. or not..


so before purchase or advise towards other clients, i guess my best bet is to figure it out here.. :)


as my account/email shows i work at the triodos bank... BUT i also do part time ict projects for my own company makeitwork.nu

i try to take the high-end functionality towards the small companies... thats why i reffere to the 3750 stacks..


ow i know you can in a sense stack the linksys and have a lag channel with a trunk across it.. then thinking redundancy in the physical ntwork layer

is more affordable for the small companies.


extending these stacks with multiple connections towards other switches or cores.. then ofcore spanning tree would work.. and you dont need a channel three imo.. i think then you grow to the need to a small coreswitch anyway .. not?


soul.

Correct Answer
alissitz Tue, 11/24/2009 - 09:50
User Badges:
  • Silver, 250 points or more

Cool, I did not want to waste anyone's time by going off on a tangent or covering info that is not requested.


Soul, if I can summarize my thoughts on this it is simply that the small business series switches are just that ... positioned and made for small businesses.  Can you make them work elsewhere?  Sure you can!  I believe in you!


This series of switches are not Cisco switches ... not the same thing and not meant to be.  Expect some limitations  when you position and sell these into high end customers or enterprises.


Cisco switches have awesome capabilities, features, and most any tweak you can think of.  They can get you into or out of most any network problem you face ... and can provide a solution in even very diverse environments.  I do not have to tell you this!  ;-)   The small business series does not have everything that Cisco does, and this is fine, they work very well too, but they are not Cisco switches.


I hope this is not too confusing ...


I cannot comment on the other posts where people have had trouble with the switches; I have not participated in the other posts.


If you can test these, I would think that this testing effort would go far.  You might find these switches to be a perfect fit for your customers, and help you win and maintain customer satisfaction.


As you mention in your last statement, this sounds right.  You can grow as needed, and move into the right product.


Kindest regards,


Andrew


PS - I like the web site!  ;-)  Very cool.

chrcoope Tue, 11/24/2009 - 11:16
User Badges:
  • Bronze, 100 points or more

Soul,


A while back, as a VCP, I set up VI3 with static LACP for a local university to virtualize 64 bit programming test platforms. They handled the infrastructure, I handled VI3. I will definitely confirm, it will be best with LACP across a stack, as shown in your Jpg.


For an additional bit of redundancy, I would also recommend 2 Network Interface Cards in the VMWare host server. :)


Regards,

Christopher

Actions

This Discussion