FRRouting release 10.6 promised “BGP IPv6 VTEP support,” claiming “it enables EVPN deployments using IPv6 tunnel endpoints while maintaining full backward compatibility with IPv4 VTEPs.” Of course, I had to try it out, and since we already have EVPN over IPv6 running on Arista EOS (since netlab release 26.01), I decided to set up a simple lab with an Arista cEOS device running release 4.35.2F and the latest FRRouting container.

I was not exactly surprised when it did not work. While Arista accepted FRRouting EVPN routes, the FRRouting BGP daemon rejected routes sent by Arista EOS:

2026-04-02 15:04:10 [INFO] bgpd: [N9HHH-F8H1M] %ADJCHANGE: neighbor 2001:db8:0:1::1(Unknown) in vrf default Up
2026-04-02 15:04:10 [ERR!] bgpd: [ZYQP8-F7JMG][EC 33554440] Bad PMSI tunnel attribute length 21 for IR
2026-04-02 15:04:10 [WARN] bgpd: [RWQFK-BA2JR][EC 33554488] 2001:db8:0:1::1: Attribute PMSI_TUNNEL_ATTRIBUTE, parse error - treating as withdrawal
2026-04-02 15:04:10 [ERR!] bgpd: [QWG8G-NT6EJ][EC 33554455] 2001:db8:0:1::1(Unknown) rcvd UPDATE with errors in attr(s)!! Withdrawing route.

Looking at the EVPN routes in the BGP table on Arista EOS reveals the dirty detail: the encoding of the PMSI_TUNNEL_ATTRIBUTE differs between the two implementations.

swe#show bgp evpn route-type imet detail
BGP routing table information for VRF default
Router identifier 10.0.0.1, local AS number 65000
BGP routing table entry for imet 2001:db8:0:1::1, Route Distinguisher: 10.0.0.1:1000
 Paths: 1 available
  Local
    - from - (0.0.0.0)
      Origin IGP, metric -, localpref -, weight 0, tag 0, valid, local, best
      Extended Community: Route-Target-AS:65000:1000 TunnelEncap:tunnelTypeVxlan
      VNI: 101000
      PMSI Tunnel: Ingress Replication, MPLS Label: 101000, Leaf Information Required: false, Tunnel ID: 2001:db8:0:1::1
BGP routing table entry for imet 2001:db8:0:2::1, Route Distinguisher: 10.0.0.2:1000
 Paths: 1 available
  Local
    2001:db8:0:2::1 from 2001:db8:0:2::1 (10.0.0.2)
      Origin IGP, metric -, localpref 100, weight 0, tag 0, valid, internal, best
      Extended Community: Route-Target-AS:65000:1000 TunnelEncap:tunnelTypeVxlan
      VNI: 101000
      PMSI Tunnel: Ingress Replication, MPLS Label: 101000, Leaf Information Required: false, Tunnel ID: 0.0.0.0

As you can see from the printout, Arista EOS uses an IPv6 address as the PMSI Tunnel ID (2001:db8:0:1::1) while FRRouting uses an IPv4 address (0.0.0.0) even though the next hop of the EVPN route (the VTEP IP address) is an IPv6 address. That’s still OK (at least Arista EOS recognizes that), but FRRouting barks at an EVPN route with an IPv6 next hop and an IPv6 PMSI Tunnel ID and rejects it.

What Exactly Is the PMSI Tunnel Attribute

The PMSI Tunnel attribute (defined in RFC 6514) is used with IMET (type 3) EVPN routes to tell EVPN neighbors which BUM replication the device uses. The usual values you’d see in an EVPN/VXLAN environment are 3/4 (for multicast replication) or 6 (for ingress replication) (valid values can be found in an IANA registry).

The format of the PMSI Tunnel attribute is defined in Section 5 of RFC 6514, which defines the Tunnel ID as a variable-length field (making both IPv4 and IPv6 addresses acceptable values). Furthermore, it says:

When the Tunnel Type is set to Ingress Replication, the Tunnel Identifier carries the unicast tunnel endpoint IP address of the local PE that is to be this PE’s receiving endpoint address for the tunnel.

One could switch into the full angels dancing on pins mode and argue whether the value 0.0.0.0 is a valid value for the Tunnel ID, but most implementations seem to use a common-sense approach, saying “meh, it probably means ignore it” (or we wouldn’t be able to use FRRouting as a probe device in EVPN-over-IPv4 integration tests). Rejecting IPv6 as the PMSI Tunnel Attribute when running EVPN over IPv6 is probably a step too far, or maybe I’m just missing a nerd knob, in which case I’d love to hear about it. Here are the relevant parts of my FRRouting BGP/EVPN configuration:

router bgp 65000
 bgp router-id 10.0.0.2
 no bgp default ipv4-unicast
 bgp bestpath as-path multipath-relax
 neighbor 2001:db8:0:1::1 remote-as 65000
 neighbor 2001:db8:0:1::1 description swe
 neighbor 2001:db8:0:1::1 update-source lo
 use-underlays-nexthop-weight
 !
 address-family ipv6 unicast
  network 2001:db8:0:2::/64
  neighbor 2001:db8:0:1::1 activate
  neighbor 2001:db8:0:1::1 next-hop-self
 exit-address-family
 !
 address-family l2vpn evpn
  neighbor 2001:db8:0:1::1 activate
  advertise-all-vni
  vni 101000
   rd 10.0.0.2:1000
   route-target import 65000:1000
   route-target export 65000:1000
  exit-vni
  advertise-svi-ip
  advertise ipv6 unicast
 exit-address-family
exit

Want To Try It Out?

Here’s the lab topology I used (just in case you want to reproduce or fix the behavior):

---
provider: clab

addressing:
  loopback:
    ipv6: 2001:db8::/48
    ipv4: False
  p2p:
    ipv4: False
    ipv6: True

bgp.as: 65000
defaults.vxlan.use_v6_vtep: True

vlans:
  tenant.links: [ swe, swf ]

module: [ ospf, bgp, vlan, vxlan, evpn ]

nodes:
  swe.device: eos
  swf.device: frr

links: [ swe-swf ]

Finally, a note to the great engineers developing FRRouting: in the days of free-to-download network devices running as VMs or containers, please run interoperability tests on new features. In some cases, netlab might be able to help and generate the required device configurations on non-FRR devices.