IOS route selection, null vs iBGP

forumsttor · ‎01-27-2011

Hi

Short description: why does ios select null route w/ distance 230 as active path instead of route learned from iBGP?

Normally R1's active route is static route via fa2/0
ip route 192.168.4.0/23 255.255.254.0 FastEthernet2/0 192.168.4.6

R1#sh ip route 192.168.4.0 255.255.254.0
Routing entry for 192.168.4.0/23
    Known via "static", distance 1, metric 0
    Advertised by bgp 65001
    Routing Descriptor Blocks:
    * 192.168.4.6, via FastEthernet2/0
        Route metric is 0, traffic share count is 1

Same route is learned with iBGP from R2

R1#sh ip bgp nei 192.168.4.21 received-routes
BGP table version is 6, local router ID is 192.168.4.20
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
* i192.168.4.0/23 192.168.4.21 0 100 0 i

Total number of prefixes 1

Because R1 is announcing the prefix with BGP, it has also corresponding null route
ip route 192.168.4.0 255.255.254.0 Null0 230

As stated, normally fa2/0 static route is active. If that path is lost (fa2/0 shutdown in testing scenario),
the null0 route becomes active instead of iBGP route:

R1#sh ip route 192.168.4.0 255.255.254.0
Routing entry for 192.168.4.0/23
Known via "static", distance 230, metric 0 (connected)
Advertised by bgp 65001
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 0, traffic share count is 1

R1#sh ip bgp neighbors 192.168.4.21 received-routes
BGP table version is 9, local router ID is 192.168.4.20
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
* i192.168.4.0/23 192.168.4.21 0 100 0 i

Total number of prefixes 1

Now, depending on IOS version, the iBGP route becomes active after clearing bgp and/or removing and re-adding
the null0 route.

R1#sh ip route 192.168.4.0 255.255.254.0
Routing entry for 192.168.4.0/23
Known via "bgp 65001", distance 200, metric 0, type internal
Advertised by bgp 65001 (self originated)
Last update from 192.168.4.21 00:00:36 ago
Routing Descriptor Blocks:
* 192.168.4.21, from 192.168.4.21, 00:00:36 ago
Route metric is 0, traffic share count is 1
AS Hops 0

Notice "self originated" above. R1 indeed has the prefix configured with router bgp network statement:
router bgp 65001
network 192.168.4.0 mask 255.255.254.0

I think the problem is caused by the fact that R1 is advertising the prefix to R2. To confirm this I tried removing
the "network 192.168.4.0 mask 255.255.254.0" line from R1. After this, the iBGP path from R2 was indeed selected as
the active path in case of fa2/0 failure.

If I configure R2 to advertise the prefix with ospf, R1 selects the OSPF route as active path and the setup works.
But is this the correct fix/workaround? R1 and R2 both have connectivity to 192.168.4.0/23 and the L3 redundancy
behind fa2/0 is accomplished by VRRP (i.e. R1 and R2 are a vrrp pair).

Thanks

Afilias Canada · ‎12-17-2011

Your best in this case is to remove the nail down route via null 0, the reason is that with the null 0 approach you may end up null routing traffic if your R1-R2 link fails AND your fa2/0 is also down while your BGP upstream link is active.

In my opinion it would be better to put the prefix into BGP using the bare network command with the static route via fa2/0. if f2/0 goes down the iBGP route from the R1 will prevent the prefix from flapping and a double hop will occur for any traffic landing on the router with the failed f2/0 interface, that's all.

Because the way you are originating the prefix into BGP is impossible to have the router pick the iBGP peer as the best path the null0 interface always win. The best you can end up with is a half working solution after manipulating weight and/or local preference. If you do this you will always end up on one side with a rib-failure that never advertises the path via r1-r2 to the other iBGP peer (rib-failed prefixes are advertised only when they contain a best-path matching the next hop installed for that prefix in the RIB)

Finally make sure you track an upstream route to avoid having an active VRRP peer attracting outbound traffic that has nowhere to go (i.e R1-R2 and upstream down but f2/0 up )

goobysnack · ‎07-21-2016

Shouldn't route selection be based on Admin Distance first? iBGP is 200 by default and the AD for the null route is set to 230. The null route should never be considered. Weight and LocalPref should only be considered when there are multiple iBGP paths. So, in this case, iBGP would be selected over static null route. Right?

milan.kulik · ‎07-22-2016

Hi,

IMHO, the issue might be following:

R1#sh ip route 192.168.4.0 255.255.254.0
Routing entry for 192.168.4.0/23
Known via "static", distance 230, metric 0 (connected)
Advertised by bgp 65001
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 0, traffic share count is 1

So if the static route to Null gets active, it's also added to the BGP database with Weight=32576 by default.

Even when the same iBGP prefix is received then, the original static route wins within the BGP process itself (no matter of AD).

So you would need to play with BGP attributes a little.

Firstly to get the Weight attribute 0 when putting the static route to BGP database (using a redistribution with a route-map instead of network ... command, e.g.) and secondly to make the Local Preference worse then the one assigned to the iBGP prefix (you can use the same route-map to modify the LP), e.g.

This way you would make the iBGP prefix to beat the same static prefix redistributed to BGP within the BGP process.

And then the AD will take the role to make the iBGP prefix to beat the static one from the routing process (RIB) point of view.

Best regards,

Milan

goobysnack · ‎07-22-2016

You're right! We figured this out about an hour after I posted above. It's not the null static route that is in the RIB, it's the redistributed null static route that is in iBGP. So, the path selection is not static v iBGP, it's one iBGP vs another. In this case, the redistributed route has a weight of 32768 (default), and the iBGP route from the neighbor has a weight of 0.

So, the solution is to adjust your import policy and set a weight of 32769 or higher for the routes imported from the iBGP neighbor.

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#weight

"Paths that the router originates have a weight of 32,768 by default, and other paths have a weight of 0."