From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 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): quagga-0.96.3-1 How reproducible: Always 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: conf t int eth0 link-detect 4. observe interface status: show int eth0 5. plug/unplug cable, observe status again Actual Results: Interface eth0 is up, line protocol is up [...] ->Unplug cable 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...) Additional info: 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 engineer against)
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. Thanks! 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 running. 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?