Utilizing EVPN/VXLAN with MLAG Clusters « ipSpace.internet weblog

There’s no higher strategy to begin this weblog submit than with a widespread fantasy: we don’t want MLAG now that the majority distributors have applied EVPN multihoming.

TL&DR: This fantasy is near the not even unsuitable class.

As we mentioned within the MLAG System Overview weblog submit, each MLAG implementation wants no less than three useful elements:

• Forwarding desk synchronization – members of an MLAG cluster should synchronize MAC and ARP tables.
• Synchronized management airplane protocols – members of an MLAG cluster should use the identical system ID for LACP and may synchronize STP state (usually applied with working STP on a single member of the MLAG cluster)
• Configuration synchronization – having completely different entry lists configured on particular person members of a hyperlink aggregation group is a wonderful recipe for prolonged troubleshooting periods.

EVPN multihoming solves the forwarding desk synchronization. An MLAG implementation may use ICCP (RFC 7275) to synchronize LAG membership and LACP (however not STP). I’m unaware of any customary know-how that might handle configuration synchronization.

EVPN multihoming is thus a wonderful constructing block of an MLAG implementation, however you continue to want different bits, a few of which aren’t standardized. Multi-vendor MLAG or MLAG cluster throughout quite a few nodes (past the same old two) thus stays firmly within the PowerPoint area.

That should be unhappy information for the true believers within the powers of EVPN, however no less than EVPN gives every thing it is advisable to synchronize the forwarding tables, proper? In any case:

• MLAG cluster members use Ethernet Phase Identifiers (ESI) to determine hyperlinks linked to the identical CE system or CE community.
• PE gadgets use the ESI data to determine different members in an MLAG cluster and elect a devoted forwarder (in energetic/standby deployments).
• MLAG cluster members use ESI data from MAC+IP updates to synchronize the MAC and ARP tables.
• Ingress PE gadgets can use ESI membership to implement optimum load balancing towards all MLAG cluster members, making the anycast gateway kludges irrelevant.

That’s nearly right, other than the final bit.

EVPN MAC-Primarily based Load Balancing

Let’s use the identical knowledge middle material we mentioned within the Combining MLAG Clusters with VXLAN Material weblog submit:

Now assume that S1 and S2 use completely different VTEP IP addresses (please observe that the main points are far more convoluted than the next simplified rationalization):

• S1 and S2 promote an ESI based mostly on the LACP System ID of host A (ESI-A).
• S1 advertises MAC-A with ESI-A and VTEP-A because the VXLAN subsequent hop.
• S2 doesn’t should promote MAC-A (though it may achieve this) – each different PE system is aware of that S1 and S2 serve the identical Ethernet phase and that they might use both to achieve MAC-A.

Up to now, so good. Now for the wrench within the works: whereas nearly all IP forwarding tables assist a number of entries for a similar IP prefix, it’s uncommon to search out forwarding {hardware} that helps multiple next-hop entry for a similar MAC handle. Utilizing multiple entry for a similar MAC handle within the MAC forwarding desk additionally doesn’t work – that’s how the forwarding {hardware} implements flooding.

Lengthy story quick: EVPN gives all of the performance one must determine MLAG member hyperlinks and shortly failover to a subset of hyperlinks on a hyperlink or node failure. Nevertheless, the forwarding {hardware} limitations require anycast VTEP IP addresses described within the Combining MLAG Clusters with VXLAN Material weblog submit. We’re (nearly) again to sq. one – or you can quit and ahead all visitors for a single MAC handle towards one of many egress VTEPs.

Utilizing EVPN because the management airplane protocol as an alternative of dynamic MAC studying does present a major profit: the egress PE gadgets can promote no matter subsequent hop they want within the MAC+IP replace messages. Many distributors use this performance to distinguish between multihomed and orphan nodes:

• MAC addresses of orphan nodes are marketed with unicast VTEP IP handle
• Members of an MLAG cluster promote the MAC addresses of multihomed nodes with the shared anycast VTEP IP handle.

Whereas the above answer works nice in a gradual state, any single hyperlink failure may flip a multihomed node into an orphan node, triggering an fascinating sequence of replace messages (the main points are left as an train for the reader).

Some distributors attempt to go a step additional: they promote MAC+IP data with anycast VTEP IP handle and add an IP prefix (EVPN RT5) for the node IP handle (a /32 or /128 prefix) with the unicast VTEP IP handle. IP visitors is thus load-balanced between unicast VTEP IP addresses^{, whereas MAC-based forwarding makes use of the anycast VTEP IP handle.}

Coming again to the “EVPN multihoming makes MLAG out of date” fantasy: for each complicated downside, there’s an answer that’s easy, neat, and unsuitable (and works finest in PowerPoint). MLAG is not any exception.

Extra Info

All three webinars can be found with Normal ipSpace.internet Subscription.