[quagga-dev 1387] link-detect issues (not quite working)

Eric S. Johnson esj at cs.fiu.edu
Wed Aug 11 00:43:42 BST 2004


Hi,

quagga 0.96.5-20040810 (from cvs webpage download)
kernel 2.6.6
interface card 8139too drivers (stock from kernel)
zebra config below

I saw odd behavior with link-detect enabled. 

The card drivers would correctly report the IFF_RUNNING status (and ip 
monitor did too, as did ifconfig tell me correctly RUNNING or not) of 
the ethernet link.

quagga would correctly modify it's RIB to match the card status
IE, if there was good link on eth0 a "show ip route" within quagga
would show the route to the net available, and connected. And if the
link was bad the "show ip route" within quagga would not show a 
route to the net, as well as "show int eth0" saying
Interface eth0 is up, line protocol is down

But the kernel FIB would not be modified. Even if the link was not showing
as running (via ifconfig or "show int eth0" saying line protocol down)
the actual kernel rib (via netstat -r -n or ip route list on command
line) would still show the route to the network that was instantiated
on eth0. And it would try to send packets out that interface if destined
to that network.

Some of these problems were discussed in quagga-user back in may/june 2004
under the subject: Problem with link-detect. No real resolution 
came out of that thread.


I did some pokeing around in the code this afternoon. It seems quagga 
doesn't even try to modify the RIB for RIB_SYSTEM_ROUTE routes.
RIB_SYSTEM_ROUTE routes being ZEBRA_ROUTE_KERNEL or ZEBRA_ROUTE_CONNECT
routes. 

So I took (what I thought) was a sledgehammer to it and changed the 
RIB_SYSTEM_ROUTE macro to only be ZEBRA_ROUTE_KERNEL routes. But the 
netlink calls to remove the CONNECTED routes failed:

2004/08/10 17:18:12 ZEBRA: netlink_parse_info: netlink-listen type RTM_NEWLINK(16), seq=0, pid=0
2004/08/10 17:18:12 ZEBRA: MESSAGE: ZEBRA_INTERFACE_DOWN eth0
2004/08/10 17:18:12 ZEBRA: netlink_route_multipath(): (single hop)RTM_DELROUTE 10.1.1.128/26 via 10.1.1.128 if 12, type Directly connected
2004/08/10 17:18:12 ZEBRA: netlink_talk: netlink-cmd type RTM_DELROUTE(25), seq=172004/08/10 19:18:12 ZEBRA: netlink-cmd error: No such process, type=RTM_DELROUTE(25), seq=17, pid=0


My knowledge of netlink interface is pretty slim, so I may (probably am)
missing subtleties with my brute force approach.

If I "ip route delete" the route from the command line, it goes away just
fine. Even though the interface is still UP (and not RUNNIING :)

So. My questions are:

1. Why doesn't zebra mess with the CONNECTED routes? 
Shouldn't link-detect cause even CONNECTED routes (maybe especially 
CONNECTED routes) to be removed from the kernel FIB as well as
the zebra RIB?

2. Why did my brute force attempt to let it do that fail?
Can netlink not be used to remove CONNECTED routes, or was the 
netlink command to do it not correctly formed?, wrong fib? wrong 
type? As I said my netlink experience is limited to what I have learned
today, so I may be completly misunderstanding something.

Im going to spend even more time tomorrow researching this and 
the code, but if there is a clue bat, please whap me upside the 
head with it.

Thanks for any pointers or comments
E

(zebra.conf included)
[root at localhost hda1]# more zebra.conf
!
! Zebra configuration saved from vty
!   2004/08/09 18:27:07
!
hostname g1-r3
password zeb1
enable password zeb1
log file /mnt/hda1/zebra.log
debug zebra events
debug zebra kernel
debug zebra packet
!
interface eth0
 description link to area 2 net 2 
 link-detect
 ip address 10.1.1.130/26
 ipv6 nd suppress-ra
!
interface eth1
 description link to area 2 net 3 
 link-detect
 ip address 10.1.1.193/26
 ipv6 nd suppress-ra
!
interface eth2
 description link to area 0 net 0 
 link-detect
 ip address 10.1.0.4/24
 ipv6 nd suppress-ra
!
interface gre0
 shutdown
 ipv6 nd suppress-ra
!
interface lo
!
interface shaper0
 ipv6 nd suppress-ra
!
interface sit0
 shutdown
 ipv6 nd suppress-ra
!
interface tunl0
 shutdown
 ipv6 nd suppress-ra
!
!
line vty
!



More information about the Quagga-dev mailing list