Frames across the fabric
host1 pings host2: same subnet, different leaves, a routed fabric in between. It works.
A capture on leaf1's uplink shows how. Every frame is wrapped in UDP to port 4789 between the two loopbacks, with VNI 100 in the VXLAN header, and the original Ethernet frame inside:
- host1's ARP request for 10.100.0.2 is a broadcast, so leaf1 sends a copy to every VTEP in VNI 100's flood list (just leaf2 here).
- host2's ARP reply comes straight back, unicast.
- The pings follow the same path. (The capture also caught both hosts' IPv6 router solicitations: broadcast-like traffic is flooded the same way.)
The kernel's forwarding table on leaf1's vxlan100 shows what EVPN programmed: the all-zeros entry pointing at 10.0.0.12 is the flood list, and host2's MAC points at VTEP 10.0.0.12 marked extern_learn. It was installed by the control plane, not learnt from traffic.
Where to go next
This lab stretches one layer-2 segment. Real fabrics usually add:
- Symmetric IRB with an anycast gateway: every leaf routes between VNIs, with the same gateway IP and MAC on every leaf, using a layer-3 VNI per tenant VRF and type 5 (IP prefix) routes.
- ARP suppression: leaves answer ARP from what EVPN already knows, so ARP broadcasts never cross the fabric.
- Multihoming: one host attached to two leaves, with type 1 and type 4 routes and Ethernet segment identifiers.
- Two spines, for redundancy.
root@host1:~# ping -c 2 10.100.0.2
PING 10.100.0.2 (10.100.0.2): 56 data bytes
64 bytes from 10.100.0.2: seq=0 ttl=64 time=0.138 ms
64 bytes from 10.100.0.2: seq=1 ttl=64 time=0.521 ms
--- 10.100.0.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.138/0.329/0.521 ms- Lines 3–4: Same subnet, different leaves.
leaf1# timeout 8 tcpdump -lni eth0 -c 4 udp port 4789
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:33:34.334627 IP 10.0.0.11.49746 > 10.0.0.12.4789: VXLAN, flags [I] (0x08), vni 100
IP6 fe80::9cc3:ddff:fe10:d715 > ff02::2: ICMP6, router solicitation, length 16
14:33:34.334712 IP 10.0.0.12.37656 > 10.0.0.11.4789: VXLAN, flags [I] (0x08), vni 100
IP6 fe80::5021:acff:fec9:3b30 > ff02::2: ICMP6, router solicitation, length 16
14:33:35.325941 IP 10.0.0.11.38812 > 10.0.0.12.4789: VXLAN, flags [I] (0x08), vni 100
ARP, Request who-has 10.100.0.2 tell 10.100.0.1, length 28
14:33:35.326006 IP 10.0.0.12.38812 > 10.0.0.11.4789: VXLAN, flags [I] (0x08), vni 100
ARP, Reply 10.100.0.2 is-at 02:00:00:00:02:02, length 28
4 packets captured
6 packets received by filter
0 packets dropped by kernel- Line 8: VXLAN between the loopbacks, VNI 100…
- Line 9: …carrying host1's ARP broadcast.
- Line 11: The reply, unicast.
leaf1# bridge fdb show dev vxlan100
52:21:ac:c9:3b:30 master br100
02:00:00:00:02:02 vlan 1 extern_learn master br100
02:00:00:00:02:02 extern_learn master br100
46:09:a5:a1:d5:f5 vlan 1 master br100 permanent
46:09:a5:a1:d5:f5 master br100 permanent
00:00:00:00:00:00 dst 10.0.0.12 self permanent
02:00:00:00:02:02 dst 10.0.0.12 self extern_learn- Line 7: The flood list: all-zeros MAC to leaf2.
- Line 8: host2's MAC, installed by the control plane (extern_learn).
Check your understanding
host1 sends an ARP broadcast. How does it reach host2 without multicast in the underlay?
- leaf1 copies it to every VTEP in VNI 100's flood list, built from type-3 routes
- The spine floods it
- It doesn't; ARP is suppressed
- Through spanning tree