Red Hat Bugzilla – Bug 110377
link detection does not work
Last modified: 2014-08-31 19:25:37 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1)
Description of problem:
Quagga claims to support (as per documentation) network link state
(eg. link present) detection, if the underlying network driver
properly supports IFF_RUNNING, which I interpret that the driver
properly uses netif_carrier_on()/_off().
According to ifconfig, this does work.
However, quagga still does not detect link state changes (eg.
"line protocol is up/down").
It does, during startup. But will not detect any changes - which
is why I would want a routing daemon in the first place..
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Make sure your network driver supports IFF_RUNNING by running
ifconfig, verifying the RUNNING flag is displayed when the network
cable is present, and the RUNNING flag disappears once you unplug the
network cable (and call ifconfig again)
2. start quagga (zebra)
3. enable link detection:
4. observe interface status:
show int eth0
5. plug/unplug cable, observe status again
Actual Results: Interface eth0 is up, line protocol is up
Interface eth0 is up, line protocol is up
Expected Results: Interface eth0 is up, line protocol is up
After unplugging the cable, and repeating the command, it should be:
Interface eth0 is up, line protocol is down
(and the apropriate changes in the routing table but I trust that will
happen once the interface shows line protocol down...)
quagga will notice manually configured status changes (eg. I ifconfig
an interface down manually on a different shell, however this
is an entirely different issue (the interface is then, correctly,
"Interface eth0 is down")
strace neither shows activity during unplug/plugin cable, nor any
periodic polling. It does show netlink activity during ifconfig tests.
Could this be a kernel bug, because despite properly knowing the
status change (witness IFF_RUNNING) doesnt send a change notification
via netlink, but quagga expects a notification there ?
One workaround until fix would be to tweak your link timers.
For example, configuring ospf with a hello of 2 s for a particular
point to point would result in a dead time of 8 s (4x hello_time). You
can also try to lower the retransmit time to one second.
This will result in much faster convergence times but cause
oscillations if your IGP links flap rapidly (something that you should
I am fully aware that, strictly speaking, link detection is not
mandatory, and can more or less be emulated with routing protocols,
especially with timers as aggressive as you suggest.
(and in general, you twiddle with those timers only if you have
EXTREMELY good reason).
In the current situation, I wanted just a failover scenario without
a routing protocol, eg. use floating statics, and was quite delighted
when I read the quagga doc
that this is now supported - and disappointed when it didnt work...
I just want to add a "me too" because I would really like to see this fixed. I
am seeing the same results using the 2.6.9-11.ELsmp kernel,e1000 ethernet
cards, and quagga-0.97.3-1.FC3 (until the 100% CPU issue with quagga from RH EL
4 is fixed). I am using Redhat to setup a redundant pair of routers. The way I
have things setup, we could survive a switch failure as well as a router
failure with no service interruption if only dead links could be detected and
routes over dead link could be dropped from the routing table.
Fedora Core 1 is maintained by the Fedora Legacy project for security updates
only. If this problem is a security issue, please reopen and reassign to the
Fedora Legacy product. If it is not a security issue and hasn't been resolved in
the current FC5 updates or in the FC6 test release, reopen and change the
version to match.
NOTE: Fedora Core 1 is reaching the final end of support even by the Legacy
project. After Fedora Core 6 Test 2 is released (currently scheduled for July
26th), there will be no more security updates for FC1. Please use these next two
weeks to upgrade any remaining FC1 systems to a current release.
I just tested on FC5 with kernel 2.6.16-1.2133_FC5smp, an e1000 ethernet card
and quagga-0.98.5-4 by pulling the ethernet cable while quagga/zebra was
In this configuration, zebra properly reports the status as "Interface eth0 is
up, line protocol is down" when the link is lost and returns to "Interface eth0
is up, line protocol is up" once the link is re-established.
Okay, so works in the current release, yeah?