What Is a Valid BGP Route?
Carlos Mendioroz sent me a seemingly simple question: when is a BGP route invalid? My knee-jerk reaction: when the next hop is not reachable (and I’m not the only one). WRONG – BGP routes with unreachable next hop are still valid, as shown in the following printout:
R1#show ip bgp 10.1.1.0
BGP routing table entry for 10.1.1.0/24, version 6
Paths: (1 available, no best path)
Not advertised to any peer
65001
192.168.0.1 (inaccessible) from 172.16.1.2 (192.168.0.1)
Origin IGP, metric 0, localpref 100, valid, internal
Has anyone seen a BGP route that was not valid recently? Could you tell us how you got it? I’m suspecting you might get an invalid route with RPKI, but don’t have the necessary infrastructure in place to test it.
Junos, for instance, put routes with inaccessible Next-Hop in the "hidden" part of the routing table, you don't see them in the the routing table (you may see them using "show route hidden").
But I would like to make you another question concerning BGP Next-Hop. Are we sure that a route with "not pingable" Next-Hop never participates to the BGP selection process. The obvious answer is "Are you new to BGP ? For sure a route with "not pingable" Next-Hop DOES NOT participate to the BGP selection process". WRONG ! It could sound incredible but it can happen (it happened to me, and also see this discussion : https://learningnetwork.cisco.com/message/160879#160879).
Don't you think that this is a "big bug" ? You may see this behaviour both in IOS and Junos. I strongly disagree with their point of view !!! They should do something to correct this behaviour (I have to investigate further, perhaps something has been done on Cisco IOS XR, but I'm not sure).
May be wrong tho...if anyone has a contact at Cisco, ask them :)
http://www.slideshare.net/mynog/rpki-introduction-by-randy-bush
Slide 40 and 41 show RPKI valid and invalid paths, the line mentioned in your blog post isn't changed regardless of the RPKI state.
"The phrase "the BGP connection is closed" means the TCP connection has been closed, the associated Adj-RIB-In has been cleared, and all resources for that BGP connection have been deallocated. Entries in the Loc-RIB associated with the remote peer are marked as invalid. The local system recalculates its best routes for the destinations of the routes marked as invalid. Before the invalid routes are deleted from the system, it advertises, to its peers, either withdraws for
the routes marked as invalid, or the new best routes before the invalid routes are deleted from the system."
Note to self: read RFCs before asking stupid questions ;)
I do not remember how many docs define valid as reachable NH. I do not remember how many times I eluded the issue while teaching (guilty here!). Some traces of this can also be found by searching the Internet...
-Carlos
The thing is... "valid" is not clearly defined in one place, so... the only way to be sure would be to have an insider let us know what the cisco's show ip bgp valid tag means.
I'll try to discover if closing a connection makes teh valid go away (i.e. if there is a window of visibility of that state).
-Carlos
See http://www.cisco.com/c/en/us/td/docs/ios/iproute_bgp/command/reference/irg_book/irg_bgp5.html#wp1156281
Table: 28 shows the BGP status codes where if the NH is not reachable it will not have a *, as is not valid etc...
Table 29 shows the "Origin" field, where it described the above output, whether or not the Origin is valid (which I think it always will be right now...as RPKI shows on a different output. Still think it may be left over from soBGP possibly)
But what really worries me is the definition of "unreachable Next-Hop". According to IOS and Junos, a Next-Hop is considered unreachable even if it is not pingable (tested it, a default-route is sufficient to declare the Next-Hop reachable !). Don't you think this should be fixed, to avoid traffic black-holes ?
I'd rephrase Tiziano's observation with the following: Some OSs (to be tested - would love to have insights on this), keep announcing a BGP route (with the BGP Holdtime being the upper time limit) whose BGP-NH is withdrawn (either implicitly or explicitly) by the underlying IGP if they manage to resolve it recursively with either other BGP prefixes or the Default route if any.
I find this conceptually wrong. I'd give priority to what the IGP says instead of keeping alive for the BGP Holdtime timer duration (ish) the prefix of a dead BGP-NH. I'd love to know other opinions on this aspect.
Andrea
I'd rephrase Tiziano's observation with the following: Some OSs (to be tested - would love to have insights on this), keep announcing a BGP route (with the BGP Holdtime being the upper time limit) whose BGP-NH is withdrawn (either implicitly or explicitly) by the underlying IGP if they manage to resolve it recursively with either other BGP prefixes or the Default route if any. I find this conceptually wrong. I'd give priority to what the IGP says instead of keeping alive for the BGP Holdtime timer duration (ish) the prefix of a dead BGP-NH. I'd love to know other opinions on this aspect. Andrea
The status of the routes have three state fields, represented by three chars:
Route state: supressed, valid or else (s/*/ )
Selection state: history/damped/selected/multipath (h/d/>/m)
Internal state: internal or else (i/ )
In this "Route state" sense, valid is defined as not historical, i.e., a remembered route for dampening purpouses... whenever you don't have an 'h' in the second char, you will see a '*' in the first.
Go figure that!
-Carlos
Junos uses a special command to display unresolved routes (hidden) > show route resolution unresolved
Status codes: s suppressed, d damped, h history, *
valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network From Flaps Duration
Reuse Path
*d 10.41.144.0/24 10.1.100.104 2 00:03:17
00:12:20 6504
router bgp 65001
address-family ipv4 unicast
network 169.169.169.169/32
VDC2(config)# show ip route 169.169.169.169/32
IP Route Table for VRF "default"
Route not found
VDC2(config)# show ip bgp 169.169.169.169/32
BGP routing table information for VRF default, address family IPv4 Unicast
BGP routing table entry for 169.169.169.169/32, version 26
Paths: (1 available, best #0)
Flags: (0x080002) on xmit-list, is not in urib
Path type: local, path is invalid, no labeled nexthop
AS-Path: NONE, path locally originated
0.0.0.0 (metric 0) from 0.0.0.0 (198.18.13.1)
Origin IGP, MED not set, localpref 100, weight 32768