Snipping to this, as it seems fishy: > Output from the same router "router1.place6": > > bird> show babel neighbors > babel1: > IP address Interface Metric Routes Hellos Expires > fe80::21b:21ff:febc:bf36 bond0.8 96 8 12 0.000 > fe80::21b:21ff:febc:bfe0 bond0.8 65535 14 9 0.000 > fe80::20d:b9ff:fe49:a705 bond0.8 96 4 12 0.000 > fe80::a236:9fff:fe08:a780 bond0.8 65535 7 10 0.000 > fe80::20d:b9ff:fe57:2f91 bond0.8 96 4 12 0.000 > fe80::21b:21ff:febc:bfd8 bond0.8 65535 7 10 0.000 > fe80::21b:21ff:febc:bfe0 bond0.35 65535 14 9 0.000 > fe80::21b:21ff:febc:bfe0 bond0.100 65535 14 9 0.000 > fe80::21b:21ff:febc:bfe0 bond0.12 65535 14 9 5.999 > fe80::21b:21ff:febc:bfe0 bond0.38 65535 8 10 5.999
A metric of 65535 means 'infinity', i.e., Babel has determined that this peer is no longer reachable. So it looks like there's some kind of connectivity issue here, which would also explain why the routes end up with no valid destination. Are Babel Hello packets being dropped? Maybe your link has some issue with multicast traffic being dropped or something? The 'hellos' column also indicates that *all* the peers are experiencing hello packet loss to a certain extent (on a perfect link they would all be 16). And since you've marked the link as 'wired', Babel uses a binary on/off link state algorithm, where there's a sharp cutoff when the hello history drops below a certain threshold. If you link really is unreliable, you should mark the link as 'wireless' which will result in a different algorithm that can deal with some loss and still maintain connectivity. It also seems odd that the same peer IP shows up on different interfaces (are those different VLANs) - is that expected? -Toke