[Xorp-users] iBGP routes not being used/forwarded

Bruce M Simpson bms at incunabulum.net
Tue Dec 2 22:30:46 PST 2008


Russ,

We need to see what the RIB thinks about the routes you're introducing 
from your collector daemon.

Russ Dill wrote:
> ...
>
> However, no local routes are added:
>
> ip route
> 192.168.1.0/24 <http://192.168.1.0/24> dev eth0  proto kernel  scope 
> link  src 192.168.1.136 <http://192.168.1.136>  metric 2
> 169.254.0.0/16 <http://169.254.0.0/16> dev eth0  scope link  metric 1000
> 10.0.0.0/8 <http://10.0.0.0/8> dev mea0  scope link
> default via 192.168.1.1 <http://192.168.1.1> dev eth0
>
> And no updates are sent to the backhaul peer.
>
> Both peers are running XORP 1.5-6 from debian.
>   

The most likely explanation for the behaviour you are seeing, is that 
the updates are present in the BGP routing table, but the RIB is not 
selecting them as the candidate paths because of that 10.0.0.0/8 entry, 
which the RIB will learn about from the FEA as a 'connected' route. 
That's pretty clear from the output you've provided.

Note that whilst the iBGP routes are "valid", they are not "best", 
therefore there is absolutely no reason for iBGP to propagate them in 
updates -- unless you do some very specific tweaking using LOCAL_PREF 
and import policies, to cause those routes to win BGP's internal lookup.

You're also going to have to do some tricks with administrative distance 
to get the RIB to choose the iBGP learned routes with the /24 prefixes. 
XORP defaults to an admin distance of 200 for iBGP and 0 for "connected" 
routes, so clearly, the iBGP routes will lose the RIB lookup every time.

I believe the features to control admin distance on a per-protocol basis 
got added in the run up to the 1.5 release -- OLSR certainly makes use 
of them -- although they may not be fully documented until 1.6.

thanks
BMS





More information about the Xorp-users mailing list