public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stefan Rompf <srompf@isg.de>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Interface operative status detection
Date: Sun, 20 Jan 2002 01:51:30 +0100	[thread overview]
Message-ID: <3C4A1492.DC48A17F@isg.de> (raw)
In-Reply-To: <3C498CC9.6FAED2AF@isg.de.suse.lists.linux.kernel> <p73g0525je4.fsf@oldwotan.suse.de>

Andi Kleen wrote:

> It's only when you assume that the link beat is a "serious" sign for
> link healthiness. Unfortunately there are many error cases where a link
> can fail, but the link beat is still there - for example the software
> on the other machine crashing but the NIC still working fine. These
> seem to be the majority of the cases in fact except for demo situations
> where people pull cables on purpose.

I disagree. There are two very real situations that come to my mind
spontaneously:

-Many telecom providers loop back a synchronous serial line whenever the
connection fails somewhere on the WAN. While this actually isn't a link
beat, it can be detected as an interface failure instantly
(!IFF_RUNNING) and is therefore much faster than any (even highly tuned)
routing protocol.

-You have two redundant routers pointing into an ethernet segment, and
if the NIC of one router starts failing, the switch might decide to turn
off the port in question because of excessive errors (many switches do).
Or the switch may simply lose power. Without link beat detection, the
router in question cannot see these situations and will happily continue
advertising the connected network, making the automated backup
mechanism fail. ARP probing is no solution as it can only detect a host
on the network going down, not the interface.


Of course, link beat detection is not the magic lantern making all
networking problems vanish, but from my networking experience it is
important enough to support it.

Stefan


  reply	other threads:[~2002-01-20  0:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3C498CC9.6FAED2AF@isg.de.suse.lists.linux.kernel>
2002-01-19 17:40 ` Interface operative status detection Andi Kleen
2002-01-20  0:51   ` Stefan Rompf [this message]
2002-02-12 14:52   ` David L. Parsley
2002-02-12 15:58     ` Chris Friesen
2002-02-12 16:08       ` Stefan Rompf
2002-01-19 15:12 Stefan Rompf
2002-01-19 15:29 ` Jeff Garzik
2002-01-19 18:34 ` Roberto Nibali
2002-02-08 10:16 ` Jeff Garzik

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=3C4A1492.DC48A17F@isg.de \
    --to=srompf@isg.de \
    --cc=ak@suse.de \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox