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
