EVPN D-VNI with IPv6 VTEPs: upstream fixes and possible FRR UDP checksum bug

SmokeytheCat · August 10, 2026, 3:51am

I’ve been testing EVPN D-VNI route leaking on VyOS 1.5 rolling using an SVD (external, vnifilter) and IPv6 VTEPs.

I wanted to document this here in case anyone else is testing the same setup.

So far I have run into three issues in the IPv6 D-VNI dataplane path. Two already have upstream fixes:

FRR: 390ddee81c60d706afea99ac128338baa41aa4f1
zebra: fix DVNI route encap type for IPv6 VTEPs

Without this, Zebra uses the IPv4 LWT encapsulation type for an IPv6 VTEP instead of LWTUNNEL_ENCAP_IP6.
Linux: b853b94e848216b82ecaa0d5d3c7f6c9066e32a4
ipv6: Allow for nexthop device mismatch with "onlink"

Without this, Linux rejects the D-VNI route because the remote VTEP gateway and vxlan0 device do not match, despite the route being installed with onlink.

After applying those two fixes, the routes install correctly, but I found what appears to be a third FRR issue.

FRR creates the IPv6 D-VNI route without the LWT csum flag:

encap ip6 id 6600 dst fd69:255:240::11
via inet6 fd69:255:240::11 dev vxlan0 onlink

The resulting VXLAN packet reaches the receiving VTEP with an outer IPv6 UDP checksum of zero. It is visible on the physical underlay interface, but is not decapsulated onto vxlan0.

If I manually replace the same route with:

encap ip6 id 6600 dst fd69:255:240::11 csum
via inet6 fd69:255:240::11 dev vxlan0 onlink

the packet immediately decapsulates correctly. Doing the same for the reverse D-VNI route gives working bidirectional traffic.

I tested a small FRR change which adds:

LWTUNNEL_IP6_FLAGS = TUNNEL_CSUM

to the IPv6 D-VNI LWT attributes, and that also appears to solve the issue without manually modifying the routes.

I’ve opened an upstream FRR issue with the reproducer and proposed fix:

github.com/FRRouting/frr

zebra: IPv6 EVPN D-VNI LWT routes omit UDP checksum flag

opened 03:45AM - 10 Aug 26 UTC

houndsolo

# zebra: IPv6 EVPN D-VNI LWT routes omit UDP checksum flag ## Environment * FR…R 10.6.1 with upstream commit `390ddee81c60d706afea99ac128338baa41aa4f1` * VyOS 1.5 rolling * Linux 6.18.41 with upstream commit `b853b94e848216b82ecaa0d5d3c7f6c9066e32a4` * EVPN Single VXLAN Device: * `external` * `vnifilter` * IPv6 VTEPs * EVPN D-VNI route leaking between VRFs Two fixes were already needed for IPv6 D-VNI: 1. FRR `390ddee81c60d706afea99ac128338baa41aa4f1` `zebra: fix DVNI route encap type for IPv6 VTEPs` 2. Linux `b853b94e848216b82ecaa0d5d3c7f6c9066e32a4` `ipv6: Allow for nexthop device mismatch with "onlink"` After those fixes, D-VNI routes install correctly, but I found what appears to be another IPv6-specific issue. ## Actual behavior FRR installs a D-VNI route similar to: ```text 10.8.0.0/16 encap ip6 id 6600 src :: dst fd69:255:240::11 hoplimit 0 tc 0 via inet6 fd69:255:240::11 dev vxlan0 onlink ``` Traffic generated by this route reaches the remote VTEP with an outer IPv6 UDP checksum of zero: ```text fd69:255:240::20.42447 > fd69:255:240::11.4789: [bad udp cksum 0x0000 -> ...] VXLAN, flags [I], vni 6600 ``` The packet is visible on the receiving physical interface, but is not decapsulated onto `vxlan0`. ## Reproducer / workaround Replacing the same route manually with the LWT `csum` flag fixes the dataplane immediately: ```bash ip route replace table lylat_lan 10.8.53.1/32 \ encap ip6 id 6600 \ dst fd69:255:240::11 \ csum \ via inet6 fd69:255:240::11 \ dev vxlan0 onlink ``` After adding `csum`, the receiving VTEP shows a valid UDP checksum and the packet follows the expected path: ```text eth1 -> vxlan0 -> bridge -> destination VRF ``` Applying the same workaround to the reverse D-VNI route makes traffic fully bidirectional. ## Expected behavior For native IPv6 VTEPs, FRR-installed D-VNI LWT routes should request an outer UDP checksum, equivalent to: ```text encap ip6 ... csum ``` ## Proposed fix `_netlink_nexthop_encode_dvni_label()` already writes `LWTUNNEL_IP6_DST` for native IPv6 VTEPs. Adding `LWTUNNEL_IP6_FLAGS` with the checksum bit appears to fix the issue: ```c if (!nl_attr_put16(nlmsg, buflen, LWTUNNEL_IP6_FLAGS, htons(0x01))) return false; ``` Conceptually this is: ```text LWTUNNEL_IP6_FLAGS = TUNNEL_CSUM ``` The Linux `TUNNEL_CSUM` flag is defined as the 16-bit value `0x01` in network byte order. Therefore `htons(0x01)` is used here to encode the equivalent value without relying on `TUNNEL_CSUM` being available in FRR's bundled Linux UAPI headers. In other words: ```c htons(0x01) ``` is intended to be equivalent to: ```c TUNNEL_CSUM ``` for this netlink attribute. FRR 10.6.1's bundled `include/linux/if_tunnel.h` does not currently define `TUNNEL_CSUM`, which is why I used the explicit network-byte-order value for testing. I tested this change locally and FRR then installs routes containing `csum`, and D-VNI forwarding works without the manual `ip route replace`.

I’m mainly posting this here for VyOS visibility and in case anyone else is testing D-VNI with IPv6 VTEPs.