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?
next prev parent 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 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.