osrg
L2 EVPN routes not pulled from FRR/Zebra
Running FRR/Zebra (8.1) and GoBGP (3.180.0) on the same host (ubuntu 22.04) with KVM. On the host a VLXAN interface is configured which is connected to a bridge, the bridge is connected to the KVM virtual network that a VM is connected to.
IP Interface Host Output
root@192:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:50:56:8b:c5:be brd ff:ff:ff:ff:ff:ff
altname enp11s0
inet 10.243.176.192/24 brd 10.243.176.255 scope global ens192
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe8b:c5be/64 scope link
valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:f9:0d:7a brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: vxlan9999: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br9999 state UNKNOWN group default qlen 1000
link/ether ba:91:3d:ab:2b:f3 brd ff:ff:ff:ff:ff:ff
inet6 fe80::947b:6aff:fef5:8c31/64 scope link
valid_lft forever preferred_lft forever
5: br9999: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 92:a9:79:75:7b:0d brd ff:ff:ff:ff:ff:ff
inet6 fe80::947b:6aff:fef5:8c31/64 scope link
valid_lft forever preferred_lft forever
6: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br9999 state UNKNOWN group default qlen 1000
link/ether fe:54:00:49:56:6c brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe49:566c/64 scope link
valid_lft forever preferred_lft forever
root@192:~#
The problem is that GoBGP does not receive L2EVPN MAC entries from FRR/Zebra.
FRR/Zebra has the MAC (52:54:00:49:56:6c) entry in the BGP table for the virtual machine, validated the VM to VXLAN interface by pinging from the VM to a random IP and inspecting traffic on the VXLAN interface where the ARPs are seen, further validated as the output below shows.
FRR EVPN MAC
192# show evpn mac vni all detail
VNI 9999 #MACs (local and remote) 2
MAC: 92:a9:79:75:7b:0d
Intf: br9999(5) VLAN: 1 Default-gateway Mac
Sync-info: neigh#: 0
Local Seq: 0 Remote Seq: 0
Uptime: 01:47:30
Neighbors:
fe80::947b:6aff:fef5:8c31 Active
MAC: 52:54:00:49:56:6c
Intf: vnet0(6) VLAN: 0
Sync-info: neigh#: 0
Local Seq: 0 Remote Seq: 0
Uptime: 01:47:30
Neighbors:
No Neighbors
FRR BGP L2VPN
192# show bgp l2vpn evpn
BGP table version is 3, local router ID is 192.168.122.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
EVPN type-1 prefix: [1]:[EthTag]:[ESI]:[IPlen]:[VTEP-IP]
EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 192.168.122.1:2
*> [2]:[0]:[48]:[52:54:00:49:56:6c]
10.243.176.191 32768 i
ET:8 RT:65000:9999
*> [2]:[0]:[48]:[92:a9:79:75:7b:0d]:[128]:[fe80::947b:6aff:fef5:8c31]
10.243.176.191 32768 i
ET:8 RT:65000:9999
*> [3]:[0]:[32]:[10.243.176.191]
10.243.176.191 32768 i
ET:8 RT:65000:9999
Displayed 3 out of 3 total prefixes
192#
FRR Route Table
192# show ip route
Codes: K - kernel route, C - connected, 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,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
K>* 0.0.0.0/0 [0/0] via 10.243.176.254, ens192, 00:07:04
C>* 10.243.176.0/24 is directly connected, ens192, 00:07:04
192#
The FRR configuration is
192# show run
Building configuration...
Current configuration:
!
frr version 8.1
frr defaults traditional
hostname 192
log syslog informational
no ipv6 forwarding
service integrated-vtysh-config
!
router bgp 65000
bgp default l2vpn-evpn
!
# no peering as only using FRR to provide routes to GoBGP
address-family l2vpn evpn
advertise-all-vni
advertise-svi-ip
exit-address-family
exit
!
end
GoBGP is configured as follows
root@192:~# cat /etc/gobgpd.conf
global:
config:
as: 65000
router-id: 10.243.176.192
port: 179
local-address-list:
- 10.243.176.192
apply-policy:
config:
default-import-policy: accept-route
default-export-policy: accept-route
neighbors:
- config:
peer-as: 65000
auth-password: password
neighbor-address: 10.243.176.191
# local-as: 1000
# remove-private-as: all
as-path-options:
config:
allow-own-as: 1
# replace-peer-as: true
afi-safis:
- config:
afi-safi-name: l2vpn-evpn
zebra:
config:
enabled: true
url: unix:/var/run/frr/zserv.api
redistribute-route-type-list:
- wildcard
version: 6
software-name: frr8.1
As the redistribute-route-type-list is set to wildcard (temp for debug, should be bgp only) the connected and static routes are pulled in by GoBGP as shown
GoBGP Global RIB
root@192:~# gobgp global rib
Network Next Hop AS_PATH Age Attrs
*> 0.0.0.0/0 10.243.176.254 01:52:43 [{Origin: i} {Med: 0}]
*> 10.243.176.0/24 0.0.0.0 01:52:43 [{Origin: i} {Med: 0}]
But EVPN routes are not.
GoBGP EVPN Routes
root@192:~# gobgp global rib -a evpn
Network not in table
root@192:~#
It doesn't seem like a FRR/Zebra issue hence raising the issue here.
I tried reproducing the issue and found the exact same result, no routes are imported into GoBGP from Zebra, I don't know if the feature simply isn't there of if it's a bug. The alternative is simply to peer FRR with GoBGP to get the routes in. But I'd much prefer the alternative.
unsubscribe
On Sun, Oct 15, 2023, 13:46 SkalaNetworks @.***> wrote:
I tried reproducing the issue and found the exact same result, no routes are imported into GoBGP from Zebra, I don't know if the feature simply isn't there of if it's a bug. The alternative is simply to peer FRR with GoBGP to get the routes in. But I'd much prefer the alternative.
— Reply to this email directly, view it on GitHub https://github.com/osrg/gobgp/issues/2706#issuecomment-1763458578, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH5T2UJ6CGKRBYYPJDOKD3X7QONRANCNFSM6AAAAAA422KVF4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>
i may be extremely confused, but i have some questions about this PR, please bear with me
- instead of max(current, top - mine_old) why not do max(current - mine_old, top - mine_old) ?
- is it even possible to adequately test this sort of patch without running a couple of gophers on a testnet?
