Norman Henderson
2017-06-20 06:01:32 UTC
We have three internet connections at the moment, one of which is stable
but costly per Gb, and the other two cheaper and uncapped but highly prone
to failures - usually somewhere upstream in their networks. These can
manifest as slowdowns, high lost packet rates, or complete failures.
(Welcome to Africa...)
We have complex route_rules which prefer the cheaper providers but allow
(some users) access to the costly provider if the normal ones are disabled
in Shorewall.
1) Sometimes a particular user (usually me!) needs to use the costly
provider for a while, although other users have to suffer the normal
providers. Since it's a pain to change the route_rules file and restart
Shorewall (with implications for tunnels and other things too), I have just
been deleting the relevant "ip rule" to give myself access to the costly
provider. The trouble is that these rules come back again all by
themselves, after a random delay but sometimes just a few minutes.
Question: what Shorewall features / behaviors trigger the ip rules to be
reinitialized? Is there something I could do (or stop doing) to prevent
this happening?
2) FOOLSM suffers from the limitation that it will only monitor an on-net
address i.e. if the interface address is 192.168.0.1/24, it will only
monitor a remote address in that same subnet. Question: does anyone know of
a different monitoring solution that will enable and disable providers
based on an end-to-end path (such as to my virtual server in the USA)?
3) I have experimented with monitoring scripts of my own but there is a
conundrum:
- if a provider is flaky it needs to be disabled, otherwise it remains the
chosen route for users and they don't get any Internet.
- Meaningful testing of the status of a path require the interface to be
enabled. For example, pings over an interface that is up, but for which the
provider is marked "down" in Shorewall alternately succeed or report
"Operation not permitted".
- therefore, testing the status of a path requires frequent enabling and
disabling (if it is found to still be flaky) which in turn introduces brief
but annoying route changes that mess with users' ability to access the 'net.
Question: Any ideas for how to disable a provider and the corresponding
route_rules (for users) and yet still allow the firewall itself to reliably
use that interface? At least for pings and maybe for more complex tests
e.g. speedtest.net.
Thanks in advance!
but costly per Gb, and the other two cheaper and uncapped but highly prone
to failures - usually somewhere upstream in their networks. These can
manifest as slowdowns, high lost packet rates, or complete failures.
(Welcome to Africa...)
We have complex route_rules which prefer the cheaper providers but allow
(some users) access to the costly provider if the normal ones are disabled
in Shorewall.
1) Sometimes a particular user (usually me!) needs to use the costly
provider for a while, although other users have to suffer the normal
providers. Since it's a pain to change the route_rules file and restart
Shorewall (with implications for tunnels and other things too), I have just
been deleting the relevant "ip rule" to give myself access to the costly
provider. The trouble is that these rules come back again all by
themselves, after a random delay but sometimes just a few minutes.
Question: what Shorewall features / behaviors trigger the ip rules to be
reinitialized? Is there something I could do (or stop doing) to prevent
this happening?
2) FOOLSM suffers from the limitation that it will only monitor an on-net
address i.e. if the interface address is 192.168.0.1/24, it will only
monitor a remote address in that same subnet. Question: does anyone know of
a different monitoring solution that will enable and disable providers
based on an end-to-end path (such as to my virtual server in the USA)?
3) I have experimented with monitoring scripts of my own but there is a
conundrum:
- if a provider is flaky it needs to be disabled, otherwise it remains the
chosen route for users and they don't get any Internet.
- Meaningful testing of the status of a path require the interface to be
enabled. For example, pings over an interface that is up, but for which the
provider is marked "down" in Shorewall alternately succeed or report
"Operation not permitted".
- therefore, testing the status of a path requires frequent enabling and
disabling (if it is found to still be flaky) which in turn introduces brief
but annoying route changes that mess with users' ability to access the 'net.
Question: Any ideas for how to disable a provider and the corresponding
route_rules (for users) and yet still allow the firewall itself to reliably
use that interface? At least for pings and maybe for more complex tests
e.g. speedtest.net.
Thanks in advance!