[Xorp-hackers] Question on RIB

[Pavlin Radoslavov]

Ben Greear <greearb at candelatech.com> wrote:

> I have a scenario of 4 routers.  Starting config is:
> 
> A <-> B
> B <-> C
> C <-> D
> 
> Also:
> B <-> D  (high cost link)
> 
> OSPF chooses the B-C link instead of the high cost link, and all is well.
> 
> Then, I disconnect (remove the interfaces & OSPF config for those interfaces
> with xorpsh)
> 
> B & C
> 
> OSPF correctly starts using the high-cost link.
> 
> 
> Then, I reconnect B & C with the low cost link.
> 
> It seems OSPF is trying to do the right thing.  Routes are deleted from
> the high-cost link, but they do not appear on the low cost link.  The
> reason appears to be this error in RIB.  I tried doing a 'commit' after
> adding the interface and before adding the config to OSPF, but that did
> not help.
> 
> Any idea how RIB learns about the directly connected interfaces?  Looks like
> I need to somehow make it learn faster...

I presume you already double-checked that that 10.2.3.3 indeed is a
router directly connected to one of the new added interfaces.

The RIB itself obtains the interface information from the FEA (like
the routing protocols themselves), so it appears the reason for the
error is a race condition.
After the interface is added, the FEA notifies both OSPF and RIB
about the change. However, by the time the information reaches OSPF
and it sends add_route to the RIB, the RIB still hasn't received
update.

Off the top of my head, I see two possible solutions (at least):

(a) Change the OSPF so it delays the add_route XRL to the RIB after
    a new interface has been added. This is a hackish solution
    that is probably not that difficult to implement, but strictly
    speaking it doesn't eliminate the race condition. E.g., even if
    you delay, for say, 5 seconds there is no guarantee the
    interface update from the FEA has reached the RIB within those
    5 seconds.

(b) Have the OSPF obtain the interface information via the
    RIB. I.e., have the RIB act as a proxy for passing the
    information from the FEA to OSPF. This will guarantee that the
    RIB will always see the update before the protocol (OSPF).
    FYI, we do something similar for multicast: the MFEA acts as a
    proxy for the interface information propagation from the FEA to
    IGMP/MLD and PIM-SM, but the original motivation for that was
    different (the MFEA was adding multicast-specific information to
    the iftree).
    Though, in case of MFEA the implementation takes a short-cut
    utilizing the fact that both the FEA and MFEA are within the
    same process. The RIB implementation needs to be a bit different
    in that aspect.

Regards,
Pavlin

> [ 2007/10/24 16:40:25 TRACE xorp_ospfv2 OSPF ] Add route Net 10.2.2.0/24 Nexthop 10.2.3.3 metric 2 equal false discard false policy
> [ 2007/10/24 16:40:25  ERROR xorp_rib:17650 RIB rib.cc:856 add_route ] Attempting to add IGP route to table "ospf" (prefix 10.2.2.0/24 next-hop 10.2.3.3): no directly connected interface toward the next-hop router
> [ 2007/10/24 16:40:25 WARNING xorp_rib XrlRibTarget ] Handling method for rib/0.1/add_route4 failed: XrlCmdError 102 Command failed Could not add IPv4 route net 10.2.2.0/24, nexthop: 10.2.3.3 to unicast RIB
> [ 2007/10/24 16:40:25  ERROR xorp_ospfv2:17680 OSPF xrl_io.cc:1167 route_command_done ] callback: add_route: ribname rib net 10.2.2.0/24 nexthop 10.2.3.3 102 Command failed Could not add IPv4 route net 10.2.2.0/24, nexthop: 10.2.3.3 to unicast RIB
> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers