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
