All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rene Gallati <lartc@draxinusom.ch>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Interface not marked down when links are down
Date: Thu, 20 Jan 2005 07:25:20 +0000	[thread overview]
Message-ID: <41EF5CE0.2040501@draxinusom.ch> (raw)
In-Reply-To: <20050120020957.43586.qmail@web50108.mail.yahoo.com>

SPJ wrote:
> I am not sure if this problem has already being
> posted, but I haven't found any solution. Excuse me if
> it's a repost but would appreciate any pointers. 
> I have newly configured Multipath default route. I
> have 1  local connection and 4 internet connections. I
> am using kernel 2.6.7 and have applied Julian's
> relevent patches. 
> When the next hop is down, julian's patch takes care
> of the links changing the route to only the links
> which it finds are up and forwarding traffic to those
> links. But if the problem is anywhere in between,
> beyond the next hop, the links are not marked
> identified as down (I down see the change in multipath
> default route) and requests still go via them and
> hence no connectivity, even if some other links are
> up.
> Does Julian's patch takes care of route only if next
> hop is down. Any solution to this problem?

You are looking at the wrong layer. If the next hop is unreachable, 
which is a layer 2 thing, the system notices this and acts accordingly. 
If however a link further away is down, there is no such mechanism on 
layer 2 and your system cannot react to it (with standard means).

This is quite "psychic" if you want. Why should your system magically 
know there is a problem 4 hops upstream ? It only sees the links it is 
directly attached. The packets are accepted on one link and this is 
where the responsibility of your multihomed system ends. It neither does 
nor should track packets over the full path from source to destination.

There is a solution however: For that kind of thing you need to look 
into routing software (BGP, OSPF) which has this capability. If you 
don't control the upstream machines, you will need to get a bgp-peering 
with your upstream provider to be able to react to outages. If your 
mentioned 4 connections are standard home-adsl/cable connections, this 
might be difficult however.

Hope that helps.
-- 

C U

      - -- ---- ----- -----/\/  René Gallati  \/\---- ----- --- -- -

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

      reply	other threads:[~2005-01-20  7:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-20  2:09 [LARTC] Interface not marked down when links are down SPJ
2005-01-20  7:25 ` Rene Gallati [this message]

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=41EF5CE0.2040501@draxinusom.ch \
    --to=lartc@draxinusom.ch \
    --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.