bgpd: EVPN Type 5 next hop can latch the IPv4 router-id on an IPv6 VXLAN underlay #23268

Found this doing EVPN interop testing on an IPv6-only VXLAN underlay against 10.7.1.

On the per-VRF advertise ipv6 unicast Type 5 path, bgpd sometimes writes the BGP instance's IPv4 bgp router-id into the 16-octet IPv6 next-hop field, zero-padded, instead of the L3VNI's VXLAN tunnel source. It's a startup race: it needs the EVPN session to establish before zebra has published the L3VNI tunnel source to bgpd. Once it latches it doesn't self-heal.

Version: quay.io/frrouting/frr:10.7.1, Linux 7.0.0-30-generic, containerlab.

What I see

# show bgp l2vpn evpn route type prefix
 *>  [5]:[0]:[64]:[2001:db8:110:2::] RD 65000:110
                   a6e:2::                  0         32768 ?
                   ET:8 RT:65000:110 Rmac:6e:f1:60:d7:28:a9

Expected next hop is fd00:110::2, the L3VNI's tunnel source.

It's origination, not display

# show bgp l2vpn evpn neighbors fd00:110::1 advertised-routes
Route Distinguisher: 65000:110
 *> [5]:[0]:[64]:[2001:db8:110:2::]
                   a6e:2::                  0    100      0 ?

So that's what goes on the wire, not just what the CLI prints.

What the value is

a6e:2:: is 0a 6e 00 02 followed by twelve zero octets. 0x0a6e0002 is 10.110.0.2, the bgp router-id on the per-VRF instance. The 4-octet IPv4 identifier lands at the front of the 16-octet field and the rest is zero-filled.

L3VNI state is correct at the same moment

# show evpn vni detail
VNI: 110
  Type: L3
  Tenant VRF: vrf1
  Local Vtep Ip: fd00:110::2
  State: Up

zebra has the right tunnel source. bgpd is holding a stale value from origination.

What clears it

• clear bgp * — no change, still a6e:2::
• ip link set vxlan110 down; ip link set vxlan110 up — re-originates with fd00:110::2
• readdressing the VRF loopback — no effect once it's correct

Resetting the session doesn't re-derive it, so the value is latched at origination rather than recomputed per advertisement.

Frequency

Four fresh deploys left to settle 25s with no peer: correct all four. Four deploys with the peer coming up about a second after the topology: one latched the bad value, three were fine.

Scope

Only the per-VRF advertise ipv6 unicast Type 5 path. Type 2 and Type 3 on the same image and the same underlay carried the correct IPv6 tunnel source on every run.

Config

vrf vrf1
 vni 110
 exit-vrf
!
router bgp 65000
 bgp router-id 10.110.0.2
 no bgp default ipv4-unicast
 neighbor fd00:110::1 remote-as 65000
 address-family l2vpn evpn
  neighbor fd00:110::1 activate
  advertise-all-vni
 exit-address-family
!
router bgp 65000 vrf vrf1
 bgp router-id 10.110.0.2
 address-family ipv6 unicast
  redistribute connected
 exit-address-family
 address-family l2vpn evpn
  advertise ipv6 unicast
  rd 65000:110
  route-target both 65000:110
 exit-address-family

bgp router-id is set explicitly because no interface in the topology holds an IPv4 address.

Repro

1. Build the VRF, L3VNI, bridge, SVI and tenant loopback in the kernel before FRR boots.
2. VXLAN tunnel source is an IPv6 address; no IPv4 anywhere on the underlay link.
3. Start FRR, then bring the EVPN peer up immediately, within a second or so.
4. show bgp l2vpn evpn route type prefix.

The peer here is my own daemon, but that shouldn't matter — FRR's own advertised-routes shows the bad value, so any receiver gets it.