Debugging advertised prefixes that are seemingly never seen by BIRD
Hi, On BIRD 2.0.7 I've got some eBGP sessions with this config: # bird.conf filter bgp6_out { if (source = RTS_INHERIT) && (net ~ [ 2001:DB8:1F1::/48+ ]) then accept; else reject; } protocol kernel { ipv6 { import all; export filter { krt_prefsrc = 2001:DB8:0:1f1::e; accept; }; }; metric 500; learn; scan time 10; merge paths on; } 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; }; } # END 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? The only suspicious thing in my syslog is: Oct 29 21:21:09 hostname bird: Restarting protocol uplinka6 Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute However, even though I don't know which prefixes these are related to, they do only happen 11 times (every time), not 100+ times as I would expect if that were the culprit. Still, if there is a way to get more information about which prefix/nexthop it doesn't like here, that would also be good. An example from tcpdump that was running while "restart uplinka6" was happening: 20:06:20.516521 IP6 (class 0xc0, hlim 255, next-header TCP (6) payload length: 1460) 2001: db8::64:607b.179 > 2001:db8::64:607a.44737: Flags [.], cksum 0x79e5 (correct), seq 4777:62 17, ack 188, win 16197, length 1440: BGP Update Message (2), length: 621 Multi-Protocol Reach NLRI (14), length: 574, Flags [OE]: AFI: IPv6 (2), SAFI: Unicast (1) nexthop: 2001:db8::64:608a, nh-length: 16, no SNPA 2001:db8:1f1:200::/56 2001:db8:1f1:d00::/56 2001:db8:1f1:e00::/56 2001:db8:1f1:1900::/56 2001:db8:1f1:f003::/64 2001:db8:1f1:f007::/64 2001:db8:1f1:f00d::/64 2001:db8:1f1:f012::/64 2001:db8:1f1:f01a::/64 2001:db8:1f1:f023::/64 2001:db8:1f1:f038::/64 2001:db8:1f1:f03a::/64 2001:db8:1f1:f03b::/64 2001:db8:1f1:f042::/64 2001:db8:1f1:f048::/64 2001:db8:1f1:f052::/64 2001:db8:1f1:f059::/64 2001:db8:1f1:f06d::/64 2001:db8:1f1:f06e::/64 2001:db8:1f1:f07c::/64 2001:db8:1f1:f0b4::/64 2001:db8:1f1:f0bc::/64 2001:db8:1f1:f0c3::/64 2001:db8:1f1:f0c5::/64 2001:db8:1f1:f0e8::/64 2001:db8:1f1:f0ea::/64 2001:db8:1f1:f10d::/64 2001:db8:1f1:f11c::/64 2001:db8:1f1:f120::/64 2001:db8:1f1:f123::/64 2001:db8:1f1:f12b::/64 2001:db8:1f1:f142::/64 2001:db8:1f1:f142::/64 2001:db8:1f1:f143::/64 2001:db8:1f1:f153::/64 2001:db8:1f1:f155::/64 2001:db8:1f1:f15f::/64 2001:db8:1f1:f164::/64 2001:db8:1f1:f191::/64 2001:db8:1f1:f199::/64 2001:db8:1f1:f1ab::/64 2001:db8:1f1:f1e6::/64 2001:db8:1f1:f1f4::/64 2001:db8:1f1:f22e::/64 2001:db8:1f1:f24f::/64 2001:db8:1f1:f2e0::/64 2001:db8:1f1:f309::/64 2001:db8:1f1:f334::/64 2001:db8:1f1:f342::/64 2001:db8:1f1:f350::/64 2001:db8:1f1:f361::/64 2001:db8:1f1:f36c::/64 2001:db8:1f1:f371::/64 2001:db8:1f1:f376::/64 2001:db8:1f1:f384::/64 2001:db8:1f1:f38c::/64 2001:db8:1f1:f057::/64 2001:db8:1f1:f03e::/64 2001:db8:1f1:f0fc::/64 2001:db8:1f1:f1d1::/64 2001:db8:1f1:c00::/56 2001:db8:1f1:f060::/64 2001:db8:1f1:f09d::/64 Origin (1), length: 1, Flags [T]: IGP AS Path (2), length: 6, Flags [T]: 64943 Multi Exit Discriminator (4), length: 4, Flags [O]: 0 None of those made it into my kernel routing table or were logged by BIRD's debug at all. 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 and I can ping it. There are routes like the above for all of the 2001:db8::64:6xxa that are my servers. $ ip -6 ro | grep ^2001:db8::64:6..a/127 2001:db8::64:601a/127 via 2001:db8::64:607b dev bond0 proto bird src 2001:db8:0:1f1::e metric 500 pref medium 2001:db8::64:602a/127 via 2001:db8::64:607b dev bond0 proto bird src 2001:db8:0:1f1::e metric 500 pref medium …etc Any ideas? Thanks, Andy
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."
Hi Ondrej, On Mon, Oct 31, 2022 at 03:21:16PM +0100, Ondrej Zajicek via Bird-users wrote:
On Sat, Oct 29, 2022 at 10:29:25PM +0000, Andy Smith via Bird-users wrote:
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.
[…]
Debugging is fixed in v2.0.9, now it logs a detailed reason and all rejected prefixes.
Good to know. I will see about doing an upgrade.
If 2001:db8::64:608a is not directly reachable, but reachable through another route, then you need recursive next hop resolution.
Thanks, yes, it was the nexthops. The operator of the other end changed the nexthops and now it works, but we will bear in mind "gateway recursive" setting. Thanks, Andy
participants (2)
-
Andy Smith -
Ondrej Zajicek