BGP Best-Path selection process examined given its criteria for selection, IMPORTANT behaviors of iBGP vs eBGP, Next-Hop examined in detail, and more!

We are back with this Topology I believe once more before we switch gears and leave Path and Attribute discussion alone for a bit.

One quick real world note, I fired up my lab and I was missing R4’s loopback network / Peering across all routers, and I started troubleshooting when I stopped and saw the port light was off on the switch because the RJ-45 was just barely disconnected but looked ok.

So for physical labs, and especially the real world, a reminder to start with Layer 1 🙂

Back to the topic at hand, I want to review this from the perspective from R1, as it’s basically directly connected to all routers except R4, so it is the only one that gives me the output to dis-assemble with THE 10 COMMANDMENTS OF BGP:

1. Highest weight preferred (BGP Weight is a Cisco proprietary attribute)
2. If tie or non-Cisco routers involved, highest local preference (LocPrf)
   
3. Locally originated path preferred
4. Shortest AS_PATH preferred
5. Best Origin Code ( i > e > ?)
6. Lowest MED
7. eBGP path preferred over iBGP path
8. Lowest IGP metric to BGP next-hop address
9. Oldest Path
10. Path from BGP router with lowest BGP RID

That is right, the same list from last post, and we are going to dissect where I left off on my last post, which is the output of “sh ip bgp” from R1:

R1#sh ip bgp
BGP table version is 6, local router ID is 1.1.1.1
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
*> 1.1.1.1/32       0.0.0.0                        0                       32768   i
*> 2.2.2.2/32       172.12.123.2             0             0                      200 i
*>i3.3.3.3/32       172.12.123.3             0          100           0       i
* i4.4.4.4/32        172.12.23.4               0          100           0       400 i
*>                          172.12.123.2            0                                     200 400 i
*> 5.5.5.5/32        172.12.15.5              0                            0       500 i
R1#

So first thing to mention which is a real oddity, is that sometimes these attributes do not fill in as illustrated above, but even not filled they still run on their defaults:

• Next-Hop for a network local to the router will be 0.0.0.0 by default
• Weight for a network local to the router will be 32768 by default
• Local Preference (LocPrf) is 100 by default, whether it shows 0 or nothing at all
• BGP default metric is 0, and appears to show up consistently in “sh ip bgp”

Now I’ve highlighted the entry for network 4.4.4.4 in red, to review the Best Path selection given the list at the top of the post, and review the differences options.

The Weight and LocPrf are the same (defaults) whether they are shown or not, in fact, I will demonstrate an extension of the “sh ip bgp” command for certain networks:

R1#sh ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 6
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1          2
  400
    172.12.23.4 (inaccessible) from 172.12.123.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal
  200 400
    172.12.123.2 from 172.12.123.2 (2.2.2.2)
      Origin IGP, localpref 100, valid, external, best
R1#

This command is great int terms of information you can gather like the number of available paths / which Path is best at the top, who its being advertised to, and also attribute information for each path like valid / local pref / internal or external / valid or best / RID in parenthesis / if it is accessible from the local router.

Looking at the general output from “sh ip bgp” and the more detailed version, you can see the “valid” but not “best” path appears with a Next Hop of 172.12.23.4, when it has no routes to get anywhere (as it is directly connected to all other routers aside from R4).

So this goes back to the concept of reachability, as R1 has no routes statically configured or dynamically learned, so therefore the path goes to “inaccessible” as R1 doesn’t know have a route to it.

We have to look at the Topology again, and why I heavily illustrated Peerings, to understand this BGP behavior of Route Advertisement of iBGP vs eBGP:

When R4 sends the network of 4.4.4.4 to R2, R2 then sends advertises the network to R1 via eBGP, whereas when it advertises the same network to R3 via eBGP, R3 sends it to R1 as an iBGP Peer. So we have some eBGP vs iBGP behaviors going on here.

And yes, I realize putting 4 commas in a sentence is not grammatically correct, like starting a sentence with the word “And.”

So before explaining the behavior, I will start with a fix for the behavior, and then explain harmoniously what the behavior is and why the fix worked!

Our journey start over on R3 that is forwarding R4’s interface IP address as a Next-Hop instead of its own, and we will be using a new command “next-hop-self” configured in BGP router configuration mode as a modifier to the “neighbor …” command:

R3(config-router)#neighbor 172.12.123.1 ?
  activate                 Enable the Address Family for this Neighbor
  advertise-map            specify route-map for conditional advertisement
  advertisement-interval   Minimum interval between sending BGP routing updates
  allowas-in               Accept as-path with my AS present in it
  capability               Advertise capability to the peer
  default-originate        Originate default route to this neighbor
  description              Neighbor specific description
  disable-connected-check  One-hop away EBGP peer using loopback address
  distribute-list          Filter updates to/from this neighbor
  dmzlink-bw               Propagate the DMZ link bandwidth
  ebgp-multihop            Allow EBGP neighbors not on directly connected
                           networks
  fall-over                session fall on peer route lost
  filter-list              Establish BGP filters
  inherit                  Inherit a template
  local-as                 Specify a local-as number
  maximum-prefix           Maximum number of prefixes accepted from this peer
  next-hop-self            Disable the next hop calculation for this neighbor
  next-hop-unchanged       Propagate the iBGP paths’s next hop unchanged for
                           this neighbor
  password                 Set a password
  peer-group               Member of the peer-group

R3(config-router)#neighbor 172.12.123.1 next-hop-self ?
  <cr>

R3(config-router)#neighbor 172.12.123.1 next-hop-self
R3(config-router)#

I have not yet gotten to what makes up the Next-Hop calculation, but we will circle back to that, as there is still a lot of BGP left in my studies.

So we see the <cr> so that is it for the command, however we aren’t done here, as with “clear ip ospf proc” to sometimes force an update we have to do something similar here but it is nowhere near as dramatic (losing adjacencies and such). It is actually called a ‘soft reset’, and this is a VERY GOOD command to know like “clear ip route *” or “clear ip ospf proc”, you just have to know it like the back of your hand:

R3#clear ip bgp * soft out
R3#

The different ways to clear BGP adjacencies and use this command in different ways will be reviewed in another post, but for now we are sticking with the ‘soft reset’. So now that we have configured R1’s iBGP neighbor with next-hop-self and issued a soft reset, let’s look back it R1’s “sh ip bgp” and “sh ip bgp 4.4.4.4” output to see what changed:

R1#sh ip bgp
BGP table version is 7, local router ID is 1.1.1.1
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
*> 1.1.1.1/32       0.0.0.0                        0                       32768 i
*> 2.2.2.2/32       172.12.123.2             0                             0    200 i
*>i3.3.3.3/32       172.12.123.3             0        100               0  i
*>i4.4.4.4/32       172.12.123.3             0        100               0 400 i
*                            172.12.123.2                                             0 200 400 i
*> 5.5.5.5/32       172.12.15.5              0                               0 500 i
R1#

That looks better just at first glance, as we now see the correct Next-Hop IP addresses, but lets dig into the specific network to review changes to that:

R1#sh ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 7
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
     2
  400
    172.12.123.3 from 172.12.123.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best
  200 400
    172.12.123.2 from 172.12.123.2 (2.2.2.2)
      Origin IGP, localpref 100, valid, external
R1#

Even though it’s a bit sloppy (this is how it shows in the actual CLI and is not sloppy formatting), highlighted in red is the AS_PATH, which finally breaks the tie at Best Path selection is rule #4 – Shortest AS_PATH

Also a quick note highlighted from the output above in blue, is #7 of the Best Path determinations, which states External path preferred over Internal. In fact I thought I’d be able to demonstrate it, but my brain is getting tired, and I’m not being very successful at manipulating the network to exemplify that BGP will use an external route as the best path over an internal if the selection list ties all the way to #7.

(EDIT: NEVERMIND, RULE #7 SHOWN IN BOTTOM OF POST FROM NEXT LAB!)

Speaking of tie breakers, #10 on the Best Path selection list, the BGP RID seen in the above output in parenthesis will almost never be a tie breaker, and #9 of “oldest path” is even really a stretch but possible.

I said I’d get back to it, and here it is, the mysterious Next-Hop calculation

So I remove the command “next-self-hop” and verify on R1 we are back to normal:

R3#conf t
R3(config)#router bgp 100
R3(config-router)#no neighbor 172.12.123.1 next-hop-self
R3(config-router)#^Z
R3#
R3#clear ip bgp * soft out
R3#
ASR#1
[Resuming connection 1 to r1 … ]

R1#sh ip bgp
BGP table version is 9, local router ID is 1.1.1.1
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
*> 1.1.1.1/32       0.0.0.0                        0                           32768 i
*>i3.3.3.3/32      172.12.123.3              0       100                   0 i
* i4.4.4.4/32       172.12.23.4                0       100                    0 400 i
*>                         172.12.123.2                                                 0 200 400 i
*> 5.5.5.5/32       172.12.15.5               0                                  0 500 i
R1#

So as can be seen we again have 172.12.23.4 as a Next-Hop value, and we are back to taking a less preferred route due to a BGP behavior or rule that is very odd / hard to grasp, so you may need to read it a few times to understand it:

• When a BGP Speaker advertises a route to an eBGP neighbor, the next-hop address is that of the advertising interface of the remote BGP Speaker. This makes sense.
• When an iBGP neighbor sends route updates, if the route originated outside the local AS, the next-hop address remains the source address of the router in the remote AS. This is the oddity.

So when R2 received the update from R4 for network 4.4.4.4/32, R2 sent it to R1 with the IP address of its interface pointing at R1 is the next-hop.

When R4 sends this same network to R3, R3 sends updates to all it’s iBGP neighbors with the originating interface as the next-hop rather than the interface pointing at R1:

R1#sh ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 9
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1          2
  400
    172.12.23.4 (inaccessible) from 172.12.123.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal
  200 400
    172.12.123.2 from 172.12.123.2 (2.2.2.2)
      Origin IGP, localpref 100, valid, external, best
R1#

So be very wary if you find yourself with a Topology of both iBGP and eBGP Peers advertising networks to each other, and watch those “i”s and “e”s in the tables, because those are subject to this odd behavior and will cost you exam points or possibly your job if you don’t understand this important concept!

So that is about all I have to say about that, I am almost half way done with BGP videos, but still have a lot of important ground to cover including what the MED (Multi-Exit Discriminator) is in my next post – Hasta manana!

 

EDIT!!!!! :

 

I was re-cabling the MED lab with no NBMA in it, whole new Topology, when I found I had created the right conditions to demonstrate Rule #7 at work:

R1#sh ip bgp
BGP table version is 5, local router ID is 1.1.1.1
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
*> 1.1.1.1/32       0.0.0.0                       0                         32768 i
*>i2.2.2.2/32       172.12.124.2             0       100                  0 i
* i3.3.3.3/32       172.12.23.3                0       100                  0 3 i
*>                        172.12.13.3                0                                0 3 i
*>i4.4.4.4/32       172.12.124.4             0       100                  0 i
R1#sh ip bgp 3.3.3.3
BGP routing table entry for 3.3.3.3/32, version 5
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1
  3
    172.12.23.3 (inaccessible) from 172.12.124.2 (172.12.124.2)
      Origin IGP, metric 0, localpref 100, valid, internal
  3
    172.12.13.3 from 172.12.13.3 (172.12.23.3)
      Origin IGP, metric 0, localpref 100, valid, external, best
R1#

Again going down the list of 10 for BGP, everything ties with each other until the eBGP Path is preferred over the iBGP, and thus the best valid Path!

I am dead tired, but so glad I got that snippet in, I’ll be back tomorrow to show the Topology that demonstration came from and talk about MED!