lab07-VxLAN&M-LAG
Task VXLAN. Multihoming
Configure a resilient client connection using EVPN Multihoming.
Подключите клиентов 2-я линками к различным Leaf Настроите агрегированный канал со стороны клиента Настроите multihoming для работы в Overlay сети. Если используете Cisco NXOS - vPC, если иной вендор - то ESI LAG (либо MC-LAG с поддержкой VXLAN) Зафиксируете в документации - план работы, адресное пространство, схему сети, конфигурацию устройств Опционально - протестировать отказоустойчивость - убедиться, что связнность не теряется при отключении одного из линков
• Connect the client using two physical links to different Leaf switches
• Configure a link aggregation group (LAG) on the client side
• Set up EVPN multihoming for operation within the overlay network
◦ If using Cisco NXOS, implement vPC
◦ For other vendors, configure ESI-LAG or MC-LAG with VXLAN support
• Test failover behavior:
◦ Verify that connectivity is maintained when one of the links is disconnected
Network diagram
Due to functional limitations in FRR, we’re switching the Leaf vendor to Arista. FRR is fundamentally a routing stack, and switch-like functionality is implemented via underlying Linux tools — which makes it unsuitable for native switching features. In particular, MLAG could not be brought up on FRR-based nodes. We’ll keep Linux with bonding as the client platform. The lab is built using the following role-based device mapping host- linux, leaf - arista, spine - arista
Underlay IP Address Allocation
• Underlay addressing follows the format 10.x.y.z, where:
◦ x = Data Center ID
◦ y = Spine switch ID
◦ z = Sequential host address per leaf connection
• Host addressing uses the 172.16.x.z/24 format, where:
◦ x = Leaf switch ID
◦ z = Sequential host address
◦ Each leaf switch uses .1 as its own IP in the corresponding subnet
• Loopback addressing uses 192.168.a.b/32, where:
◦ a = 1 for spine switches
◦ a = 2 for leaf switches
◦ b = Spine or leaf ID (assigned sequentially)
• IPv6 addressing uses fd00::[IPv4]
Interconnect ipv4 ipv6
Spine-1
Eth1
10.1.1.0/31
fd00::10:1:1:0/127
Leaf-1
Eth1
10.1.1.1/31
fd00::10:1:1:1/127
Spine-1
Eth2
10.1.1.2/31
fd00::10:1:1:2/127
Leaf-2
Eth1
10.1.1.3/31
fd00::10:1:1:3/127
Spine-1
Eth3
10.1.1.4/31
fd00::10:1:1:4/127
Leaf-3
Eth1
10.1.1.5/31
fd00::10:1:1:5/127
Spine-1
Eth4
10.1.1.6/31
fd00::10:1:1:6/127
Leaf-4
Eth1
10.1.1.7/31
fd00::10:1:1:7/127
Spine-2
Eth1
10.1.2.0/31
fd00::10:1:2:0/127
Leaf-1
Eth2
10.1.2.1/31
fd00::10:1:2:1/127
Spine-2
Eth2
10.1.2.2/31
fd00::10:1:2:2/127
Leaf-2
Eth2
10.1.2.3/31
fd00::10:1:2:3/127
Spine-2
Eth3
10.1.2.4/31
fd00::10:1:2:4/127
Leaf-3
Eth2
10.1.2.5/31
fd00::10:1:2:5/127
Spine-2
Eth4
10.1.2.6/31
fd00::10:1:2:6/127
Leaf-4
Eth2
10.1.2.7/31
fd00::10:1:2:7/127
Leaf-1
Eth3
10.0.1.0/31
fd00::10:0:1:0/127
Leaf-2
Eth3
10.0.1.1/31
fd00::10:0:1:1/127
Leaf-3
Eth3
10.0.1.2/31
fd00::10:0:1:2/127
Leaf-4
Eth3
10.0.1.3/31
fd00::10:0:1:3/127
Leaf-1
Eth4
------------
------------
Leaf-2
Eth4
------------
------------
Leaf-3
Eth4
------------
------------
Leaf-4
Eth4
------------
------------
Host-1
Eth1
172.16.1.11/24
fd00::172:16:1:b/116
Leaf-1
Eth5
access vlan red
access vlan red
Host-1
Eth2
172.16.1.11/24
fd00::172:16:1:b/116
Leaf-2
Eth5
access vlan red
access vlan red
Host-2
Eth1
172.16.1.12/24
fd00::172:16:1:c/116
Leaf-3
Eth5
access vlan red
access vlan red
Host-2
Eth2
172.16.1.12/24
fd00::172:16:1:с/116
Leaf-4
Eth5
access vlan red
access vlan red
Host-3
Eth1
172.16.2.13/24
fd00::172:16:2:d/116
Leaf-1
Eth6
access vlan blue
access vlan blue
Host-3
Eth2
172.16.2.13/24
fd00::172:16:2:d/116
Leaf-2
Eth6
access vlan blue
access vlan blue
Host-4
Eth1
172.16.2.14/24
fd00::172:16:2:e/116
Leaf-3
Eth6
access vlan blue
access vlan blue
Host-4
Eth2
172.16.2.14/24
fd00::172:16:2:e/116
Leaf-4
Eth6
access vlan blue
access vlan blue
loopback
Spine-1
192.168.1.1
fd00::192:168:1:1
Spine-2
192.168.1.2
fd00::192:168:1:2
Leaf-1
192.168.2.1
fd00::192:168:2:1
Leaf-2
192.168.2.2
fd00::192:168:2:2
Leaf-3
192.168.2.3
fd00::192:168:2:3
Leaf-4
192.168.2.4
fd00::192:168:2:4
Network based on ospf(underlay)+ibgp(overlay). Area ospf 0, bgp as 65500
Launching a lab in the Netlab
There were no special launch requirements. To avoid mixing services and transport into a single namespace, I introduced a dedicated VRF called user, where both vlan-if interfaces were placed — allowing the hosts to communicate with each other. Since I typically work with a centralized gateway model (where L3 terminates on the border leaf), I decided to experiment with a distributed gateway to understand how it’s configured and how it forwards traffic. One caveat: the gateway module that handles FHRP protocols only stretches IPv4 addresses across devices. Attempts to extend this behavior to IPv6 weren’t very successful.
File Topology For quick reference, here’s the inline listing:
Validating
First, we verify basic connectivity with ping tests. It’s probably a good time to start integrating automated validation. To do this, we add a validate block to the topology file.
Input netlab validate and see:
It’s beautiful, really — sometimes it feels like cheating. The lab builds itself, validates itself, and the only thing that requires real effort is writing a proper YAML topology file. Let’s take a look at what spine-2 knows about our hosts.
Since EVPN is up over both IPv4 and IPv6, things are about to get interesting. To make it easier to interpret, let’s introduce a MAC address table for the devices.
h1
aa:c1:ab:31:a1:6f
172.16.1.11/24
fd00::172:16:1:b/116
fe80::a8c1:abff:fe0d:85f0/64
red
101000
h2
aa:c1:ab:82:c9:3c
172.16.2.12/24
fd00::172:16:2:c/116
fe80::a8c1:abff:fea5:c348/64
red
101000
h3
aa:c1:ab:e6:14:53
172.16.1.13/24
fd00::172:16:1:d/116
fe80::a8c1:abff:fecb:d425/64
blue
101001
h4
aa:c1:ab:a6:ff:af
172.16.2.14/24
fd00::172:16:2:e/116
fe80::a8c1:abff:fe60:b145/64
blue
101001
We’ve already covered L2 VNIs in Lab 5, so now let’s focus on our MLAG configuration.
Here are leaf-3 leaf-4
Everything looks solid from all angles.
Now we need to understand whether this technology actually protects us from equipment or link failures. Let’s consider the following failure scenarios:
1. We were performing a maintenance upgrade, and leaf-1 went down. (See point 1 in the diagram)
2. It wasn’t just us — someone was working in the cross-connect, and all uplinks to leaf-3 were damaged. (Points 2–3 in the diagram)
3. The day of disasters continued: on leaf-4, the interface module facing the servers burned out. (Points 4–5 in the diagram)
We’ll simulate all failures by shutting down the relevant interfaces.
Wrote the failure scenario — and honestly, it’s terrifying. I can only imagine what kind of panic this would trigger in the monitoring system 😅.
Interface status
Run netlab validate and see
Testing
The tests were successfully passed — despite our best efforts to break things. Of course, with a bit more creativity and a few extra shutdown commands, we could probably destabilize the lab further… but let’s show some mercy and proceed to collect the configurations.
For Wireshark enthusiasts — here’s a capture from leaf-4, taken across several validation runs. It clearly shows that traffic flows bidirectionally even during failure scenarios, confirming that EVPN multihoming and failover mechanisms are working as intended.
leaf-4 was chosen specifically because it allows us to observe how traffic shifts to the peer-link when attempting to reach hosts. We can see traffic flowing through eth3 and eth4, which connect leaf-3 and leaf-4:
• eth3 effectively acts as an alternate EVPN path. Since we’re using iBGP, the EVPN peering between leaf-3 and the spine remains intact — a backup route is simply installed. leaf-3 continues to advertise and receive EVPN routes from the rest of the fabric.
• eth4 serves as the peer-link for MLAG operation.
This setup demonstrates how traffic is rerouted through the peer-link during failure scenarios, maintaining connectivity without disrupting the control plane.
We can see that the MLAG links are in an Active-partial state — which makes sense, since the peer’s interfaces are down. Despite that, the EVPN peering remains stable — the control plane is unaffected.
Here’s the OSPF route table from spine-1, confirming that underlay routing is still functional and reachability to loopbacks and VTEPs is preserved.
We can see that leaf-3’s loopback (192.168.2.3) is reachable with a route cost of 30.
Meanwhile, leaf-1 (192.168.2.1) is completely absent from the routing table — no visibility at all.
Device configuration files(with interfaces in up):
Last updated