BGP extended next hop capability not working from version 5.0.1

[madhu222]

Description

The route is showing with next hop as IPv4 address instead of next hop ID/IPv6 link local

Steps to Reproduce

1. Have BGP unnumbered neighborship between two systems
2. Have loopback configured on both and assign as router-id for both
3. Advertise a route from one system
4. Check the other system, it will show the route as not stable route in bgp because the next hop will be IPv4 address (loopback) instead of interface ID/IPv6 link local address

###Components
[bgpd]

Versions

• Kernel:Debian 4.9
• FRR: 6.0

Attachments

show ip bgp summary

IPv4 Unicast Summary:
BGP router identifier 3.3.3.3, local AS number 65535 vrf-id 0
BGP table version 0
RIB entries 1, using 160 bytes of memory
Peers 2, using 41 KiB of memory
Peer groups 2, using 128 bytes of memory

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/P
fxRcd
br200           4      65001      79      87        0    0    0 00:09:08
    0
br10            4      65002     119     106        0    0    0 00:08:09
    1

show ip bgp
BGP table version is 0, local router ID is 3.3.3.3, vrf id 0
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
   40.1.1.0/24      4.4.4.4                  0             0 65002 i

interface lo100
 ip address 3.3.3.3/32
!
router bgp 65535
 bgp router-id 3.3.3.3
 bgp bestpath as-path multipath-relax
 bgp bestpath compare-routerid
 neighbor fabric peer-group
 neighbor fabric remote-as 65001
 neighbor fabric capability extended-nexthop
 neighbor fabric1 peer-group
 neighbor fabric1 remote-as 65002
 neighbor fabric1 capability extended-nexthop
 neighbor br200 interface peer-group fabric
 neighbor br10 interface peer-group fabric1
 !
 address-family ipv6 unicast
  neighbor fabric activate
  neighbor fabric1 activate
 exit-address-family

Thanks!

[jllorente]

I ran into the same problem and decided to bisect the commit that introduced the problem.
I think this is the culprit: 4c39114

However, I was able to get around the issue by removing "neighbor fabric capability extended-nexthop", since the neighbor declared via an interface already use extended-nexthop by default. As a result, frr will announce and negotiate the extended-nexthop capability making unnumbered BGP work again!

[madhu222]

@jllorente thanks. I tested it out. It works for me as well without capability extended next-hop

[madhu222]

@donaldsharp Can you please check the commit as @jllorente mentioned and fix it?

[jllorente]

Hi @donaldsharp , did you have time to look into this issue? Were you able to verify if the issue was indeed introduced in that commit?

[sworleys]

@donaldsharp @jllorente The issue referenced here #3721 seems to have been fixed with #3868

Has this been resolved with it as well?