mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Stefan Rompf <srompf@isg.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Interface operative status detection
Date: 19 Jan 2002 18:40:35 +0100	[thread overview]
Message-ID: <p73g0525je4.fsf@oldwotan.suse.de> (raw)
In-Reply-To: <3C498CC9.6FAED2AF@isg.de.suse.lists.linux.kernel>
In-Reply-To: Stefan Rompf's message of "19 Jan 2002 16:27:54 +0100"

Stefan Rompf <srompf@isg.de> writes:

> while playing with the Zebra routing daemon, I realized that neither
> Linux nor Zebra are capable of detecting the operative state of an
> interface, f.e. the ethernet link beat. This is a major show stopper
> against using Linux for "serious" IP routing.

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. To handle all the other cases you
need a separate heartbeat protocol that actually checks if the higher
layers above the networking card are alive on the peer too. Most routing
protocols do this already in fact, e.g. OSPF or RIP with their 'hello' 
packets. The Linux IP stack does it also using ARP probes.  When a probe
is not answered the routing daemon eventually notices and takes action.
While waiting for probes is a bit slower (30-60s usually), checking
the link beat only handles such a small subset of cases that it is not
worth it to optimize these rare ones. 

Commercial vendors seem to like it because it looks good in demos ;),
but linux fortunately doesn't have to be concerned with such marketing
reasoning. 

In short - Linux doesn't have this feature because it's not needed.
If your routing protocol relies on link state checking without other
probing it's broken. Zebra isn't. 

-Andi

       reply	other threads:[~2002-01-19 17:41 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 ` Andi Kleen [this message]
2002-01-20  0:51   ` Stefan Rompf
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=p73g0525je4.fsf@oldwotan.suse.de \
    --to=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=srompf@isg.de \
    /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

Powered by JetHome