Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.
http://bugzilla.quagga.net/show_bug.cgi?id=394
Summary: RTF_DONE is ignored in rtm_read()
Product: Quagga
Version: CVS
Platform: Other
OS/Version: other
Status: NEW
Severity: major
Priority: Medium
Component: zebra
AssignedTo: web@pilot.org.ua
ReportedBy: web@pilot.org.ua
CC: paul@dishone.st
RTF_DONE flag isn't checked for messages, arriving from kernel routing socket.
This results in all route commands being interpreted instead of processing only
those, which has succeeded. As a result RIB has wrong idea what is installed in
FIB and what is not:
Initial state (a.b.c.d is the default gateway):
# vtysh -e 'sh ip ro 192.168.30.30'
Routing entry for 0.0.0.0/0
Known via "ospf", distance 110, metric 10000
Last update 1d01h02m ago
a.b.c.d, via fxp0
Routing entry for 0.0.0.0/0
Known via "kernel", distance 0, metric 0, best
* a.b.c.d, via fxp0
# route -n get 192.168.30.30
route to: 192.168.30.30
destination: default
mask: default
gateway: a.b.c.d
interface: fxp0
flags: <UP,GATEWAY,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 1500 0
Now we install a route through an unreachable nexthop:
# route add -host 192.168.30.30 192.168.50.50
add host 192.168.30.30: gateway 192.168.50.50
Surprisingly, FreeBSD accepts it and even marks it UP:
# route -n get 192.168.30.30
route to: 192.168.30.30
destination: 192.168.30.30
gateway: 192.168.50.50
interface: fxp0
flags: <UP,GATEWAY,HOST,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 1500 0
zebra notices the new route, but marks it as inactive:
# vtysh -e 'sh ip ro 192.168.30.30'
Routing entry for 192.168.30.30/32
Known via "kernel", distance 0, metric 0
* 192.168.50.50 inactive
Now we install another route without deleting the first one. The OS can't
tolerate this any more:
# route add -host 192.168.30.30 192.168.150.150
route: writing to routing socket: File exists
add host 192.168.30.30: gateway 192.168.150.150: route already in table
But zebra has updated its RIB:
# vtysh -e 'sh ip ro 192.168.30.30'
Routing entry for 192.168.30.30/32
Known via "kernel", distance 0, metric 0
* 192.168.150.150 inactive
The nexthop is mistakenly marked as present in FIB. This can result in the
following situation:
1. zebra has an OSPF route to X. The route is installed into FIB.
2. some other process issues RTM_ADD command, which fails due to presence of the
above route.
3. zebra imports a new ghost kernel route into RIB, which wins over OSPF route.
The OSPF route is withdrawn from the FIB.
4. RIB lists 2 entries for the destination X: a kernel one (ACTIVE, SELECTED,
FIB) and an OSPF one (ACTIVE). FIB has no route records for X.
A patch to fix this is being prepared.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-bugs
comments should be made in the comments box of this bug
report.
http://bugzilla.quagga.net/show_bug.cgi?id=394
Summary: RTF_DONE is ignored in rtm_read()
Product: Quagga
Version: CVS
Platform: Other
OS/Version: other
Status: NEW
Severity: major
Priority: Medium
Component: zebra
AssignedTo: web@pilot.org.ua
ReportedBy: web@pilot.org.ua
CC: paul@dishone.st
RTF_DONE flag isn't checked for messages, arriving from kernel routing socket.
This results in all route commands being interpreted instead of processing only
those, which has succeeded. As a result RIB has wrong idea what is installed in
FIB and what is not:
Initial state (a.b.c.d is the default gateway):
# vtysh -e 'sh ip ro 192.168.30.30'
Routing entry for 0.0.0.0/0
Known via "ospf", distance 110, metric 10000
Last update 1d01h02m ago
a.b.c.d, via fxp0
Routing entry for 0.0.0.0/0
Known via "kernel", distance 0, metric 0, best
* a.b.c.d, via fxp0
# route -n get 192.168.30.30
route to: 192.168.30.30
destination: default
mask: default
gateway: a.b.c.d
interface: fxp0
flags: <UP,GATEWAY,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 1500 0
Now we install a route through an unreachable nexthop:
# route add -host 192.168.30.30 192.168.50.50
add host 192.168.30.30: gateway 192.168.50.50
Surprisingly, FreeBSD accepts it and even marks it UP:
# route -n get 192.168.30.30
route to: 192.168.30.30
destination: 192.168.30.30
gateway: 192.168.50.50
interface: fxp0
flags: <UP,GATEWAY,HOST,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 1500 0
zebra notices the new route, but marks it as inactive:
# vtysh -e 'sh ip ro 192.168.30.30'
Routing entry for 192.168.30.30/32
Known via "kernel", distance 0, metric 0
* 192.168.50.50 inactive
Now we install another route without deleting the first one. The OS can't
tolerate this any more:
# route add -host 192.168.30.30 192.168.150.150
route: writing to routing socket: File exists
add host 192.168.30.30: gateway 192.168.150.150: route already in table
But zebra has updated its RIB:
# vtysh -e 'sh ip ro 192.168.30.30'
Routing entry for 192.168.30.30/32
Known via "kernel", distance 0, metric 0
* 192.168.150.150 inactive
The nexthop is mistakenly marked as present in FIB. This can result in the
following situation:
1. zebra has an OSPF route to X. The route is installed into FIB.
2. some other process issues RTM_ADD command, which fails due to presence of the
above route.
3. zebra imports a new ghost kernel route into RIB, which wins over OSPF route.
The OSPF route is withdrawn from the FIB.
4. RIB lists 2 entries for the destination X: a kernel one (ACTIVE, SELECTED,
FIB) and an OSPF one (ACTIVE). FIB has no route records for X.
A patch to fix this is being prepared.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-bugs