Re: redundancy with Adsl modem

["Gáspár Lajos" <swifty@freemail.hu>]

Hi Lloyd,

Thank you for your comment ! :D
I have never used this monitor, but I am going to try it... :D

2012-01-04 15:08 keltezéssel, Lloyd Standish írta:
> I'm sure your iface match is very useful in many circumstances.  
> However I would like to point out that link status monitor 
> (http://lsm.foobar.fi/) actually evaluates the link quality by pinging 
> an IP (perhaps several hops past the gateway IP), keeping track of the 
> number of lost and late-arriving packets over the last 60 seconds.  If 
> the number of late or dropped packets exceeds a certain (configurable) 
> number, then the link is reported as "down".  The main advantage to 
> this (and the fact that it happens outside of netfilter) is that the 
> firewall can be automatically reconfigured to exclude the failed link 
> from routing.  When the link quality is seen to have improved, the 
> failed link can be included again in the routing decision.

I think that both of these approaches has pros and cons.

Maybe you also know that (in Linux) the kernel chooses the output 
interface depending on the routing table and not the source IP...
So if the ping is not bound to a specific interface then it is "useless"...
(There is an oping utility that can be set up to use a specific interface.)
I do not know LSM but I hope that it is also aware of this.

Besides this, pinging is not always accurate and may lead the 
application think that link quality is dropping down...
Just imagine that the pinged host(s) can be under a DOS attack and the 
reply times can go high...
(Not to mention that the pinging generates traffic and that requires 
resources. Probably not too much resources at all :D)

Other question is that how often/rarely do you ping? If often then it is 
too much traffic. If rarely then do you REALLY KNOW that the interface 
was all the time up?

To repeat myself: I do not know LSM :D

It seems to me that LSM is some kind of line quality checking software...

OTOH my match checks the interface state when the packet is in the queue...
With that info you can mark the packets and let the kernel decide about 
the routing depending on the mark..

But my match does not know anything about the "quality" of the 
connection just about the state of the interface...

Returning to the main question:
If an interface goes down then the associated connections will most 
likely break down...
Without knowing the required "high-availability" services, for example 
you can use "fallback_relay" in postfix; multiple remote lines in 
openvpn, etc. etc. etc.
So maybe the redundancy is not the right word for the main requirement...
I would ask myself: Do I really need redundancy or do I need alternativity?


Swifty