Hi,
I am seeing the following problem with zebra (quagga 0.96.4 pulled
from CVS on 20040427). It occurs under linux 2.4.22 and
under linux 2.6.4.
If I remove the IPV4 address from an ethernet interface, using this command:
ip addr flush dev eth1.4
then the zebra routing table is not being updated properly.
Beforehand, everything looks fine:
[hero@ti25 hero]$ ip -f inet addr show dev eth1.4
7: eth1.4: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
inet 10.147.33.197/27 brd 10.147.33.223 scope global eth1.4
ti25> sh ip route 10.147.33.192/27
Routing entry for 10.147.33.192/27
Known via "kernel", distance 0, metric 0
* directly connected, eth1.4
Routing entry for 10.147.33.192/27
Known via "connected", distance 0, metric 0, best
* directly connected, eth1.4
Then I flush the address from the interface. ip monitor shows the
following netlink messages:
Deleted 7: eth1.4 inet 10.147.33.197/27 brd 10.147.33.223 scope global eth1.4
Deleted broadcast 10.147.33.223 dev eth1.4 table local proto kernel scope link src 10.147.33.197
Deleted broadcast 10.147.33.192 dev eth1.4 table local proto kernel scope link src 10.147.33.197
Deleted local 10.147.33.197 dev eth1.4 table local proto kernel scope host src 10.147.33.197
And now the kernel routing table no longer has the entry for 10.147.33.192,
but zebra still has it:
ti25> sh ip route 10.147.33.192/27
Routing entry for 10.147.33.192/27
Known via "kernel", distance 0, metric 0, best
* directly connected, eth1.4
It seems that the netlink messages do not include one explicitly deleting
the link route. When the address is assigned, the kernel tables look like
this:
[hero@ti25 hero]$ ip route ls table all | grep 10.147.33
10.147.33.192/27 dev eth1.4 proto kernel scope link src 10.147.33.197
broadcast 10.147.33.223 dev eth1.4 table local proto kernel scope link src 10.147.33.197
local 10.147.33.197 dev eth1.4 table local proto kernel scope host src 10.147.33.197
broadcast 10.147.33.192 dev eth1.4 table local proto kernel scope link src 10.147.33.197
So the netlink delete messages include everything except the first "scope link"
route. I guess the kernel assumes that the deletion is implicit in
the deletion of the address. But zebra seems to hold on to that
route.
This is a problem because zebra may then ignore other routes from OSPF
that are actually now the best route, but zebra doesn't realize it.
Any thoughts? Is zebra wrong? Or is netlink wrong? I just thought
I'd query the list before I start debugging the code. Should zebra
automatically remove all routes through an interface once it sees
that the IP address has gone away?
Thanks,
Andy
I am seeing the following problem with zebra (quagga 0.96.4 pulled
from CVS on 20040427). It occurs under linux 2.4.22 and
under linux 2.6.4.
If I remove the IPV4 address from an ethernet interface, using this command:
ip addr flush dev eth1.4
then the zebra routing table is not being updated properly.
Beforehand, everything looks fine:
[hero@ti25 hero]$ ip -f inet addr show dev eth1.4
7: eth1.4: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
inet 10.147.33.197/27 brd 10.147.33.223 scope global eth1.4
ti25> sh ip route 10.147.33.192/27
Routing entry for 10.147.33.192/27
Known via "kernel", distance 0, metric 0
* directly connected, eth1.4
Routing entry for 10.147.33.192/27
Known via "connected", distance 0, metric 0, best
* directly connected, eth1.4
Then I flush the address from the interface. ip monitor shows the
following netlink messages:
Deleted 7: eth1.4 inet 10.147.33.197/27 brd 10.147.33.223 scope global eth1.4
Deleted broadcast 10.147.33.223 dev eth1.4 table local proto kernel scope link src 10.147.33.197
Deleted broadcast 10.147.33.192 dev eth1.4 table local proto kernel scope link src 10.147.33.197
Deleted local 10.147.33.197 dev eth1.4 table local proto kernel scope host src 10.147.33.197
And now the kernel routing table no longer has the entry for 10.147.33.192,
but zebra still has it:
ti25> sh ip route 10.147.33.192/27
Routing entry for 10.147.33.192/27
Known via "kernel", distance 0, metric 0, best
* directly connected, eth1.4
It seems that the netlink messages do not include one explicitly deleting
the link route. When the address is assigned, the kernel tables look like
this:
[hero@ti25 hero]$ ip route ls table all | grep 10.147.33
10.147.33.192/27 dev eth1.4 proto kernel scope link src 10.147.33.197
broadcast 10.147.33.223 dev eth1.4 table local proto kernel scope link src 10.147.33.197
local 10.147.33.197 dev eth1.4 table local proto kernel scope host src 10.147.33.197
broadcast 10.147.33.192 dev eth1.4 table local proto kernel scope link src 10.147.33.197
So the netlink delete messages include everything except the first "scope link"
route. I guess the kernel assumes that the deletion is implicit in
the deletion of the address. But zebra seems to hold on to that
route.
This is a problem because zebra may then ignore other routes from OSPF
that are actually now the best route, but zebra doesn't realize it.
Any thoughts? Is zebra wrong? Or is netlink wrong? I just thought
I'd query the list before I start debugging the code. Should zebra
automatically remove all routes through an interface once it sees
that the IP address has gone away?
Thanks,
Andy