[Xorp-hackers] Question on RIB

Ben Greear greearb at candelatech.com
Thu Oct 25 18:07:32 PDT 2007


Pavlin Radoslavov wrote:
> 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.

Yes, can ping between them and traceroute shows expected info.

Also, if I restart XORP, it comes up with expected routes.

> 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.

Option B seems best to me.  In general, it seems we should have exactly
one 'real' interface tree, and let other modules query it and cache whatever
local info they need from this tree.  The modules should be aware that interfaces
can change at any time, so they should handle errors (ie, I added a route to interface
foo and foo doesn't exist now) gracefully.  It seems OSPF basically does handle
the errors...it just prints a message instead of asserting or crashing.

That said, I'll see if I can figure out a way to do 'A' quickly.  Trying
really hard to get something working by Monday, even if it's a bit of a
hack :)

Thanks,
Ben



More information about the Xorp-hackers mailing list