Cisco – Local in show ip bgp output

bgpcisco

What does Local mean in this output?

R4#show ip bgp 10.6.0.0/24  
BGP routing table entry for 10.6.0.0/24, version 19  
Paths: (1 available, best #1, table Default-IP-Routing-Table)  
  Advertised to update-groups:  
        2  
  **Local**    192.168.0.6 (metric 156160) from 192.168.0.5 (192.168.0.5)  
      Origin IGP, metric 0, localpref 100, valid, internal, best  
      Originator: 192.168.0.6, Cluster list: 192.168.0.5

Best Answer

The Local keyword highlighted in your question means the prefix is sourced locally in that router's AS (i.e. there is no AS path).

Consider two configurations, where the routers have a BGP session with each other, and DEN-EDGE-01 is announcing 10.204.1.1/32.

Announce:10.204.1.1/32
DEN-EDGE-01----------------DEN-EDGE-02
172.16.1.203               172.16.1.204

Peering within the same ASN: `Local` keyword shown

DEN-EDGE-01 in AS100 is configured to send 10.204.1.1...

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 10.204.1.1 mask 255.255.255.255
 ! Send 10.204.1.1 to DEN-EDGE-02
 neighbor 172.16.2.204 remote-as 100
 no auto-summary

DEN-EDGE-02 in AS100 is configured with...

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 ! Just receive routes from DEN-EDGE-01
 neighbor 172.16.2.203 remote-as 100
 no auto-summary
!

When I receive 10.204.1.1 on DEN-EDGE-02, there is no AS-path, only Local

DEN-EDGE-02#sh ip bgp 10.204.1.1
BGP routing table entry for 10.204.1.1/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  Local   <------------
    172.16.2.203 from 172.16.2.203 (172.16.2.203)
      Origin IGP, metric 0, localpref 100, valid, internal, best
DEN-EDGE-02#

Peering with a different ASN: AS path shown

Now we reconfigure both routers... one in AS100 and the other in AS200. DEN-EDGE-01 in AS100 is configured to send 10.204.1.1...

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 10.204.1.1 mask 255.255.255.255
 ! Send 10.204.1.1 to DEN-EDGE-02
 neighbor 172.16.2.204 remote-as 200
 no auto-summary

DEN-EDGE-02 in AS200 is configured with...

router bgp 200
 no synchronization
 bgp log-neighbor-changes
 ! Just receive routes from DEN-EDGE-01
 neighbor 172.16.2.203 remote-as 100
 no auto-summary
!

When I receive 10.204.1.1 on DEN-EDGE-02, now we see a real AS-path, because DEN-EDGE-01 is in a different AS.

DEN-EDGE-02#sh ip bgp 10.204.1.1
BGP routing table entry for 10.204.1.1/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  100   <------------
    172.16.2.203 from 172.16.2.203 (172.16.2.203)
      Origin IGP, metric 0, localpref 100, valid, external, best
DEN-EDGE-02#

Related Solutions

Bgp – “Local Policy Denied Prefixes” in ‘show ip bgp neighbor’ output

This is most probably because of EBGP split horizon kicking in... i.e. 7204 router receives those prefixes from Quagga, selects best path, and attempts to advertise them. Since the only neighbor is the neighbor the best path was received from, it filters the advertisements. The counter above shows that.

Cisco Commands – Order of Entries in ‘show ip bgp x.x.x.x’

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.