5 
Router# show ip bgp 10.3.3.3 255.255.255.255
BGP routing table entry for 10.3.3.3/32, version 35
Paths: (3 available, best #2, table default)
Multipath: eBGP
Flag: 0x860
  Advertised to update-groups:
     1
  200
    10.71.8.165 from 10.71.8.165 (192.168.0.102)
      Origin incomplete, localpref 100, valid, external, backup/repair
      Only allowed to recurse through connected route
  200
    10.71.11.165 from 10.71.11.165 (192.168.0.102)
      Origin incomplete, localpref 100, weight 100, valid, external, best
      Only allowed to recurse through connected route
  200
    10.71.10.165 from 10.71.10.165 (192.168.0.104)
      Origin incomplete, localpref 100, valid, external,
      Only allowed to recurse through connected route

Above is sample output of "show ip bgp x.x.x.x". This particular BGP router has learned multiple paths to get to the 10.3.3.3/32 host, and is listing each entry. Of the three that were learned, the 2nd one is the best -- and therefor the entry that makes it to the actual Route table (RIB).

My question is, does the order in which the three paths to the target appear in the output of this command indicate something? If so, what does it mean?

Improve this question

2 Answers 2

Reset to default
3

My question is, does the order in which the three paths to the target appear in the output of this command indicate something? If so, what does it mean?

The order of received prefixes listed by the show ip bgp or show ip bgp x.x.x.x command varies depending on your BGP configuration.

Consider the following topology. The BGP speaker R6 is aggregating eBGP neighborships for BGP ASN 888.

ASN 123, 1581 and 1771 are all originating the same network prefixes in order to demonstrate the behavior of the show ip bgp output.

                   +-------+                
                   | AS 888|                
                   |  (R6) |                
172.16.13.1        +-+-+-+-+
172.16.13.3          | | |
172.16.26.2          | | |        172.30.4.10
           \         | | |       /           
   +--------+        | | |       +---------+
   | AS 123 +--------+ | +-------+ AS 1771 |
   +--------+          |         +---------+
                       |                    
                  +----+----+               
                  | AS 1581 | \             
                  +---------+  172.40.10.10

Below is the initial view of Router 6's BGP table.

R6#show ip bgp 10.101.1.1/32
BGP routing table entry for 10.101.1.1/32, version 9
Paths: (5 available, best #5, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  1771
    172.30.4.10 from 172.30.4.10 (172.30.4.10)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  1581
    172.40.10.10 from 172.40.10.10 (172.40.10.10)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  123
    172.16.13.1 from 172.16.13.1 (172.16.101.1)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  123
    172.16.13.3 from 172.16.13.3 (172.16.103.1)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  123
    172.16.26.2 from 172.16.26.2 (172.16.102.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

These routes can be re-ordered in the show ip bgp x.x.x.x output by controlling the order that they're learned. Below, all eBGP neighbors advertising the 10.101.1.1/32 prefix are administratively shutdown and brought up one at a time.

R6(config)#router bgp 888
R6(config-router)#neighbor 172.16.13.1 shutdown
R6(config-router)#neighbor 172.16.13.3 shutdown
R6(config-router)#neighbor 172.16.26.2 shutdown
R6(config-router)#neighbor 172.30.4.10 shutdown
R6(config-router)#neighbor 172.40.10.10 shutdown
R6(config-router)#no neighbor 172.40.10.10 shutdown
*Jun  2 01:39:47.750: %BGP-5-ADJCHANGE: neighbor 172.40.10.10 Up
R6(config-router)#no neighbor 172.16.26.2 shutdown
*Jun  2 01:40:31.929: %BGP-5-ADJCHANGE: neighbor 172.16.26.2 Up
R6(config-router)#no neighbor 172.30.4.10 shutdown
*Jun  2 01:40:49.400: %BGP-5-ADJCHANGE: neighbor 172.30.4.10 Up
R6(config-router)#no neighbor 172.16.13.3 shutdown
*Jun  2 01:41:05.853: %BGP-5-ADJCHANGE: neighbor 172.16.13.3 Up
R6(config-router)#no neighbor 172.16.13.1 shutdown
*Jun  2 01:41:19.225: %BGP-5-ADJCHANGE: neighbor 172.16.13.1 Up

If deterministic MED is not enabled, then prefixes are listed in chronological order, regardless of originating AS, from youngest to oldest (top to bottom).

R6(config-router)#do show ip bgp 10.101.1.1/32
BGP routing table entry for 10.101.1.1/32, version 52
Paths: (5 available, best #5, table default)
  Advertised to update-groups:
     3
  Refresh Epoch 2
  123
    172.16.13.1 from 172.16.13.1 (172.16.101.1)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  123
    172.16.13.3 from 172.16.13.3 (172.16.103.1)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  1771
    172.30.4.10 from 172.30.4.10 (172.30.4.10)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  123
    172.16.26.2 from 172.16.26.2 (172.16.102.1)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  1581
    172.40.10.10 from 172.40.10.10 (172.40.10.10)
      Origin IGP, metric 0, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

If deterministic MED is enabled, the prefixes are grouped by ASN. The prefixes are still listed in chronological order from youngest to oldest within their respective ASN group and the ASN group order is displayed from youngest to oldest with the eldest prefix of each group being compared.

R6(config-router)#bgp deterministic-med
R6(config-router)#do show ip bgp 10.101.1.1/32
BGP routing table entry for 10.101.1.1/32, version 52
BGP Bestpath: deterministic-med
Paths: (5 available, best #4, table default)
  Advertised to update-groups:
     3
  Refresh Epoch 2
  123
    172.16.13.1 from 172.16.13.1 (172.16.101.1)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  123
    172.16.13.3 from 172.16.13.3 (172.16.103.1)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  123
    172.16.26.2 from 172.16.26.2 (172.16.102.1)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  1581
    172.40.10.10 from 172.40.10.10 (172.40.10.10)
      Origin IGP, metric 0, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  1771
    172.30.4.10 from 172.30.4.10 (172.30.4.10)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

The BGP neighbors that belong to AS 1581 and 1771 can be forced to flap and reorder the ASN groups. 

R6(config-router)#neighbor 172.30.4.10 shutdown
R6(config-router)#neighbor 172.40.10.10 shutdown
R6(config-router)#no neighbor 172.40.10.10 shutdown
R6(config-router)#no neighbor 172.30.4.10 shutdown
*Jun  2 02:23:33.407: %BGP-5-ADJCHANGE: neighbor 172.30.4.10 Up
*Jun  2 02:32:09.242: %BGP-5-ADJCHANGE: neighbor 172.40.10.10 Up

The eldest route below is from ASN 123 causing the ASN group to be listed at the bottom of the show ip bgp x.x.x.x output.

R6(config-router)#do show ip bgp 10.101.1.1/32
BGP routing table entry for 10.101.1.1/32, version 10
BGP Bestpath: deterministic-med
Paths: (5 available, best #5, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  1581
    172.40.10.10 from 172.40.10.10 (172.40.10.10)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  1771
    172.30.4.10 from 172.30.4.10 (172.30.4.10)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  123
    172.16.13.1 from 172.16.13.1 (172.16.101.1)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  123
    172.16.13.3 from 172.16.13.3 (172.16.103.1)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  123
    172.16.26.2 from 172.16.26.2 (172.16.102.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

After your BGP table has sorted with deterministic MED enabled, removing deterministic MED will not return your BGP table to standard formatting until routes are removed/cleared and relearned.

Improve this answer
1

The order means nothing. It's just the way the data was retrieved from internal structures or (may be) sorted to be smoother.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.