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.

14 comments:

  1. Why don't you ask Carlos? If the route is valid due to RPKI, then he would know about it or can at least check his config for it.
  2. IMHO, this is one of the idiosyncrasies of Cisco IOS. Why should a route with invalid Next-Hop be considered valid ? IMHO such a route should be considered invalid, as any route that does not participate to the BGP selection process. I would have used one more letter to indicate this phenomenon in the first column of the "show ip bgp" (or the newer version "show bgp ipv4 unicast"), instead of the "*", which in this case is surely misleading.
    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).
    Replies
    1. I don't understand why you bring ICMP into the conversation. ICMP should have no bearing on routing protocol decision. The presence or absence of echo replies is of little importance. ICMP depends on the routing protocol for ICMP to functon. The routing protocol does not (and should not) depend on ICMP.
  3. If you do a sh ip bgp, is there a * next to this route? There shouldn't be. The * and this representation of "validity" are two different things. The representation of valid you are referring to I believe is the validity of the AS path, which comes from soBGP which I don't think ever took off but was something Cisco came up with. I would be surprised if you ever saw that line show anything but valid (unless you find a device which supports soBGP and you learned the route with an 'invalid' AS path)

    May be wrong tho...if anyone has a contact at Cisco, ask them :)
    Replies
    1. Sorry you may be right with RPKI....
    2. Sorry for the spam, just did some ol'googling and found this
      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.
  4. RFC 4271, Section 6 says that routes are marked invalid after a TCP connection closes. The route is then removed. So if you have a route in loc-rib but the adj-rib-in has been cleared - the route is invalid. It is possible we may never see a route as "invalid" since it is already gone from the CLI output at that point.

    "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."
    Replies
    1. Looks like you've solved the mystery. Thank you!

      Note to self: read RFCs before asking stupid questions ;)
    2. Well thanks for asking the question - it forced me to look it up :)
  5. Thank you Brian!
    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
  6. Hmm, I went ahed and read the RFC, and even though section 6 says "mark as invalid" (in the Loc-RIB), it is also the case that section 9.1.2.1 it says that inaccessible NH routes would be invalid.
    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
  7. I still think that the valid shown in the above output is not referring to a valid route as described in the RFC above. The word "valid" in the above output is part the "Origin" field not part of the BGP status codes.

    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)
  8. It seems to me that the real problem is to understand what is the real meaning that Cisco assigns to the word "valid". I do not think either that Cisco uses the word "valid" conforming to Section 6 of RFC 4271. Whatever the point of view of Cisco, I prefer the Junos approach, which clearly differs between routes with reachable or unreachable Next-Hop. You can see the former in the routing table while you can see the latter only in the "hidden" part of the routing table.

    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 ?
    Replies
    1. 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

  9. Sorry, I made a typo in the comment above. The last lines should be read as follows : "According to IOS and Junos, a Next-Hop is considered reachable even if it is not pingable (tested it, a default-route is sufficient to declare the Next-Hop reachable !).
    Replies
    1. 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

  10. Ok, I did some cheating... and it seems I have the answer:
    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
  11. Ah. So we wont see "valid" if the route has been dampened. Good find!
  12. completition to my above comment:
    Junos uses a special command to display unresolved routes (hidden) > show route resolution unresolved

  13. A dampened route might be valid :

    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
  14. If you want to see an Invalid BGP route just declare any non-existant prefix in your BGP process: ex:

    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
Add comment
Sidebar