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