BGP fails to determine nexthop routed directly to interface #15535
Comments
|
Could you try enabling |
yep, the same: |
|
Could you show |
and bgpd.log: anyway, default is wrong direction for that route, it should point to wg0 |
|
@vgrebenschikov can we get the following outputs also: |
|
@vgrebenschikov can you post the wireguard config (minus any keys of course) ? |
|
can you please provide the configuration topology for recreation of this bug. |
|
Even if a fix were made to propagate directly connected routes (where the outgoing interface has no IP address assigned) from the kernel to the BGP routing table, it would not enable sending traffic in the reverse direction. In a Data Center environment where traffic is predominantly TCP-based, bidirectional traffic must be expected. Therefore, an interface such as wg0 without an IP address configured would be considered incomplete from the Data Center perspective. |
It has IP address assigned, but, it is not "broadcast" interface, so, it, like any onther P2P interface, has address on our end and routes into interface, that it. Similar problem with tun interface for example. Kernel is very certan on this - somehow we have lost scenario a. above for BGP ... |
topology is trivial, just two hosts connected with wireguard, and expected that BGP session will work over the tunnel. 
|
can you please provide configuration for better understanding. |
# ifconfig wg0
wg0: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
options=80000<LINKSTATE>
inet 172.22.4.192 netmask 0xffffffff
# netstat -rn | fgrep wg0
172.22.4.253 link#6 UHS wg0
# ping -c1 172.22.4.253
PING 172.22.4.253 (172.22.4.253): 56 data bytes
64 bytes from 172.22.4.253: icmp_seq=0 ttl=64 time=74.567 ms
# vtysh -e 'show run'
...
router bgp 65021
no bgp ebgp-requires-policy
no bgp network import-check
neighbor 172.22.4.253 remote-as 65022
neighbor 172.22.4.253 interface wg0
neighbor 172.22.4.253 update-source wg0
# vtysh
srv# show ip bgp 172.22.9.0/24
BGP routing table entry for 172.22.9.0/24, version 0
Paths: (1 available, no best path)
Not advertised to any peer
65022
172.22.4.253 (inaccessible) from 172.22.4.253 (172.22.9.1)
Origin IGP, invalid, external
Last update: Thu Jun 27 19:17:33 2024
Notice:
# route -n get 172.22.4.253
route to: 172.22.4.253
destination: 172.22.4.253
fib: 0
interface: wg0
flags: <UP,HOST,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1420 1 0
# vtysh -e 'show ip route 172.22.4.253'
Routing entry for 172.22.0.0/16
Known via "ospf", distance 110, metric 120, best
Last update 00:06:56 ago
* 172.22.2.1, via em0, weight 1
What will fix situation - assignment of the subnet which will include other end of tunnel on wg0 interaface, now FRR think that other end is reachable, but it fact it was reachable before: # ifconfig wg0 172.22.4.192/26
# vtysh -e 'show ip route 172.22.4.253'
Routing entry for 172.22.4.192/26
Known via "connected", distance 0, metric 1, best
Last update 00:01:01 ago
* directly connected, wg0
# vtysh -e 'show ip bgp 172.22.9.0/24'
BGP routing table entry for 172.22.9.0/24, version 6
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
172.22.4.253
65022
172.22.4.253 (metric 1) from 172.22.4.253 (172.22.9.1)
Origin IGP, valid, external, best (First path received)
Last update: Thu Jun 27 19:17:33 2024probably, the problem is connected with th issue #9185 |
|
Is it possible to test this with the latest releases? |
Tested on 10.0 - situation the same |
|
Please provide the point-to-point configuration details since I am having trouble with it. Not testing with the most recent version. |
Description
BGP route shown as "no best path" and next-hop shown as (inaccessible):
while route is fine (Kernel), but it directly points to interface (point-to-point):
or in system:
adding the same static route does not change anything:
But, if I assign whole subnet to interface:
Everything works as expected:
Looks like there is a problem in next-hop availability algorythm.
FRRouting 8.5.4 (srv) on FreeBSD(14.0-RELEASE).
Version
How to reproduce
use any point-to-point interface without sub-net (i.e. wg0) to make BGP session
Expected behavior
Valid direct route to interface should be accounted for installing BGP routes to the interface
as:
Actual behavior
BGP route is not installed:
Additional context
No response
Checklist
The text was updated successfully, but these errors were encountered: