From: "Adrian C." <drupix@gmail.com>
To: "Kevin J. Cummings" <cummings@kjchome.homeip.net>
Cc: linux-admin <linux-admin@vger.kernel.org>
Subject: Re: SSL Certificate signing problem
Date: Sun, 10 Oct 2004 03:24:10 +0300 [thread overview]
Message-ID: <60a7468904100917247ae77c18@mail.gmail.com> (raw)
In-Reply-To: <4168804A.9020200@kjchome.homeip.net>
If i assign metric 1 to 1st gway and 2 to 2nd it never falls back from
gateway with best metric. Even if it goes down it still sticks to it.
Something is terribly wrong. I am running Slackware 10.
On Sat, 09 Oct 2004 20:20:26 -0400, Kevin J. Cummings
<cummings@kjchome.homeip.net> wrote:
>
>
> Adrian C. wrote:
> > Hello. I'm trying to setup a simple failover between 2 gateways on kernel 2.6.2
> > Here it goes.
> > just one interface for everything: eth0
> > route add default gw 192.168.1.1
> > route add default gw 192.168.2.1
> >
> > let's say i ping gmail.com and i kill the 192.168.1.1 machine. ping
> > stops for about 2 minutes then the next gateway is used and the ping
> > comes back to live. The only problem here is that it forgets to NAT my
> > clients via the new gway. At least that's my only explanation why it
> > stops NATting. Masquerading is done without a -d so destination is
> > any. What can be done here?
> > Also please let me know the files in which i should modify fallback
> > timeout for routes. I need a route check every 10 seconds or so.
> > One more thing, if 192.168.1.1 comes back to live i would like to
> > become the preferred gateway no matter if 192.168.1.2 is alive and
> > used by kernel. Is this solved by metrics?
>
> I thought that this is what Metrics were supposed to do. If you
> *prefer* the .1.1 route, assign it a better Metric than the .2.1 route.
> Then, when the .1.1 route goes down, the packets should be immediately
> re-routed to the .2.1 interface, and when the .1.1 comes back up, the
> first route should work again. THat's *my* understanding of how Metrics
> are supposed to work.
>
> I'm not an expert, and I'm not sure about what happens after a TCP
> connection is already established and then an interface fails (or
> restores) whether *that* connection will continue to use the previous
> routing or not.
>
> --
> Kevin J. Cummings
> kjchome@rcn.com
> cummings@kjchome.homeip.net
> cummings@kjc386.framingham.ma.us
>
next prev parent reply other threads:[~2004-10-10 0:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-07 18:26 SSL Certificate signing problem Tony Gogoi
2004-10-09 23:42 ` Adrian C.
2004-10-10 0:20 ` Kevin J. Cummings
2004-10-10 0:24 ` Adrian C. [this message]
2004-10-10 1:07 ` Kevin J. Cummings
2004-10-10 7:55 ` Adrian C.
2004-10-11 5:35 ` Adrian C.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60a7468904100917247ae77c18@mail.gmail.com \
--to=drupix@gmail.com \
--cc=cummings@kjchome.homeip.net \
--cc=linux-admin@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).