frr: fix EVPN type-5 forwarding for IPv6 prefixes

[zeeke]

depends on:

• frr: only redirect to VXLAN for remote L3 nexthops #632

EVPN type-5 routes for IPv6 prefixes use v4-mapped nexthop
addresses (::ffff:X.X.X.X) when the VTEP uses IPv4.
These failed for two reasons: grout_add_nexthop() looked up the
RMAC cache with an IPADDR_V6 key but grout_neigh_update_ctx()
stored it under IPADDR_V4, so the hash never matched; and the
nexthop carried GR_AF_IP6, causing vxlan_output to look for an
IPv6 underlay route that does not exist.

Fix both by detecting v4-mapped addresses: extract the embedded
IPv4, store the nexthop as GR_AF_IP4, and look up the RMAC with
the matching IPADDR_V4 key. Add the VXLAN interface redirect that
was missing from the IPv6 path. In ip6_output, derive the VTEP
address family from l3->af instead of hardcoding GR_AF_IP6.

EVPN Type-5 (IP prefix) nexthops now handle IPv6 v4-mapped next-hops (::ffff:X.X.X.X) correctly when the VTEP uses IPv4: in grout_add_nexthop, IS_MAPPED_IPV6 triggers ipv4_mapped_ipv6_to_ipv4, and the L3 nexthop is stored as IPv4 (l3->af = GR_AF_IP4 with l3->ipv4 set to the embedded IPv4) rather than forcing IPv6 (GR_AF_IP6). RMAC cache lookup is performed with the matching VTEP address representation by setting the VTEP key to vtep.ipa_type = IPADDR_V4 / vtep.ipaddr_v4 before calling l3vni_rmac_get, so remote nexthops resolve against the RMAC cached under the IPv4 VTEP entry instead of failing and causing VXLAN forwarding to use an invalid IPv6 underlay route. Native (non-mapped) IPv6 nexthops continue to use GR_AF_IP6 with IPv6 VTEP data.

The missing VXLAN interface redirect on the IPv6 (including mapped) path was fixed: req->nh.iface_id is now set to vxlan_iface_id only inside the if (rmac != NULL) block (guarded by vxlan_iface_id != GR_IFACE_ID_UNDEF), alongside setting the remote nexthop MAC and GR_NH_F_REMOTE flag.

VXLAN datapath VTEP address-family handling was generalized to match the L3 address family: ip_output_process and ip6_output_process now set eth_data->vtep.af = l3->af and populate eth_data->vtep.ipv4 when l3->af == GR_AF_IP4, otherwise populate eth_data->vtep.ipv6 (removing hardcoded IPv4/IPv6 assumptions on the output path).

EVPN L3VPN smoke coverage was extended to dual-stack: smoke/evpn_l3vpn_frr_test.sh enables IPv6 forwarding and adds IPv6 addressing/default routes on both namespaces, updates FRR to redistribute and advertise both IPv4/IPv6 unicast in address-family l2vpn evpn, adds IPv6 Type-5 readiness/installation waits for fd00:16::/64 and fd00:48::/64 (via wait_event using route6 add), validates IPv6 VRF route installation with ip -n evpn-peer -6 route show, and extends connectivity checks with IPv6 pings (ping -6) across the VXLAN L3 overlay.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 7d5c3f52-0e7b-491b-bdda-228ec8df2af0

📥 Commits

Reviewing files that changed from the base of the PR and between 7b0541f and e950717.

📒 Files selected for processing (4)

• frr/rt_grout.c
• modules/ip/datapath/ip_output.c
• modules/ip6/datapath/ip6_output.c
• smoke/evpn_l3vpn_frr_test.sh

🚧 Files skipped from review as they are similar to previous changes (4)

• modules/ip/datapath/ip_output.c
• modules/ip6/datapath/ip6_output.c
• frr/rt_grout.c
• smoke/evpn_l3vpn_frr_test.sh

---

📝 Walkthrough

Walkthrough

The GR nexthop path now handles IPv4 and mapped IPv6 L3VNI nexthops with RMAC-based VXLAN interface rewrites. The VXLAN output path now uses the nexthop address family when building VTEP data. The smoke test now sets up IPv6 on both peers, advertises both IPv4 and IPv6 EVPN Type-5 routes, checks IPv6 route installation, and adds IPv6 connectivity tests.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[rjarry]

Keep this comment, it cannot hurt.

[rjarry]

Same here, keep the comment just above l3vni_rmac_get():

grout/frr/rt_grout.c

Line 741 in 45afc2b

// Apply cached RMAC from EVPN NEIGH install if available.

grout/frr/rt_grout.c

Line 744 in 45afc2b

rmac = l3vni_rmac_get(req->nh.vrf_id, &vtep);