[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