Closed Sushi1324 closed 1 month ago
This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose
label in order to avoid having this issue closed.
This issue will be automatically closed in the specified period unless there is further activity.
Describe the bug
This appears to specifically be an issue with compatibility between Juniper EVPN-VXLAN and FRR EVPN. I have Juniper QFX5120 switches in a leaf and spine design configured as the core for my VXLAN underlay to route between several Proxmox Hypervisors running FRR to serve as the EVPN control plane. In order to provide an uplink out of the Proxmox cloud, I have enabled my two Juniper Spine switches as VTEPs and configured ESI-LAG to an upstream router.
FRR is learning the MAC associations for the upstream device (20:ed:47:98:5a:40) correctly from the 2 Spines with the ESI I have configured on my Juniper switches:
My local guest behind the VXLAN VTEP on my Hypervisor can ping the Upstream router, but gets DUP ICMP warnings. When I investigated further, it appears that while FRR learns the correct ESI for the LAG configured by Juniper, it is not creating an association between the ESI and any remote VTEPs and is instead flooding all VTEPs with any traffic destined to the routers MAC address. This means that the Host is sending a VXLAN encapsulated ICMP request message to both Spine switches which are both being forwarded to the upstream router, which then replies to both, hence the DUP ICMP warnings.
I can see that the Type 4 routes from Juniper advertise that this ESI should be associated with the VTEP IPs of both spine switches:
But when I view the ESI there are no associated VTEPs:
The Nexthop group displayed doesn't seem to exist either from what I can find but I'm likely not looking in the correct place.
Is there any reason that FRR would be ignoring the Type 4 routes that indicate which VTEPs are associated with a particular ESI? I know examples I've seen with FRR for configuring ESI-LAG the ESI shows Type information and should know the remote VTEP IPs to use, so I believe if I can fix the ESI to VTEP associations this should work properly.
To Reproduce
Configure a standard EVPN implementation on FRR. My configuration is generated via Proxmox tooling but should be fairly standard, using an ISIS core to advertise/learn loopback IPs to use as VTEP endpoints with my two Juniper Spine switches (100.120.0.20+21) acting as route reflectors:
Then on two Juniper switches, configure them as remote VTEPs, then add an LACP Bond with the same ESI and System ID configured on both devices. In my case no additional BGP sessions are needed as I am using the Spine/Route Reflectors as the VTEPs/ESI-LAG switches. Here is the relevant configuration on one of the Juniper Spines:
The second switch configured as part of the ESI lag looks nearly identical besides device specific IPs
Expected behavior I expect the FRR control plan to associate the ESI learned through BGP with the 2 specific VTEP Endpoints I have configured that are advertised via Type 4 routes. Then traffic destined for the ESI is sent to 1 VTEP endpoint or another rather than flooding all VTEP endpoints on the particular VNI, resulting in duplicated packets.
Versions