Re: bgp static routes indirect next hop

Tony JOrdan · ‎01-21-2014

Hi all,

I know it seems basic, but I wanted to add static routes to be advertised from the route-reflector to the client peers. The client peer recieves the route but points the destination back to the reflector!

First I'll start with the correct way

route-reflector client peer

ip route vrf test 172.21.1.0 255.255.255.0 172.28.10.2

sh ip ro vrf test

S 172.21.1.0 [1/0] via 172.28.10.2

C 172.28.10.0/24 is directly connected, FastEthernet0/1/1.50

L 172.28.10.1/32 is directly connected, FastEthernet0/1/1.50

route-reflector

172.21.0.0/24 is subnetted, 1 subnets

B 172.21.1.0 [200/0] via 10.255.255.36, 16:03:11

note 10.255.255.36 is loopback of route-reflector client

All ok, the static has been correctly redistributed from the client peer and advertised by the reflector.

Now configure the static from the route-reflector

static removed from route-reflector client

Add static to route-reflector

ip route vrf test 172.21.1.0 255.255.255.0 172.28.10.2

sh ip ro vrf test

172.21.0.0/24 is subnetted, 1 subnets

S 172.21.1.0 [1/0] via 172.28.10.2

172.28.0.0/16 is variably subnetted, 2 subnets, 2 masks

B 172.28.10.0/24 [200/0] via 10.255.255.36, 4w4d

the route route for 172.21.0.0 does a recursive lookup to the correct destination.

Now interestingly look at the the route-reflector client peer

sh ip ro vrf test

172.21.0.0/24 is subnetted, 1 subnets

B 172.21.1.0 [200/0] via 10.255.255.120, 00:09:48

172.28.0.0/16 is variably subnetted, 3 subnets, 3 masks

C 172.28.10.0/24 is directly connected, FastEthernet0/1/1.50

L 172.28.10.1/32 is directly connected, FastEthernet0/1/1.50

Here we note the bgp route for 172.21.0.0 is now pointing back to the route-reflector.

Is this behaviour just the limitation of doing static routes with indirect next hop?

Cheers

Tony

Jon Marshall · ‎01-21-2014

Tony

I assume when you moved the configuration to the router reflector you removed the static route from the VRF on the router reflector client ?

If so i would expect this to happen with all protocols, not just BGP. The issue is that the router reflector is only advertising the 172.21.1.0/24 network with itself as the next hop. There is nothing in the route advertisement to tell the client that this is a recursive lookup and that actually the client is the router with the direct link to the next hop ie. 172.28.10.2.

Obviously if you left the static route in the VRF on the client it would ignore the IBGP update because of the AD and use it's own static route.

Jon

Tony JOrdan · ‎01-21-2014

HI Jon,

yes thats correct, config moved to rr

Does this not show a recursive lookup?

sh ip ro vrf test

172.21.0.0/24 is subnetted, 1 subnets

S 172.21.1.0 [1/0] via 172.28.10.2 ==================== reachable by this address

172.28.0.0/16 is variably subnetted, 2 subnets, 2 masks

B 172.28.10.0/24 [200/0] via 10.255.255.36, 4w4d ============= lookup for 172.28.10.0 network

Tony

Jon Marshall · ‎01-21-2014

Tony

Yes that is a recursive lookup but it is only relevant to the router reflector ie. when it advertises 172.21.1.0/24 to the client there is nothing in that advertisement to tell the client that the actual next hop is a network directly connected to the client.

And the router reflector is simply advertising out 172.21.1.0/24 as you have configured it. I guess the question you are asking is does the route reflector not realise the actual next hop is 10.255.255.36 so it shouldn't be advertising a route to the client for 172.21.1.0/24 when it knows to get to that network it has to go back to the client.

I don't think the routing protocols have those kind of checks built in with recursive lookups. Recursive lookups are resolved by CEF to point to the actual next hop eg if you did on the router reflector -

"sh ip route vrf test 172.21.1.0 255.255.255.0" then the next hop would be 172.28.10.2

"sh ip cef vrf test 172.21.1.10 255.255.255.0" then the next hop is actually 10.255.255.36 ie. the route reflector client

(note i am assuming there is such a command as "sh ip cef vrt test .....")

so if the router resolved the actual next hop it might realise it is trying to advertise a route to a peer that is actually the next hop for that route. I say might because i have never tested it and couldn't say for sure and IBGP itself may not behave exactly the same way as other routing protocols.

But routing protocols,as far as i am aware, don't do this resolution of the real next hop so the 172.21.1.0/24 advertisement is seen in isolation if that makes sense.

It makes sense to me but like i say i have never tested this (and don't have anything to test with) so i may be off the mark.

Jon

Jon Marshall · ‎01-21-2014

Tony

Just a quick addition. When i said routing protocols are not concerned with recursive lookups that may have been a bit misleading. For the route to be installed in the routing table the next hop must be reachable even if it is recursive.

What i was trying to get across was that in terms of advertisements i don't believe they do this recursion ie. they simply advertise out the networks you have told them to as long as the actual next hop is reachable.

Jon