we have Windows servers with that nifty Broadcom "Teaming" option as well as Linux CentOS servers with "Bonding" - and of course VMWare hosts with their virtual "switches". Now to set them up properly for both speed aggregation and/or redundancy I need a sanity check please. (EXOS version 15.4.x.x / 15.5.x.x)
(1) Easy scenario: If the team plugs into the same switch, all I need to do is LAG the two ports (sharing/grouping), right? I have both speed aggregation and redundancy.
(2) If the team plugs into two different switches that are connected via an ISC link, do I treat it as a regular MLAG setup? I.e. vlan ISC, add the LAG port, give IP addresses, create mlag peer, enable mlag on port (grouped, if we're going to extremes), all done? (See Concepts Guide example page 294 or thereabouts) Do I still have speed aggregation and redundancy?
(3) Now for the tricky part. Let's say the team plugs into two different (Summit) switches that do NOT have an ISC between each other, but those two switches are lagged to two switches (BlackDiamonds) who have MLAGs to those edge switches (Summits) defined. Kinda your 'standard'(?) two-tier scenario.
What do I do in this case (3) ? I think I have proper redundancy, how about speed aggregation? Do I need to configure anything interesting on the Summits? BDs? Anywhere?
In all those 3 scenarios, do things change depending on if I use Windows/Broadcom Teaming vs. Linux Bonding or VMWare's virtual switch? In the case of VMWare, I presume I just treat it like a regular switch, though, like scenario (3).
And two general questions. The ISC vlan, can I put it on its own separate Virtual Router, like "VR-ISC", just to make sure I don't accidentally enable ipforwarding and route things to it?
Regarding the MLAG-ID, that's just an ID that's unique ID per switch, but has to be the same on the peering switches, right? I'm second-guessing myself after reading this statement "...and an "mlag-id" which is used to reference the corresponding port on the MLAG peer
switch..." in the Concepts Guide.