On Sat, Apr 23, 2022 at 11:20:57PM +0200, Toke Høiland-Jørgensen wrote:
(3) Due to route flapping I tried to increase "metric decay" to 60s. After running "birdc configure" the values became very large for one link (on one side only).
Which values become very large? And is this persistent? What kind of route flapping were you seeing?
The routes were "flapping" simply because the RTT were very similar and sometimes one next hop wins, sometimes the other. I don't think this is a problem, but expected behaviour. I was just trying out the "metric decay" setting to check if routing tables do change less often. Seems to work.
Hmm, so that initial value is '-973' as a 32-bit unsigned int. So looks like there's an overflow in the RTT calculation. I'll add some sanity checks to make sure this doesn't happen (as indeed babeld has as well).
I did not observe this problem with the new version anymore.
I force-pushed an updated version to the same branch which fixes the issues you noted above apart from the route flap one. Inspired by the first issue noted above, I also added a separate config parameter to control the *sending* of timestamps, which defaults to on.
I am running the new version since Tuesday and everything looks good so far. Best regards, Stefan Haller