Even though next hop inaccessible, route in BGP table shows up as "best"

[Anthony Wathen]

Good day, I am encountering an unusual issue with IOSv that I've never seen before. I am currently working on a iBGP next-hop modification lab, and encountering a slight problem I've never seen before when labbing in the past.

Visualize the following topology:

R1<--iBGP--> R7 <--eBGP--> R9

Firstly, the metric in the "show ip bgp [route]" output is not displaying the route as inaccessible, although the metric shows 0: 

R1#sh ip bgp 112.0.0.0
BGP routing table entry for 112.0.0.0/8, version 56
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     6         
  Refresh Epoch 1
  54 50 60, (Received from a RR-client), (received & used)
    155.1.79.9 from 155.1.67.7 (150.1.7.7)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

R9 is the one originating the route 112.0.0.0. This didn't throw me off (Although the "inaccessible" piece should be showing up), but considering this is from R1's BGP table, this is what threw me off, which was also in R1's BGP table:

Network Next Hop Metric LocPrf Weight Path *
*>i 28.119.16.0/24 155.1.108.10 0 100 0 54 i
*>i 28.119.17.0/24 155.1.108.10 0 100 0 54 i
*>i 112.0.0.0 155.1.79.9 0 100 0 54 50 60 i

I am seeing the route with the carat, which means "best" (Which shouldn't be there until I modify the next hop to 155.1.67.7, since 155.1.79.9, as noted in the output below), and even though the next hop is inaccessible, it is still showing up as best. Now, please NOTE, that the 155.1.79.9 IP is not reachable, as noted in the routing table:

R1#show ip route 155.1.79.0
% Subnet not in table

This is normal, but the carat being populated next to the route should not be. Has anyone seen this in the near past? Is it a bug?

[Harold Ritter · Accepted solution]

Hi Anthony,

The fact that you are not seeing a route to the next hop when doing a "show ip route 155.1.79.0" means that you don't have a specific route. The fact that BGP is not showing the route as unreachable means that it is using the default route to reach the next hop.

Please do a "show ip cef 155.1.79.9" to verify that.

Regards,

[Harold Ritter]

Note that you can prevent this default behavior (i.e: use default route to resolve the NH) by using the Selective next hop tracking feature:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3s/irg-xe-3s-book/bgp_support_for_next-hop_address_tracking.html#GUID-2F82A5E2-24E5-4993-ABC3-0B3032FE885C

router bgp 2
 bgp log-neighbor-changes
 neighbor 192.168.100.2 remote-as 2
 neighbor 192.168.100.2 update-source Loopback0
 !
 address-family ipv4
  bgp nexthop route-map SelectiveNHT
  neighbor 192.168.100.2 activate
 exit-address-family
!

route-map SelectiveNHT permit 10
 match ip address prefix-list host_route
!         
route-map SelectiveNHT deny 20
!      

ip prefix-list host_route seq 5 permit 0.0.0.0/0 ge 32

The above example would only allow a host route (/32) to resolve the next hop.

Regards,

[Anthony Wathen]

AHHHHH yes! I do have a default route (It's only used for connectivity to the external network outside of hypervisor i.e. connectivity to the RADIUS server and my user subnet). I don't know why I didn't think about that. I will just update the default to something a bit more specific. Thank you sir!

[Anthony Wathen]

Ahhhh yes! I do have a default route (It's only used for connectivity to the external network outside of hypervisor i.e. connectivity to the RADIUS server and my user subnet). I don't know why I didn't think about that. I will just update the default to something a bit more specific. Thank you sir!