frr
frr copied to clipboard
FRRouting
bgpd: fix use real SID in BGP nexthop tracking
When receiving an SRv6 BGP update, the nexthop tracking is used to find out the reachability of the BGP update.
show bgp ipv6 vpn fd00:200::/64
Paths: (1 available, best #1) [..] 4:4::4:4 from 4:4::4:4 (4.4.4.4) Origin incomplete, metric 0, localpref 100, valid, internal, best (First path received) Extended Community: RT:52:100 Remote label: 16 Remote SID: 2001:db8:f4:: Last update: Mon Mar 11 11:50:04 2024
The IPv6 address used is the "Remote SID". Actually, this value is incomplete. Remote SID stands for the attribute value received in BGP, while the label value determines a complement of SRv6 SID value. The transposition technique authorises that in BGP, and in the above case, the incoming BGP update has used the transposition length.
When there is a transposition in the SID attribute available, use the real SID address. The nexthop tracking will use that forged address.
show bgp nexthop
Current BGP nexthop cache: 4:4::4:4 valid [IGP metric 30], #paths 0, peer 4:4::4:4 gate fe80::dced:1ff:fed6:878c, if ntfp3 Last update: Mon Mar 11 11:50:02 2024 2001:db8:f4:1:: valid [IGP metric 0], #paths 2 gate fe80::dced:1ff:fed6:878c, if ntfp3
Fixes: 26c747ed6c0b ("bgpd: extend make_prefix to form srv6-based prefix")
How does
show bgp nexthoplook before this change?
before this change, we were using the ipv6 address block length value only. after this change, we also see the function part, which is the exact SID value.
How does
show bgp nexthoplook before this change?
after:
> # show bgp nexthop
> Current BGP nexthop cache:
> 4:4::4:4 valid [IGP metric 30], #paths 0, peer 4:4::4:4
> gate fe80::dced:1ff:fed6:878c, if ntfp3
> Last update: Mon Mar 11 11:50:02 2024
> 2001:db8:f4:1:: valid [IGP metric 0], #paths 2
> gate fe80::dced:1ff:fed6:878c, if ntfp3
and before, the nexthop was 2001:db8:f4::
CI:rerun libyang version may have changed during execution which caused the failure
