From mboxrd@z Thu Jan 1 00:00:00 1970 From: Damion de Soto Date: Thu, 08 Apr 2004 06:58:23 +0000 Subject: Re: [LARTC] setup fail-over with redhat9... Message-Id: <4074F80F.1020302@snapgear.com> List-Id: References: <003501c41cc6$e604c0b0$6400a8c0@stillnicks> In-Reply-To: <003501c41cc6$e604c0b0$6400a8c0@stillnicks> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Hi Cristiano, > I know that to make redundance work ill have to setup the ip route and > ip rule in my system. To do that, i found a bash script called "NETSANE > - http://muse.linuxmafia.org/netsane/". I have to change somethings like > interface of the first and second lines in netsane.conf. So, i did all > the changes needed. Looking good so far, i can ping outside sites the > both eth2 and eth0 doing "ping -I eth# www.kernel.org", i dont have a > "default route" and etc. ok, that's good. > Ok, now goes the worse part. I cant MASQUERADE the connection to my > internal network, and even if i could, will redundance work if the first > interface fails? I dont think so. No, as the netsane webpage says, it does not provide redundancy. > Because i tried a normal ping (ping > www.kernel.org ) and it always goes through eth2, > even the i unplug the adsl line from the router/modem to simulate a down > link. Yes, your packet routes get cached by the kernel. Eventually, it will realise that route is dead, and has a 50% chance of getting out the other active interface. > I believe that should be an IPTABLES configuration to make NAT work with > redundance, not the usual below: > # turn on NAT (IP masquerading for outgoing packets) > $IPTABLES -A POSTROUTING -t nat -o eth0 -j MASQUERADE #you will want to masquerade out eth2 as well. $IPTABLES -A POSTROUTING -t nat -o eth2 -j MASQUERADE > Im using the rc.firewall-2.4 right now, and it clearly doesnt work with > redundance. As far as I know, the only way you can get fail-over/redundancy, is to have a program continually monitor both links, and bring up/down the interfaces and change the routes as required. You should be able to write a shell script that pings out eth2, and if it doesn't get a reply, brings down that interface and fixes the routes. Then, wait, try again later and see if eth2 is working again. Regards, -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Damion de Soto - Software Engineer email: damion@snapgear.com SnapGear - A CyberGuard Company --- ph: +61 7 3435 2809 | Custom Embedded Solutions fax: +61 7 3891 3630 | and Security Appliances web: http://www.snapgear.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --- Free Embedded Linux Distro at http://www.snapgear.org --- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/