Hi Sheldon,
> So your problem really comes down to this: how do I know
> whether one of my routes is working?
More or less: Yes.
> That question can be answered in a number of ways, including
> the use of the mon package or homegrown scripts. But
> basically, it's pretty trivial to test reachability, and
> equally trivial to affect routing based on the test result and
> previous state.
The firewall is an appliance which is able to check the state of its primary outgoing line. If this one fails it takes that interface down and everything switches to the backup line automatically. Unfortunately the developers have not thought about the possibilty to check the state of the backup line as well.
I _could_ of course check for the readiness with scripts and then try to influence the source routing on the appliance (no linux/freebsd) via SNMP or SSH commands. However this seems overly complicated and to be honest it just does not feel right to have one thing/line checked on the appliance and the other from another system. Just thinking about all the possibilities of things going wrong here is causing me a headache. :-)
> So once your system is testing and responding to route
> failure dynamically, _all_ your applications now benefit, and
> you don't need custom hacks for each one.
I know and I agree. It's just that I really do not want to change routing via scripts on the central firewall/routing appliance. Either the device is able to manage things for itself or I will have to try to live without it. Of course one way to handle this would indeed be to check for the state of the backup line and depending on this write the interface to a file/variable and read/use this in Exim using string expansion...
> This is just my approach. It's not "the right way", I just think it
> makes sense.
