You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! For some reason even when the NVE receives an RT-5 route with Gateway IP field filled in, Gateway IP won't be used as the overlay index, even though the corresponding RT-2 route is present in the FIB. RT-5 get installed as "pure" RT-5 routes (with RMAC as the overlay index).
Topology and description
Systems involved
TS-1 (VyOS 1.4) is a tenant router that is peered to PE-1 via a BGPv4 connection. From PE-1's point of view, TS-1 resides in the vrf "Vrf1".
PE-1 (Debian12/FRR 10.0) is an NVE. PE-1 is peered to TS-1 via a BGPv4 session inside a vrf "Vrf1". PE-1 is EVPN-peered to PE-2.
PE-2 (Debian12/FRR 10.0) is an NVE which is EVPN-peered to the PE-1 router.
What the systems are doing
TS-1 advertises three IP prefixes via a BGPv4 connection towards PE-1. The advertised prefixes are 192.168.51.0/24, 192.168.52.0/24, 192.168.53.0/24.
PE-1 advertises these three IP prefixes towards PE-2 as RT-5 routes. The command "advertise ipv4 unicast gateway-ip" was issued on PE-1, so PE-1 fills in the Gateway IP field of the RT-5 routes with the IP address of TS-1 (192.168.100.1).
PE-1 also advertises an RT-2 route for TS-1's IP address (192.168.100.1 on eth1).
PE-2 receives the RT-5 routes and TS-1's RT-2 route from PE-1 and installs them in the FIB.
PE-2 has the command "enable-resolve-overlay-index" configured under the underlay BGP EVPN configuration section.
This is how Wireshark sees one of the RT-5 routes (note that the Gateway IP is non-zero). This was captured on PE-2's e1 interface (facing PE-1).
EVPN NLRI: IP Prefix route
Route Type: IP Prefix route (5)
Length: 34
Route Distinguisher: 00010a8100010001 (10.129.0.1:1)
ESI: 00:00:00:00:00:00:00:00:00:00
Ethernet Tag ID: 0
IP prefix length: 24
IPv4 address: 192.168.51.0
IPv4 Gateway address: 192.168.100.1
VNI: 1000
#!/bin/sh
##############
### sysctl ###
##############
sysctl -w net.ipv4.conf.all.forwarding=1
sysctl -w net.ipv4.conf.ens3.forwarding=0
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv4.conf.default.rp_filter=0
sysctl -w net.ipv4.conf.all.rp_filter=0
###############
### OS Conf ###
###############
hostnamectl set-hostname PE1
###########################
### Physical Interfaces ###
###########################
ip link add dummy0 type dummy
ip address add 10.129.0.1/32 dev dummy0
ip link set dummy0 up
ip link set dev ens4 name e1
ip address add 10.129.11.1/24 dev e1
ip link set dev e1 up
ip link set dev ens9 name e6
###########
### VRF ###
###########
ip link add Vrf1 type vrf table 1000
ip link set Vrf1 up
#############
### VXLAN ###
#############
ip link add br0 type bridge
ip link set br0 master Vrf1
ip link set br0 addr 54:aa:aa:aa:aa:aa
nft 'add table bridge EBTABLES'
nft 'add chain bridge EBTABLES forward { type filter hook forward priority 0; }'
nft 'add rule bridge EBTABLES forward obrname "br0" ether daddr 54:aa:aa:aa:aa:aa drop'
ip link set br0 up
### e6
ip link set e6 master br0
ip link set e6 up
### VNI 1100
nft 'add rule bridge EBTABLES forward obrname "br0" arp daddr ip 192.168.100.254 drop'
ip address add 192.168.100.254/24 dev br0
ip link set br0 up
sysctl -w net.ipv4.conf.br0.arp_accept=1
ip link add vni1100 type vxlan local 10.129.0.1 dstport 4789 id 1100 nolearning
ip link set vni1100 master br0 addrgenmode none
ip link set vni1100 type bridge_slave neigh_suppress on learning off
ip link set vni1100 up
### L3 VNI
ip link add br1 type bridge
ip link set br1 addr 54:00:02:00:01:00
ip link set br1 master Vrf1
ip link set br1 up
ip link add vni1000 type vxlan local 10.129.0.1 dstport 4789 id 1000 nolearning
ip link set vni1000 master br1 addrgenmode none
ip link set vni1000 type bridge_slave neigh_suppress on learning off
ip link set vni1000 up
#!/bin/sh
##############
### sysctl ###
##############
sysctl -w net.ipv4.conf.all.forwarding=1
sysctl -w net.ipv4.conf.ens3.forwarding=0
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv4.conf.default.rp_filter=0
sysctl -w net.ipv4.conf.all.rp_filter=0
###############
### OS Conf ###
###############
hostnamectl set-hostname PE2
###########################
### Physical Interfaces ###
###########################
ip link add dummy0 type dummy
ip address add 10.129.0.2/32 dev dummy0
ip link set dummy0 up
ip link set dev ens4 name e1
ip address add 10.129.11.2/24 dev e1
ip link set dev e1 up
ip link set dev ens9 name e6
###########
### VRF ###
###########
ip link add Vrf1 type vrf table 1000
ip link set Vrf1 up
#############
### VXLAN ###
#############
ip link add br0 type bridge
ip link set br0 master Vrf1
nft 'add table bridge EBTABLES'
nft 'add chain bridge EBTABLES forward { type filter hook forward priority 0; }'
nft 'add rule bridge EBTABLES forward obrname "br0" ether daddr 54:aa:aa:aa:aa:aa drop'
### e6
ip link set e6 master br0
ip link set e6 up
### VLAN 100 / VNI 100
nft 'add rule bridge EBTABLES forward obrname "br0" arp daddr ip 192.168.100.254 drop'
ip address add 192.168.100.254/24 dev br0
ip link set br0 up
sysctl -w net.ipv4.conf.br0.arp_accept=1
ip link add vni1100 type vxlan local 10.129.0.2 dstport 4789 id 1100 nolearning
ip link set vni1100 master br0 addrgenmode none
ip link set vni1100 type bridge_slave neigh_suppress on learning off
ip link set vni1100 up
### L3 VNI
ip link add br1 type bridge
ip link set br1 addr 54:00:02:00:02:00
ip link set br1 master Vrf1
ip link set br1 up
ip link add vni1000 type vxlan local 10.129.0.2 dstport 4789 id 1000 nolearning
ip link set vni1000 master br1 addrgenmode none
ip link set vni1000 type bridge_slave neigh_suppress on learning off
ip link set vni1000 up
Expected behavior
The RT-5 routes get installed with TS-1's IP address (192.168.100.1) as the next-hop. The next-hop is resolved recursively through the RT-2 route for the TS-1 address.
Actual behavior
The RT-5 routes get installed as "pure" RT-5 routes, with the next-hop set to PE-1's VTEP address.
PE-2 FIB:
PE2# show ip route vrf Vrf1
Codes: K - kernel route, C - connected, L - local, S - static,
R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric, t - Table-Direct,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
VRF Vrf1:
B>* 192.168.51.0/24 [20/0] via 10.129.0.1, br1 onlink, weight 1, 00:20:15
B>* 192.168.52.0/24 [20/0] via 10.129.0.1, br1 onlink, weight 1, 00:20:15
B>* 192.168.53.0/24 [20/0] via 10.129.0.1, br1 onlink, weight 1, 00:20:15
C>* 192.168.100.0/24 is directly connected, br0, 00:24:46
B>* 192.168.100.1/32 [20/0] via 10.129.0.1, br1 onlink, weight 1, 00:20:15
L>* 192.168.100.254/32 is directly connected, br0, 00:24:46
Additional context
Looking at the source code it seems to me that the issue could be related to where FRR looks for the resolved next-hop. It seems to look it up in the table which you can see by issuing the "show bgp nexthop" command which contains next-hops of the underlay BGP session. But it's hard for me to say for certain.
Checklist
I have searched the open issues for this bug.
I have not included sensitive information in this report.
The text was updated successfully, but these errors were encountered:
Description
Hi! For some reason even when the NVE receives an RT-5 route with Gateway IP field filled in, Gateway IP won't be used as the overlay index, even though the corresponding RT-2 route is present in the FIB. RT-5 get installed as "pure" RT-5 routes (with RMAC as the overlay index).
Topology and description
Systems involved
What the systems are doing
This is how Wireshark sees one of the RT-5 routes (note that the Gateway IP is non-zero). This was captured on PE-2's e1 interface (facing PE-1).
Version
How to reproduce
TS-1 Config:
PE-1
PE-1 FRR Config:
PE-1 OS Config
PE-2
PE-2 FRR Config
PE-2 OS Config:
Expected behavior
The RT-5 routes get installed with TS-1's IP address (192.168.100.1) as the next-hop. The next-hop is resolved recursively through the RT-2 route for the TS-1 address.
Actual behavior
The RT-5 routes get installed as "pure" RT-5 routes, with the next-hop set to PE-1's VTEP address.
PE-2 FIB:
Additional context
Looking at the source code it seems to me that the issue could be related to where FRR looks for the resolved next-hop. It seems to look it up in the table which you can see by issuing the "show bgp nexthop" command which contains next-hops of the underlay BGP session. But it's hard for me to say for certain.
Checklist
The text was updated successfully, but these errors were encountered: