Date: Fri, 21 Sep 2001 22:41:58 -0700 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Odhiambo Washington" <wash@wananchi.com>, "FBSD-Q" <freebsd-questions@FreeBSD.ORG> Subject: RE: Changing Default Route Message-ID: <005601c14329$4b6f73c0$1401a8c0@tedm.placo.com> In-Reply-To: <20010921181136.A86413@ns2.wananchi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message----- >From: owner-freebsd-questions@FreeBSD.ORG >[mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of Odhiambo >Washington >Sent: Friday, September 21, 2001 8:12 AM >To: FBSD-Q >Subject: Changing Default Route > > > >Hello people > >I have just two questions: > >1. Has anyone out there crafted a shell script that can monitor >whether the default route is active? > if active, leave alone; if inactive change to abother route; if >route is back up, change back to it. yes and no, it depends on what you define as "active" let's say you have 2 connections into a gateway, one the primary and one the secondary. The primary is bigger than the secondary and so you desire that the primary be used unless it's down then it switches over to the secondary. Now, if you define "active" as whether the interface the primary is connected to is UP or DOWN, then no problem, a higher metric on the default route through the secondary will do it, no script required. For example, suppose the primary interface is a T1 card in the BSD box. If the T1 goes down the card senses loss of carrier, and ifconfig's DOWN the interface. The gateway then knows that the lowest metric default route is no good and sends to the next lowest metric default route. But, let's say your T1 never goes down, but instead certain times of the day the ISP that this T1 is connected to suffers loss of connectivity deep in their network. The break here is many hops away from you. In this case you cannot use interface state detection to adjust route tables because from your gateway's perspective, the primary route is still working. All your gateway cares about is that it can get packets to the next hop router - if it can, then it generally knows nothing about anything beyond that router. Or, let's say your primary is not a T1 but instead a bridged cable modem. Cable modems are connected to the system via Ethernet, and even if they suffer loss of signal, they don't down their ethernet interface, so your gateway is still unable to detect an inactive circuit. The situation is also complicated because when you commence using the alternate route, that route is through a different interface that has a different IP number. So once you start using that route, from the Internet's perspective, the IP number of your server has changed - servers on the Internet now don't know how to get to you. Now, there are ways around these problems, but they are highly dependent on the network architecture your using to plug in to the Internet. Without knowing this there's little anyone can do to advise you. > I have a link that keeps fluctuating and I seriously need >something to run out of cron to manage the > connectivity for me. I don't have sufficient skills to script this >but I believe someone could already > be doing that. > If all you need is client-like connectivity to the Internet, where you can use NAT on your gateway, and you don't care what your public IP number is, then this is not that hard. But - if your offering services over the Internet (ie: people need to transmit traffic TO you) then you need more than a script, you need some well-thought-out networking architecture design. I've gotten in long, involved arguments with people in this forum before on this topic. A lot of them tend to shoot before thinking because they think that redundancy is merely a short script away that twiddles where the default route points. I call them out on it and the usual response is that they are going to prove me wrong by posting their simple script that cleverly solves the problem. Then they go home and try to write this script and as they are doing it they start to understand all the factors and realize that it can't be done, and the simple, clever script never materializes on the mailing list. Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?005601c14329$4b6f73c0$1401a8c0>