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 (Even though it's not displaying the "inaccessible" piece), 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?
