Machine Learning Authors: Pat Romanski, Elizabeth White, Yeshim Deniz, Zakia Bouachraoui, Liz McMillan

Blog Feed Post

MLAG: An Example of Complexity that should not be

In Monday’s blog post, Derick explained the network engineering cycle, traversal in the referential space and the need to provide solutions that enable the network engineer to do his or her job better, more accurate, easier, simpler, more complete. We cannot automate or encapsulate a network engineer’s job and we should not try. We must however encapsulate and automate specific tasks and workflows.

Multichassis Link Aggregation (MLAG) is one of those features that should be so straightforward, but isn’t. MLAG allows a single device to be connected to 2 ethernet switches using a single Link Aggregation Group (LAG). The device is configured with a single LAG with ports that are connected to two switches, rather than a single switch. The two switches coordinate between each other and make it appear to the device as if they are single device.

This part is actually straightforward, it really comes down to using a single LACP system-id across both links from both switches. The end device is blind to the fact there are different switches at the end of each link.

MLAG is Complicated

The hardest part of MLAG is the packet forwarding coordination and behavior between the two switches. For instance, if the end device sends a broadcast packet onto one of the links of the LAG towards switch 1 of the MLAG, the solution must ensure that switch 2 does not send that same broadcast packet back to the end device. Because the two switches together create a LAG, the basic rule that a packet received on a LAG can never be send back out that same LAG must be observed. Sounds simple, but if that broadcast packet gets to switch 2, how does it know it came from the device at the other end of the LAG to begin with? Sounds trivial, just look at the source MAC address, but ethernet forwarding usually does not do anything with a source MAC address.

If a broadcast packet comes in the rest of the network and arrives at switch 1 and 2, who will forward this packet? Only one of them can, again to avoid duplication of packets. Similarly for multicast. In multicast rich environments, would you always pick the same switch to forward this onto the LAG, or would you share that responsibility. And if you share, how do you inform the rest of the network that it is this switch for this specific group that is responsible for distribution?

When one of then links in the LAG fails, what does that switch do with packets towards the end device? How does it get that packet to its MLAG peer so that it is delivered? If you have configured MLAG on any popular platform out there, you have now discovered the reason for the private interconnect between two MLAG peers.

They’re all the same, but different

Whether you call it MLAG, SMLT, VSS, vPC, vLAG or anything else, they all implement the same concept. And there is no question that MLAG is a rather complicated feature to implement and get all the data forwarding possibilities right. There are many failure scenarios to consider to ensure that traffic is not lost, looped, or duplicated.

There is however no reason to expose any of this complexity to you as the user. Why do I have to create a port group between two switches, then explain to each that they are MLAG peers on a special VLAN, then stick IP addresses on this VLAN, create an MLAG peering session, verify it is up and running, then create actual MLAG ports that are mapped to some unique identifier I need to track that needs to match up with the one used on the peer? I counted 24 individual configuration steps just to get the MLAG peering configured.

Why so Complicated?

This is a perfect example of exposing the gory details of the scaffolding required for something that as a user really should be as simple as “I want this port on this and that port on that switch to be part of the same LAG”. Because really that is what you want. Sure, for debugging purposes you may need to understand what is communicated between switches and who has taken responsibility for what, but why did you the user have to manually create all this plumbing between the two systems? That should be encapsulated by us, the vendor, so that you can focus on automating the actual provisioning of ports in an MLAG.

And I completely understand the implementation reasons for having 2 switches matched up to become MLAG peers and MLAGs can only exist between those two peers. But it’s one of those limitations imposed on you that should not be, there is absolutely no reason you could not have 3 MLAG peers. Or 4. Or any combination of 2 switches, different for each MLAG. For us there is no difference between a LAG and an MLAG. That is, there most certainly is a difference, but as far as provisioning one goes, they are identical. You simply configure a LAG. And you have a choice to add ports from other switches to that LAG. And that’s it. All that took was a desire to remove these constraints to make your job easier and more accurate.

Focusing on the user experience of the network takes time, it takes determination, it requires a completely different view on delivering capabilities. Read Derick’s blog post from this past Monday and you will get a sense of our beliefs and approach.


[Today's fun fact: Sauerkraut is also a member of the cabbage family and should not be considered an insult (ref: yesterday's fun fact). It is fat free, low in calories, provides about a third of daily needs of vitamin C in a single cup and contains iron, calcium, potassium, thiamin, riboflavin, niacin and 8 grams of fiber. Americans consume 387 million pounds a year, that is more per capita than Germany. And it was first created in the Alsace in France, not Germany.]

The post MLAG: An Example of Complexity that should not be appeared first on Plexxi.

Read the original blog entry...

More Stories By Marten Terpstra

Marten Terpstra is a Product Management Director at Plexxi Inc. Marten has extensive knowledge of the architecture, design, deployment and management of enterprise and carrier networks.

CloudEXPO Stories
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next-gen applications and how to address the challenges of building applications that harness all data types and sources.
Lori MacVittie is a subject matter expert on emerging technology responsible for outbound evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture experience in both high-tech and enterprise organizations, in addition to network and systems administration expertise. Prior to joining F5, MacVittie was an award-winning technology editor at Network Computing Magazine where she evaluated and tested application-focused technologies including app security and encryption-related solutions. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University, and is an O'Reilly author.
CloudEXPO New York 2018, colocated with DevOpsSUMMIT and DXWorldEXPO New York 2018 will be held November 12-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI and Machine Learning to one location.
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
ICC is a computer systems integrator and server manufacturing company focused on developing products and product appliances to meet a wide range of computational needs for many industries. Their solutions provide benefits across many environments, such as datacenter deployment, HPC, workstations, storage networks and standalone server installations. ICC has been in business for over 23 years and their phenomenal range of clients include multinational corporations, universities, and small businesses.