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
