netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Graf <tgraf@suug.ch>
To: Hasso Tepper <hasso@estpak.ee>
Cc: netdev@oss.sgi.com
Subject: Re: Link detection
Date: Mon, 14 Mar 2005 15:57:10 +0100	[thread overview]
Message-ID: <20050314145710.GO31837@postel.suug.ch> (raw)
In-Reply-To: <200503141605.02959.hasso@estpak.ee>

* Hasso Tepper <200503141605.02959.hasso@estpak.ee> 2005-03-14 16:05
> > The routes must stay if the interface isn't shut down completely. A loss
> > of the carrier can be temporarly for just a very short period of time.
> > What we can do is, like in the neighbour tables, differ between a
> > adimistrative shutdown and a loss of the carrier with a new flag, would
> > that help you?
> 
> In theory yes, if this info is carried over netlink. 

It is carried but not in the way I mentioned. I was wrong with IFF_UP, it
isn't modified. An event is sent upon carrier off and again when the carrier
is found again so you must toggle. Alternatively we can alter a flag in
netif_carrier_(on|off) which is probably a good idea anyway. I'll prepare
a patch for this. Polling sysfs is definitely not the way to go.

> > Problem #1: Differ between a temporary loss of carrier and a permanent
> >             failure. Relatively easy from userspace because userspace
> >      knows about the strategy.
> 
> Is there need for that? There should be knob of course to tune behaviour 
> IMHO. Sure there are applications which expect current behaviour. 

Now that I know you're only taking about implicite routes the problem
is less serious, still a timeout value would be a good thing, one can
always set it to 0 to remove routes immediately or disable it completely.

> I think that you misunderstood. I don't talk about any routes created by any 
> user space applications or by user. These _must_ be untouched of course. 
> I'm talking about routes _kernel_ creates if address is added to the 
> interface. All other routes are not problem anyway. Even if their next hop 
> points to network behind down interface, their next hop is unreachable and 
> route shouldn't be used, no?

Makes a lot more sense now. Yes, the nexthops should be marked unreachable
since the routing cache flushed upon a NETDEV_CHANGE.

What about setting RFT_REJECT/RTN_UNREACHABLE on those routes for the time
the carrier is gone?

  reply	other threads:[~2005-03-14 14:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-14 12:35 Link detection Hasso Tepper
2005-03-14 13:32 ` Thomas Graf
2005-03-14 14:05   ` Hasso Tepper
2005-03-14 14:57     ` Thomas Graf [this message]
2005-03-14 18:41       ` Hasso Tepper
2005-03-14 14:41   ` Hasso Tepper
2005-03-14 15:03     ` Thomas Graf
2005-03-14 16:54     ` Thomas Graf
2005-03-14 16:16 ` [PATCH] ip link should print NO-CARRIER for !IFF_RUNNING && IFF_UP Thomas Graf

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=20050314145710.GO31837@postel.suug.ch \
    --to=tgraf@suug.ch \
    --cc=hasso@estpak.ee \
    --cc=netdev@oss.sgi.com \
    /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).