On Sat, Oct 29, 2022 at 10:29:25PM +0000, Andy Smith via Bird-users wrote:
Hi,
On BIRD 2.0.7 I've got some eBGP sessions with this config:
... The session establishes and 2001:db8::64:607b sends me some 591 IPv6 prefixes, however only 385 of them end up in my routing table, without any logging as to why.
I've done "debug uplinka6 all" and then "restart uplinka6" and there is no mention in the logs at all of any of the missing prefixes yet I can see them in a tcpdump so I know 2001:db8::64:607b is sending. Also the operator of 2001:db::64:607b is convinced they are being advertised correctly.
Watching "ip monitor route" I also see no mention at all of the prefixes I'm not getting.
Is there any kind of enhanced debugging I can do to work out why BIRD does not do anything with some of those prefixes?
Hi Debugging is fixed in v2.0.9, now it logs a detailed reason and all rejected prefixes.
All of those have nexthop 2001:db8::64:608a that being another of my servers, so to experiment I tried adding a route like BIRD would:
# ip route add 2001:db8:1f1:c00::/56 via 2001:db8::64:608a metric 500
and did get:
RTNETLINK answers: No route to host
which is odd because there is a route that was accepted for this nexthop:
$ ip route get 2001:baf::64:608a 2001:db8::64:608a from :: via 2001:db8::64:607b dev bond0 proto bird src 2001:db8:0:1f1::e metric 500 pref medium
If 2001:db8::64:608a is not directly reachable, but reachable through another route, then you need recursive next hop resolution. That is enabled by default just for IBGP / multihop sessions, as it is usually not needed for EBGP / direct sessions. See: https://bird.network.cz/?get_doc&v=20&f=bird-6.html#bgp-gateway Try: protocol bgp uplinka6 { local 2001:db8::64:607a as 64607; neighbor 2001:db8::64:607b as 64943; hold time 30; ttl security on; ipv6 { import all; export filter bgp6_out; gateway recursive; }; } -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."