WLG-IX and CHC-IX migration to EVPN VXLAN

We’ve recently upgraded the switching fabric in both Wellington and Christchurch to EVPN VXLAN, which is the modern standard for building resilient, scalable Ethernet fabrics.

Previously, these exchanges ran over VPLS back by an MPLS + LDP core. It did the job, but it came with a few drawbacks. Our switches would exchange labels to establish paths between devices, and in a full mesh configuration the exchange VLAN was stretched across all switches to emulate one big ethernet segment. Because this effectively behaves like a single big switch, everything gets shoved in the data plane, so when a MAC is unknown it became flooded across all pseudowires.

At this point whilst we may know your MAC address, VPLS doesn’t have the ability to associate MAC<>IP mappings, thus broadcasts are inevitable. Another shortcoming of the VPLS implementation our hardware uses is its inability to distribute traffic evenly across the core, this means we had to use traffic engineering (RSVP-TE) to define paths between Site-A<>Site-B, this works well but as the exchange grows so does the amount of pseudowire tunnels, traffic engineering complexity and time to identify/locate faults in a failure scenario.

We also know that VPLS is aging; vendors are no longer prioritising implementation of this feature as the more modern equivalent has been here for a while and is the defacto in 2025 – VXLAN.

An EVPN VXLAN based exchange design resolves a number of our issues by utilising EVPN for the control plane (type 2 EVPN) so MAC and IP bindings are signalled in BGP rather than inferred by flooding. The pseudowires are replaced with simple layer 3 paths which the exchanges associated VXLAN tunnels over, allowing the fabric to use native ECMP for load distribution without traffic engineering with the added benefit of more uniform LAG hashing due to more entropy!

Convergence speeds up as state changes are signalled through EVPN routes instead of data-plane learning and with the added feature of ARP/ND suppression our edge devices will stop IP<>MAC bindings and reply locally to your ARP requests! Although we had to disable that feature due to unexpected behaviour and our commitment to stability, migrating to EVPN VXLAN still yields massive operational and scaling benefits.