lab05-VxLAN-L2
Task VxLAN. L2 VNI
Set up an Overlay using VXLAN EVPN to provide Layer 2 connectivity between host-clients.
Configure BGP peering between Leaf and Spine nodes using address-family l2vpn evpn. Establish Layer 2 connectivity between clients in Zone 1, and verify that it is operational
Network diagram
The lab is built using the following role-based device mapping host- linux, leaf - frr, 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-2
Eth2
10.1.2.0/31
fd00::10:2:1:0/127
Leaf-1
Eth2
10.1.2.1/31
fd00::10:2:1:1/127
Spine-2
Eth2
10.1.2.2/31
fd00::10:2:1:2/127
Leaf-2
Eth2
10.1.2.3/31
fd00::10:2:1:3/127
Spine-2
Eth3
10.1.2.4/31
fd00::10:2:1:4/127
Leaf-3
Eth2
10.1.2.5/31
fd00::10:2:1:5/127
Host-1
Eth1
172.16.1.11/24
fd00::172:16:1:b/116
Leaf-1
Eth3
access vlan red
access vlan red
Host-2
Eth1
172.16.2.12/24
fd00::172:16:2:c/116
Leaf-2
Eth3
access vlan blue
access vlan blue
Host-3
Eth1
172.16.1.13/24
fd00::172:16:3:e/116
Leaf-3
Eth3
access vlan red
access vlan red
Host-4
Eth1
172.16.2.14/24
fd00::172:16:4:d/116
Leaf-3
Eth4
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
Network based on ospf(underlay)+ibgp(overlay). Area ospf 0, bgp as 65500
Launching a lab in the Netlab
It all seemed straightforward, but I spent a long time troubleshooting FRR access behavior. If you assign connected interfaces out of order, it causes mismatches — FRR ends up configuring interfaces that don’t match the actual bridge interfaces inside the Alpine Linux container running FRR. Additionally, I wasn’t satisfied with the default behavior where a BGP session is created between spine nodes acting as route reflectors, even though there’s no direct link between them. This session seems unnecessary in topologies where spine nodes are only meant to reflect routes and not peer directly.
So I dove into the code — specifically into: /usr/local/lib/python3.10/dist-packages/netsim/modules/bgp.py While reviewing it, I discovered that when route reflectors are present, Netlab does not build a full mesh. Instead, it creates sessions only from RR nodes, but doesn’t handle peering between multiple RRs. I added a conditional check to support RR-to-RR sessions — and Netlab promptly broke. After revisiting some Python basics, I realized the issue was indentation-related. Once I fixed the formatting, Netlab launched successfully.
Everything seemed fine, but I realized that my change unconditionally disables the RR-to-RR session. Polling fellow network engineers didn’t yield a clear reason why such a session might be needed — but I figured someone might find it useful in specific topologies. So I added a control parameter to the handler: /usr/local/lib/python3.10/dist-packages/netsim/modules/bgp.yml This parameter allows users to toggle RR-to-RR session creation. Default value: False. I had to restart the lab a couple of times to validate the logic and ensure the change didn’t break anything.
I’m attaching the modified bgp.py and bgp.yml files here, in case someone stumbles upon this before I get around to contributing it upstream to the Netlab project. bgp.py bgp.yml
File Topology For quick reference, here’s the inline listing:
Validating
What was our intended outcome? Establish connectivity between h1 and h3, and between h2 and h4, respectively — and ensure it works via VXLAN. We launch the lab and start verifying with ping tests.
Ping traffic between hosts is flowing — which means it's time to inspect what's happening on the leaf and spine nodes. We’ll check routing tables, EVPN advertisements, and other control plane details. Since EVPN is up and running for both IPv4 and IPv6, things might get interesting. To keep track of MAC-to-host mappings, let’s introduce a MAC address table for all devices.
h1
aa:c1:ab:0d:85:f0
172.16.1.11/24
fd00::172:16:1:b/116
fe80::a8c1:abff:fe0d:85f0/64
red
101000
h2
aa:c1:ab:a5:c3:48
172.16.2.12/24
fd00::172:16:2:c/116
fe80::a8c1:abff:fea5:c348/64
blue
101001
h3
aa:c1:ab:cb:d4:25
172.16.1.13/24
fd00::172:16:1:d/116
fe80::a8c1:abff:fecb:d425/64
red
101000
h4
aa:c1:ab:60:b1:45
172.16.2.14/24
fd00::172:16:2:e/116
fe80::a8c1:abff:fe60:b145/64
blue
101001
Here’s what spine-1 reports about our EVPN state:
As we can see, both link-local addresses and vlan-if interfaces — which are bound inside FRR — are being propagated. Below is an excerpt from ip a on leaf-3.
And here’s the EVPN route output from leaf-3:
If you take a look in Wireshark, you can observe Type 2 route exchanges happening on the leaf node.
One of the most surprising discoveries was that Type 2 EVPN routes also carry IPv6 link-local addresses.
It’s easy to retrieve config files using: netlab collect
Device configuration files:
Last updated