Hello Aleksander
That’s an excellent and very insightful question. Your troubleshooting process is perfect, and your hypothesis is correct. You have pinpointed the reason for the failure.
Let’s break down the “why” in detail.
The behavior you’re observing is a direct result of two interacting mechanisms: the default next-hop-self rule of eBGP and the VTEP source validation check performed by the VXLAN data plane.
The Control Plane Problem: eBGP next-hop-self
In an eBGP EVPN fabric, your leaf switches are in different ASes.
- When LEAF1 advertises its EVPN routes (like the Type-3 route for BUM traffic handling) to LEAF2, the eBGP protocol rules dictate that it must change the NEXT_HOP attribute to its own source IP address used for the peering.
- LEAF1’s VTEP source is its Loopback0 IP (3.3.3.3) and its physical link IP for peering is 192.168.13.3.
- LEAF1 sends the BGP update, but changes the next-hop from 3.3.3.3 to 192.168.13.3.
- LEAF2 receives this update and installs the route. It now populates its list of valid remote VTEPs (the NVE peer list) for that VNI with the IP 192.168.13.3. It has no knowledge of 3.3.3.3 from the control plane.
- You can verify this on LEAF2 before the fix with:
show bgp l2vpn evpn all(Notice the Next Hop for routes from LEAF1)show nve peers(Notice that LEAF1’s VTEP IP 3.3.3.3 is missing)
The Data Plane Impact: VTEP Source Validation
Now, for the data plane:
- When a server like S1 sends an ARP request, LEAF1 encapsulates it in a VXLAN packet. The outer source IP of this packet is its VTEP address, which is 3.3.3.3 (from Loopback0).
This packet is sent to the VNI’s multicast group and is received by LEAF2. - Upon receipt, LEAF2 performs a critical security and loop-prevention check: “Did this packet come from a valid, known VTEP for this VNI?”
- It checks the outer source IP (3.3.3.3) against its NVE peer list.
- As we established, the list only contains 192.168.13.3. The check fails because 3.3.3.3 is an unknown source. The packet is silently dropped.
This is precisely what you observed with your packet capture. The packet enters LEAF2 but is dropped before it can be decapsulated and sent to the local interface. Good going in your diagnosis! If you need any other help or clarification, let us know!
I hope this has been helpful!
Laz