> I didn't mean any present incorrect behaviour, but rather a weakness which may
> (or may not) reappear at some point later and cause painful bugs
I'm not worried, that's the kind of issue that valgrind is good at
detecting (and I regularly run babeld through valgrind). There's plenty
of other
Dear all,
Version 1.8.1 of babeld, the Babel routing daemon, is available from
https://www.irif.fr/~jch//software/files/babeld-1.8.1.tar.gz
https://www.irif.fr/~jch//software/files/babeld-1.8.1.tar.gz.asc
This release makes two important changes, and upgrading is strongly
recommended.
> you may find this video interesting:
> https://youtu.be/agPdI7cY5eU
Cool. I see some more info on https://meshpoint.me/
> We are using Babel routing for MeshPoint, and we would like to become
> a more active contributors to Babel project.
Let's try to arrange to meet and have a chat. I'll
> Presently, I'm starting my babeld instances in 2.1 seconds intervals and
> then wait 25 seconds for convergence.
That's not what Babel is optimised for.
Babel is built around the assumption that links are unstable. A Babel
node keeps a fair amount of state so it can reroute quickly in the
>>> My thinking on this is that you only need the host routes when a client
>>> actually roams.
>> This is only going to work if you either use no hold time, or implement
>> the optional algorithm in Section 3.1 of rfc6126bis.
> I'm assuming you mean the ACKed retraction algorithm in Section
> However, using a more convoluted 7-node setup I can hardly get under 40
> seconds.
How are you measuring? Are you rebooting your routers, or merely toggling
links up/down?
If the latter, than there is a problem. If the former, then you should
either make sure that the state file is
601 - 606 of 606 matches
Mail list logo
