Hi list, I have a client who have two lines, one a 64k leased line specifically for e-mail, the other a 512k ADSL for browsing and general internet use. Unfortunately the 64k line turns out to be not as reliable as it should (due to the telco, I suspect), but as it's a 24month contract, not much we can do. What I would like to do is use the ADSL as a backup. The 64k line is the primary MX, the ADSL backup MX. Problem is, when the 64k line goes down, the mail server still tries to reply via the usual gateway, which is the router just this side of the line. In other words it doesn't know that the line has gone down, because it's own gateway is still up. Is it possible to set a timeout to all traffic to the default gateway, and have it try a backup gateway? The mailserver is SUSE 9.2 Pro, the ADSL is on an IP-COP firewall - both share the same internal network. Thanks -- Kind regards Hans du Plooy SagacIT (Pty) Ltd hansdp at sagacit dot com
On Tue, 2005-04-26 at 15:28 +0200, Hans du Plooy wrote:
Hi list,
I have a client who have two lines, one a 64k leased line specifically for e-mail, the other a 512k ADSL for browsing and general internet use.
Unfortunately the 64k line turns out to be not as reliable as it should (due to the telco, I suspect), but as it's a 24month contract, not much we can do. Sure you can, keep complaining and threaten to go else where if they don't provide the service they promised. I'm sure they promised something better then 70% uptime.
What I would like to do is use the ADSL as a backup. The 64k line is the primary MX, the ADSL backup MX.
Problem is, when the 64k line goes down, the mail server still tries to reply via the usual gateway, which is the router just this side of the line. In other words it doesn't know that the line has gone down, because it's own gateway is still up.
Is it possible to set a timeout to all traffic to the default gateway, and have it try a backup gateway?
The mailserver is SUSE 9.2 Pro, the ADSL is on an IP-COP firewall - both share the same internal network.
Perhaps this can be done through the use of a proxy server for outgoing but not for incoming unless you have a fixed IP on the DSL line. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
On Tue, 2005-04-26 at 10:10 -0400, Ken Schneider wrote: > > Unfortunately the 64k line turns out to be not as reliable as it should > > (due to the telco, I suspect), but as it's a 24month contract, not much > > we can do. > Sure you can, keep complaining and threaten to go else where if they > don't provide the service they promised. I'm sure they promised > something better then 70% uptime. Actually I can't. The problem is not with the ISP - they're fanatastic - but with the phone company, who sucks but happens to be the only one here. > Perhaps this can be done through the use of a proxy server for outgoing > but not for incoming unless you have a fixed IP on the DSL line. Don't have a fixed IP on the ADSL, but that's not the issue (been using dyndns on ADSL and it works well). I'm trying to figure out how to get the linux box know which interface the connection is made on, and reply via the same interface. The ADSL firewall masquerades, and forwards traffic on port 25 to port 25 on the maiserver's internal interface (eth1, say). So if, say hotmail's mailserver connects via the ADSL, the linux box still sees the connection from mxwhatever.hotmail.com, and tries to respond via eth0 through the leased line, because that's it's default gateway. I'm sure the solution is simple, but I keep missing it. Thanks -- Kind regards Hans du Plooy SagacIT (Pty) Ltd hansdp at sagacit dot com
On Tue, 2005-04-26 at 17:14 +0200, Hans du Plooy wrote: > On Tue, 2005-04-26 at 10:10 -0400, Ken Schneider wrote: > > > Unfortunately the 64k line turns out to be not as reliable as it should > > > (due to the telco, I suspect), but as it's a 24month contract, not much > > > we can do. > > Sure you can, keep complaining and threaten to go else where if they > > don't provide the service they promised. I'm sure they promised > > something better then 70% uptime. > Actually I can't. The problem is not with the ISP - they're fanatastic > - but with the phone company, who sucks but happens to be the only one > here. > The last place I worked at, before I retired, I was also the network admin. When I started to have problems with a dedicated line I would complain to the ISP who would in turn forward the complaint to the phone company, the ISP is who requested the install in the first place. Enough complaints resulted in the phone company sending a tech to resolve the problem. Many times the request resulted in the connection being moved to a different cable pair to fix the problem. Sometimes the tech would find a nearly broken wire at the connection and would fix that (even though no one had touched the wire to cause it to break). Strange things do happen. Keep complaining (in a nice way) it may do some good. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
On Tue, 2005-04-26 at 17:14 +0200, Hans du Plooy wrote:
On Tue, 2005-04-26 at 10:10 -0400, Ken Schneider wrote:
Unfortunately the 64k line turns out to be not as reliable as it should (due to the telco, I suspect), but as it's a 24month contract, not much we can do.
Sure you can, keep complaining and threaten to go else where if they don't provide the service they promised. I'm sure they promised something better then 70% uptime.
Actually I can't. The problem is not with the ISP - they're fanatastic - but with the phone company, who sucks but happens to be the only one here.
The last place I worked at, before I retired, I was also the network admin. When I started to have problems with a dedicated line I would complain to the ISP who would in turn forward the complaint to the phone company, the ISP is who requested the install in the first place. Enough complaints resulted in the phone company sending a tech to resolve the problem. Many times the request resulted in the connection being moved to a different cable pair to fix the problem. Sometimes the tech would find a nearly broken wire at the connection and would fix that (even though no one had touched the wire to cause it to break). Strange things do happen. Keep complaining (in a nice way) it may do some good. Nice idea Ken, but I have to back Hans here. With the telecoms monopoly we have here in South Africa, they actually don't care. It is either use
Ken Schneider wrote: the service at exorbitant rates or do without. No complaints taken seriously, unless it stops them making money. -- ======================================================================== Hylton Conacher - Linux user # 229959 at http://counter.li.org Currently using SuSE 9.0 Professional with KDE 3.1 ========================================================================
Problem is, when the 64k line goes down, the mail server still tries to reply via the usual gateway, which is the router just this side of the line. In other words it doesn't know that the line has gone down, because it's own gateway is still up.
Is it possible to set a timeout to all traffic to the default gateway, and have it try a backup gateway?
This may help you. It is a simple setup, that I copied from a web article at http://enterprise.linux.com/article.pl?sid=05/04/10/2132252 It is a basic setup that may need some tweaking. Good luck! - James W. By: Rohit Girhotra Today, it's hard to imagine an organization operating without taking advantage of the vast resources and opportunities that the Internet provides. The Internet's role has become so significant that no organization can afford to have its Net connection going down for too long. Consequently, most organizations have some form of a secondary or backup connection ready (such as a leased line) in case their primary Net connection fails. However, the process of switching over from the primary to the backup connection, if done manually by the system administrator, can take some time, depending upon how ready the backup setup is and on the availability of the administrator at the right moment. The process can even become a costly affair if the organization must buy dedicated routers for the purpose of automatic switchover. But there is an easy and cost-effective alternative -- setting up a Linux failover router. In this article we will look at setting up an existing Linux machine as a failover router to provide quick and automatic switchover from a dead Internet connection (the primary connection) to one that is operational (the secondary connection). To begin, you'll need a PC with any recent GNU/Linux distro installed. You'll also need three network cards to put into this Linux box. Two of the three network cards, say eth0 and eth1, will connect to the Internet routers/gateways of your primary ISP (say ISP1) and secondary ISP (say ISP2). The third network card, say eth2, will connect to your internal LAN. Setting up the network Begin by setting up your network based on the configuration information available to you. You can make the configurations from the X Window GUI using the Network utility. To do so, open the Network utility from Main Menu > System Settings > Network. This will open up a network configuration window displaying a list of all the network cards installed on your system. Double-click on the network card you wish to configure, select the Statically Set IP Addresses option, and assign the IP address along with the subnet mask. There is also a Default Gateway Address field; tou can leave it blank for the time being, as it can be specified later on from the command line. Assign the IP addresses provided to you by your ISPs to the two network cards, eth0 and eth1. In our setup, we assigned eth0=61.16.130.100 and eth1=200.15.110.101 (which are public IP addresses), along with the subnet mask 255.255.255.224. Assign a private IP address based on your internal LAN subnet to your third card. We assigned eth2=10.0.0.1, where 10.0.0.0/24 was the address range for our internal LAN setup. Save your changes and exit. Now turn on IP packet forwarding on the Linux box by changing the value of net.ipv4.ip_forward to 1 in the /etc/sysctl.conf file and executing the command: # sysctl -p Next, you need to configure iptables by adding certain rules, so that your internal LAN can route packets to the Internet. For this, issue the following commands as root: # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE # iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT # iptables -A FORWARD -d 10.0.0.0/24 -j ACCEPT # iptables -A FORWARD -s ! 10.0.0.0/24 -j DROP The above commands turn on masquerading in the NAT table by appending a POSTROUTING rule (-A POSTROUTING) for all outgoing packets on the two Ethernet interfaces, eth0 and eth1. The next two lines accept forwarding of all packets to and from the 10.0.0.0/24 network. The last line drops the packets that do not come from the 10.0.0.0/24 network. To make the iptables rules permanent, save them as follows: # iptables-save > /etc/sysconfig/iptables Now you must restart your network, as well as iptables: # /etc/init.d/network restart # /etc/init.d/iptables restart To see if your new iptables rules have gone into effect, type iptables --L. Enabling failover routing After you have configured your network, the next step is to enable failover routing on your Linux box, so that if the first route dies the router will automatically switch over to the next route. To do so, you'll need to add the default gateway routes provided to you by your ISPs for both your network cards: # route add default gw 61.16.130.97 dev eth0 # route add default gw 200.15.110.90 dev eth1 Here, 61.16.130.97 is the gateway address given by ISP1 and 200.15.110.90 is the gateway address given by ISP2. Replace them with the addresses available to you. These routes will disappear every time you reboot the system. In order to make these routes permanent add the above two commands in the /etc/rc.d/rc.local file, which is run at boot time. Also make sure that all the computers on your internal LAN (10.0.0.0/24) have their default gateway address set as the IP address of the eth3 Ethernet interface (i.e. 10.0.0.1) of your failover router. Finally, modify the /proc/sys/net/ipv4/route/gc_timeout file. This file contains a numerical value that denotes the time in seconds after which the kernel declares a route to be inactive and automatically switches to the other route if available. Open the file in any text editor and change its default value of 300 to some smaller value, say 10 or 15. Save the changes and exit. Now your Linux machine is ready to serve as a failover router, automatically and quickly switching to the secondary route every time the primary route fails.
On Tue, 2005-04-26 at 11:48 -0400, James Wright wrote:
This may help you. It is a simple setup, that I copied from a web article at http://enterprise.linux.com/article.pl?sid=05/04/10/2132252
It is a basic setup that may need some tweaking. Good luck! Thanks, this looks great!
-- Kind regards Hans du Plooy SagacIT (Pty) Ltd hansdp at sagacit dot com
participants (4)
-
Hans du Plooy
-
Hylton Conacher (ZR1HPC)
-
James Wright
-
Ken Schneider