Step 1: WEIGHT

The first step, holding the highest precedence over all other steps, in the best-path algorithm involves comparing a path attribute called the WEIGHT attribute. The WEIGHT attribute is a Cisco-proprietary attribute, and therefore, this step is performed only on Cisco routers. It is represented by a 16-bit number with a valid range of 0 to 65,535. The attribute is an optional, non-transitive attribute, meaning its value is only significant to the local router and will not be exchanged with neighboring BGP routers in UPDATE messages.

By default, the router will set the WEIGHT for all paths it injects into the BGP table through either network, redistribute, or aggregate-address commands to 32768. Paths introduced into the BGP table are considered local paths, and an example can be seen in the show ip bgp 110.19.1.1 output on R19 below:

R19#show run | section router bgp
 
router bgp 100
 bgp log-neighbor-changes
 network 110.19.1.1 mask 255.255.255.255
 
R19#show ip bgp 110.19.1.1
 
BGP routing table entry for 110.19.1.1/32, version 2
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1          2
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (19.19.19.19)
      Origin IGP, metric 0, localpref 100, weight 32768, valid,
sourced, local, best
      rx pathid: 0, tx pathid: 0x0

R19 is configured to inject a path to the 110.19.1.1 network into BGP. This path is flagged in its BGP table as a local route.

All other paths received through BGP updates have their WEIGHT attributes initialized at 0. These defaults can be modified per neighbor or per prefix. The non-transitive property of the WEIGHT attribute carries the implication that it is not possible to set it in the outbound direction for a neighbor. If such a configuration is ever attempted, the router kindly reminds you of this fact with the message “% ‘WEIGHT’ used as BGP outbound route-map, set weight not supported.” The non-transitive restriction leaves only two ways of manually setting the weight attribute on a router:

• Attached to the neighbor command using the neighbor x.x.x.x weight weight command

• Attached to the neighbor command using an inbound route map with the set weight clause

The non-transitive property of the WEIGHT attribute also ensures that a router cannot influence the WEIGHT value of its BGP peer. The WEIGHT attribute’s position as first in the best-path algorithm and its inability to be affected by neighboring BGP routers give the administrator complete control over what the local router ultimately chooses as its best path, regardless of the interactions of other path attributes.

The WEIGHT attribute can be utilized to force the local router to prefer one path over another in its BGP table. When deciding between two paths to the same prefix in the BGP table, the router will choose the path with the higher WEIGHT value. This preference for choosing higher weight values means that all prefixes originated by the router itself (through the network, redistribute, or aggregate-address commands) will be preferred over all other routers by default due to their default weight setting of 32,768.

This point can be observed below. R20 is configured to inject paths to the 110.20.1.1 and 110.20.2.1 prefixes into its BGP table using a network command:

router bgp 100
 network 110.20.1.1 mask 255.255.255.255
 network 110.20.2.1 mask 255.255.255.255
 
R20#show ip bgp
 
BGP table version is 16, local router ID is 20.20.20.20
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path,
f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop             Metric LocPrf Weight Path
 *>i  110.19.1.1/32    19.19.19.19              0    100      0 i
 *>i  110.19.2.1/32    19.19.19.19              0    100      0 i
 *>   110.20.1.1/32    0.0.0.0                  0         32768 i
 *>   110.20.2.1/32    0.0.0.0                  0         32768 i
 *>i  120.18.1.1/32    19.19.19.19              0    100      0 200 i
 *                     200.2.20.2                             0 300 200 i
 *>i  120.18.2.1/32    19.19.19.19              0    100      0 200 i
 *                     200.2.20.2                             0 300 200 i
 *>   130.7.1.1/32     200.2.20.2                             0 300 i
 * i  140.15.1.1/32    19.19.19.19              0    100      0 200 400 i
 *>                    200.2.20.2                             0 300 400 i
 * i  140.15.2.1/32    19.19.19.19              0    100      0 200 400 i
 *>                    200.2.20.2                             0 300 400 i

The WEIGHT values for those paths (highlighted in red) have been set to 32768 in the output. In contrast, the WEIGHT values for the BGP paths learned from R19 and R2 (110.19.1.1/32, 110.19.2.1/32, 120.18.1.1/32, and 120.18.2.1/32) are set to 0.

As stated above, the administrator can manually modify the WEIGHT attribute for a particular path to influence the local outbound routing decision in the BGP table. In the output above, R20 learns paths to the 120.18.1.1 and 120.18.2.1 prefixes from its iBGP neighbor R19 and eBGP neighbor R2. Because the WEIGHT values for these paths are tied, the path via R19 is chosen as best because it has a shorter AS_PATH attribute length (step 4 in the best-path algorithm, explained in detail later). To demonstrate the WEIGHT attribute’s higher precedence over the AS_PATH attribute length, R20 will be configured to prefer the path via R2 instead of R19 for the 120.18.1.1 prefix.

Recall that the WEIGHT value can be assigned directly with the neighbor x.x.x.x weight command. However, this would apply to all routes learned from that neighbor, which is not the desired outcome of this example. Instead, a route map will be configured using the set weight clause. The route map uses a prefix list to target only the 120.18.1.1 prefix. This route map will be applied to the R20/R2 neighbor peering statement in the inbound direction, as shown below.

In the following configuration, the prefix 120.18.1.1 is first identified and permitted in a prefix list called 123. Then a route map called tst is created that references the 123 prefix list. This route map contains the set weight parameter with a value of 32768. The route map is then appended to the neighbor statement for the eBGP peer 200.2.20.2 in the inbound direction:

R20(config)#ip prefix-list 123 permit 120.18.1.1/32
 
R20(config)#route-map tst permit 10
R20(config-route-map)#match ip address prefix 123
R20(config-route-map)#set weight 32768
R20(config)#route-map tst permit 90
 
R20(config)#router bgp 100
R20(config-router)#neighbor 200.2.20.2 route-map tst in

With the above configured, clear ip bgp * soft in is issued on R20. R20 sends a route refresh message to all its neighbors, which is an indication to them to re-send their routing advertisements. When R20 receives the refreshed BGP updates, it processes the inbound route map configuration, assigning the WEIGHT value of 32768 to R2’s path for the prefix 120.18.1.1.

Since the WEIGHT value has higher precedence than the AS_PATH attribute, R20 chooses the path via R2 as best. Notice that the best path to 120.18.2.1 has not been affected. Traffic destined to the 120.18.1.1 network from R20 will now transit AS 300, and traffic destined to the 120.18.2.1 network from R20 will be sent to R19.

R20#show ip bgp regexp _200$
 
BGP table version is 48, local router ID is 20.20.20.20
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path,
f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop             Metric LocPrf Weight Path
 *>  120.18.1.1/32    200.2.20.2                     32768 300 200 i
 * i                  19.19.19.19          0    100      0 200 i
 *   120.18.2.1/32    200.2.20.2                         0 300 200 i
 *>i                  19.19.19.19          0    100      0 200 i

Observing R20’s advertisement of the 120.18.1.1 network to R19 helps confirm the non-transitive property of the WEIGHT attribute. A quick look at R19’s BGP table for its paths to the 120.18.1.1/32 prefix reveals a missing WEIGHT value for the path received from R20:

R19#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 6
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 2
  300 200
    20.20.20.20 (metric 11) from 20.20.20.20 (20.20.20.20)
      Origin IGP, metric 0, localpref 100,[weight value of 0 should be
 here but isn’t], valid, internal
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  200
    200.18.19.18 from 200.18.19.18 (18.18.18.18)
      Origin IGP, metric 0, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

The missing WEIGHT value is a result of how Cisco IOS chooses to display path attributes in the long format of the show ip bgp x.xx.x.x command. The router shows a weight value only if it has a value over 0. Paths with a WEIGHT value of 0 do not report this value in the long version of the command. The 0 WEIGHT value is, however, reported in the short version show ip bgp command output shown below:

R19#show ip bgp | begin Net
 
     Network          Next Hop             Metric LocPrf Weight Path
 *>  110.19.1.1/32    0.0.0.0               0         32768 i
 *>  110.19.2.1/32    0.0.0.0               0         32768 i
 *>i 110.20.1.1/32    20.20.20.20           0    100      0 i
 *>i 110.20.2.1/32    20.20.20.20           0    100      0 i
 * i 120.18.1.1/32    20.20.20.20           0    100      0 300 200 i
 *>                   200.18.19.18          0             0 200 i
 *>  120.18.2.1/32    200.18.19.18          0             0 200 i
 *   130.7.1.1/32     200.18.19.18                        0 200 300 i
 *>i                  20.20.20.20           0    100      0 300 i
 * i 140.15.1.1/32    20.20.20.20           0    100      0 300 400 i
 *>                   200.18.19.18                        0 200 400 i
 * i 140.15.2.1/32    20.20.20.20           0    100      0 300 400 i
 *>                   200.18.19.18                        0 200 400 i

The output above confirms that R19 has a WEIGHT value of 0 for all paths to the 120.18.1.1/32 network, including the path it receives from R20. This fact can further be seen by the packet capture below:

Internet Protocol Version 4, Src: 20.20.20.20, Dst: 19.19.19.19
Transmission Control Protocol, Src Port: 179, Dst Port: 24627, Seq:
43, Ack: 43, Len: 283
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 66
    Type: UPDATE Message (2)
   Withdrawn Routes Length: 0
    Total Path Attribute Length: 38
    Path attributes
        Path Attribute - ORIGIN: IGP
        Path Attribute - AS_PATH: 300 200
        Path Attribute - NEXT_HOP: 20.20.20.20
        Path Attribute - MULTI_EXIT_DISC: 0
        Path Attribute - LOCAL_PREF: 100

    Network Layer Reachability Information (NLRI)
        120.18.1.1/32
Border Gateway Protocol - UPDATE Message
Border Gateway Protocol - UPDATE Message
Border Gateway Protocol - UPDATE Message

The key point to notice in the capture is there is no “Path Attribute - WEIGHT” section in the packet capture, which proves that R20 did not advertise the WEIGHT value to R19.

All of the above pieces of evidence confirm that the WEIGHT value is not exchanged between neighbors. R19 chooses the path received from R18 over the one received from R20 for the same prefix due to the lower AS_PATH attribute.

Step 2: Local Preference

Local preference, or LOCAL_PREF, is the next step in the BGP best-path algorithm. Unlike WEIGHT, local preference is a well-known discretionary BGP attribute, meaning all implementations of BGP should understand the local preference attribute. It is a 32-bit number ranging from 0 to 4,294,967,295. As with WEIGHT, higher values are preferred over lower ones. The default local preference value for received paths that have no explicit local preference defined is 100.

Local preference is used by the local AS to signify a global preference for a specific path that should be used within the AS. To serve this purpose, local preference has what is known as limited transitive capabilities.

Limited transit capability signifies that Local Preference can be sent in BGP updates, but routers only send it in specific situations. It is only sent in BGP updates to iBGP peers and is never sent to eBGP peers. This limited transit functionality is what allows Local Preference to be used to define preferred paths for prefixes in the entire AS and affect the entire AS’s outbound routing decisions. Local Preference’s limited transit capability does not apply to confederation eBGP peers as documented in RFC 4271:

R2#show ip bgp regex _200$
 
BGP table version is 28, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path,
f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop             Metric LocPrf Weight Path
 *   120.18.1.1/32    200.2.20.20                         0 100 200 i
 *                    200.2.10.10                         0 400 200 i
 *>                   200.2.16.16                         0 200 i
 *   120.18.2.1/32    200.2.20.20                         0 100 200 i
 *                    200.2.10.10                         0 400 200 i
 *>                   200.2.16.16                         0 200 i

R3#show ip bgp regex _200$
 
--- omitted ---
     Network          Next Hop               Metric LocPrf Weight Path
 *   120.18.1.1/32    200.3.10.10                           0 400 200 i
 *>                   2.2.2.2                 0    100      0 (312) 200 i
 *   120.18.2.1/32    200.3.10.10                           0 400 200 i
 *>                   2.2.2.2                 0    100      0 (312) 200 i
 

R3#show ip route bgp
 
--- omitted ---
Gateway of last resort is not set
 
      110.0.0.0/32 is subnetted, 2 subnets
B        110.19.1.1 [200/0] via 2.2.2.2, 00:27:47
B        110.19.2.1 [200/0] via 2.2.2.2, 00:27:47
      120.0.0.0/32 is subnetted, 2 subnets
B        120.18.1.1 [200/0] via 2.2.2.2, 00:27:16
B        120.18.2.1 [200/0] via 2.2.2.2, 00:27:16
 
--- omitted ---

R6#show ip bgp regex _200$
 
--- omitted ---
     Network          Next Hop              Metric LocPrf Weight Path
 *>i 120.18.1.1/32    3.3.3.3                0    100      0 (312) 200 i
 *                    200.6.11.11                          0 400 200 i
 *>i 120.18.2.1/32    3.3.3.3                0    100      0 (312) 200 i
 *                    200.6.11.11                          0 400 200 i
 
R6#show ip route bgp
 
--- omitted ---
Gateway of last resort is not set
 
      110.0.0.0/32 is subnetted, 2 subnets
B        110.19.1.1 [200/0] via 3.3.3.3, 00:30:18
B        110.19.2.1 [200/0] via 3.3.3.3, 00:30:18
      120.0.0.0/32 is subnetted, 2 subnets
B        120.18.1.1 [200/0] via 3.3.3.3, 00:29:50
B        120.18.2.1 [200/0] via 3.3.3.3, 00:29:50

R8#show ip bgp regexp _200$
 
BGP table version is 32, local router ID is 8.8.8.8
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path,
f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop          Metric LocPrf Weight Path
 *>  120.18.1.1/32    6.6.6.6             0    100      0 (336 312) 200 i
 *>  120.18.2.1/32    6.6.6.6             0    100      0 (336 312) 200 i
 
R8#show ip route bgp | begin Gateway
Gateway of last resort is not set
 
      110.0.0.0/32 is subnetted, 2 subnets
B        110.19.1.1 [200/0] via 6.6.6.6, 00:31:22
B        110.19.2.1 [200/0] via 6.6.6.6, 00:31:22
      120.0.0.0/32 is subnetted, 2 subnets
B        120.18.1.1 [200/0] via 6.6.6.6, 00:31:10
B        120.18.2.1 [200/0] via 6.6.6.6, 00:31:10

R8#traceroute 120.18.1.1
 
Type escape sequence to abort.
Tracing the route to 120.18.1.1
VRF info: (vrf in name/id, vrf out name/id)
  1 30.6.8.6 1 msec 1 msec 1 msec
  2 30.3.6.3 1 msec 1 msec 1 msec
  3 30.2.3.2 2 msec 2 msec 1 msec
  4  *  *  * 

R6(config)#ip prefix-list 123 permit 120.18.1.1/32
 
R6(config)#route-map tst permit 10
R6(config-route-map)#match ip address prefix 123
R6(config-route-map)#set local-preference 200
R6(config)#route-map tst permit 90

Local Preference Outbound

In this section, the administrator chooses to apply the change in the outbound direction on R6. R6 will only advertise the selected path with the modified LOCAL_PREF value to neighbors where the route map is applied.

In order to attempt to change outbound to affect all the other routers in AS 300’s best-path decision, the change will be applied on every neighbor command for R6’s peers within AS 300. In this case, it is applied to R3 and R8 in the outbound direction, as shown:

R6(config)#router bgp 336
R6(config-router)#neighbor 3.3.3.3 route-map tst out
R6(config-router)#neighbor 8.8.8.8 route-map tst out
 
R6#clear ip bgp * soft

After the changes have been made, the BGP table is refreshed by issuing the clear ip bgp * soft command. As a result, R6 re-sends the updates to R3 and R8 with the modified LOCAL_PREF value 200, as shown in the packet capture below:

Internet Protocol Version 4, Src: 6.6.6.6, Dst: 8.8.8.8
Transmission Control Protocol, Src Port: 29995, Dst Port: 179, Seq:
24, Ack: 20, Len: 387
Border Gateway Protocol - UPDATE Message
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 72
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 44
    Path attributes
        Path Attribute - ORIGIN: IGP
        Path Attribute - AS_PATH: (336 312) 200
        Path Attribute - NEXT_HOP: 6.6.6.6
        Path Attribute - MULTI_EXIT_DISC: 0
        Path Attribute - LOCAL_PREF: 200
    Network Layer Reachability Information (NLRI)
        120.18.1.1/32

The expectation at this point is that all of the routers in AS 300 now choose to use R6 to reach the designated prefix 120.18.1.1/32. A quick glance at R8’s BGP table seems promising:

R8#show ip bgp regexp _200$
 
BGP table version is 33, local router ID is 8.8.8.8
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path,
f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop          Metric LocPrf Weight Path
 *>  120.18.1.1/32    6.6.6.6             0    200      0 (336 312) 200 i
 *>  120.18.2.1/32    6.6.6.6             0    100      0 (336 312) 200 i

R8’s BGP table reflects the changes made on R6. The path to 120.18.1.1/32 now has a local preference value of 200. This proves that even though R8 is a confed-eBGP peer to R6, R6 still communicates the local preference changes to R8, in compliance with the RFC excerpt mentioned earlier.

The problem, however, comes in whenever R3’s BGP table is examined:

R3#show ip bgp regexp _200$
 
--- omitted ---
     Network          Next Hop              Metric LocPrf Weight Path
 *>  120.18.1.1/32    2.2.2.2                 0    100      0 (312) 200 i
 *                    200.3.10.10                           0 400 200 i
 *>  120.18.2.1/32    2.2.2.2                 0    100      0 (312) 200 i
 *                    200.3.10.10                           0 400 200 i

R3’s BGP table contains no noticeable changes. It continues to use R2’s path as the best path to reach the prefix 120.18.1.1/32. Why does R3 seemingly ignore R6’s advertisements? The answer lies in R6’s BGP table, shown on the next page:

R6#show ip bgp regexp _200$
 
--- omitted---
 
     Network          Next Hop             Metric LocPrf Weight Path
 *>i 120.18.1.1/32    3.3.3.3                0    100      0 (312) 200 i
 *                    200.6.11.11                          0 400 200 i
 *   120.18.2.1/32    200.6.11.11                          0 400 200 i
 *>i                  3.3.3.3                0    100      0 (312) 200 i

This table reveals that, although R6 has advertised a modified local preference value to its neighbors, its own BGP table is unchanged by the outbound policy. The reason is that outbound modifications to path attributes do not affect the local router’s BGP table. R6 still chooses R3 as its best path due to the shorter AS_PATH attribute length. As a result, R6 will not advertise R3’s path back to R3 because R3 is a confederation internal peer. The iBGP split-horizon rule prevents R6 from advertising an internal route to an internal peer. This fact is proven by observing R6’s advertised routes to R3 below, using the command show ip bgp neighbors 3.3.3.3 advertised-routes:

R6#show ip bgp neighbors 3.3.3.3 advertised-routes
 
BGP table version is 27, local router ID is 6.6.6.6
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path,
f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop            Metric LocPrf Weight Path
 *>  140.15.1.1/32    200.6.11.11                            0 400 i
 *>  140.15.2.1/32    200.6.11.11                            0 400 i

R6#show ip bgp neighbors 3.3.3.3
BGP neighbor is 3.3.3.3,  remote AS 336, internal link
  BGP version 4, remote router ID 3.3.3.3
  Neighbor under common administration
  BGP state = Established, up for 6d00h
  Last read 00:00:22, last write 00:00:24, hold time is 180, keepalive
  interval is 60 seconds
  Neighbor sessions:
    1 active, is not multisession capable (disabled)

R6 does, however, advertise the path to R8. You might think that R3 should still receive the path from R6 through the R8 → R7 → R5 → R4 path. Following that path leads to the correct answer:

1. First, R3 selects R2’s path as the best path to reach the 120.18.1.1/32 prefix. The AS_CONFED_SEQUENCE at this point is (312). R3 advertises this best path to R6.

2. R6 receives the path and chooses it as its best path. It advertises the path to R8 with the modified LOCAL_PREF value of 200 and the AS_CONFED_SEQUENCE value (336 312).

3. R8 receives the path as well and chooses it as its best path. It advertises to R7, retaining the received LOCAL_PREF of 200 and the AS_CONFED_SEQUENCE value (336 312).

4. R7 receives the path and marks it as the best path. It advertises the path to R5 with the retained LOCAL_PREF value 200 and the modified AS_CONFED_SEQUENCE value (378 336 312).

5. R5 receives the path, marks it as best, and advertises to R4, retaining the received LOCAL_PREF value 200 and the AS_CONFED_SEQUENCE value (378 336 312).

6. R4 receives the path and marks it as best. It advertises the path to R1 and R3 with the retained LOCAL_PREF value 200 and the AS_CONFED_SEQUENCE value (345 378 336 312).

What happens next is critical to this example. Both R3 and R1 receive the path from R4 in a BGP update. They examine the AS_CONFED_SEQUENCE attribute, only to find their own sub-ASN in the sequence. For this reason, both R1 and R3 deny the update. This is proven on R3 through the following debug message:

BGP(0): 4.4.4.4 rcv UPDATE w/ attr: nexthop 6.6.6.6, origin i, local-
pref 200, metric 0, originator 0.0.0.0, merged path (345 378 336 312)
200, AS_PATH , community , extended community , SSA attribute
BGPSSA ssacount is 0
 
BGP(0): 4.4.4.4 rcv UPDATE about 120.18.1.1/32 -- DENIED due to:
AS-PATH contains our own AS;

Notice that the path is received from 4.4.4.4, with the LOCAL_PREF value 200 and the indicated AS_CONFED_SEQUENCE clearly containing R3’s sub-ASN 336. The same occurs on R1. Both R1 and R3 are forced to deny the path, in compliance with standard BGP confederation rules. These rules protect the topology from a loop situation that could occur as a result of modifying the LOCAL_PREF value outbound on R6.

All in all, modifying the LOCAL_PREF value outbound on R6 does not result in the desired outcome because R6 does not affect the change itself. R6 continues to use the same path through R3 to reach the 120.18.1.1/32 prefix, triggering a sequence of events that ultimately leads to the state reported above.

While there may be specific use cases where setting the local preference in this manner is a desirable outcome, it should be done with caution and careful examination due to the fact that suboptimal routing and control/data plane loops can result in such changes. It is also true that R6 could also manipulate its own BGP table to remedy the problem. It is far easier to simply apply the change inbound, as specified in the next section.

R5#show ip route bgp | in 120.18.1.1
B        120.18.1.1 [200/0] via 6.6.6.6, 00:49:06

R5#show ip cef 6.6.6.6
6.6.6.6/32
  nexthop 30.4.5.4 Ethernet0/0.45
  nexthop 30.5.7.7 Ethernet0/0.57

R6(config)#router bgp 336
 
R6(config-router)#no neighbor 3.3.3.3 route-map tst out
R6(config-router)#no neighbor 8.8.8.8 route-map tst out
 
R6#clear ip bgp * soft
R6(config)#router bgp 336
R6(config-router)#neighbor 200.6.11.11 route-map tst in

R6#clear ip bgp * soft
 
R6#show ip bgp regexp _200$
 
--- omitted ---
     Network          Next Hop              Metric LocPrf Weight Path
 *>  120.18.1.1/32    200.6.11.11                  200      0 400 200 i
 *   120.18.2.1/32    200.6.11.11                           0 400 200 i
 *>i                  3.3.3.3                 0    100      0 (312) 200 i

BGP(0): 6.6.6.6 rcvd UPDATE w/ attr: nexthop 6.6.6.6, origin i,
localpref 200, metric 0, merged path 400 200, AS_PATH
 
BGP(0): 6.6.6.6 rcvd 120.18.1.1/32

BGP(0): 6.6.6.6 rcvd UPDATE w/ attr: nexthop 6.6.6.6, origin i,
localpref 200, metric 0, merged path (336) 400 200, AS_PATH
 
Scode_l20:07:09.543: BGP(0): 6.6.6.6 rcvd 120.18.1.1/32

R3#show ip bgp regexp _200$
 
BGP table version is 26, local router ID is 3.3.3.3

Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path,
f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop              Metric LocPrf Weight Path
 *>i 120.18.1.1/32    6.6.6.6                 0    200      0 400 200 i
 *                    200.3.10.10                           0 400 200 i
 *>  120.18.2.1/32    2.2.2.2                 0    100      0 (312) 200 i
 *                    200.3.10.10                           0 400 200 i

R2#show ip bgp regexp _200$
 
BGP table version is 22, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path,
f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop       Metric LocPrf Weight Path
 *>  120.18.1.1/32    3.3.3.3             0    200      0 (336) 400 200 i
 *                    200.2.16.16                       0 200 i
 *                    200.2.10.10                       0 400 200 i
 *                    200.2.20.20                       0 100 200 i
 *>  120.18.2.1/32    200.2.16.16                       0 200 i
 *                    200.2.10.10                       0 400 200 i
 *                    200.2.2                           0 100 200 i

R6#show ip bgp regex _200$
--- omitted ---
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 120.18.1.1/32    3.3.3.3                  0    100      0 (312) 200 i
 *                    200.6.11.11                            0 400 200 i
 *>i 120.18.2.1/32    3.3.3.3                  0    100      0 (312) 200 i
 *                    200.6.11.11                            0 400 200 i

R6#show ip bgp regexp _200$
--- omitted ---
     Network          Next Hop            Metric LocPrf Weight Path
 *>  120.18.1.1/32    200.6.11.11                   200      0 400 200 i
 *   120.18.2.1/32    200.6.11.11                            0 400 200 i
 *>i                  3.3.3.3                  0    100      0 (312) 200 i

19:00:42.568: BGP(0): 3.3.3.3 rcv UPDATE about 120.18.1.1/32 --
withdrawn
The final table on R3 is as follows:
R3#show ip bgp regexp _200$
BGP table version is 26, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, >
best,
i - internal,
              r RIB-failure, S Stale, m multipath, b backup-
path,
f RT-Filter,
              x best-external, a additional-path, c RIB-
compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 120.18.1.1/32    6.6.6.6             0    200      0 400 200 i
 *                    200.3.10.10                       0 400 200 i
 *>  120.18.2.1/32    2.2.2.2             0    100      0 (312)
200 i
 *                    200.3.10.10                       0 400 200 i

Internet Protocol Version 4, Src: 200.2.20.2, Dst: 200.2.20.20
Transmission Control Protocol, Src Port: 179, Dst Port: 59790, Seq:
43, Ack: 20, Len: 293
Border Gateway Protocol - UPDATE Message
Border Gateway Protocol - UPDATE Message
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 52
    Type: UPDATE Message (2)

    Withdrawn Routes Length: 0
    Total Path Attribute Length: 24
    Path attributes !LOCAL_PREF is missing here
        Path Attribute - ORIGIN: IGP
        Path Attribute - AS_PATH: 300 200
        Path Attribute - NEXT_HOP: 200.2.20.2
    Network Layer Reachability Information (NLRI)
        120.18.2.1/32

R20#show ip bgp regexp _200$
 
BGP table version is 17, local router ID is 20.20.20.20
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path,
f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop            Metric LocPrf Weight Path
 *   120.18.1.1/32    200.2.20.2                          0 300 400 200 i
 *>i                  19.19.19.19           0    100      0 200 i
 *   120.18.2.1/32    200.2.20.2                          0 300 200 i
 *>i                  19.19.19.19           0    100      0 200 i

R20#show ip bgp 120.18.1.1
BGP routing table entry for 120.18.1.1/32, version 48
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 13
  200

    19.19.19.19 (metric 11) from 19.19.19.19 (110.19.2.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 13
  300 400 200
    200.2.20.2 from 200.2.20.2 (2.2.2.2)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

Step 3: Locally Originated

Step 3 of the BGP best-path algorithm makes a distinction between locally originated paths and paths received from other BGP peers. As mentioned earlier, in BGP, a locally originated path is a path that was injected into the BGP table using either the network, redistribute, or aggregate-address command. By default, the BGP router should prefer to use paths that it locally originates over any path received by another BGP peer if the previous steps in the BGP best-path algorithm resulted in a tie.

To demonstrate this preference, R16 has been chosen. Currently R16 chooses to use the path from R18 to reach the 120.18.1.1/32 prefix. Because this path has not been locally originated by R16 and instead was received from R18, it is a prime candidate for this demonstration.

R16#show ip bgp regex ^$
 
BGP table version is 36, local router ID is 16.16.16.16
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path,
f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 120.18.1.1/32    18.18.18.18              0    100      0 i
 *>i 120.18.2.1/32    18.18.18.18              0    100      0 i

On R16, a static route to Null0 is created for the 120.18.1.1/32 prefix, as shown below. Such a route is called a discard route because Null0 is a discard interface on a Cisco router. Any traffic sent to the Null0 interface is silently discarded by the router. Creating such a route for the 120.18.1.1/32 prefix populates a route in the routing table that directs traffic sent to the 120.18.1.1/32 prefix to the Null0 interface. This simply means all traffic sent to the 120.18.1.1/32 prefix will be discarded. This route is then injected into the BGP table by matching it with a network command on R16:

 
R16(config)#ip route 120.18.1.1 255.255.255.255 null0
 
R16(config)#router bgp 200
R16(config-router)#network 120.18.1.1 mask 255.255.255.255

R16#show ip bgp regexp ^$
 
--- omitted ---
 
     Network          Next Hop            Metric LocPrf Weight Path
 *>  120.18.1.1/32    0.0.0.0                  0         32768 i
 * i                  18.18.18.18              0    100      0 i
 *>i 120.18.2.1/32    18.18.18.18              0    100      0 i
 
R16#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 19
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1          2
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (16.16.16.16)
      Origin IGP, metric 0, localpref 100, weight 32768, valid,
sourced, local, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  Local
    18.18.18.18 (metric 11) from 18.18.18.18 (18.18.18.18)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0

R16 chooses the locally sourced path to Null0 instead of the one received from R18. However, the reason it chooses this path is not because of step 3 of the best-path algorithm. Instead, it’s because of step 1.

Recall that step 1 of the best-path algorithm prefers paths with higher WEIGHT values. By default, Cisco IOS assigns a local weight of 32768 to all locally originated paths in the BGP table. In doing so, Cisco guarantees that locally originated paths will be preferred over all received paths to the same prefix. In order to properly test the step 3 preference, the WEIGHT attribute for the locally originated path needs to be set to 0 to match the default WEIGHT values for received paths.

A route map is therefore created that sets WEIGHT to 0. Unlike most other changes made in this document, the route map is applied to the network command instead of to a neighbor statement. Route maps applied to network commands affect only the specific prefix being injected using the network command. More importantly, any path attributes modified by the route map are reflected in the BGP table of the local router. It is not necessary to specify an in or out direction when applying a route map directly to the network command. It is always applied in the in direction. The configuration commands used are shown below:

R16(config)#route-map tst permit 10
R16(config-route-map)#set weight 0
 
R16(config)#router bgp 200
R16(config-router)#network 120.18.1.1 mask 255.255.255.255 route-map tst

After applying the changes, R16’s BGP tables reflect the following:

R16#show ip bgp regex ^$
 
--- omitted ---
     Network          Next Hop            Metric LocPrf Weight Path
 *>  120.18.1.1/32    0.0.0.0                  0             0 i
 * i                  18.18.18.18              0    100      0 i
 *>i 120.18.2.1/32    18.18.18.18              0    100      0 i
 

R16#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 18
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1          2
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (16.16.16.16)
      Origin IGP, metric 0, localpref 100, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  Local
    18.18.18.18 (metric 11) from 18.18.18.18 (18.18.18.18)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0

With the WEIGHT and LOCAL_PREF values being equal, R16 still prefers its own locally sourced path to the prefix due to step 3 in the best-path algorithm. It is important to note that this configuration was implemented as a proof-of-concept to demonstrate step 3 of the best-path algorithm processes. It is not recommended to implement this configuration in a production environment because traffic may be blackholed unintentionally as a result.

Step 4: AS_PATH

In the first three steps of the BGP best-path algorithm, determinations are made based on administrative preferences or how the paths were inserted into the BGP table. While each step is instrumental in creating policies, the steps do not really describe much about measurable characteristics in the path itself, as a distance vector or link-state routing protocol would.

The fourth step in the BGP best-path algorithm deals with the length of the AS_PATH attribute. Specifically, when deciding between two paths, BGP should choose the path with the shorter AS_PATH attribute length. The reasoning for this preference is grounded in the assumption that a shorter AS_PATH attribute length indicates that the path goes through fewer autonomous systems and therefore is a shorter path to the destination prefix.

This assumption is based on how the AS_PATH attribute is set. When a BGP router originates a path to a prefix, the AS_PATH attribute is empty. Whenever the BGP router advertises the same path to an external neighbor, it prepends its local ASN, such as ASN1, to the AS_PATH attribute. The external peer receives the path and stores it in its BGP table with the new AS_PATH attribute value of ASN1. When the same external peer advertises the path to one if its own external peers, it prepends its ASN, ASN2, to the existing AS_PATH attribute value. Now the AS_PATH attribute has two values: ASN2 and ASN1.

Following suit, the third external peer receives the path with AS_PATH attribute values ASN2 and ASN1. Whenever it advertises the path along again, it prepends its ASN, ASN3, to the AS_PATH attribute, resulting in the AS_PATH attribute length ASN3, ASN2, and ASN1. This process continues as the path is advertised from external peer to external peer. Each successive peer prepends its own ASN to the AS_PATH attribute length.

The prepending process ensures that when a BGP peer receives a path from its external peer, the AS_PATH attribute is presented in order from first ASN hop to originating ASN hop. By looking at the AS_PATH attribute of a BGP prefix in the BGP table, it is possible to determine every AS that has received and forwarded the path.

Notice the use of the term external BGP peer in the prepending process above. This terminology is important because the prepending process only occurs when a path is advertised between external BGP peers. When a BGP router advertises a prefix to an internal BGP peer, it does not automatically modify the AS_PATH attribute in any way. This behavior makes sense, based on the purpose of the AS_PATH attribute.

The AS_PATH attribute is a well-known, mandatory attribute. Its primary purpose is to record the ASNs a path follows in order to prevent routing loops between autonomous systems. Whenever a BGP router receives a path from its external BGP peer, it checks the AS_PATH attribute for any occurrence of its own ASN. If the path contains the local ASN, the router rejects the path and will not install it in its BGP table, assuming the path passes through the local router’s own ASN.

For example, say that debug bgp updates is enabled on R20. Then R2 is forced to re-send its best paths to all of its BGP neighbors, including R20. R20 receives an UPDATE with path information for its 110.19.1.1/32 and 110.19.2.1/32 prefixes. It rejects the update it receives from R2, however, because the ASN 100 is contained in the AS_PATH attribute:

 
R20#debug ip bgp updates

R2#clear ip bgp * soft out

BGP(0): 200.2.20.2 rcv UPDATE about 110.19.1.1/32 -- DENIED due to:
AS-PATH contains our own AS;
BGP(0): 200.2.20.2 rcv UPDATE about 110.19.2.1/32 -- DENIED due to:
AS-PATH contains our own AS;

This check has been instituted to prevent external routing loops in BGP.

Because the AS_PATH is designed to record AS hops, it makes sense for internal peers not to perform prepending when advertising paths amongst themselves because no AS boundary has been crossed.

The AS_PATH attribute can be modified using set as-path prepend [asn1 asn2 asn3] for the route map. The route map is then applied to a neighbor command in the outbound or inbound direction. The effects of this command are different, depending on which direction it is set. To demonstrate these differences, R10 and R9 from AS 400 along with R17 from AS 200 will be used as an example, with interest focused on the 140.15.1.1/32 and 140.15.2.1/32 prefixes. R17 receives these prefixes from R9 and R10 with an AS_PATH attribute of 400, as shown below:

R17#show ip bgp regex _400$
 
--- omitted ---
 
     Network          Next Hop              Metric LocPrf Weight Path
 *   140.15.1.1/32    200.9.17.9                             0 400 i
 *>                   200.10.17.10                           0 400 i
 *   140.15.2.1/32    200.9.17.9                             0 400 i
 *>                   200.10.17.10                           0 400 i

The Wireshark capture below shows the AS_PATH attribute in the UPDATE message received by R17 from R10, and R9 contains the ASN 400 as the AS_SEQUENCE:

Internet Protocol Version 4, Src: 200.10.17.10, Dst: 200.10.17.17
Transmission Control Protocol, Src Port: 60843, Dst Port: 179,
Seq: 100, Ack: 96, Len: 231
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 53
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 20
        Path Attribute - AS_PATH: 400
            Flags: 0x40, Transitive, Well-known, Complete
            Type Code: AS_PATH (2)
            Length: 6
            AS Path segment: 400
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 1
                AS4: 400
        Path Attribute - NEXT_HOP: 200.10.17.10
            Flags: 0x40, Transitive, Well-known, Complete
            Type Code: NEXT_HOP (3)
            Length: 4
            Next hop: 200.10.17.10
    Network Layer Reachability Information (NLRI)
        140.15.1.1/32
        140.15.2.1/32
  

  
Internet Protocol Version 4, Src: 200.9.17.9, Dst: 200.9.17.17 
Transmission Control Protocol, Src Port: 59690, Dst Port: 179,
Seq: 96, Ack: 220, Len: 204
Border Gateway Protocol - UPDATE Message 
    Marker: ffffffffffffffffffffffffffffffff 
    Length: 53 
    Type: UPDATE Message (2) 
    Withdrawn Routes Length: 0 
    Total Path Attribute Length: 20 
        Path Attribute - AS_PATH: 400 
            Flags: 0x40, Transitive, Well-known, Complete 
            Type Code: AS_PATH (2) 

            Length: 6 
            AS Path segment: 400 
                Segment type: AS_SEQUENCE (2) 
                Segment length (number of ASN): 1 
                AS4: 400 
        Path Attribute - NEXT_HOP: 200.9.17.9 
            Flags: 0x40, Transitive, Well-known, Complete 
            Type Code: NEXT_HOP (3) 
            Length: 4 
            Next hop: 200.9.17.9 
    Network Layer Reachability Information (NLRI) 
        140.15.1.1/32 
        140.15.2.1/32

R17 receives two paths for each 140.15.1.1 and 140.15.1.2. By default, R17 prefers whichever route it received first, which in this example is R10’s path.

R17(config)#router bgp 200 
R17(config-router)#neighbor 200.9.17.9 shutdown
  
22:02:17.293: %BGP-5-NBR_RESET: Neighbor 200.9.17.9 reset (Admin.
shutdown)
22:02:17.298: %BGP-5-ADJCHANGE: neighbor 200.9.17.9 Down Admin.
shutdown
22:02:17.298: %BGP_SESSION-5-ADJCHANGE: neighbor 200.9.17.9 IPv4
Unicast topology base removed from session  Admin. shutdown 

R17(config-router)#no neighbor 200.9.17.9 shutdown
*Jun  5 22:02:31.164: %BGP-5-ADJCHANGE: neighbor 200.9.17.9 Up 

AS 400 has a specific application that utilizes the 140.15.1.1/32 address. Because of internal politics, traffic for this application needs to come into the AS via R9 whenever possible. The goal will be for R17 to prefer to use the path through R9 to reach the 140.15.1.1/32 prefix instead of R10 using only the AS_PATH attribute.

The following sections demonstrate solutions for this scenario that involve prepending AS_PATH outbound and inbound.

R10(config)#ip prefix-list 123 permit 140.15.1.1/32
 
R10(config)#route-map tst permit 10
R10(config-route-map)#match ip address prefix 123
R10(config-route-map)#set as-path prepend 400
 
R10(config)#route-map tst permit 90
R10(config-route-map)#router bgp 400
R10(config-router)#neighbor 200.10.17.17 route-map tst out
 
R10#clear ip bgp * soft out

Internet Protocol Version 4, Src: 200.10.17.10, Dst: 200.10.17.17
Transmission Control Protocol, Src Port: 179, Dst Port: 23911, Seq: 1,
Ack: 20, Len: 204
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 52
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 24
    Path attributes
        Path Attribute - AS_PATH: 400 400
            Flags: 0x40, Transitive, Well-known, Complete
            Type Code: AS_PATH (2)
            Length: 10
            AS Path segment: 400 400
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 2
                AS4: 400
                AS4: 400
        Path Attribute - NEXT_HOP: 200.10.17.10
            Flags: 0x40, Transitive, Well-known, Complete
            Type Code: NEXT_HOP (3)
            Length: 4
            Next hop: 200.10.17.10
    Network Layer Reachability Information (NLRI)
        140.15.1.1/32

 
R17#show ip bgp regex _400$
 
--- omitted ---
 
     Network          Next Hop            Metric LocPrf Weight Path
 *   140.15.1.1/32    200.9.17.9                             0 400 i
 *>                   200.10.17.10                           0 400 i

 *   140.15.2.1/32    200.9.17.9                             0 400 i
 *>                   200.10.17.10                           0 400 i
 

R17#show ip bgp regex _400$
 
--- omitted ---
 
     Network          Next Hop            Metric LocPrf Weight Path
 *>  140.15.1.1/32    200.9.17.9                             0 400 i
 *                    200.10.17.10                           0 400 400 i
 *   140.15.2.1/32    200.9.17.9                             0 400 i
 *>                   200.10.17.10                           0 400 i

R10:
 
ip prefix-list PREPEND seq 5 permit 140.15.1.1/32

!
route-map PREPEND permit 10
 match ip address prefix-list PREPEND
 set as-path prepend 200
route-map PREPEND permit 20
!
router bgp 400
 neighbor 200.10.17.17 route-map PREPEND out
 
BGP Update message from R10 to R17:
Internet Protocol Version 4, Src: 200.10.17.10, Dst: 200.10.17.17
Transmission Control Protocol, Src Port: 60843, Dst Port: 179, Seq:
455, Ack: 91, Len: 204
Border Gateway Protocol - UPDATE Message
   Marker: ffffffffffffffffffffffffffffffff
    Length: 52
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 24
    Path attributes
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 400 200
            Flags: 0x40, Transitive, Well-known, Complete
            Type Code: AS_PATH (2)
            Length: 10
            AS Path segment: 400 200
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 2
                AS4: 400
                AS4: 200
    Network Layer Reachability Information (NLRI)
        140.15.1.1/32

16:46:39.466: BGP(0): 200.10.17.10 rcv UPDATE about
140.15.1.1/32 -- DENIED due to: AS-PATH contains our own AS;

R10#show ip bgp regexp _300$
 
--- omitted ---
 
     Network          Next Hop            Metric LocPrf Weight Path
 * i 130.7.1.1/32     11.11.11.11              0    100      0 300 i
 *                    200.10.17.17                           0 200 300 i
 *                    200.3.10.3                             0 300 i
 *>                   200.2.10.2                             0 300 i
 

R12#show ip bgp regexp _300$
 
--- omitted ---
 
    Network          Next Hop            Metric LocPrf Weight Path
 * i 130.7.1.1/32     11.11.11.11              0    100      0 300 i
 *>i                  10.10.10.10              0    100      0 300 i

R10(config)#ip prefix-list PREPEND permit 130.7.1.1/32
 
R10(config)#route-map PREPEND permit 10
R10(config-route-map)#match ip address prefix PREPEND
R10(config-route-map)#set as-path prepend 400
R10(config)#route-map PREPEND permit 20
 
R10(config-route-map)#router bgp 400
R10(config-router)#neighbor 12.12.12.12 route-map PREPEND out
 
R10#clear ip bgp *

R10#show ip bgp regexp _300$
 
--- omitted ---
 
     Network          Next Hop               Metric LocPrf Weight Path
 * i 130.7.1.1/32     11.11.11.11              0    100      0 300 i
 *                    200.10.17.17                           0 200 300 i
 *                    200.3.10.3                             0 300 i
 *>                   200.2.10.2                             0 300 i

R12#show ip bgp regexp _300$
 
--- omitted ---
 
     Network          Next Hop            Metric LocPrf Weight Path
  * i 130.7.1.1/32     11.11.11.11              0    100      0 300 i
  *>i                  10.10.10.10              0    100      0 300 i

Internet Protocol Version 4, Src: 10.10.10.10, Dst: 9.9.9.9
Transmission Control Protocol, Src Port: 12201, Dst Port: 179, Seq:
20, Ack: 20, Len: 233
Border Gateway Protocol – UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 62
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 34
    Path attributes
        Path Attribute – AS_PATH: 300
            Flags: 0x40, Transitive, Well-known, Complete
            Type Code: AS_PATH (2)
            Length: 6
            AS Path segment: 300
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 1
                AS4: 300
    Network Layer Reachability Information (NLRI)
        130.7.1.1/32

Step 5: Origin Code

The fifth step in the BGP best-path decision algorithm relates to how the path was first injected into the BGP table. This attribute is known as the well-known mandatory ORIGIN attribute. The ORIGIN attribute is defined as having one of three values: IGP, EGP, or INCOMPLETE.

The ORIGIN value of IGP signifies that the path was first injected into the BGP table directly by the originating router. In Cisco IOS, paths that are injected into the BGP process in the following ways are given the ORIGIN code IGP:

1. Using a network command in the BGP process

2. As the result of the aggregate-address command where the as-set option is not used

3. As the result of the aggregate-address command with the as-set option used and all component paths have an ORIGIN code of IGP

A value of EGP signifies that the path was originally injected into an EGP process by a legacy EGP-only-speaking router. Finally, a value of INCOMPLETE signifies that there is no authoritative origin information for the path.

The INCOMPLETE origin code requires a bit more explanation than the first two. Paths with origin of INCOMPLETE are typically for NLRI that have been redistributed into BGP from another routing source. The INCOMPLETE origin code also applies to NLRI that are injected into BGP using an aggregate-address command along with the as-set option, if any component path covered by the aggregate has an INCOMPLETE origin.

These origins are shown in the show ip bgp output under the Path column with values of e, i or ?, as shown below:

Router#show ip bgp
BGP table version is 14, local router ID is 100.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path,
f RT-Filter,

              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.11.1.1/32      200.2.16.16                            0 200 100 i
 *>  2.22.2.2/32      0.0.0.0                  0         32768 ? 

In the output above, the i and ? to the far right of the AS_PATH information indicates the origin of the path.

Because redistributed information is external to the BGP process, BGP has less granular information about the path compared to a path that was directly injected into BGP originally. The BGP best-path algorithm prefers to trust paths that were originated directly by BGP (containing code IGP) or EGP over such paths.

The ORIGIN attribute of a particular path can be changed by using the set origin argument in a route map. The BGP best-path algorithm prefers ORIGIN code IGP over EGP and code EGP over INCOMPLETE.

R19 is chosen to demonstrate this path preference. It has two potential paths it can use to reach the 140.15.1.1/32 prefix: one from R18 and another from R20.

R19#show ip bgp 140.15.1.1
 
BGP routing table entry for 140.15.1.1/32, version 10
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 1
  200 400
    200.18.19.18 from 200.18.19.18 (18.18.18.18)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  300 400
    20.20.20.20 (metric 11) from 20.20.20.20 (20.20.20.20)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0

Without any further modifications, R19 chooses the path through R18 because it is an external path, and all steps prior tie; that is, the WEIGHT, LOCAL_PREF, locally originated, AS_PATH, and ORIGIN steps all tie.

The packet capture shows the BGP update message sent by R18 to R19, where the ORIGIN code for the 140.15.1.1 network is set to IGP. The code is set to IGP by R15 when the network is injected into BGP using the network command. This code is preserved in UPDATE messages as it is exchanged between BGP routers.

Internet Protocol Version 4, Src: 200.18.19.18, Dst: 200.18.19.19
Transmission Control Protocol, Src Port: 40092, Dst Port: 179,
Seq: 24, Ack: 24, Len: 192
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 57
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 24
    Path attributes
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
                0... .... = Optional: Not set
                .1.. .... = Transitive: Set
                ..0. .... = Partial: Not set
                ...0 .... = Extended-Length: Not set
                .... 0000 = Unused: 0x0
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
    Network Layer Reachability Information (NLRI)
        140.15.1.1/32
        140.15.2.1/32

The path preference for the 140.15.1.1 prefix on R19 can be changed by modifying the ORIGIN value of the path received from R18 to INCOMPLETE. This method is implemented below on R19.

A prefix list 123 permitting the 140.15.1.1/32 prefix is first configured. This prefix list is then referenced inside the route map TST. The set origin code command under the route map sets the origin code to INCOMPLETE. An empty permit route map statement allows for all other prefixes to pass through. Finally, the route map TST is appended to the neighbor 200.18.19.18 statement in an inbound direction:

R19(config)#ip prefix-list 123 permit 140.15.1.1/32
 
R19(config)#route-map TST per 10
R19(config-route-map)#match ip address prefix 123
R19(config-route-map)#set origin incomplete
R19(config)#route-map TST permit 90
 
R19(config)#router bgp 100
R19(config-router)#neighbor 200.18.19.18 route-map TST in
 
R19#clear ip bgp * soft in
 
R19#show ip bgp 140.15.1.1
 
BGP routing table entry for 140.15.1.1/32, version 30
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 2
  200 400
    200.18.19.18 from 200.18.19.18 (120.18.2.1)
      Origin incomplete, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  300 400
    20.20.20.20 (metric 11) from 20.20.20.20 (20.20.20.20)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

clear ip bgp * soft in is then issued on R19, causing R18 to re-send its BGP routing advertisements to R19. R19 can then apply the newly configured policy that sets the path attribute of the origin code to INCOMPLETE for the 140.15.1.1/32 prefix. With these changes made, R19 now chooses the path through R20 because its ORIGIN code of IGP is a more favorable code than the path through R18 with an incomplete origin code.

Step 6: MED

The sixth step in the BGP best-path algorithm compares the value of the MED or MULTI_EXIT_DISC attribute. The MED attribute is an optional non-transitive attribute that is used to indicate a preferred entry point into the local AS to a neighboring AS. MED is expressed as a 32-bit unsigned number and is commonly referred to as the metric of a BGP path because it behaves in a similar way to IGP metrics.

The MED attribute is set and exchanged in many different ways, depending on a specific set of circumstances. To aid in the explanation, the following adjustments have been made to the original topology:

• The prefix 130.7.1.1 is no longer advertised into BGP on R7.

• The prefix 130.7.1.1 is advertised into OSPF Area 0 on R7.

• R2 and R3 advertise the 130.7.1.1 prefix into BGP using a network statement.

• R1 has been configured to set the WEIGHT value to 100 for the path to the 130.7.1.1 network it receives from R4.

R7(config)#router bgp 378
R7(config-router)#no network 130.7.1.1 mask 255.255.255.255
 
R7(config-router)#interface lo10
R7(config-if)#ip ospf 1 area 0

R2(config)#router bgp 312
R2(config-router)#network 130.7.1.1 mask 255.255.255.255
 

R3(config)#router bgp 336
R3(config-router)#network 130.7.1.1 mask 255.255.255.255

R1(config)#ip prefix-list 123 permit 130.7.1.1/32
 
R1(config)#route-map TST permit 10
R1(config-route-map)#match ip address prefix 123
R1(config-route-map)#set weight 100
R1(config)#route-map TST permit 90
 
R1(config)#router bgp 312
R1(config-router)#neighbor 4.4.4.4 route-map TST in

After making the changes, R2 and R3 now receive the prefix 130.7.1.1 through OSPF instead of through BGP. On R2 and R3, the network command matches this OSPF-learned route. The result is that R2 and R3 originate the BGP prefix 130.7.1.1 into BGP instead of R7. R1 will prefer the path advertised to it from R4 by R3 and advertise it to R2. With this setup, the different ways in which MED is set can be examined.

 
 
R2#show ip bgp
---omitted---
     Network          Next Hop               Metric LocPrf Weight Path
 * i 130.7.1.1/32     3.3.3.3                 31    100    0 (345 336)
 *                    3.3.3.3                 31    100    0 (336) i
 *>                   30.1.2.1                41           32768 i
 
R2#show ip bgp 130.7.1.1
BGP routing table entry for 130.7.1.1/32, version 20
Paths: (3 available, best #3, table default)
  Advertised to update-groups:
     1          2          3
  Refresh Epoch 5
  (345 336)
    3.3.3.3 (metric 11) from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 31, localpref 100, valid, confed-internal
      rx pathid: 0, tx pathid: 0

  Refresh Epoch 6
  (336)
    3.3.3.3 (metric 11) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 31, localpref 100, valid, confed-external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  Local
    30.1.2.1 from 0.0.0.0 (2.2.2.2)
      Origin IGP, metric 41, localpref 100, weight 32768, valid,
sourced, local, best
      rx pathid: 0, tx pathid: 0x0

R2#show ip route 130.7.1.1
 
Routing entry for 130.7.1.1/32
  Known via "ospf 1", distance 110, metric 41, type intra area
  Advertised by bgp 312
  Last update from 30.1.2.1 on Ethernet0/0.12, 01:59:48 ago
  Routing Descriptor Blocks:
  * 30.2.3.3, from 7.7.7.7, 01:59:48 ago, via Ethernet0/0.23
      Route metric is 41, traffic share count is 1
    30.1.2.1, from 7.7.7.7, 01:59:48 ago, via Ethernet0/0.12
      Route metric is 41, traffic share count is 1

R2#show ip bgp
 
 * i  130.7.1.1/32     3.3.3.3                31    100      0 (345 336) i
 *                     3.3.3.3                31    100      0 (336) i
 *>                    30.1.2.1               41         32768 i

R3#show ip route ospf | section 130.7.1.1
 
O        130.7.1.1 [110/31] via 30.3.6.6, 00:23:21, Ethernet0/0.36
                   [110/31] via 30.3.4.4, 00:23:21, Ethernet0/0.34
 

R3#show ip bgp 130.7.1.1
 
BGP routing table entry for 130.7.1.1/32, version 27
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1          2          3
  Refresh Epoch 1
  (312)
    2.2.2.2 (metric 11) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 41, localpref 100, valid, confed-external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  Local
    30.3.4.4 from 0.0.0.0 (3.3.3.3)
      Origin IGP, metric 31, localpref 100, weight 32768, valid,
sourced, local, best
      rx pathid: 0, tx pathid: 0x0

R20#show ip bgp 130.7.1.1
 
BGP routing table entry for 130.7.1.1/32, version 22
Paths: (1 available, best #1, table default)

  Advertised to update-groups:
     2
  Refresh Epoch 1
  300
    200.2.20.2 from 200.2.20.2 (2.2.2.2)
      Origin IGP, metric 41, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

Internet Protocol Version 4, Src: 200.2.20.2, Dst: 200.2.20.20
Transmission Control Protocol, Src Port: 25684, Dst Port: 179,
Seq: 24, Ack: 240, Len: 306
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 55
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 27
    Path attributes
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 300
            Flags: 0x40, Transitive, Well-known, Complete
            Type Code: AS_PATH (2)
            Length: 6
            AS Path segment: 300
        Path Attribute - NEXT_HOP: 200.2.20.2
            Flags: 0x40, Transitive, Well-known, Complete
            Type Code: NEXT_HOP (3)
            Length: 4
            Next hop: 200.2.20.2
        Path Attribute - MULTI_EXIT_DISC: 41
            Flags: 0x80, Optional, Non-transitive, Complete
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 41
    Network Layer Reachability Information (NLRI)
        130.7.1.1/32

R20#show ip route bgp | sec 130.7.1.1
 
B        130.7.1.1 [20/41] via 200.2.20.2, 00:02:23
      140.15.0.0/32 is subnetted, 2 subnets

R19#show ip bgp 130.7.1.1
 
BGP routing table entry for 130.7.1.1/32, version 23
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  200 300
    200.18.19.18 from 200.18.19.18 (18.18.18.18)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  300
    20.20.20.20 (metric 11) from 20.20.20.20 (20.20.20.20)
      Origin IGP, metric 41, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
Internet Protocol Version 4, Src: 20.20.20.20, Dst: 19.19.19.19
 
Transmission Control Protocol, Src Port: 179, Dst Port: 51761, Seq:
43, Ack: 20, Len: 217
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 62
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 34
    Path attributes
        Path Attribute - ORIGIN: IGP

            Flags: 0x40, Transitive, Well-known, Complete
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 300
            Flags: 0x40, Transitive, Well-known, Complete
            Type Code: AS_PATH (2)
            Length: 6
            AS Path segment: 300
        Path Attribute - NEXT_HOP: 20.20.20.20
            Flags: 0x40, Transitive, Well-known, Complete
            Type Code: NEXT_HOP (3)
            Length: 4
            Next hop: 20.20.20.20
        Path Attribute - MULTI_EXIT_DISC: 41
            Flags: 0x80, Optional, Non-transitive, Complete
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 41
        Path Attribute - LOCAL_PREF: 100
            Flags: 0x40, Transitive, Well-known, Complete
            Type Code: LOCAL_PREF (5)
            Length: 4
            Local preference: 100
    Network Layer Reachability Information (NLRI)
        130.7.1.1/32

R18#show ip bgp 130.7.1.1
 
BGP routing table entry for 130.7.1.1/32, version 25
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  100 300
    200.18.19.19 from 200.18.19.19 (19.19.19.19)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  300
    16.16.16.16 (metric 11) from 16.16.16.16 (16.16.16.16)

      Origin IGP, metric 41, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

Internet Protocol Version 4, Src: 200.18.19.19, Dst: 200.18.19.18
Transmission Control Protocol, Src Port: 179, Dst Port: 62942,
Seq: 43, Ack: 24, Len: 188
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 52
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 24
    Path attributes
        Path Attribute - ORIGIN: IGP
        Path Attribute - AS_PATH: 100 300
        Path Attribute - NEXT_HOP: 200.18.19.19
    Network Layer Reachability Information (NLRI)
        130.7.1.1/32

R10#show ip bgp 130.7.1.1
 
BGP routing table entry for 130.7.1.1/32, version 25
Paths: (5 available, best #5, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  300
    11.11.11.11 (metric 11) from 12.12.12.12 (12.12.12.12)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 11.11.11.11, Cluster list: 12.12.12.12
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  200 300
    200.10.17.17 from 200.10.17.17 (17.17.17.17)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1

  300
    200.3.10.3 from 200.3.10.3 (3.3.3.3)
      Origin IGP, metric 31, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  300
    200.2.10.2 from 200.2.10.2 (2.2.2.2)
      Origin IGP, metric 41, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  300
    11.11.11.11 (metric 11) from 11.11.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

R11#show ip bgp 130.7.1.1
 
BGP routing table entry for 130.7.1.1/32, version 30
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2          3
  Refresh Epoch 1
  300
    200.6.11.6 from 200.6.11.6 (6.6.6.6)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

R6#show ip bgp 130.7.1.1
 
BGP routing table entry for 130.7.1.1/32, version 29
Paths: (1 available, best #1, table default, RIB-failure(17) - next-
hop mismatch)
  Advertised to update-groups:
     1          3
  Refresh Epoch 1
  Local
    3.3.3.3 (metric 11) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 31, localpref 100, valid, confed-internal,
best
      rx pathid: 0, tx pathid: 0x0

R11(config)#router bgp 400
R11(config-router)#bgp bestpath med missing-as-worst
 
R11#clear ip bgp *

R11#show ip bgp 130.7.1.1
 
BGP routing table entry for 130.7.1.1/32, version 42
BGP Bestpath: med
Paths: (3 available, best #2, table default)
  Advertised to update-groups:
     1          3
  Refresh Epoch 2
  300
    10.10.10.10 (metric 11) from 12.12.12.12 (12.12.12.12)
      Origin IGP, metric 31, localpref 100, valid, internal
      Originator: 10.10.10.10, Cluster list: 12.12.12.12
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 3
  300
    10.10.10.10 (metric 11) from 10.10.10.10 (10.10.10.10)
      Origin IGP, metric 31, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  300
    200.6.11.6 from 200.6.11.6 (6.6.6.6)
      Origin IGP, metric 4294967295, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

R10(config)#router bgp 400
R10(config-router)#neighbor 200.10.17.17 shutdown
R10(config-router)#neighbor 200.3.10.3 shutdown
R10(config-router)#neighbor 200.2.10.2 shutdown
R10(config-router)#neighbor 9.9.9.9 shutdown
R10(config-router)#neighbor 11.11.11.11 shutdown
R10(config-router)#neighbor 12.12.12.12 shutdown
 

R2(config)#ip prefix-list 123 permit 110.19.1.1/32
 
R2(config)#route-map TST permit 10
R2(config-route-map)#match ip address prefix 123
R2(config-route-map)#set metric 200
 
R2(config)#router bgp 312
R2(config-router)#neighbor 200.2.10.10 route-map TST out

R3(config)#ip prefix-list 123 permit 110.19.1.1/32
 
R3(config)#route-map TST permit 10
R3(config-route-map)#match ip address prefix 123
R3(config-route-map)#set metric 300
 
R3(config)#router bgp 336
R3(config-router)#neighbor 200.3.10.10 route-map TST out
 

R9(config)#ip prefix-list 123 permit 110.19.1.1/32
 
R9(config)#route-map TST permit 10
R9(config-route-map)#match ip address prefix 123
R9(config-route-map)#set metric 100
 
R9(config)#router bgp 400
R9(config-router)#neighbor 10.10.10.10 route-map TST out

R17(config)#ip prefix-list 123 permit 110.19.1.1/32
 
R17(config)#route-map TST permit 10
R17(config-route-map)#match ip address prefix 123
R17(config-route-map)#set metric 150
 
R17(config)#router bgp 200
R17(config-router)#neighbor 200.10.17.10 route-map TST out

R10(config)#router bgp 400
R10(config-router)#no neighbor 9.9.9.9 shutdown
R10(config-router)#no neighbor 200.3.10.3 shutdown
R10(config-router)#no neighbor 200.10.17.17 shutdown
R10(config-router)#no neighbor 200.2.10.2 shutdown

R10#show ip bgp 110.19.1.1
 
BGP routing table entry for 110.19.1.1/32, version 84
BGP Bestpath: med
Paths: (4 available, best #3, table default)
  Advertised to update-groups:
     6          7
  Refresh Epoch 1
  300 100
    200.2.10.2 from 200.2.10.2 (2.2.2.2)
      Origin IGP, metric 200, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  200 100

    200.10.17.17 from 200.10.17.17 (17.17.17.17)
      Origin IGP, metric 150, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  300 100
    200.3.10.3 from 200.3.10.3 (3.3.3.3)
      Origin IGP, metric 300, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  200 100
    9.9.9.9 (metric 11) from 9.9.9.9 (9.9.9.9)
      Origin IGP, metric 100, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0

R10(config)#router bgp 400
 
R10(config-router)#neighbor 9.9.9.9 shutdown
R10(config-router)#neighbor 200.3.10.3 shutdown
R10(config-router)#neighbor 200.10.17.17 shutdown
R10(config-router)#neighbor 200.2.10.2 shutdown
R10(config-router)#bgp always-compare-med
 
! Reestablishing the BGP peerings in order:
 
R10(config-router)#no neighbor 9.9.9.9 shutdown
 
%BGP-5-ADJCHANGE: neighbor 9.9.9.9 Up
 
R10(config-router)#no neighbor 200.3.10.3 shutdown
 
%BGP-5-ADJCHANGE: neighbor 200.3.10.3 Up
 
R10(config-router)#no neighbor 200.10.17.17 shutdown
 
%BGP-5-ADJCHANGE: neighbor 200.10.17.17 Up
 
R10(config-router)#no neighbor 200.2.10.2 shutdown
 
%BGP-5-ADJCHANGE: neighbor 200.2.10.2 Up

R10#show ip bgp 110.19.1.1
 
BGP routing table entry for 110.19.1.1/32, version 85
BGP Bestpath: med
Paths: (4 available, best #4, table default)
  Advertised to update-groupsc:
     7
  Refresh Epoch 1
  300 100

    200.2.10.2 from 200.2.10.2 (2.2.2.2)
      Origin IGP, metric 200, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  200 100
    200.10.17.17 from 200.10.17.17 (17.17.17.17)
      Origin IGP, metric 150, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  300 100
    200.3.10.3 from 200.3.10.3 (3.3.3.3)
      Origin IGP, metric 300, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  200 100
    9.9.9.9 (metric 11) from 9.9.9.9 (9.9.9.9)
      Origin IGP, metric 100, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

R10(config)#router bgp 400
R10(config-router)#no bgp always-compare-med
R10(config-router)#bgp deterministic-med
 
R10#show ip bgp 110.19.1.1
 
BGP routing table entry for 110.19.1.1/32, version 87
BGP Bestpath: deterministic-med: med
Paths: (4 available, best #3, table default)
  Advertised to update-groups:
     6          7
  Refresh Epoch 1
  200 100
    9.9.9.9 (metric 11) from 9.9.9.9 (9.9.9.9)
      Origin IGP, metric 100, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  200 100
    200.10.17.17 from 200.10.17.17 (17.17.17.17)
      Origin IGP, metric 150, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

  Refresh Epoch 1
  300 100
    200.2.10.2 from 200.2.10.2 (2.2.2.2)
      Origin IGP, metric 200, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  300 100
    200.3.10.3 from 200.3.10.3 (3.3.3.3)
      Origin IGP, metric 300, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

R10(config)#router bgp 400
R10(config-router)#bgp always-compare-med
R10(config-router)#bgp deterministic-med
 
R10#clear ip bgp *
 
R10#show ip bgp 110.19.1.1
 
BGP routing table entry for 110.19.1.1/32, version 96
BGP Bestpath: deterministic-med: med
Paths: (4 available, best #1, table default)
Flag: 0x820
  Advertised to update-groups:
     11
  Refresh Epoch 1
  200 100
   9.9.9.9 (metric 11) from 9.9.9.9 (9.9.9.9)
      Origin IGP, metric 100, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  200 100
    200.10.17.17 from 200.10.17.17 (17.17.17.17)
      Origin IGP, metric 150, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  300 100
    200.2.10.2 from 200.2.10.2 (2.2.2.2)
      Origin IGP, metric 200, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  300 100
    200.3.10.3 from 200.3.10.3 (3.3.3.3)
      Origin IGP, metric 300, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

Step 7: eBGP over iBGP

The seventh step in the BGP best-path algorithm gives preference to external paths over internal paths. If no best path has been chosen within the first six steps of the best-path algorithm, BGP will prefer to send traffic on an external path rather than an internal one. Paths received from an eBGP peer are external paths, while paths received from an iBGP peers are internal paths.

This is an important distinction to make. What makes a path internal or external is not the path itself but from which type of BGP peering the path was learned. This means a path can be advertised to the router by an external peer, existing in the local router’s BGP table as an external path.

When the router advertises this same path to one of its iBGP peers, the iBGP peer will consider the path an internal path in its own BGP table. The distinction points to the fact that BGP does not advertise routes per se. Instead, it advertises paths and descriptions about those paths. A path learned from an eBGP peer describes a path that is external to the local BGP domain. A path learned from an iBGP peer describes a path inside the local BGP domain. Consider this example:

R19#show ip bgp 140.15.1.1
 
BGP routing table entry for 140.15.1.1/32, version 34
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 1
  300 400
    20.20.20.20 (metric 11) from 20.20.20.20 (20.20.20.20)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  200 400
    200.18.19.18 from 200.18.19.18 (18.18.18.18)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

In this case, R19 has learned two paths to reach the prefix 140.15.1.1/32. Keep in mind that the 140.15.1.1/32 prefix does not exist within R19’s local BGP domain (AS 100). However, that does not determine the path types reported in the BGP table. R19 learns one path from its iBGP neighbor R20 and another from its eBGP peer R18. If R19 were to follow the path to R20, the packets would flow toward a BGP router inside the domain first. Thus, it is an internal path. If R19 were to follow the path received from R18, the packets would flow to a BGP router outside, or external to, the domain. Thus the path is an external path.

This policy assumes that the administrator has no preference between the two paths in question because the preceding six criteria (WEIGHT, LOCAL_PREF, locally originated versus received from another peer, AS_PATH, ORIGIN, and MED) have tied, and there is no explicit administration-driven preference between the two paths. Thus BGP makes the decision to prefer the external path over the internal one.

This is basically a form of hot-potato routing, where the AS attempts to exit external traffic in the smallest number of internal hops possible. For example, the BGP table on R10 for the 120.18.1.1/32 and 120.18.2.1/32 prefixes reveals the following:

R10#show ip bgp regex _200$
 
BGP table version is 8, local router ID is 10.10.10.10
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path,
f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
              t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop            Metric LocPrf Weight Path
 * i  120.18.1.1/32    9.9.9.9              0    100      0 200 i
 * i                   9.9.9.9              0    100      0 200 i
 *                     200.2.10.2                         0 300 200 i
 *                     200.3.10.3                         0 300 200 i
 *>                    200.10.17.17                       0 200 i
 * i  120.18.2.1/32    9.9.9.9              0    100      0 200 i
 * i                   9.9.9.9              0    100      0 200 i
 *                     200.2.10.2                         0 300 200 i
 *                     200.3.10.3                         0 300 200 i
 *>                    200.10.17.17                       0 200 i

R10 receives five paths for both prefixes. Paths to next hops 200.3.10.3 and 200.2.10.2 are not considered because of a longer AS_PATH length. For the remaining paths, in accordance with step 7, R10 will choose the paths with the next hop 200.10.17.17 as its best path because it was received from an external peer. The other two remaining paths were received from the internal iBGP peer, R9 (indicated with the i to the left of the prefix).

Thinking about the flow of traffic, with R10 choosing the external path directly to R17, R10 will forward transit traffic for 120.18.1.1/32 and 120.18.2.1/32 directly out the local AS toward the proper destination.

If R10 chose to send to R9 (as indicated in its internal paths), transit traffic traverses an extra hop inside the local AS before ultimately leaving. This is an example of cold-potato routing, where transit traffic is kept local to the AS longer before leaving the AS, possibly leading to latency and internal link utilization.

Confederations

Recall the concept of confederation internal peers and confederation external peers. Some publications claim that the decision-making algorithm prefers confederation external peers over confederation internal peers. Let’s examine these claims from R5’s point of view of the 120.18.1.1 prefix:

R5#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 4
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  (336 312) 200
    3.3.3.3 (metric 21) from 4.4.4.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, confed-internal,
best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  (378 336 312) 200
    6.6.6.6 (metric 31) from 7.7.7.7 (7.7.7.7)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      rx pathid: 0, tx pathid: 0

Here, R5 receives two paths to 120.18.1.1: one from its confederation iBGP (internal) neighbor R4 and the other from its confederation eBGP (external) neighbor R7. According to the statements from other sources, R5 should prefer the path through R7, but this is not the case, as you can see above. In reality, with all else being equal, the decision falls on the lowest IGP metric to the next hop.

R5’s metric to reach next hop 3.3.3.3 is 21, whereas the metric to reach next hop 6.6.6.6 is 31. Since the metric to the next hop 3.3.3.3 is lower than the metric to 6.6.6.6, R5 uses the path from R4.

To prove this point, the metrics will be modified in the topology. This is done by modifying the OSPF cost on the E0/0.45 interface on R5 to 20. With the changes made, the output below reveals a tie in metric to reach both 3.3.3.3 and 6.6.6.6:

R5(config)#interface e0/0.45
R5(config-subif)#ip ospf cost 20
 
R5#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 4
Paths: (2 available, best #1, table default)
Flag: 0x100
  Advertised to update-groups:
     1
  Refresh Epoch 1
  (336 312) 200
    3.3.3.3 (metric 31) from 4.4.4.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, confed-internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  (378 336 312) 200
    6.6.6.6 (metric 31) from 7.7.7.7 (7.7.7.7)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      rx pathid: 0, tx pathid: 0

Because R4’s RID 4.4.4.4 is lower than R7’s RID 7.7.7.7, R4’s path is chosen as best. This fact can once again be proven by modifying the router IDs on both routers such that R7’s RID is lower:

R7(config)#router bgp 378
R7(config-router)#bgp router-id 1.1.1.7

R5#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 14
Paths: (2 available, best #1, table default)

  Advertised to update-groups:
     2
  Refresh Epoch 1
  (378 336 312) 200
    6.6.6.6 (metric 31) from 7.7.7.7 (1.1.1.7)
      Origin IGP, metric 0, localpref 100, valid, confed-external,
best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  (336 312) 200
    3.3.3.3 (metric 31) from 4.4.4.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, confed-internal
      rx pathid: 0, tx pathid: 0

With the changes made, the path via R7 is chosen as the best path due the lower RID. The results above should not be surprising as this is the exact behavior described in RFC 5065 Section 5.3, point 4:

Path selection criteria for information received from members inside a confederation MUST follow the same rules used for information received from members inside the same autonomous system, as specified in [BGP-4].

In addition, the following rules SHALL be applied:

1. If the AS_PATH is internal to the local confederation (i.e., there are only AS_CONFED_* segments), consider the neighbor AS to be the local AS.

2. Otherwise, if the first segment in the path that is not an AS_CONFED_SEQUENCE or AS_CONFED_SET is an AS_SEQUENCE, consider the neighbor AS to be the leftmost AS_SEQUENCE AS.

3. When comparing routes using AS_PATH length, CONFED_SEQUENCE and CONFED_SETs SHOULD NOT be counted.

4. When comparing routes using the internal (IBGP learned) versus external (EBGP learned) rules, treat a route that is learned from a peer that is in the same confederation (not necessarily the same Member-AS) as "internal".

This simply means that all peers that are members of the same confederation should be treated as internal peers, regardless of whether they belong to the same member AS. Because R4, R5, and R7 are all members of the confederation AS 300, when comparing paths received from confederation members, the paths are treated as though they are internal paths.

This rule also has the side effect of making eBGP paths preferred over both iBGP and confederation eBGP paths because iBGP and confederation eBGP paths are treated the same.

Step 8: Lowest IGP Metric to the Next Hop

At this stage in the best-path algorithm, BGP is left with two paths that are both either external or internal. Step 8 in the best-path algorithm is a comparison that is based on internal metrics to reach the next hop. In this step, BGP prefers paths to which the local router has a lower metric to reach the BGP next hop. The comparison exists as an enhancement to BGP’s hot-potato routing default. By comparing the internal cost to reach the next hop for two similar paths, BGP further ensures that the closest exit is chosen for the traffic.

The IGP metric to the next hop is the aggregate IGP metric, as stored in the local router’s RIB. This information is kept up to date with IGP metric changes.

To examine the effects of the IGP next hop on BGP decision making, the 120.18.1.1/32 network is examined within AS 400. The following catalogs the prefix’s journey from edge router to internal router:

1. R10 and R9 receive multiple paths for the 120.18.1.1 prefix. They both choose their eBGP paths from R17 as best and advertise them to R12. R10 also advertises its best path to R11.

   On R10:

   Click here to view code image

   R10#show ip bgp regexp _200$
    
   BGP table version is 10, local router ID is 10.10.10.10
   Status codes: s suppressed, d damped, h history, * valid, > best,
   i - internal,
                 r RIB-failure, S Stale, m multipath, b backup-path,
   f RT-Filter,
                 x best-external, a additional-path, c RIB-compressed,
                 t secondary path,
   Origin codes: i - IGP, e - EGP, ? - incomplete
   RPKI validation codes: V valid, I invalid, N Not found
    
        Network          Next Hop            Metric LocPrf Weight Path
    * i  120.18.1.1/32    9.9.9.9              0    100      0 200 i
    * i                   9.9.9.9              0    100      0 200 i
    *>                    200.10.17.17                       0 200 i
    *                     200.3.10.3                         0 300 200 i
    *                     200.2.10.2                         0 300 200 i
    * i  120.18.2.1/32    9.9.9.9              0    100      0 200 i
    * i                   9.9.9.9              0    100      0 200 i
   
    *>                    200.10.17.17                       0 200 i
    *                     200.3.10.3                         0 300 200 i
    *                     200.2.10.2                         0 300 200 i
   

   On R9:

   Click here to view code image

   R9#show ip bgp regexp _200$
    
   BGP table version is 97, local router ID is 9.9.9.9
   Status codes: s suppressed, d damped, h history, * valid, > best,
   i - internal,
                 r RIB-failure, S Stale, m multipath, b backup-path,
   f RT-Filter,
                 x best-external, a additional-path, c RIB-compressed,
                 t secondary path,
   Origin codes: i - IGP, e - EGP, ? - incomplete
   RPKI validation codes: V valid, I invalid, N Not found
        Network          Next Hop            Metric LocPrf Weight Path
    * i  120.18.1.1/32    10.10.10.10              0    100      0 200 i
    *>                    200.9.17.17                            0 200 i
    * i  120.18.2.1/32    10.10.10.10              0    100      0 200 i
    *>                    200.9.17.17                            0 200 i
   

2. R12 receives two paths: one from R9 and one from R10. It chooses the one from R9 because of lower RID and advertises it to R11 and R13 (as shown below).

   On R12:

   Click here to view code image

   R12#show ip bgp 120.18.1.1
   BGP routing table entry for 120.18.1.1/32, version 6
   Paths: (2 available, best #1, table default)
     Advertised to update-groups:
        1
     Refresh Epoch 1
     200, (Received from a RR-client)
       9.9.9.9 (metric 11) from 9.9.9.9 (9.9.9.9)
         Origin IGP, metric 0, localpref 100, valid, internal, best
         rx pathid: 0, tx pathid: 0x0
     Refresh Epoch 1
     200, (Received from a RR-client)
       10.10.10.10 (metric 11) from 10.10.10.10 (10.10.10.10)
         Origin IGP, metric 0, localpref 100, valid, internal
         rx pathid: 0, tx pathid: 0
   

3. R11 receives three paths: one from R6, one from R10, and one from R12. The path through R6 has a longer AS_PATH length and is less preferred. The remaining paths from R10 and R12 are compared. The next hop for the path via R10 is 10.10.10.10 and for the path via R12 is 9.9.9.9. R11 chooses the one from R10 because the metric to next hop 10.10.10.10 is lower than the one to next hop 9.9.9.9. R10 advertises the path received from R10 to R14.

   On R11:

   Click here to view code image

   R11#show ip bgp 120.18.1.1
   BGP routing table entry for 120.18.1.1/32, version 4
   Paths: (3 available, best #3, table default)
     Advertised to update-groups:
        1          3
     Refresh Epoch 1
     200
       9.9.9.9 (metric 21) from 12.12.12.12 (12.12.12.12)
         Origin IGP, metric 0, localpref 100, valid, internal
         Originator: 9.9.9.9, Cluster list: 12.12.12.12
         rx pathid: 0, tx pathid: 0
     Refresh Epoch 1
     300 200
       200.6.11.6 from 200.6.11.6 (6.6.6.6)
         Origin IGP, localpref 100, valid, external
         rx pathid: 0, tx pathid: 0
     Refresh Epoch 1
     200
       10.10.10.10 (metric 11) from 10.10.10.10 (10.10.10.10)
         Origin IGP, metric 0, localpref 100, valid, internal, best
         rx pathid: 0, tx pathid: 0x0
   

   Note

   The output above may look odd because the next hop advertised by R12 for the path to 120.18.1.1 is 9.9.9.9 instead of itself (12.12.12.12). However, this is normal behavior for BGP routers in a route reflector configuration.

   Originally, R9 received the advertisement from R17, its eBGP neighbor. When R9 advertised the path to R12, it set itself as the next hop because it is configured with the next-hop-self command under its neighbor command for its peering with R12.

   Under normal circumstances, R12 would not advertise the path to R11 because it is an internal path. R11 is a route reflector client of R12, however, which means R12 can relax its normal iBGP split-horizon rule and reflect the path to R11.

   When a route reflector reflects a path, it does not change the next hop to itself. This is because the route reflector does not insert itself into the data forwarding path unnecessarily. The next hop should be retained as R9 because it was R9 that originally advertised in the internal prefix, and R9 is the edge router to which all other routers in the topology should recurse.

   To help better show this interaction, two packet captures are included below:

   Click here to view code image

   ! BGP update message from R9 to R12:
    
   Internet Protocol Version 4, Src: 9.9.9.9, Dst: 12.12.12.12
   Transmission Control Protocol, Src Port: 179, Dst Port: 41971, Seq:
   66, Ack: 397, Len: 171
    
   Border Gateway Protocol - UPDATE Message
       Marker: ffffffffffffffffffffffffffffffff
       Length: 67
       Type: UPDATE Message (2)
       Withdrawn Routes Length: 0
       Total Path Attribute Length: 34
       Path attributes
   Path Attribute - ORIGIN: IGP
   Path Attribute - AS_PATH: 200 
   Path Attribute - NEXT_HOP: 9.9.9.9 Path Attribute - MULTI_EXIT_DISC: 0
   Path Attribute - LOCAL_PREF: 100
       Network Layer Reachability Information (NLRI)
           120.18.1.1/32
           120.18.2.1/32
   ! BGP update message from R12 to R11:
   Internet Protocol Version 4, Src: 12.12.12.12, Dst: 11.11.11.11
   Transmission Control Protocol, Src Port: 179, Dst Port: 60255, Seq:
   24, Ack: 1, Len: 354
   Border Gateway Protocol - UPDATE Message
       Marker: ffffffffffffffffffffffffffffffff
       Length: 81
       Type: UPDATE Message (2)
       Withdrawn Routes Length: 0
       Total Path Attribute Length: 48
       Path attributes
   Path Attribute - ORIGIN: IGP
   Path Attribute - AS_PATH: 200
   Path Attribute - NEXT_HOP: 9.9.9.9
   Path Attribute - MULTI_EXIT_DISC: 0
   Path Attribute - LOCAL_PREF: 100
   
   Path Attribute - CLUSTER_LIST: 12.12.12.12 Path Attribute -
   ORIGINATOR_ID: 9.9.9.9
       Network Layer Reachability Information (NLRI)
           120.18.1.1/32
           120.18.2.1/32
   

   R9 advertises itself as next hop to R12 in the first packet capture. In the second capture,

   R12 continues to advertise R9 as next hop to R11 because it is performing route reflection.

4. R13 receives a single path to the prefix from R12 and advertises it on to R14.

   On R13:

   Click here to view code image

   R13#show ip bgp 120.18.1.1
    
   BGP routing table entry for 120.18.1.1/32, version 129
   Paths: (1 available, best #1, table default)
     Advertised to update-groups:
        2
     Refresh Epoch 1
     200
       9.9.9.9 (metric 21) from 12.12.12.12 (12.12.12.12)
         Origin IGP, metric 0, localpref 100, valid, internal, best
         Originator: 9.9.9.9, Cluster list: 12.12.12.12
         rx pathid: 0, tx pathid: 0x0
   

5. R14 has two paths: one path with next hop 10.10.10.10 and the other with next hop 9.9.9.9, shown below. R14 chooses the path through R10 as best because of the lower metric to the next hop 10.10.10.10.

   On R14:

   Click here to view code image

   R14#show ip bgp 120.18.1.1
    
   BGP routing table entry for 120.18.1.1/32, version 43
   Paths: (2 available, best #2, table default)
   Flag: 0x100
     Not advertised to any peer
     Refresh Epoch 2
     200
       9.9.9.9 (metric 31) from 13.13.13.13 (13.13.13.13)
         Origin IGP, metric 0, localpref 100, valid, internal
   
         Originator: 9.9.9.9, Cluster list: 13.13.13.13, 12.12.12.12
         rx pathid: 0, tx pathid: 0
     Refresh Epoch 2
     200
       10.10.10.10 (metric 21) from 11.11.11.11 (11.11.11.11)
         Origin IGP, metric 0, localpref 100, valid, internal, best
         Originator: 10.10.10.10, Cluster list: 11.11.11.11
         rx pathid: 0, tx pathid: 0x0
   

In the sequence above, both R11 and R14 make best-path decisions based on their internal IGP metric to reach the next hop for the prefix 120.18.1.1/32.

First, R11 chooses its path from R10 because its metric to the next hop 10.10.10.10 is 1,1 compared to the alternate path through R12, with a next hop of 9.9.9.9 and metric of 21. R14 chooses the path from R11 with metric 21 to reach next hop 10.10.10.10 compared to the path from R13, with a metric of 31, to reach the next hop 9.9.9.9.

All the metrics from the above are calculated based on the cumulative IGP metric to reach the next hop. In this case, the metric used is the OSPF cost for the routes as installed in the routing table, as shown in the output on R14:

R14#show ip route 9.9.9.9
Routing entry for 9.9.9.9/32
  Known via "ospf 1", distance 110, metric 31, type intra area
  Last update from 40.11.14.11 on Ethernet0/0.1114, 2d23h ago
  Routing Descriptor Blocks:
  * 40.13.14.13, from 9.9.9.9, 2d23h ago, via Ethernet0/0.1314
      Route metric is 31, traffic share count is 1
    40.11.14.11, from 9.9.9.9, 2d23h ago, via Ethernet0/0.1114
      Route metric is 31, traffic share count is 1
 
R14#show ip route 10.10.10.10
 
Routing entry for 10.10.10.10/32
  Known via "ospf 1", distance 110, metric 21, type intra area
  Last update from 40.11.14.11 on Ethernet0/0.1114, 00:51:21 ago
  Routing Descriptor Blocks:
  * 40.11.14.11, from 10.10.10.10, 00:51:21 ago, via Ethernet0/0.1114
      Route metric is 21, traffic share count is 1

To manipulate BGP’s choice of best path utilizing the IGP metric to the next hop, the administrator can modify the physical link OSPF costs to engineer the desired results. For example, to force R14 to prefer the path through R9 instead of R10, the administrator could change the costs of R12’s e0/0.1012 interface and R14’s e0/0.1114 interface.

In the following, R12 has its e0/0.1012 interface’s cost increased to 20, while R14 has its e0/0.1114 interface’s cost increased to 30. The result increases the metric R14 uses to reach the next hop 10.10.10.10 from 20 to 41, as shown below:

R12(config)#interface e0/0.1012
R12(config-subif)#ip ospf cost 20

R14(config)#interface e0/0.1114
R14(config-subif)#ip ospf cost 10
 
R14#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 53
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  200
    9.9.9.9 (metric 31) from 13.13.13.13 (13.13.13.13)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 9.9.9.9, Cluster list: 13.13.13.13, 12.12.12.12
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  200
    10.10.10.10 (metric 41) from 11.11.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 10.10.10.10, Cluster list: 11.11.11.11
      rx pathid: 0, tx pathid: 0

As a result of the above configuration, R14 now installs the path via R9 as the best path due to the lower metric (31) to reach 9.9.9.9.

Step 9: Determine if Multiple Paths Exist

A common phenomenon in IP routing is a situation whereby the router receives multiple equal-cost routes to reach a specific destination. In such a situation, the individual routing protocols can offer both routes to the RIB for load sharing purposes. BGP also includes this functionality, but it is implemented based on two criteria.

First, BGP selects only a single path as the best path to a particular prefix and installs it into the RIB. This setting is limited by what is known as the maximum path configuration setting. By default, the maximum path setting is set to 1, which is why only a single path is installed into the RIB from BGP. The show ip protocols output below confirms this default setting:

R10#show ip protocols | section "bgp 400"
 
Routing Protocol is "bgp 400"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  IGP synchronization is disabled
  Automatic route summarization is disabled
  Neighbor(s):
    Address          FiltIn FiltOut DistIn DistOut Weight RouteMap
    9.9.9.9
    11.11.11.11
    12.12.12.12
    200.2.10.2
    200.3.10.3
    200.10.17.17
  Maximum path: 1
  Routing Information Sources:
    Gateway         Distance      Last Update
    12.12.12.12          200      03:43:11
    200.10.17.17          20      03:43:48
    200.2.10.2            20      03:43:48
  Distance: external 20 internal 200 local 200

The administrator must designate the type and quantity of paths that can be considered for multipath. For example, if the administrator designates that only two external paths can be considered to be installed into the RIB, then BGP picks two external paths as multipath and one as best path. Both paths are installed into the RIB.

The maximum-paths [ibgp | eibgp] [number-of-paths] command controls the quantity and type of paths that can be used as best paths and can be installed as multiple paths in the RIB. There are three ways this command can be used in BGP router configuration mode:

• maximum-paths [number-of-paths]: Chooses only equal external paths

• maximum-paths eibgp [number-of-paths]: Chooses between a mix of equal external and internal paths

• maximum-paths ibgp [number-of-paths]: Chooses only equal internal paths

For example, let’s configure R10 to increase its default number of maximum paths to four by using the command maximum-paths 4. With this form of the command, R10 will only select up to four equal-cost paths as multipath in the BGP RIB to be installed in the RIB. The effects of this change are reflected in the show ip protocols output on R10:

R10(config)#router bgp 400
R10(config-router)#maximum-paths 4
 
R10#show ip protocols | section bgp
 
Routing Protocol is "bgp 400"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  IGP synchronization is disabled
  Automatic route summarization is disabled
  Neighbor(s):
    Address          FiltIn FiltOut DistIn DistOut Weight RouteMap
    9.9.9.9
    11.11.11.11
    12.12.12.12
    200.2.10.2
    200.3.10.3
    200.10.17.17
  Maximum path: 4
  Routing Information Sources:
    Gateway         Distance      Last Update
    12.12.12.12          200      00:22:51
    200.2.10.2            20      00:00:09
    200.3.10.3            20      00:22:18
    200.10.17.17          20      00:22:48
  Distance: external 20 internal 200 local 200

Now that the BGP default has been modified to allow multiple equal-cost paths to be selected as the best path from the BGP table, the second criterion deals with how BGP determines whether two paths are equal. This is a simple calculation for IGPs, which use metric values to determine what specific route is more preferred over another. If the metric value ties between two routes learned by an IGP, the IGP will automatically list them as candidates for multipath routing. BGP does not use metric values in this way.

As discussed earlier, BGP does not include the concept of traditional metrics, as IGPs do. Instead, it relies on its path attributes to determine degrees of preference for all received paths. Logically speaking, if BGP determined that particular path attributes are equal between two competing paths, then it could provide both paths as routes to the RIB of the local router. The only thing BGP would need to do is determine which path attributes should be equal and integrate such a check into the best-path algorithm it already uses. BGP includes this functionality but with different criteria.

First, it must be established that the BGP algorithm always chooses a single best path. No matter what multipath settings are applied, there is always a solitary best path selected in the BGP table for all prefixes. Any additional paths that are to be installed in the RIB are selected based on how much they match the chosen best path.

Step 9 in the best-path algorithm performs this step. If, for a particular competing path, certain attributes are equal to the current best path, then step 9 calls for a check of the multipath settings for the router. BGP selects as many equal paths as the maximum path settings allow. In the above, R10’s maximum path setting was increased to four. Thus, BGP would install up to four paths from the BGP table into the RIB.

So, in short, these are the two criteria for selecting multiple paths in the BGP table:

• The maximum path setting must be set to allow more than one path.

• Certain attributes of the path in question must match the same attributes of the current best path.

Although the specific attributes that must match vary depending on which version of the maximum-paths command is used, at least the following attributes must be equal to the current best path:

• WEIGHT

• LOCAL_PREF

• AS_PATH length

• ORIGIN

• MED

• AS_PATH SEQUENCE

The next subsections review the specific requirements for each maximum-paths command variant.

External Paths In order for BGP to consider two or more external paths as equal-cost paths suitable for multipathing, in addition to the attributes listed above, the following additional requirements must be met:

• The path must be learned from an external or confederation-external BGP neighbor.

• The IGP metric to the next hop should be equal to the best-path IGP metric.

In other words, the path must be an external path or must be learned from an external confederation peer, and the router’s own metric to reach the next hop should be the same. These concepts are proven next, using R10. In the following configuration, the previous maximum-paths 4 command is removed. R10 receives a mix of internal and external paths to reach the 130.7.1.1/32 prefix shown below:

R10(config)#router bgp 400
R10(config-router)#no maximum-paths 4
 
R10#show ip bgp 130.7.1.1
 
BGP routing table entry for 130.7.1.1/32, version 58
Paths: (4 available, best #3, table default)
  Advertised to update-groups:
     1          2
  Refresh Epoch 2
  300
    11.11.11.11 (metric 11) from 11.11.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  300
    200.3.10.3 from 200.3.10.3 (3.3.3.3)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  300
    200.2.10.2 from 200.2.10.2 (2.2.2.2)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  200 300
    200.10.17.17 from 200.10.17.17 (17.17.17.17)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

The path from R17 is not considered a best path because of the longer AS_PATH length. The path from R11 is also not considered the best path because it is an internal BGP route, unlike the external BGP routes received from R2 and R3. The paths from R2 and R3 are identical up to step 10. Without multipath enabled, the decision is based on whichever path is older. In this case, the path received from R2 is older or was marked as best before the path to R3, and thus R10 chooses R2’s path as its best path.

R10 submits the above best path via R2 to the RIB. This can be confirmed with the show ip route 130.7.1.1 output on R10:

R10#show ip route 130.7.1.1
 
Routing entry for 130.7.1.1/32
  Known via "bgp 400", distance 20, metric 0
  Tag 300, type external
  Last update from 200.2.10.2 00:08:59 ago
  Routing Descriptor Blocks:
  * 200.2.10.2, from 200.2.10.2, 00:08:59 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 300
      MPLS label: none

R10 has an additional path to the same prefix in its BGP RIB that appears to be virtually identical to its best path through R2. However, because the default maximum path setting is 1, it will only install the best path in the RIB. In order for R10 to consider the extra external path, the maximum-paths 2 command is configured on R10. Remember that the maximum-paths command followed by a number only considers external paths for equal-cost multipathing.

R10(config)#router bgp 400
R10(config-router)#maximum-paths 2

The output of the show ip protocols command confirms that the maximum paths setting has taken effect:

R10#show ip protocols | s bgp
 
Routing Protocol is "bgp 400"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  IGP synchronization is disabled
  Automatic route summarization is disabled
  Neighbor(s):
    Address          FiltIn FiltOut DistIn DistOut Weight RouteMap
    9.9.9.9
    11.11.11.11
    12.12.12.12
    200.2.10.2
    200.3.10.3
    200.10.17.17
  Maximum path: 2
  Routing Information Sources:
    Gateway         Distance      Last Update
    12.12.12.12          200      00:29:17
    200.10.17.17          20      00:29:16
    200.3.10.3            20      00:00:54
    200.2.10.2            20      00:20:03
  Distance: external 20 internal 200 local 200

With the new maximum path setting in effect, R10’s BGP table shows the following:

R10#show ip bgp 130.7.1.1
 
BGP routing table entry for 130.7.1.1/32, version 122
Paths: (4 available, best #3, table default)
Multipath: eBGP
  Advertised to update-groups:
     1          2
  Refresh Epoch 2
  300
    11.11.11.11 (metric 11) from 11.11.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  300
    200.3.10.3 from 200.3.10.3 (3.3.3.3)

      Origin IGP, localpref 100, valid, external, multipath(oldest)
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  300
    200.2.10.2 from 200.2.10.2 (2.2.2.2)
      Origin IGP, localpref 100, valid, external, multipath, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  200 300
    200.10.17.17 from 200.10.17.17 (17.17.17.17)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

Now R10 marks the external paths received from R3 and R2 as multipath, with R2’s path as best. The multipath designation indicates that R10 has sent both paths to the RIB for multipath installation consideration. This can be seen in R10’s routing table for the same prefix:

R10#show ip route 130.7.1.1
 
Routing entry for 130.7.1.1/32
  Known via "bgp 400", distance 20, metric 0
  Tag 300, type external
  Last update from 200.2.10.2 00:00:11 ago
  Routing Descriptor Blocks:
  * 200.3.10.3, from 200.3.10.3, 00:00:11 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 300
      MPLS label: none
    200.2.10.2, from 200.2.10.2, 00:00:11 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 300
      MPLS label: none

It is important to understand that even though BGP sends both paths to the RIB to be installed, BGP will still only advertise one path as its best path to its other BGP neighbors. To demonstrate this, in this example, R10 has selected R2’s path as its best path. The output of the show ip bgp neighbor 12.12.12.12 advertised-routes command shows that this is the same path that R10 advertises to R12 as its iBGP neighbor:

R10#show ip bgp neighbor 12.12.12.12 advertised-routes
 
BGP table version is 27, local router ID is 10.10.10.10
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path,
f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop           Metric LocPrf Weight Path
 *>   110.19.1.1/32    200.10.17.17                       0 300 100 i
 *>   110.19.2.1/32    200.10.17.17                       0 300 100 i
 *>   120.18.1.1/32    200.10.17.17                       0 200 i
 *>   120.18.2.1/32    200.10.17.17                       0 200 i
 *>   130.7.1.1/32     200.2.10.2                         0 300 i

This behavior is not unlike IGP behavior—specifically with distance vector protocols. Distance vector IGPs advertise only a single route to reach a destination prefix, even if they have multiple routes stored in their IGP topology tables and stored in the RIB. Similarly, BGP advertises a single best path while installing multiple equal-cost paths.

External and Internal Paths The example above shows a configuration where R10 is allowed to install its additional external equal-cost path into the RIB. However, if you look again at R10’s show ip bgp 130.7.1.1 output, you see that there is another path that could potentially be installed in the routing table:

R10#show ip bgp 130.7.1.1
 
BGP routing table entry for 130.7.1.1/32, version 27
Paths: (4 available, best #3, table default)
Multipath: eBGP
  Advertised to update-groups:
     2          3
  Refresh Epoch 2
  300
    11.11.11.11 (metric 11) from 11.11.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0

  Refresh Epoch 1
  300
    200.3.10.3 from 200.3.10.3 (3.3.3.3)
      Origin IGP, localpref 100, valid, external, multipath(oldest)
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  300
    200.2.10.2 from 200.2.10.2 (2.2.2.2)
      Origin IGP, localpref 100, valid, external, multipath, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  200 300
    200.10.17.17 from 200.10.17.17 (17.17.17.17)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

The path received from R11 ties with the paths received from R2 and R3 except for one thing: The path received from R11 is an internal path, while the current best path received from R2 is an external path. With the maximum-paths 2 command, only external paths are considered for multipathing.

If you wanted to include any potential equal path, regardless of whether it was an internal or external path, you would use the maximum-paths eibgp command. In this case, the router will designate all paths as multipath candidates if the following attributes are the same as for its current best path:

• WEIGHT

• LOCAL_PREF

• AS_PATH

• ORIGIN

• MED

• AS_PATH SEQUENCE

Basically, the requirements are that steps 1–6 should all result in a tie when compared to the current best path. To configure this command, the maximum-paths 2 command should be removed from the configuration on R10 and replaced with the maximum-paths eibgp 3 command. Note that the number increases from 2 to 3. This ensures that three total paths (including the best path) can be marked for multipathing. This configuration is shown below:

R10(config)#router bgp 400
R10(config-router)#no maximum-paths 2
R10(config-router)#maximum-paths eibgp 3
R10#show ip bgp 130.7.1.1
 
BGP routing table entry for 130.7.1.1/32, version 144
Paths: (4 available, best #3, table default)
Multipath: eiBGP
  Advertised to update-groups:
     1          2
  Refresh Epoch 2
  300
    11.11.11.11 (metric 11) from 11.11.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal,
 multipath
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  300
    200.3.10.3 from 200.3.10.3 (3.3.3.3)
      Origin IGP, localpref 100, valid, external, multipath(oldest)
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  300
    200.2.10.2 from 200.2.10.2 (2.2.2.2)
      Origin IGP, localpref 100, valid, external, multipath, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  200 300
    200.10.17.17 from 200.10.17.17 (17.17.17.17)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

After you configure this command, the internal path from R11 and the external paths from R2 and R3 are both designated as multipath in the BGP table, as shown above. These paths are once again installed in the routing table, as shown in the output below:

R10#show ip route 130.7.1.1
 
Routing entry for 130.7.1.1/32
  Known via "bgp 400", distance 20, metric 0
  Tag 300, type external
  Last update from 200.2.10.2 00:00:55 ago
  Routing Descriptor Blocks:
  * 200.3.10.3, from 200.3.10.3, 00:00:55 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 300
      MPLS label: none
    200.2.10.2, from 200.2.10.2, 00:00:55 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 300
      MPLS label: none
    11.11.11.11, from 11.11.11.11, 00:00:55 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 300
      MPLS label: none

The maximum-paths eibgp command includes equal internal and external paths in the calculation, as expressed above. Even though the multipath configuration includes both internal and external paths, there will still be only one best path. In this example, the best path is the path received from R2. All other multipath-capable paths are selected if they contain attributes that are equal to the path R10 received from R2.

R10(config-router)#maximum-paths eibgp 3
 
%BGP: This may cause traffic loop if not used properly (command
accepted)
R10(config-router)#
*Jun 28 14:35:08.029: %BGP-4-MULTIPATH_LOOP: This may cause traffic
loop if not used properly (command accepted).

Internal Paths Finally, the maximum-paths ibgp command can be used to have the router select multipath paths for only internally learned paths. When selecting multipath paths for internal paths, the following additional attributes must be the same between the candidate multipath path and the current best path:

• Both paths must be learned from an internal neighbor.

• The IGP metric to the BGP next hop should be equal to the best path.

To demonstrate this feature, R12’s BGP table for the 130.7.1.1 prefix is shown below:

R12#show ip bgp 130.7.1.1
 
BGP routing table entry for 130.7.1.1/32, version 112
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  300, (Received from a RR-client)
    10.10.10.10 (metric 11) from 10.10.10.10 (10.10.10.10)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  300, (Received from a RR-client)
    11.11.11.11 (metric 11) from 11.11.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0

Here, R12 receives two iBGP paths to reach the prefix. It has marked its path from R10 as the best path because of the lower BGP RID. For the path through R11, however, all of the required path attributes for multipath are equal with R12’s current best path through R10.

The maximum-paths ibgp 2 command is configured under BGP router configuration mode on R12 to allow R12 to install the extra path through R11 as multipath in the RIB. The results are shown in the output below. R12 designates both internal paths as multipaths, with the path received from R10 as the best path.

R12(config)#router bgp 400
R12(config-router)#maximum-paths ibgp 2
 
R12#show ip bgp 130.7.1.1
 
BGP routing table entry for 130.7.1.1/32, version 120
Paths: (2 available, best #1, table default)
Multipath: iBGP
  Advertised to update-groups:
     1
  Refresh Epoch 1
  300, (Received from a RR-client)
    10.10.10.10 (metric 11) from 10.10.10.10 (10.10.10.10)
      Origin IGP, metric 0, localpref 100, valid, internal, multipath,
best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  300, (Received from a RR-client)
    11.11.11.11 (metric 11) from 11.11.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal,
multipath(oldest)
      rx pathid: 0, tx pathid: 0

As you have seen in this section, the BGP multipath settings allow BGP to act like a normal IGP and install multiple paths into the routing table if certain attributes are equal to its current best path. When configuring BGP multipathing, the following should be considered:

• Potential multipath paths are compared to the current BGP best path.

• It is not possible to configure maximum-paths or maximum-paths ibgp along with maximum-paths eibgp.

• It is possible to configure maximum-paths along with maximum-paths ibgp.

The first point is just another friendly reminder that the multipath comparison is made by comparing the path attributes of the additional path to the current BGP best path. If multipathing isn’t working, start by verifying that the proper set of attributes matches between the two paths.

The second point enforces the requirement that if both internal and external paths to the same prefix are to be considered for multipathing, it is not possible to enable multipathing for only one set of paths. In other words, the administrator must choose whether only internal or external paths to the same prefix are considered for multipathing. This is because the maximum-paths eibgp command would include a subset of the other two commands. Including this subset makes it incompatible for consideration.

On the other hand, the second point emphasizes that it is possible to configure the maximum-paths and maximum-paths ibgp commands together. This use is not detailed in this document.

Step 10: Oldest Route

The next steps of the BGP best-path algorithm introduce a series of tie-breaker conditions that are designed to help deterministically choose a best path from two paths that are virtually identical. At this point, the two paths under consideration have similar attributes and are either both external or both internal paths. Step 10 of the best-path algorithm specifically deals with stability between external peers.

Put simply, at this step, BGP prefers an external path that has already become best over any competing external path with the same attributes. This ensures that BGP does not unnecessarily introduce route flaps into the BGP process run with its external peers by informing it of a path that is only superior to the local BGP router’s already chosen best path based on criteria following this step.

The show ip bgp output lists paths in reverse order from when they were received. That is, paths at the bottom of the list were received first, and paths at the top of the list were received last.

This step only applies to external paths and is skipped if any of the following are true:

• The router ID is the same for multiple paths, indicating that the path was learned from the same router.

• There is currently no best path, indicating that the current best path was lost or has never been selected.

• The bgp best-path compare-routerid command has been enabled. This is explained in step 11 of the best-path algorithm.

Because this section is heavily dependent on a specific order of operations, the following has been applied to the topology in order to achieve consistent results:

• The R17/R10 peering is shut down.

• The R17/R10 peering is brought up.

To demonstrate how this step functions, examine the output of the show ip bgp 140.15.1.1 output on R17:

R17(config)#router bgp 200
R17(config-router)#neighbor 200.10.17.10 shutdown
 
%BGP-5-NBR_RESET: Neighbor 200.10.17.10 reset (Admin. shutdown)
 
%BGP-5-ADJCHANGE: neighbor 200.10.17.10 Down Admin. shutdown
 
%BGP_SESSION-5-ADJCHANGE: neighbor 200.10.17.10 IPv4 Unicast topology
base removed from session  Admin. shutdown
 
R17(config-router)#no neighbor 200.10.17.10 shutdown

%BGP-5-ADJCHANGE: neighbor 200.10.17.10 Up
 
 
R17#show ip bgp 140.15.1.1
 
BGP routing table entry for 140.15.1.1/32, version 28
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1          2
  Refresh Epoch 1
  400
    200.10.17.10 from 200.10.17.10 (10.10.10.10)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  400
    200.9.17.9 from 200.9.17.9 (9.9.9.9)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

R17 receives two paths for the 140.15.1.1/32 prefix: one from R9 and one from R10. Between the two competing prefixes, the WEIGHT, LOCAL_PREF, AS_PATH, ORIGIN, and MED are all tied. In addition, both paths are external paths. The deciding factor between the two paths is that the path from R9 was received first, as indicated by its being the last path listed in the output. Since R9 is the oldest route, BGP prefers R9.

To prove this point, the peering between R17 and R9 is shut down and brought back up again. R17 removes all prefixes learned from R9 as the peering goes down. At this point, the only path R17 has is from R10, which it now considers best. When the peering is restored to R9, R9 advertises its path back to R17. R17 runs the best-path algorithm for the two paths again. The result of the calculation is that R17 will continue to retain its current best path via R10 as its oldest path.

R17(config)#router bgp 200
R17(config-router)#neighbor 200.9.17.9 shut

%BGP-5-NBR_RESET: Neighbor 200.9.17.9 reset (Admin. shutdown)
%BGP-5-ADJCHANGE: neighbor 200.9.17.9 Down Admin. shutdown
%BGP_SESSION-5-ADJCHANGE: neighbor 200.9.17.9 IPv4 Unicast topology
base removed from session  Admin. shutdown
 
R17(config-router)#no neighbor 200.9.17.9 shut

%BGP-5-ADJCHANGE: neighbor 200.9.17.9 Up
 
R17#show ip bgp 140.15.1.1
 
BGP routing table entry for 140.15.1.1/32, version 20
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1          2
  Refresh Epoch 1
  400
    200.9.17.9 from 200.9.17.9 (9.9.9.9)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  400
    200.10.17.10 from 200.10.17.10 (10.10.10.10)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

A key aspect of understanding this step comes whenever the “best” path is not also the oldest path. In the case above, R10’s path was retained as best, and it was the oldest path. This provided for a clear basic understanding. To fully grasp the functionality, however, you need to understand the case where the “best” path isn’t also the oldest path. The path to the prefix 120.18.1.1/32 on R2 can help demonstrate.

R2 has three paths to reach this prefix. Of those three paths, R2 chooses the path through R16 as its best path because it has the lower AS_PATH length. Before looking at the output on R2, R2’s peerings need to be reset as follows:

1. The R20 and R2/R16 peerings are shut down.

2. The R2/20 peering is brought up

3. The R2/R16 peering is brought up.

Now, the output of show ip bgp 120.18.1.1 on R2 should appear in the following order:

R2#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 20
Paths: (3 available, best #1, table default)
  Advertised to update-groups:
     8          9          10
  Refresh Epoch 1
  200
    200.2.16.16 from 200.2.16.16 (16.16.16.16)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  100 200
    200.2.20.20 from 200.2.20.20 (20.20.20.20)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  400 200
    200.2.10.10 from 200.2.10.10 (10.10.10.10)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

In output above, R16’s path is chosen as the best path because it has a lower AS_PATH length attribute than the paths received from R10 and R20. This determination is made in step 4 of the best-path algorithm. If step 4 in the AS_PATH algorithm were skipped, then processing would eventually fall to step 10, where BGP would prefer the oldest route.

This scenario can be tested using the bgp bestpath as-path ignore command on R2. After making this change, R2 ignores step 4 of the best-path algorithm when evaluating best paths. In this case, the expectation is that R10’s path would be chosen because it was received before the path received from R16. However, R2 still chooses R16, as shown below:

R2(config)#router bgp 312
R2(config-router)#bgp bestpath as-path ignore
 
show ip bgp 120.18.1.1
BGP routing table entry for 120.18.1.1/32, version 20
Paths: (3 available, best #1, table default)
  Advertised to update-groups:
     8          9          10
  Refresh Epoch 1
  200
    200.2.16.16 from 200.2.16.16 (16.16.16.16)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  100 200
    200.2.20.20 from 200.2.20.20 (20.20.20.20)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  400 200
    200.2.10.10 from 200.2.10.10 (10.10.10.10)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

R2 chooses 16 again because BGP has determined that the three paths are all the same. Since R2 previously marked the path through R16 as best, in compliance with step 10 of the best-path algorithm, R2 will not swap the best path to R10. To do so, R2 would have to first lose R2’s path in its BGP table, prompting a new evaluation for the best path, as demonstrated below:

! Shutting down the peering between R2 and R16
 
R2(config)#router bgp 312
R2(config-router)#neighbor 200.2.16.16 shutdown
 
Neighbor 200.2.16.16 reset (Admin. shutdown)
neighbor 200.2.16.16 Down Admin. Shutdown

neighbor 200.2.16.16 IPv4 Unicast topology base removed from session
Admin. Shutdown
 
! Bringing back the peering between R2 and R16
 
R2(config-router)#no neighbor 200.2.16.16 shutdown
%BGP-5-ADJCHANGE: neighbor 200.2.16.16 Up
 
 
R2#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 27
Paths: (4 available, best #4, table default)
  Advertised to update-groups:
     1          2          3
  Refresh Epoch 1
  200
    200.2.16.16 from 200.2.16.16 (16.16.16.16)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  (336) 400 200
    3.3.3.3 (metric 11) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  100 200
    200.2.20.20 from 200.2.20.20 (20.20.20.20)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  400 200
    200.2.10.10 from 200.2.10.10 (10.10.10.10)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

Here, R2 shuts down its peering to R16. This causes it to lose its best path. R2 then decides between the path from R10 and the path from R20 remaining in its BGP table. The path to R10 is chosen between the two paths, but this time it isn’t due to the older route but because of step 11, covered below.

R2 skips the oldest-path comparison because when it loses its best path R16, there is no longer an existing best path in its table. As covered above, if there is no current best path, then BGP does not evaluate the oldest route.

During convergence, R2 receives a path from R3 as well. R10’s path is preferred over R3’s because R10’s path is an external path, while R3’s path is a confederation-external path. Finally, the R16 peering comes up again, and R2 receives R16’s path again. This time, because it is still ignoring AS_PATH calculations, it retains R10 as its best path because R10 is the oldest path.

So step 10 of the best-path algorithm can be put succinctly as follows: If there is already a current best path, continue using that same best path if all other attributes are equal. So, it isn’t necessarily strictly the oldest path that is always selected; rather, the oldest best path is selected.

R2:
router bgp 312
 no bgp bestpath as-path ignore
R2#clear ip bgp * soft in
R2#show ip bgp 120.18.1.1
BGP routing table entry for 120.18.1.1/32, version 31
Paths: (3 available, best #1, table default)
  Advertised to update-groups:
     1          2          3
  Refresh Epoch 2
  200
    200.2.16.16 from 200.2.16.16 (16.16.16.16)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 3
 100 200
    200.2.20.20 from 200.2.20.20 (20.20.20.20)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 3
  400 200
    200.2.10.10 from 200.2.10.10 (10.10.10.10)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

Step 11: Lowest Router ID

Step 11 in the best-path algorithm considers the router ID assigned to the BGP router. The BGP router ID is a 32-bit value that is automatically assigned to a router in the following way:

1. If a loopback address exists, the highest IP address of a loopback on the router is used as the BGP router ID

2. The highest IP address assigned to a non-shut physical interface is used as the BGP router ID

The administrator is also given the option to manually set the BGP router ID for better control over its value. This is accomplished using the bgp router-id command in BGP router configuration mode.

At this step, BGP prefers the path that was learned from the router with the lower BGP router ID. There isn’t much to this particular preference. It is a mostly arbitrary decision—with some interesting caveats. First, to demonstrate the functionality, R12’s 120.18.1.1/32 prefix is examined below:

R12#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 74
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  200, (Received from a RR-client)
    9.9.9.9 (metric 11) from 9.9.9.9 (9.9.9.9)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  200, (Received from a RR-client)
    10.10.10.10 (metric 11) from 10.10.10.10 (10.10.10.10)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0

R12 receives two paths to reach this particular prefix: one from R9 with router ID 9.9.9.9 and one from R10 with router ID 10.10.10.10. R12 decides to choose the path with the lower RID as its best path. To prove that lower router ID is the deciding factor, R10’s router ID is modified into something lower than R9’s in the following configuration:

R10(config)#router bgp 400
R10(config-router)#bgp router-id 1.1.1.10

%BGP-5-ADJCHANGE: neighbor 9.9.9.9 Down Router ID changed
%BGP_SESSION-5-ADJCHANGE: neighbor 9.9.9.9 IPv4 Unicast topology base
removed from session  Router ID changed

Changing the router ID on R10 causes R10 to reset all of its BGP sessions. As a result, R12 now chooses the path through R10 as the best path because of its lower BGP router ID.

R12#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 86
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  200, (Received from a RR-client)
    10.10.10.10 (metric 11) from 10.10.10.10 (1.1.1.10)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  200, (Received from a RR-client)
    9.9.9.9 (metric 11) from 9.9.9.9 (9.9.9.9)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0

There are two caveats to how this particular step is processed, both having to do with paths with route reflector attributes attached to them. Route reflectors are an iBGP scaling mechanism whereby a router is designated as a route reflector. The route reflector is statically configured with a set of route reflector clients. When advertising routes to its clients, the route reflector is allowed to relax the iBGP split-horizon rules and advertise internal paths to each of its clients.

When the route reflector reflects a path, it adds attributes to the paths in the UPDATE messages sent to its clients. The two most important attributes are Originator ID and Cluster List. The route reflector keeps track of which BGP router originally advertised a path to the route reflector. This attribute is important in preventing loops. If a client receives a path with its own BGP router ID in the Originator ID attribute, it will reject the path, preventing loops. This can be seen in the following capture of the UPDATE packet R12 sends to R11:

Internet Protocol Version 4, Src: 12.12.12.12, Dst: 11.11.11.11
Transmission Control Protocol, Src Port: 36963, Dst Port: 179,
Seq: 115, Ack: 218, Len: 242
Border Gateway Protocol - UPDATE Message
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 81
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 48
    Path attributes
        Path Attribute - ORIGIN: IGP
        Path Attribute - AS_PATH: 200
        Path Attribute - NEXT_HOP: 10.10.10.10
        Path Attribute - MULTI_EXIT_DISC: 0
        Path Attribute - LOCAL_PREF: 100
        Path Attribute - CLUSTER_LIST: 12.12.12.12
        Path Attribute - ORIGINATOR_ID: 1.1.1.10
    Network Layer Reachability Information (NLRI)
        120.18.1.1/32
        120.18.2.1/32

In the UPDATE message above, R12, having selected the path through R10 with new RID 1.1.1.10 as the best path, reflects that path in its BGP UPDATE message to R11. Within the UPDATE message, R12 has added the Cluster List and Originator ID attributes. In this case, Originator ID is given the value of R10’s RID 1.1.1.10 because R10 was the originator of the path. Cluster List, on the other hand, lists R12’s RID because R12 is a route reflector participating in the route reflector cluster 12.12.12.12.

The Cluster List attribute keeps track of how many route reflector clusters the path has traversed. Multiple route reflectors may exist together in larger iBGP environments. Route reflectors identify themselves using the cluster ID. The cluster ID designates which route reflectors service the same clients and helps prevent loops within the route reflector environment. When a route reflector reflects a path, it adds its own cluster ID to the Cluster Length attribute. Route reflectors will not accept paths with the local cluster ID in the Cluster List attribute.

When processing step 11 of the best-path algorithm, if one of the paths contains route reflector attributes, the Originator ID attribute is used instead of the router ID as the comparison value. The 120.18.1.1 prefix on R11 helps you understand how this comparison works. Before examining the BGP table, first, the competing paths from R10 and R12 need to tie in all steps through step 10. Without modification, R11 will choose the path through R10 because of its lower metric to the next hop. To engineer the tie condition, the ip ospf cost 20 command is issued on the VLAN 1011 interface on R11 to even out the metrics. In addition, R10’s BGP RID is set back to 10.10.10.10:

R10(config)#router bgp 400
R10(config-router)#bgp router-id 10.10.10.10
 

R11(config)#interface e0/0.1011
R11(config-subif)#ip ospf cost 20
 
R11#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 24
Paths: (3 available, best #2, table default)
  Advertised to update-groups:
     1          3
  Refresh Epoch 1
  300 200
    200.6.11.6 from 200.6.11.6 (6.6.6.6)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  200
    9.9.9.9 (metric 21) from 12.12.12.12 (12.12.12.12)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 9.9.9.9, Cluster list: 12.12.12.12
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  200
    10.10.10.10 (metric 21) from 10.10.10.10 (10.10.10.10)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0

Now that the metrics tie, R11 is left to use the lower router ID to determine the best path. In the output above, it seems that R11 has incorrectly chosen R12’s path with RID 12.12.12.12 rather than R10’s path with router ID 10.10.10.10. This is not the case. The path received from R12 has route reflector attributes. Instead of comparing R12’s router ID 12.12.12.12 with R10’s RID 10.10.10.10, R11 compares the Originator ID value 9.9.9.9. The Originator ID value 9.9.9.9 is lower than the router ID 10.10.10.10, and R11 chooses R12’s path over R10’s, as expected.

This decision-making process is outlined in Section 9 of RFC 4456:

R11(config)#interface e0/0.1011
R11(config-subif)#no ip ospf cost 20

R14(config)#interface e0/0.1114
R14(config-subif)#ip ospf cost 20
 
R14#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 88
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 1
  200
    10.10.10.10 (metric 31) from 11.11.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 10.10.10.10, Cluster list: 11.11.11.11
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  200
    9.9.9.9 (metric 31) from 13.13.13.13 (13.13.13.13)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 9.9.9.9, Cluster list: 13.13.13.13, 12.12.12.12
      rx pathid: 0, tx pathid: 0x0

R17#show ip bgp 140.15.1.1

BGP routing table entry for 140.15.1.1/32, version 24
BGP Bestpath: compare-routerid
Paths: (1 available, best #1, table default)
Flag: 0x820
  Advertised to update-groups: (Pending Update Generation)
     2          3
  Refresh Epoch 2
  400
    200.10.17.10 from 200.10.17.10 (10.10.10.10)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

R17(config-router)#no neighbor 200.9.17.9 shutdown
 
R17#show ip bgp 140.15.1.1
 
BGP routing table entry for 140.15.1.1/32, version 26
BGP Bestpath: compare-routerid
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     2          3
  Refresh Epoch 1
  400
    200.9.17.9 from 200.9.17.9 (9.9.9.9)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  400
    200.10.17.10 from 200.10.17.10 (10.10.10.10)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

Step 12: Minimum Cluster List Length

This next step in the BGP best-path algorithm provides another tie-breaker mechanism for paths with route reflector attributes. In step 11, the originator IDs of the two paths were compared, with preference given to the lower value. If the two originator IDs tie, then this step considers the Cluster Length attribute. The idea here is that because Cluster Length value is a collection of route reflector clusters that the path has traversed, comparing this value can determine which path traveled the furthest from its originator to the local router. At this step, BGP prefers the path with the lower Cluster Length value.

As an example, we can examine R14’s BGP table for the 120.18.1.1/32 prefix:

R14#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 62
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  200
    10.10.10.10 (metric 21) from 11.11.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 10.10.10.10, Cluster list: 11.11.11.11
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  200
    9.9.9.9 (metric 31) from 13.13.13.13 (13.13.13.13)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 9.9.9.9, Cluster list: 13.13.13.13, 12.12.12.12
      rx pathid: 0, tx pathid: 0

As it stands now, R14 has two paths for the 120.18.1.1 prefix: one from the route reflector R11 and the other from the route reflector R13. Without intervention, the originator IDs are different. To test the impacts of this step, the originator IDs need to tie.

To engineer this tie, R12 needs to prefer the path it learns from R10 over the path learned from R9. Lowering R10’s router ID to 1.10.10.10 accomplishes this goal:

R10(config)#router bgp 400
R10(config-router)#bgp router-id 1.10.10.10

After you make the changes on R10, R12 properly selects the path from R10 as best and advertises the new path to R13 instead of advertising the path it received from R9:

R12#show ip bgp 120.18.1.1
BGP routing table entry for 120.18.1.1/32, version 86
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  200, (Received from a RR-client)
    10.10.10.10 (metric 11) from 10.10.10.10 (1.10.10.10)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 3
  200, (Received from a RR-client)
    9.9.9.9 (metric 11) from 9.9.9.9 (9.9.9.9)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0 

R12 advertises this best path to R13, which in turn advertises it to R14. The results are shown below. R14 receives two paths that both have the originator ID set to 1.10.10.10. Recall that Originator ID is a BGP attribute that is created by the route reflector that carries the router ID of the originator of the route, which is 1.10.10.10 in this case.

R14#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 72
Paths: (2 available, best #1, table default)
  Not advertised to any peer

  Refresh Epoch 1
  200
    10.10.10.10 (metric 21) from 11.11.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 1.10.10.10, Cluster list: 11.11.11.11
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  200
    10.10.10.10 (metric 21) from 13.13.13.13 (13.13.13.13)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.10.10.10, Cluster list: 13.13.13.13, 12.12.12.12
      rx pathid: 0, tx pathid: 0

When R14 processes the two paths, the Originator ID values for the two paths tie. R14 falls to step 12 of the best-path algorithm and compares the Cluster Length attributes of the two paths. The path received from R11 has a smaller Cluster Length value, and so R11 is the best path.

R11#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 18
Paths: (3 available, best #1, table default)
  Advertised to update-groups:
     1          2
  Refresh Epoch 1
  200
    10.10.10.10 (metric 11) from 10.10.10.10 (1.10.10.10)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  200
    10.10.10.10 (metric 11) from 12.12.12.12 (12.12.12.12)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.10.10.10, Cluster list: 12.12.12.12
      rx pathid: 0, tx pathid: 0

  Refresh Epoch 1
  300 200
    200.6.11.6 from 200.6.11.6 (6.6.6.6)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

Step 13: Lowest Neighbor Address

The final factor in deciding a best path between two different paths is the neighbor peering address. At this stage, all other attributes have tied, and an arbitrary decision needs to be made in order for the router to select a best path. This arbitrary decision examines the peering address over which the path was learned. The path that was learned from a neighbor with the lowest peering address is considered the best path.

To see this, we once again examine AS 400. R14 receives two paths to reach the 120.18.1.1/32 prefix:

R14#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 6
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 1
  200
    9.9.9.9 (metric 31) from 13.13.13.13 (13.13.13.13)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 9.9.9.9, Cluster list: 13.13.13.13, 12.12.12.12
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  200
    10.10.10.10 (metric 21) from 11.11.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 10.10.10.10, Cluster list: 11.11.11.11
      rx pathid: 0, tx pathid: 0x0

R14 chooses the path from R11 as best because it has a lower metric to the next hop 10.10.10.10. To properly examine the processing of the final step in the BGP best-path algorithm, the two paths R14 receives need to tie for all attributes.

One way to accomplish this is to simply ensure that both paths use the same next hop. This way, the metric to the next hop will be the same for both prefixes. Care must also be taken to ensure that the Originator ID and Cluster Length attributes tie as well. These modifications must happen to the path R11 chooses to send to R14.

R11 receives two paths to reach the 120.18.1.1/32 prefix. Without intervention, R11 chooses the path from R10 with next hop 10.10.10.10 to reach the prefix shown below:

R11#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 6
Paths: (3 available, best #1, table default)
  Advertised to update-groups:
     1          3
  Refresh Epoch 1

  200
    10.10.10.10 (metric 11) from 10.10.10.10 (10.10.10.10)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  200
    9.9.9.9 (metric 21) from 12.12.12.12 (12.12.12.12)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 9.9.9.9, Cluster list: 12.12.12.12
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  300 200
    200.6.11.6 from 200.6.11.6 (6.6.6.6)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

R11 receives a path with next hop of 9.9.9.9 (in red) and originator ID of 9.9.9.9 (in green). The path also contains a single cluster ID in the Cluster Length attribute (in purple). These features make R11’s path from R12 a prime candidate for being advertised to R14.

R11 needs to choose the path from R12 as its best path. It currently chooses the path from R10 as best due to the lower metric to the next hop. If this metric ties between the paths received from R10 and R12, processing will shift to the lower router ID. This is desirable as the path received from R9 has route reflector attributes, meaning the originator ID will be compared with the router ID of the path received from R10. The originator ID 9.9.9.9 is lower than the router ID 10.10.10.10, making the path received from R9 the best path.

To engineer this decision, the OSPF cost on the e0/0.1011 interface of R11 is increased to 30:

R11(config)#interface e0/0.1011
R11(config-subif)#ip ospf cost 30

Now, R11’s cost to reach 10.10.10.10 through R10 increases to 31. OSPF chooses to install the route through R12 to reach the next hop with a metric of 21 instead, lowering the BGP metric to the next hop attribute to tie with the path received from R9:

R11#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 16
Paths: (3 available, best #2, table default)

  Advertised to update-groups:
     1          3
  Refresh Epoch 1
  200
    10.10.10.10 (metric 21) from 10.10.10.10 (10.10.10.10)
      Origin IGP, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  200
    9.9.9.9 (metric 21) from 12.12.12.12 (12.12.12.12)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 9.9.9.9, Cluster list: 12.12.12.12
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  300 200
    200.6.11.6 from 200.6.11.6 (6.6.6.6)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

In the above, R10’s path is compared against R9’s path. Because the metrics tie, lower Router ID is the deciding tie breaker. R9’s path is chosen as best over R10 because the Originator ID attribute (9.9.9.9) is lower than R10’s RID 10.10.10.10. R11 then compares R9’s path against R6’s. R6’s path has a longer AS_PATH length and R11 correctly chooses the path through R9 as best.

R11 will advertise this path to R14 as well. Below, R14’s BGP table now has two completely equal paths to reach 120.18.1.1/32. All attributes tie up through the Cluster Length attribute.

R14#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 78
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  200
    9.9.9.9 (metric 31) from 11.11.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 9.9.9.9, Cluster list: 11.11.11.11, 12.12.12.12
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  200

    9.9.9.9 (metric 31) from 13.13.13.13 (13.13.13.13)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 9.9.9.9, Cluster list: 13.13.13.13, 12.12.12.12
      rx pathid: 0, tx pathid: 0

With all attributes tied, processing shifts to the lowest neighbor IP address. In this case, the path from R11 is chosen as best. To prove this decision, the peering address between R14 and R11 is modified in the following steps:

1. A loopback interface is added to R11 with IP address 20.20.20.20/32 and is advertised into OSPF.

2. R11’s neighbor command for its peering to R14 is modified to source its OPEN messages with the new loopback interface’s address (20.20.20.20).

3. R14’s peering to R11’s 11.11.11.11 address is shut down, and a new peering is created to R11’s new 20.20.20.20 address.

These modifications are shown below, in sequence. After the peering to R11 comes up fully, R14 again receives identical paths to reach the 120.18.1.1/32 network. This time, because the peering address to R11 is now 20.20.20.20, when evaluating step 13 of the best-path algorithm, R14 chooses the path through R13 as its best path because the peering address with R13 is now the lowest.

R11(config)#interface lo20
R11(config-if)#ip address 20.20.20.20 255.255.255.255
R11(config-if)#ip ospf 1 area 0
 
R11(config)#router bgp 400
R11(config-router)#neighbor 14.14.14.14 update-source lo20

R14(config)#router bgp 400
R14(config-router)#neighbor 11.11.11.11 shutdown
R14(config-router)#neighbor 20.20.20.20 remote 400

%BGP-5-ADJCHANGE: neighbor 20.20.20.20 Up

R14#show ip bgp 120.18.1.1
 
BGP routing table entry for 120.18.1.1/32, version 84
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 1
  200
    9.9.9.9 (metric 31) from 20.20.20.20 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 9.9.9.9, Cluster list: 11.11.11.11, 12.12.12.12
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  200
    9.9.9.9 (metric 31) from 13.13.13.13 (13.13.13.13)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 9.9.9.9, Cluster list: 13.13.13.13, 12.12.12.12
      rx pathid: 0, tx pathid: 0x0