Given all the recent discussions and articles flying around in regards to TRILL, SPB, MLAG and other architectures and protocols, I thought it would be opportune to pen down some thoughts in this regard. Two recent articles in Network World and Network Computing have brought some of this discussion to the forefront.
TRILL and SPB are both standards-based approaches being proposed to address multi-path Layer 2 forwarding in the data center at layer. In general, a standards-based approach is good and desirable. However, as evidenced in the above articles, the market is currently divided between the two competing protocols, with some vendors supporting TRILL and others supporting SPB. What’s also important to note is that the packet encapsulation schemes that are being used in these protocols may require new hardware to support the forwarding modes. This can add significant uncertainty to the customer buying decision because not only may the customer need to invest in some new infrastructure to avail the benefits of one of these new protocols, but may also live with the uncertainty of which protocol ultimately will prevail.
So, while the TRILL/SPB discussion plays out in the industry and while more new systems come to market that support one or the other, what is an administrator to do if he/she wants multi-path in the DC?
That’s where Multi System Link Aggregation (MLAG) may provide a glide path. MLAG takes traditional link aggregation and extends it by allowing one device to essentially dual home into two different devices. See the picture on the right:
Device 1 treats the two links as regular Link Aggregation (LAG). Devices 2 and 3 participate in the MLAG to create the perception of a LAG. In effect, MLAG adds multi-path capability to traditional LAG, albeit where the number of paths is generally limited to 2. With MLAG, both links that are dual homed from Device 1 can be actively forwarding traffic. If one device in the MLAG fails, for example, if Device 3 fails, traffic is redistributed back to Device 2, thus allowing for both device and link level redundancy while utilizing both active links. MLAG can be used in conjunction with LAG and other existing technologies.
The limitation of two paths for an MLAG isn’t really such a big limitation today, because many DC networks today are designed using dual uplinks, i.e., in a large cross section of current deployments, you don’t have more than two uplinks to multi-path over anyway. And while MLAG implementations are proprietary, the “proprietariness” of MLAG is confined to the two switches in the tier that is offering the MLAG, i.e., Device 2 and Device 3 in the picture above need to be from the same vendor. Device 1, on the other hand, simply treats both the ports as a regular LAG and as such could come from another vendor. So for example, MLAG can be used in conjunction with NIC teaming where Device 1 could be a server which can be dual homed to two switches operating as an MLAG. MLAG can also be used in conjunction with upcoming standards-based technologies such as VEPA to switch VMs directly in the network over active-active paths from the server.
As such, while the industry debates around TRILL/SPB and other fabric technologies play out, MLAG may provide a useful glide path in many environments to build data center fabrics over existing deployed infrastructure.
For more information on MLAG and what topologies this can enable, read the white paper.
-Shehzad
