diff --git a/docs/MultiISP.xml b/docs/MultiISP.xml index a95c77d36..4f8cde2bc 100644 --- a/docs/MultiISP.xml +++ b/docs/MultiISP.xml @@ -1075,49 +1075,55 @@ shorewall 2 2 - eth0 192.168.1.254 track,balance=2,optional< - - shorewall 11999 -
+
Gateway Monitoring and Failover - Beginning with Shorewall 4.2.6, Shorewall includes a sample - monitoring script swping. The - swping file is available in the main directory - contained in the Shorewall-common tarball and is included in the - Shorewall-common documentation directory on the Shorewall-common RPM. - The script is inspired by Angsuman Chakraborty's gwping - script. + There are a couple of options available for monitoring the status + of provider links and taking action when a failure occurs. - For those not on 4.2.6 yet, the script may be downloaded from - http://www.shorewall.net/pub/shorewall/contrib/MultiISP-failover/. +
+ SWPING - - These samples are offered as is — they work - for me but I don't make any claim that they will work for anyone else. - But if you have a need for automated link monitoring, they offer you a - place to start. - + Beginning with Shorewall 4.2.6, Shorewall includes a sample + monitoring script swping. The + swping file is available in the main directory + contained in the Shorewall-common tarball and is included in the + Shorewall-common documentation directory on the Shorewall-common RPM. + The script is inspired by Angsuman Chakraborty's gwping + script. - The script should be copied to a directory on root's PATH such as - /usr/local/sbin/. + For those not on 4.2.6 yet, the script may be downloaded from + http://www.shorewall.net/pub/shorewall/contrib/MultiISP-failover/. - The script works by sending pings to target - IP addresses through each external interface. These targets must not - depend on any routes other than those that are present in the main - routing table. That ensures that a route is available to the target even - when the target's interface is not working and Shorewall has omitted it - from the routing configuration. An interface is assumed to be - up when a specified number (UP_COUNT) of - consecutive ping operations succeed. Similarly, an interface is assumed - to be down when a specified number (DOWN_COUNT) - of consecutive ping operations fail. You can specify the interval - between pings (PING_INTERVAL). + + These samples are offered as is — they + work for me but I don't make any claim that they will work for + anyone else. But if you have a need for automated link monitoring, + they offer you a place to start. + - The script monitors two interfaces but it is a trivial exercise to - extend it to more than two. At the top are a number of variables to - set: + The script should be copied to a directory on root's PATH such + as /usr/local/sbin/. - # + The script works by sending pings to target + IP addresses through each external interface. These targets must not + depend on any routes other than those that are present in the main + routing table. That ensures that a route is available to the target + even when the target's interface is not working and Shorewall has + omitted it from the routing configuration. An interface is assumed to + be up when a specified number (UP_COUNT) of + consecutive ping operations succeed. Similarly, an interface is + assumed to be down when a specified number + (DOWN_COUNT) of consecutive ping operations fail. You can specify the + interval between pings (PING_INTERVAL). + + The script monitors two interfaces but it is a trivial exercise + to extend it to more than two. At the top are a number of variables to + set: + + # # IP family -- 4 or 6 # FAMILY=4 @@ -1157,34 +1163,34 @@ UP_COUNT=5 # DOWN_COUNT=2 - If you leave COMMAND empty, the script sets its value - automatically depending on whether Shorewall-lite is installed. + If you leave COMMAND empty, the script sets its value + automatically depending on whether Shorewall-lite is installed. - When the status of an interface changes: + When the status of an interface changes: - - - For each interface, a file is placed in /etc/shorewall to - record the status of the interface: either 0 (UP) or 1 (DOWN). The - name of the file is - interface.status - where interface is the interface (e.g., - eth0.status). - + + + For each interface, a file is placed in /etc/shorewall to + record the status of the interface: either 0 (UP) or 1 (DOWN). The + name of the file is + interface.status + where interface is the interface (e.g., + eth0.status). + - - A shorewall -f restart command is executed - (shorewall-lite restart, if Shorewall-lite is - installed). - + + A shorewall -f restart command is + executed (shorewall-lite restart, if + Shorewall-lite is installed). + - - The contents of the main routing table are displayed. - - + + The contents of the main routing table are displayed. + + - The .status files are intended to be used with the following - /etc/shorewall/isusable script.local status=0 + The .status files are intended to be used with the following + /etc/shorewall/isusable script.local status=0 case $1 in eth0|eth1) @@ -1194,65 +1200,211 @@ esac return $status - Be sure that you modify the interface names to match your - configuration. + Be sure that you modify the interface names to match your + configuration. - Also included is a sample init script - (swping.init) to start the monitoring daemon. Copy - it to /etc/init.d/swping and use your - distribution's SysV init tools to cause it to be run at boot. It works - on OpenSuSE 11.0 -- YMMV. Modify the PROG and - STATEDIR variables as needed. + Also included is a sample init script + (swping.init) to start the monitoring daemon. + Copy it to /etc/init.d/swping and use your + distribution's SysV init tools to cause it to be run at boot. It works + on OpenSuSE 11.0 -- YMMV. Modify the PROG and + STATEDIR variables as needed. - As an alternative to using the init script, you can add the - following to /etc/shorewall/started: + As an alternative to using the init script, you can add the + following to /etc/shorewall/started: - if [ "$COMMAND" = start ]; then + if [ "$COMMAND" = start ]; then killall -9 swping 2> /dev/null #be sure that there are none left running /usr/local/sbin/swping & fi - and add this to - /etc/shorewall/stopped. + and add this to + /etc/shorewall/stopped. - if [ "$COMMAND" = stop -o "$COMMAND" = clear ]; then + if [ "$COMMAND" = stop -o "$COMMAND" = clear ]; then killall -9 swping 2> /dev/null fi - This simple script has a number of limitations: + This simple script has a number of limitations: - - - It only works on IPv4 or IPv6 but not both at once. So if you - want to monitor both IPv4 and IPv6, you need to clone the script are - run two copies; one for IPv4 and one for IPv6. - + + + It only works on IPv4 or IPv6 but not both at once. So if + you want to monitor both IPv4 and IPv6, you need to clone the + script are run two copies; one for IPv4 and one for IPv6. + - - It can only detect the gateway for interfaces managed by - dhcpcd. - + + It can only detect the gateway for interfaces managed by + dhcpcd. + - - It's method of determining whether an interface is up or down - is crude. You will normally specify the default gateway for each - provider as the sites to ping and being able to ping the default - gateway is not a surefire indication that the provider is usable. - The method of determining whether a site is up or down is also - crude. - + + It's method of determining whether an interface is up or + down is crude. You will normally specify the default gateway for + each provider as the sites to ping and being able to ping the + default gateway is not a surefire indication that the provider is + usable. The method of determining whether a site is up or down is + also crude. + - - Because of the crudeness of the algorithm, hysteresis may - occur. - + + Because of the crudeness of the algorithm, hysteresis may + occur. + - - It is tricky to configure a system such that the system works - correctly when one of its providers is down unless you largely don't - care which interface is used. - - + + It is tricky to configure a system such that the system + works correctly when one of its providers is down unless you + largely don't care which interface is used. + + +
+ +
+ Link Status Monitor (LSM) + + Link Status Monitor + was written by Mika Ilmaranta <ilmis at nullnet.fi> and performs + more sophisticated monitoring than the simple swping script described + in the preceding section. + + I personally use LSM here at shorewall.net. Here are my relevant + configuration files: + + /etc/shorewall/isusable: + + local status +status=0 + +case $1 in + eth0|eth3) + [ -f /etc/shorewall/${1}.status ] && status=$(cat /etc/shorewall/${1}.status) + ;; +esac + +return $status + + /etc/shorewall/started: + + ############################################################################### +# My 'restored' script calls this one if there is no lsm process running +############################################################################### +if [ "$COMMAND" = start -o "$COMMAND" = restore ]; then + killproc lsm 2> /dev/null + cat <<EOF > /etc/lsm/shorewall.conf +connection { + name=Avvanta + checkip=206.124.146.254 + device=eth0 + ttl=2 +} + +connection { + name=Comcast + checkip=$ETH3_GATEWAY + device=eth3 + ttl=1 +} +EOF + rm -f /etc/shorewall/*.status + /usr/sbin/lsm /etc/lsm/lsm.conf >> /var/log/lsm +fi + + eth3 has a dynamic IP address so I need to use the + Shorewall-detected gateway address ($ETH3_GATEWAY). + + /etc/shorewall/restored: + + if [ -z "$(ps ax | grep 'lsm ' | grep -v 'grep ' )" ]; then + run_started_exit +fi + + /etc/lsm/lsm.conf: + + # +# Defaults for the connection entries +# +defaults { + name=defaults + checkip=127.0.0.1 + eventscript=/etc/lsm/script + max_packet_loss=20 + max_successive_pkts_lost=7 + min_packet_loss=5 + min_successive_pkts_rcvd=10 + interval_ms=2000 + timeout_ms=2000 + warn_email=teastep@shorewall.net + check_arp=0 + sourceip= + device=eth0 + ttl=64 +} + +include /etc/lsm/shorewall.conf + + /etc/lsm/script#!/bin/sh +# +# (C) 2009 Mika Ilmaranta <ilmis@nullnet.fi> +# (C) 2009 Tom Eastep <teastep@shorewall.net> +# +# License: GPLv2 +# + +STATE=${1} +NAME=${2} +CHECKIP=${3} +DEVICE=${4} +WARN_EMAIL=${5} +REPLIED=${6} +WAITING=${7} +TIMEOUT=${8} +REPLY_LATE=${9} +CONS_RCVD=${10} +CONS_WAIT=${11} +CONS_MISS=${12} +AVG_RTT=${13} + +cat <<EOM | mail -s "${NAME} ${STATE}, DEV ${DEVICE}" ${WARN_EMAIL} + +Hi, + +Connection ${NAME} is now ${STATE}. + +Following parameters were passed: +newstate = ${STATE} +name = ${NAME} +checkip = ${CHECKIP} +device = ${DEVICE} +warn_email = ${WARN_EMAIL} + +Packet counters: +replied = ${REPLIED} packets replied +waiting = ${WAITING} packets waiting for reply +timeout = ${TIMEOUT} packets that have timed out (= packet loss) +reply_late = ${REPLY_LATE} packets that received a reply after timeout +cons_rcvd = ${CONS_RCVD} consecutively received replies in sequence +cons_wait = ${CONS_WAIT} consecutive packets waiting for reply +cons_miss = ${CONS_MISS} consecutive packets that have timed out +avg_rtt = ${AVG_RTT} average rtt, notice that waiting and timed out packets have rtt = 0 when calculating this + +Your LSM Daemon + +EOM + +[ ${STATE} = up ] && state=0 || state=1 + +echo $state > /etc/shorewall/${DEVICE}.status + +/sbin/shorewall -f restart >> /var/log/lsm 2>&1 + +/sbin/shorewall show routing >> /var/log/lsm + +exit 0; + +#EOF: +