Hi Toke (and others) I updated Babel to use microsecond timers [1] and during testing i noticed several unrelated issues. 1) Hello expiration was not properly implemented, as i understand RFC, it should reset the timer based on last packet hello interval and time-out repeatedly until hello map is zero. Fixed in [2]. 2) In some setups unicast seqno requests were sent repeatedly and seqno was increased indefinitely due to last case in babel_handle_update(), when the RFC specifies it should be done only if unfeasible route would otherwise become best. Fixed in [3], by this condition handling all unicast seqno requests: if (!feasible && (metric != BABEL_INFINITY) && (!best || (r == best) || (metric < best->metric))) babel_unicast_seqno_request(e, s, nbr); It also changes the behavior by sending seqno request when receiving infeasible update if there is no previous route from that neighbor. 3) Seems like the fix of hello expiration caused that when neighbor disappears, it is no longer removed timely and routes have to wait for route timeout, which is about a minute for 4 s hello interval. It seems that by RFC, we should recompute route metrics whanever rxcost reported by IHU is changed, so IHU expiration should be enough to make all related routes unreachable. Apparently, this is not done in BIRD. 4) Seems like we do not trigger updates when a route update with just increased seqno due to forwarded unicast request is received. That also slows convergence. IMHO we should do in babel_handle_update() something like: if (route_is_selected() && matching_entry_in_seqno_request_cache()) babel_trigger_update() Do you think that my interpretation of these issues and the fixes are correct? [1] https://gitlab.labs.nic.cz/labs/bird/commit/8a76785a6fb23a64fcc93f998336794f... [2] https://gitlab.labs.nic.cz/labs/bird/commit/c7fa4efd701716a9c40620f2e3e8f065... [3] https://gitlab.labs.nic.cz/labs/bird/commit/c54526afeb4187d55993c3ab777fcfe5... -- 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."