Ondrej Zajicek <santiago@crfreenet.org> writes:
On Tue, May 01, 2018 at 12:41:01PM +0200, Toke Høiland-Jørgensen wrote:
Toke Høiland-Jørgensen <toke@toke.dk> writes:
When a Babel node restarts, it loses its sequence number, which can cause its routes to be rejected by peers until the state is cleared out by other nodes in the network (which can take on the order of minutes).
There are two ways to fix this: Having stable storage to keep the sequence number across restarts, or picking a different router ID each time.
This implements the latter, by introducing a new option that will cause Bird to pick a random router ID every time it starts up. This avoids the problem at the cost of not having stable router IDs in the network.
BTW, I would also like to implement the EUI-64-based router ID assignment that babeld does, since it can significantly improve protocol efficiency in some v6 deployments. But that would require ignoring the global setting for router ID; is that acceptable, if it's made a configuration option?
Hi, how exactly 'EUI-64-based router ID assignment' works? Based on MAC addresses, IPv6 LL addresses, /etc/machine-id, random assignment or some other source?
It is basically using the lower 64 bits of the LL address as router ID. There's a flag in the protocol encoding that makes it possible to elide the router ID TLV in this case; if there are only a few routes this can save quite a bit of space, percentage-wise :) Of course this only works for one interface, but in pure wireless meshes, everything is usually on the same interface anyway, so that is fine (and otherwise you could configure the same LL-addr on all interfaces of course).
Ignoring global setting is OK, i just wonder whether some global EUI-64-based unique ID should not be provided directly by the nest
That might be convenient, yeah. There's the issue of picking the right interface, though; some kind of logic that says "first interface with a configured protocol"? Or should it be a per-protocol type thing? -Toke