Ben Greear <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> Candela Technologies Inc http://www.candelatech.com
>
> _______________________________________________
> Xorp-hackers mailing list
> [email protected]
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
_______________________________________________
Xorp-hackers mailing list
[email protected]
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
