[Quagga-bugs] [Bug 394] New: RTF_DONE is ignored in rtm_read()

[bugzilla-daemon at allevil.dishone.st]

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 at pilot.org.ua
        ReportedBy: web at pilot.org.ua
                CC: paul at 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.