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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.