In the considerable documentation available on the topic of Multi-LAGs (MLAGs), there are some key design points which tend to not be discussed but which are somewhat important to an understanding of MLAG (Multi Link Aggregation Group) operation.
* Components of a basic 1-Tier MLAG *
| Switch | <- One upstream switch (or server), possibly
| or | with attached users
| Server |
| | <- One "LAG Port" or Load Sharing/Balancing
| | Port consisting of two or more ethernet
| | connections supporting one or more
| | User VLANs
| | <- Two "MLAG Ports" each consisting of one or
----------- ----------- more ethernet connections supporting (the
| | | | same) one or more User VLANs
| EXOS | | EXOS | <- Two downstream EXOS switches (of the same
| Switch | | Switch | hardware type and EXOS version) functioning
| | | | as MLAG peers, possibly with attached users
| "MLAG |-------| "MLAG | <- Two "ISC Ports" forming a LAG consisting of
| Peer" | | Peer" | one or more ethernet connections supporting
| | | | (the same) one or more User VLANs plus one
----------- ----------- ISC VLAN to form a non-blocking Inter-
Switch Connection (ISC)
Note that within the context of this document, in most references a "port" actually consists of one or more ethernet ports which
The key MLAG design points are:
- are members of the same Load Sharing or Load Balancing group of any kind; from the perspective of an upstream server when communicating with the two downstream MLAG peers; or
- are members of the same LAG group; from the perspective of an upstream switch when communicating with the two downstream MLAG peers, or from the perspective of either of the downstream MLAG peers when inter-communicating over the ISC; or
- are members of the same MLAG group; from the perspective of either of the downstream MLAG peers when communicating with the upstream server or switch.
- For simplicity of configuration and responsiveness of failover/failback, Dynamic LAGs are recommended over Static LAGs - except when a Dynamic LAG cannot be used because the device at the other end of the connection is instead doing Load Sharing or Load Balancing, or doesn't support the LACP protocol. The result may differ for the LAG, MLAG, and ISC connections, which in this respect are independent of each other.
- It is desirable to minimize Unicast Flooding of unlearned traffic.
- It is desirable to minimize user traffic traversing User VLANs across the ISC.
- For ISC ports, conventional Source Address Table / Filtering DataBase Learning is disabled by default and should remain disabled while not in failover mode.
- Peered MLAG switches share all of their SAT/FDB Learning via ISC VLAN interchange - so both are capable of "fast-pathing" (that is, unicast forwarding via programmed hardware rather than requiring CPU processing) the same traffic.
- Attached users may optionally be, but are not necessarily, ethernet-linked to both of the MLAG Peer switches ("dual-homed"). Lack of dual homing is supported at the potential cost of increasing User VLAN traffic across the ISC.
- The MLAG local-peer and remote-peer ports belong to the same MLAG group so are treated by the two peer switches as effectively the same MLAG port, both in any (Dynamic LAG) LACP negotiations sent to the upstream LAG-attached device and in the concept of not forwarding traffic back out the same MLAG as received.
Note: "Local" means on this switch; "Remote" means on the peered switch across the ISC. These are relative terms only.
- To avoid underlying port# duplication on the LAG from the perspective of the connected upstream server/switch, it is important to MLAG using all unique ethernet port numbers on each MLAG peer switch.
- For best redundancy; if configuring on a BlackDiamond chassis spread the LAG ports across modules, if configuring on a Summit stack spread the LAG ports across stack members, and if configuring on a Summit standalone spread the LAG ports across different 8-port groups.
- Though only one copy of a given packet traverses an MLAG to be received by one of the MLAG peer switches, it cannot be predicted what mix of traffic will be received via the MLAG-remote-peer vs MLAG-local-peer ports. Thus, the ISC port must transport some unicast learned (if learned on remote-peer), unicast unlearned (destination is possibly on remote-peer), multicast (remote-peer may not otherwise see it), and broadcast (remote-peer may not otherwise see it) user traffic.
- The "ISC Blocking Filter", in a non-failover scenario, functions so that unicast/multicast/broadcast user traffic received via the ISC is not forwarded to the local-peer MLAG port - because this traffic potentially originated from or was already sent to the remote-peer MLAG port. Thus, the ISC blocking filter matches all Layer 2 traffic received on the ISC and blocks transmission to all local-peer MLAG ports that have remote-peer MLAG ports in the active state.
- Multi-LAGging is designed for relatively transparent loss of one of the two MLAG peer switches or one of the two MLAG "legs". In such a failover event, the ISC port will stop filtering traffic and start using conventional Source Address Table / Filtering DataBase Learning. Network connectivity should thus be retained - except for single-homed users local to a failed MLAG peer switch.
- Multi-LAGging is designed for relatively transparent loss of the ISC, as long as 'mlag peer alternate ipaddress' (EXOS 15.5+) is configured on the peers and the higher-IP peer is reachable from the lower-IP peer using the configured address. [See How to implement MLAG alternate peer ipaddress.] In such an ISC-loss event, the lower-IP peer's MLAG port will be disabled to in effect "un-peer" the two switches. In the absence of such configuration, any transiting conversations that rely on the activities of the ISC VLAN or any of the ISC-based User VLANs will likely fail.