EVPN Support for IPv6 underlay

[taspelund]

The Linux kernel supports IPv6 underlay for VXLAN tunnels. It would be nice if EVPN also supported using a v6 underlay (v6 next-hops for EVPN prefixes).

[MalteJ]

+1

[lmcerbo-ka]

Same here. I'm looking for this feature as well

[jice]

Ran into this limitation while deploying green field. Pretty important feature and supported by every major vendor.

https://news-blogs.cisco.com/datacenter/vxlanv6-vxlanv-what
https://eos.arista.com/eos-4-24-1f/ipv6-underlay-support-for-vxlan-with-evpn-control-plane/
https://apps.juniper.net/feature-explorer/feature-info.html?fKey=7914&fn=EVPN-VXLAN%20support%20for%20VXLAN%20Gateways%20using%20an%20IPv6%20underlay

[tobymitico]

+1

[willawork]

+1 for this.

It's going to affect a lot of products out there that rely on it (including big-label products) and prevent IPv6 being used as the transport.

[mestery]

Also interested in this feature.

[mestery]

It seems you can configure IPv6 VTEPs, and BGP works between them, but the routes which get distributed seem to point next hop addresses to the router-id, which is tied to IPv4, thus not allowing the various EVPN route types to be exchanged back and forth.

[donaldsharp]

there still is no support for this feature. it needs to be added by a developer

[samschmitt22]

+1 for this feature as well.

[enygren]

+1 for this feature. There are significant benefits to being able to run underlay infrastructure as IPv6-only, especially in larger environments where neither rfc1918 nor public IPv4 scale well. It's also simpler to be able to move an underlay to be IPv6-only rather than needing to keep it dual-stacked.

[andrediashexa]

+1

IPv6 being used as underlay will scale much better than IPv4.

[ayubio]

Since IPv4 address exhaustion, IPv4 became obsolete since new organizations, ISPs, data centers are unable to obtain new IPv4 address to take part of internet. IPv6 is the internet standard and IPv4 should be treated as a legacy backward compatibility mode.

Since FRRouting is all about the present and the future, all functionalities shall support IPv6. +1 for this feature.

[gabrielhce]

+1 for this feature

[jonenavix]

IPv6 being used as underlay will scale much better than IPv4!

+1 for this feature.

[paulomazoni]

+1 let's push IPV6!

[MalteJ]

Nice fake accounts!

[thiagomrangel]

Today IPv6 is the standard Internet protocol, so it's a shame not to have it as an underlay.
+1 for this feature

[andrediashexa]

I don't think it's a shame, but if we can use IPv6 as underlay will be usefull.

Besides, Proxmox is using FRR to create VXLAN and EVPN, and because IPv4 exhaustion, use IPv6 will helpfull to connect multiple datacenters.

[bernardesarthur]

I also think it's necessary to have IPv6 support for this functionality.

[willawork]

I was able to get an intermediate without IPv4 transport running, used IPv4 with IPv6 nexthop IETF Draft and it worked ok, but still had to use IPv4 for the VTEP endpoints and ipv4-unicast enabled in BGP, not IPv6 natively all round.

This issue has been lodged for 3 yrs now, surely there would have been some movement at the ranch by now. I'd put something together but my code would need more editing than would be useful by someone with the skills doing it from scratch.

[rnalrd]

Really? Nothing going on here besides a bunch of people crying for this feature (myself included)? 😄

[donaldsharp]

As with all things open source. Someone needs to step up and do the work..... If you are using FRR through one of it's vendors I would suggest putting pressure on them that way to get the functionality

[mikemallin]

We've been developing this at Cisco and are starting the process of upstreaming this back to the community. Stay tuned!

[andrediashexa]

We've been developing this at Cisco and are starting the process of upstreaming this back to the community. Stay tuned!

Thank you, Mike!

[wido]

With PR #15900 merged it seems that the first work is done, but it doesn't work yet, am I correct? I tried on a few test VMs, but FRR would still use the router-id as vtep source address.

[ross-alexander]

I'm testing with the latest git (2024.11.03, default branch) and maybe I'm not getting the configuration right but looks to be missing something still. I got it working with IPv4 which is why the neighbor clause is using IPv4 addresses. Let me know if you want me to run some checks / debugs.

EVPN (frr) configuration

router bgp 65000 vrf vxlan
neighbor 10.0.0.2 remote-as internal
neighbor 10.0.0.2 update-source vxlan
!
address-family ipv4 unicast
redistribute connected
exit-address-family
!
address-family ipv6 unicast
redistribute connected
exit-address-family
!
address-family l2vpn evpn
neighbor 10.0.0.2 activate
advertise-all-vni
exit-address-family
exit

iproute2 configuration

I'm using loopback addresses on an Linux L3 VRF (br51 / nvi551). This works with IPv4 (br50 / vni550).

ip link add br50 type bridge
ip link set br50 addrgenmode none
ip link set br50 addr 00:16:3e:00:05:21
ip link add vni550 type vxlan local 10.0.0.3 dstport 4789 id 550 nolearning dev vxlan
ip link set vni550 master br50 addrgenmode none
ip link set vni550 type bridge_slave neigh_suppress on learning off
sysctl -w net.ipv4.conf.br50.forwarding=0
sysctl -w net.ipv6.conf.br50.forwarding=0
ip link set vni550 up
ip link set enp0s6 master br50
ip link set enp0s6 up

ip link add br51 type bridge
ip link set br51 addrgenmode none
ip link set br51 addr 00:16:3e:00:05:22
ip link add vni551 type vxlan local 2001:470:688f::3 dstport 4789 id 551 nolearning dev vxlan
ip link set vni551 master br51 addrgenmode none
ip link set vni551 type bridge_slave neigh_suppress on learning off
sysctl -w net.ipv4.conf.br51.forwarding=0
sysctl -w net.ipv6.conf.br51.forwarding=0
ip link set vni551 up

gimel.prax.hepazulian.net# show evpn vni 550
VNI: 550
Type: L2
Vlan: 0
Bridge: br50
Tenant VRF: default
VxLAN interface: vni550
VxLAN ifIndex: 8
SVI interface: br50
SVI ifIndex: 7
Local VTEP IP: 10.0.0.3
Mcast group: 0.0.0.0
Remote VTEPs for this VNI:
10.0.0.2 flood: HER
Number of MACs (local and remote) known for this VNI: 1
Number of ARPs (IPv4 and IPv6, local and remote) known for this VNI: 0

gimel.prax.hepazulian.net# show evpn vni 551
VNI: 551
Type: L2
Vlan: 0
Bridge: br51
Tenant VRF: default
VxLAN interface: vni551
VxLAN ifIndex: 9
SVI interface:
SVI ifIndex: 0
Local VTEP IP: 0.0.0.0
Mcast group: 0.0.0.0
No remote VTEPs known for this VNI
Number of MACs (local and remote) known for this VNI: 0
Number of ARPs (IPv4 and IPv6, local and remote) known for this VNI: 0
Advertise-gw-macip: No
Advertise-svi-macip: No

[ross-alexander]

I had a look at zebra_l2.h and IPv4 is pretty hardcoded in there for VXLAN and GRE with struct in_addr. I'm not sure what would be recommended data structure change. I can think of two options off the top of my head.

1. Add a family field and then put struct in_addr and struct in6_addr in a union
2. Add a struct in6_addr and just set which ever is required and test both for != IN_ANY where required

An initial code change would be to correctly determine the family and update the interface display code. A steer from somebody would be appriciated.