Weighted ECMP using BGP link bandwidth - weight not propagated in FIB during recursive next-hop resolution
Fedeperrone98 opened this issue · comments
Description
I have an issue with weighted ECMP using BGP link bandwidth.
I'm trying to announce a prefix with iBGP. This prefix is an anycast prefix that is reachable through several next hops. I would like each next hop to have a weight depending on the received link bandwidth. However, during the recursive next hop resolution, the weight information is lost.
Version
/ # uname -r
6.5.0-35-generic
/ # lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm
PE-2-(ingress).2# sh version
FRRouting 10.0 (PE-2-(ingress).2) on Linux(6.5.0-35-generic).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
'--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--sbindir=/usr/lib/frr' '--with-vtysh-pager=/usr/bin/pager' '--libdir=/usr/lib/x86_64-linux-gnu/frr' '--with-moduledir=/usr/lib/x86_64-linux-gnu/frr/modules' '--disable-dependency-tracking' '--enable-rpki' '--disable-scripting' '--enable-pim6d' '--with-libpam' '--enable-doc' '--enable-doc-html' '--enable-snmp' '--enable-fpm' '--disable-protobuf' '--disable-zeromq' '--enable-ospfapi' '--enable-bgp-vnc' '--enable-multipath=256' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' 'build_alias=x86_64-linux-gnu' 'PYTHON=python3'
PE-2-(ingress).1# sh daemons
mgmtd zebra ospfd ospf6d bgpd isisd watchfrr staticd bfdd
How to reproduce
This is the network topology:
This is the running configuration of one of the egress node (PE-3):
PE-3-(egress).1# sh run
Building configuration...
Current configuration:
!
frr version 10.0
frr defaults traditional
hostname PE-3-(egress).1
log file /etc/frr/frr.log
service integrated-vtysh-config
!
ipv6 prefix-list anycast-ip seq 5 permit a::/32 le 128
!
interface eth0
ipv6 address b:0:23::3/64
ipv6 router isis loop
isis circuit-type level-1
exit
!
interface eth1
ipv6 address d:0:1:31::3/64
ipv6 ospf6 area 0
exit
!
interface lo
ipv6 address b:ffff:ffff:3::/128
ipv6 router isis loop
isis circuit-type level-1
isis passive
exit
!
router bgp 100
bgp router-id 0.0.0.3
no bgp ebgp-requires-policy
no bgp default ipv4-unicast
bgp graceful-restart
neighbor VPN peer-group
neighbor VPN remote-as 100
neighbor VPN update-source lo
neighbor b:ffff:ffff:2:: peer-group VPN
no neighbor b:ffff:ffff:2:: enforce-first-as
!
address-family ipv6 unicast
redistribute ospf6
neighbor VPN activate
neighbor VPN route-map anycast-ip out
exit-address-family
exit
!
router ospf6
ospf6 router-id 0.0.0.3
redistribute bgp
exit
!
router isis loop
is-type level-1
net 49.0001.0003.0003.0003.00
topology ipv6-unicast
exit
!
route-map anycast-ip permit 10
match ipv6 address prefix-list anycast-ip
set extcommunity bandwidth 1000
exit
!
route-map anycast-ip permit 20
exit
!
end
This is the running configuration of PE-2-(ingress):
PE-2-(ingress).1# sh ru
Building configuration...
Current configuration:
!
frr version 10.0
frr defaults traditional
hostname PE-2-(ingress).1
log file /etc/frr/frr.log
service integrated-vtysh-config
!
interface eth0
ipv6 address b:0:23::2/64
ipv6 router isis loop
isis circuit-type level-1
exit
!
interface eth1
ipv6 address b:0:25::2/64
ipv6 router isis loop
isis circuit-type level-1
exit
!
interface eth2
ipv6 address e:0:1:21::2/64
ipv6 ospf6 area 0
exit
!
interface lo
ipv6 address b:ffff:ffff:2::/128
ipv6 router isis loop
isis circuit-type level-1
isis passive
exit
!
router bgp 100
bgp router-id 0.0.0.2
no bgp ebgp-requires-policy
no bgp default ipv4-unicast
bgp graceful-restart
bgp bestpath bandwidth default-weight-for-missing
neighbor VPN peer-group
neighbor VPN remote-as 100
neighbor VPN update-source lo
neighbor b:ffff:ffff:3:: peer-group VPN
no neighbor b:ffff:ffff:3:: enforce-first-as
neighbor b:ffff:ffff:5:: peer-group VPN
no neighbor b:ffff:ffff:5:: enforce-first-as
!
address-family ipv6 unicast
redistribute ospf6
neighbor VPN activate
exit-address-family
exit
!
router ospf6
ospf6 router-id 0.0.0.2
redistribute bgp
exit
!
router isis loop
is-type level-1
net 49.0001.0002.0002.0002.00
topology ipv6-unicast
exit
!
end
Expected behavior
This is what I would like to achieve on the receiver node (PE-2) when I run show ipv6 route:
This is what I would like to achieve on the receiver node (PE-2) when I run ip -6 route show:
i.e., I would like the weights to be correctly installed in the FIB.
I obtained the expected behavior by slightly changing the above configuration. I simply not specify any source address to use for the BGP session:
PE-2:
....
router bgp 100
bgp router-id 0.0.0.2
no bgp ebgp-requires-policy
no bgp default ipv4-unicast
bgp graceful-restart
bgp bestpath bandwidth default-weight-for-missing
neighbor VPN peer-group
neighbor VPN remote-as 100
neighbor b:0:23::3 peer-group VPN
no neighbor b:0:23::3 enforce-first-as
neighbor b:0:25::5 peer-group VPN
no neighbor b:0:25::5 enforce-first-as
!
address-family ipv6 unicast
redistribute ospf6
neighbor VPN activate
exit-address-family
exit
....
PE-3:
.....
router bgp 100
bgp router-id 0.0.0.3
bgp log-neighbor-changes
no bgp ebgp-requires-policy
no bgp default ipv4-unicast
bgp graceful-restart
neighbor VPN peer-group
neighbor VPN remote-as 100
neighbor b:0:23::2 peer-group VPN
no neighbor b:0:23::2 enforce-first-as
!
address-family ipv6 unicast
redistribute ospf6
neighbor VPN activate
neighbor VPN route-map anycast-ip out
exit-address-family
exit
.....
Actual behavior
This is what I get on the receiver node (PE-2) with the command show ipv6 route:
This is what I get on the receiver node (PE-2) with the command ip -6 route show:
As you can see, the weight are not propagated in the FIB.
Additional context
It seems that the problem is due to the recursive resolution of the next hop.
I.e., during the recursive resolution of the next hop, you forget to set the weights of the resolved next hops.
I think that the proble is in the function nexthop_set_resolved(...) in the file zebra/zebra_nhg.c.
In such a function simply set the weight of resolved_hop.
Checklist
- I have searched the open issues for this bug.
- I have not included sensitive information in this report.