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
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.
PS - I like the web site! ;-) Very cool.
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,
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.
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.
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,