From: Thomas Vander Stichele <thomas@urgent.rug.ac.be>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] question re: dead gateway detection
Date: Wed, 27 Mar 2002 13:59:30 +0000 [thread overview]
Message-ID: <marc-lartc-101723763902792@msgid-missing> (raw)
In-Reply-To: <marc-lartc-101722239517873@msgid-missing>
> > So my question is: is there some way that I can detect that the actual
> > route to the net is unusable, even though the gateway is up ? If not, when
> > either one of the lines is down, users will notice they're not getting a
> > connection randomly, depending on what gateway is used for that
> > connection.
> >
> > Thomas
>
> It sounds to me like you need something which is proactively monitoring
> your network health/status. The points in the network your referring
> to, are not under your sirect control, so there's not a lot tc/ip can
> directly do to solve your problem.
>
> but with some clever scripting, you could attempt to detect a fault in
> the network, and take appropriate action. such as delete the faulty
> route for all the clients that were using it, and forec them onto the
> other route. you'll still need to be able to test the dead route from
> the box, such that you can activate again, once its working.
>
> i hope i understood the problem correctly, and havent gone off on one.
No, you understood it correctly, and this is what I used to do. However,
i was looking for a better solution and the load balancing is, in a normal
situation, better. What I wanted to know was, how can I combine this
scripting that checks for usable routes to the net with the current nano
setup I'm using. I would like for it to integrate cleanly, ie. not having
to change routes on the fly each time, but instead maybe mark the gateway
as dead by hand, for example.
If it's not possible, I might as well just go back to the older setup
without the load balancing, because in that case we just routed some of
the traffic over one gateway and some of the other traffic over another,
folding stuff back over the working line if one of the went down.
I just really like the cleanliness of the nano approach with julian's
patches, and would like to add on that instead ;)
Thomas
--
The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*- -*->
I have these hands teeming with love for you
But you're not here to touch
You said you'd wait but it's killing me
When I need something that much
<-*- thomas@apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2002-03-27 13:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-27 9:45 [LARTC] question re: dead gateway detection Thomas Vander Stichele
2002-03-27 13:15 ` Vincent AE Scott
2002-03-27 13:59 ` Thomas Vander Stichele [this message]
2002-03-27 16:22 ` Steele, Tom
2002-03-29 10:26 ` Thomas Vander Stichele
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=marc-lartc-101723763902792@msgid-missing \
--to=thomas@urgent.rug.ac.be \
--cc=lartc@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.