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
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
