Modification to BIRD to support better anycast model

Jay Grizzard elfchief at lupine.org
Tue Jun 10 00:50:40 CEST 2014


Hiiiii bird folks.

So, I've been looking at setting up a relatively simple anycast config, 
your typical 'multiple servers broadcast the same route via ospf and 
network proximity determines which you route to' type setup. BIRD seems 
like it should be able to do this fairly well, and seems to be one of 
the better/cleanest designs available for this sort of thing.

I do have one issue, though, which seems to be common to all of the 
software-based routing solutions out there: Ongoing service health isn't 
really required for continued routing. The typical setup is to do 
something like monitor the service health with a local tool, and 
withdraw the route if that tool discovers lack of health. The problem 
with this is that if something goes wrong with that check -- it hangs, 
cron dies, or whatever -- the route will keep getting broadcast and 
traffic will keep getting directed to a system no longer able to handle it.

So, I'd like to come up with a basic solution to this, where something 
active is required to keep anycast routes broadcasting, so if the app, 
monitoring, cron, etc die, the route will stop getting broadcast, 
without the monitoring having to 'manually' remove the route.

My basic idea right now, in the spirit of "minimum workable footprint," 
is to do something like having a route filter tied to a file on disk, 
where the timestamp on that file is used to determine if the route 
should be exported... if the file ages beyond a certain point, the route 
gets filtered.

So, something like this (syntax totally not thought through yet):

filter ospf_out {
     if (net == 1.2.3.0/24) then {
         if fileage("/some/path") > 5 then reject;
         accept;
     }
}

... and then have a health check that checks the app health, and touches 
/some/path. If the app goes down, or something goes wrong with the 
monitoring itself (or it just doesn't run at all), that file doesn't get 
touched, route gets filtered.

This seems like the minimum viable interface for making this happen, 
especially as far as needing to make changes to BIRD is concerned -- 
it's pretty trivial to read the timestamp on a file on a repeating basis.

My questions for the list, then:
   - Am I correct that BIRD doesn't currently have any functionality of 
this type available? I've gone through the manual a couple of times and 
don't see anything obvious, but I could have missed something.
   - Assuming it can't, where would be the right place to implement 
this? Is my guess about using an export filter a reasonable one? Anyone 
with code familiarity care to comment on any gotchas I might run into 
while doing this?
   - Anyone know of any non-BIRD tools that can do what I want natively? 
I looked at the obvious stuff (e.g. quagga) and didn't see anything, but 
would love to be corrected on this.

Thanks!

-jay




More information about the Bird-users mailing list