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