Your comments reordered. > Very much appreciate the help! This personal project was designed to teach > me a little about routing and it has definitely served that purpose > well :) But perhaps learning a little about routing isn't the same as > being very good at routing!
Distributed algorithms are tricky. They impose constraints that seem arbitrary if you don't have a full understanding of the algorithm. The interesting bit is how to commnicate these constraints to the users in a way that they understand, but unfortunately doing that does not lead to publications :-/ > I used to use a central database to coordinate where the "main route out" > was installed, but that was a little vulnerable to issues "in the > center". You've essentially reinvented SDN. You're replacing a distributed algorithm (tricky) by a central controller (much easier), which is an effective way of lifting the seemingly arbitrary constraints at the cost of introducing a central point of failure. It works very well in the datacenter, not so well in geographically distributed networks. > Unfortunately, because I don't control the ISP routers, I don't think > I have a border router by this definition. Right. > As a final thought, I think what I want is effectively > "install-duplicate-if-lowest-metric". In other words, imagine I had > a local default route out with a metric of 128 and a proto of 250, and > babel config like this: Yes, it looks like a new mechanism is needed. I need to think it over, it's not immediately obvious how your proposed mechanism interacts with Babel's loop-avoidance mechanisms. (At first sight, it might cause persistent oscillations, at least in some topologies.) -- Juliusz _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
