> Out of interest: Is there a reason why FRR doesn't just use babeld, but > something of its own?
Babeld works by speaking directly to the kernel. If multiple routing protocols are running, they all manipulate the kernel's routing table, which requires them to collaborate in order to decide which protocol is the one that's going to win. In FRR, each routing protocol speaks to the zebra deamon. The Zebra daemon receives routes from all routing protocols, and decides which routes are going to be installed in the kernel. This puts all (most) policy in a single place, at the cost of some extra complexity. Thus, every routing protocol need to be ported to FRR, both so that it speaks to Zebra instead of speaking directly to the kernel, and also so it can be configured using FRR's Cisco-like configuration language. FRR's code is derived from a port of a very old version of babeld to Quagga, which was done by Matthieu Boutier and myself. Paul Jackma (the maintainer who ended up killing Quagga) invented a lot of spurious reasons not to merge our code into Quagga. When FRR was forked from Quagga, Donald Sharp did a lot of good work to clean up and merge Matthieu's code. Unfortunately, the FRR folks never got around to updating FRR's Babel code to either merge a more recent version of babeld or do their own updates with what we've learned since then. I'm sure they'd accept a patch, but I'm not sure I can do the work myself (merging changes is a dull and error-prone job, it requires a kind of engineering discipline that I simply don't have). -- Juliusz _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
