[Xorp-users] Related Route Redistribution Ruin

[Pavlin Radoslavov]

> After 4.5 hours of digging into a problem I'm having, I believe I
> finally know enough to ask an intelligent question.
> 
> My XORP router is a BGP router peering with another BGP router elsewhere
> (not ours). We're receiving thousands of routes, fine, but unable to
> send our single route to our BGP peer.
> 
> What appears to be happening is that the route I want to send: 
> 
>  route 137.143.0.0/16 {
>         next-hop: w.x.y.z
>  }
> 
> is for some reason being ignored because it is related to one of the
> connected interfaces (137.143.16.0/20). If I change the route to
> ANYTHING not related to a connected interface, ala 137.142.0.0/16 (note
> the decrease in the second octet) the route flies out perfectly (albeit
> not the route I WANT to send out).
> 
> 'show route table ipv4 unicast static' is empty if the correct network
> is used, and "correct" if the false one is used.
> 
> I have used Xorp 1.4, and a CVS checkout from a couple weeks ago.
> 
> Am I missing something? How can I force that route to be sent?

For the static route configuration itself lets say you have
configuration like the following:

interfaces {
    interface dc0 {
        vif dc0 {
            address 10.10.10.10 {
                prefix-length: 24
            }
        }
    }
}

fea {
    unicast-forwarding4 {
        disable: false
    }
}

protocols {
    static {
        route 10.10.10.0/24 {
            next-hop: 10.10.10.10
        }
    }
}

With such setup the "show route table ipv4 unicast static" command
should return the route:

user at hostname> show route table ipv4 unicast static 
10.10.10.0/24   [static(1)/1]
                > to 10.10.10.10 via dc0/dc0

[It is odd that in your setup the route is not shown, though I
should note that in my test I am using the latest code from CVS. One
reason that comes to mind to prevent it from showing is if the cable
for the interface toward the next-hop for the route is disconnected.]

However, the same route is added to RIB by the "connected"
component:

user at hostname> show route table ipv4 unicast connected
10.10.10.0/24   [connected(0)/0]
                > via dc0/dc0

The admin distance for connected routes is better than the
static routes, therefore the winner will be the connected route:

user at hostname> show route table ipv4 unicast final 
10.10.10.0/24   [connected(0)/0]
                > via dc0/dc0


Below I assume that in your configuration you export the "connected"
routes only.

When you export routes into BGP (or into any other protocol), only
the winning routes (at the "final" table) from the exported protocol
are actually exported. Therefore in the above example the
10.10.10.0/24 route from "static" loses to the same route from
"connected" and it will not be exported into BGP.

If you really want to export a particular route into BGP that
happens to be one of your directly connected subnets, then you need
to do something like the following:

policy {
    policy-statement export-connected-subnet {
        term 100 {
            from {
                protocol: "connected"
                network4: 10.10.10.0/24
            }
        }
    }
}

protocols {
    bgp {
        export: "export-connected-subnet"
        ...
    }
}

Hope that helps,
Pavlin