Within the earlier weblog publish of the MLAG Expertise Deep Dive collection, we explored the intricacies of layer-2 unicast forwarding. Now let’s give attention to layer-2 BUM flooding performance of an MLAG system.
Our community topology may have two switches and 5 hosts, some related to a single change. That’s not a good suggestion in an MLAG setting, however even when you’ve got a picture-perfect design with all the pieces redundantly related, you’ll have to cope with it after a single hyperlink failure.
Easy MLAG topology
Think about host A sending a broadcast (or another body that must be flooded). It may use the A-S1 or the A-S2 hyperlink to take action. Let’s assume it makes use of the A-S1 hyperlink. The printed needs to be obtained by each different host related to the identical broadcast area. Getting it to X and B is straightforward – S1 sends it over a straight related hyperlink.
What about C and Y? Solely S2 can ship the printed to them – S1 has to ship all flooded frames to S2 over the peer hyperlink. To this point, so good, however now we’re hitting a snag: a packet S2 receives over the peer hyperlink shouldn’t be flooded to hosts with energetic connections to each switches. S2 ought to ahead the printed to C and Y, however to not A or B. In different phrases: S2 should implement a cut up horizon between single-attached and dual-attached hosts.
Let’s assume our switches use a MAC forwarding desk with an additional default entry that comprises the listing of all ports to which they need to flood a BUM body. That works nice for standalone switches, however we’d like two default entries for switches working in an MLAG cluster:
- A default entry for packets obtained from related community units. S1 would ahead such packets to X, A, B, and S2; S2 would ship them to A, B, C, Y, and S1.
- One other default entry for packets obtained over the peer hyperlink. S1 would ahead them to X however to not A or B. Likewise, S2 would ship them to C and Y, however not A or B.
These necessities usually are not too completely different from what we have to implement stackable switches, so we will count on most forwarding ASICs to comprise mechanisms to cope with them. The ASIC may choose one or the opposite default entry primarily based on the enter port. It may additionally use metadata hooked up to the incoming body, requiring further (proprietary) encapsulation on the peer hyperlink.
The actual enjoyable begins once we attempt to substitute the peer hyperlink with cloth connection utilizing MPLS or VXLAN encapsulation. MPLS label stack is an apparent resolution: RFC 7432 comprises a prolonged convoluted part explaining the way to promote and use an extra MPLS label to implement cut up horizon switching.
There’s no additional label in VXLAN, and the one resolution (detailed in RFC 8365) is to make use of the supply IP handle of the VXLAN packets to determine whether or not the packet is coming from the digital peer hyperlink. That should be large enjoyable to program in forwarding {hardware} judging from the catastrophic bugs that riddled early EVPN-only MLAG implementations.
We’re solely three weblog posts into this collection and we already bought layer-2 forwarding sorted out. It’s time to maneuver to layer-3 challenges, beginning with energetic/energetic layer-3 forwarding – the subject of the subsequent weblog publish within the MLAG Deep Dive collection.
