CCNP Route - BGP part 5: BGP path control

 - CCNP Route - BGP part 1: Internet Connectivity
 - CCNP Route - BGP part 2: BGP Intro
 - CCNP Route - BGP part 3: eBGP
 - CCNP Route - BGP part 4: iBGP
 - CCNP Route - BGP part 5: BGP path control
 - CCNP Route - BGP part 6: Case Studies, Labs, FAQs

BGP Traffic Engineering
Traffic Out: how we decide to route out traffic to other ASNs (more easy to do as we can control BGP Best Path)
 - Local_Pref
 - AS_Path Length
 - Lower Origin Type
 - Lowest MED  (only compared if first AS is SAM with multiple  connections)
 - Prefer eBGP over iBGP
 - Lower IGP Metric
 - Oldest route

Traffic In: how other decide to route their traffic to our ASN (Much harder)
 - trick others Best Path calculations
 - you do not administrate origin party router

 - Shortest prefix length ( is better than
 - AS_Path prepending
 - Set Outbound Communinties: Depending on your upstream ISP, incoming routes may be "colored" with several communities.
   3 Well-known communities:
   no-export (0xFFFFFF01) - Don't advertise this route to eBGP peers.
   no-advertise (0xFFFFFF02) - Don't advertise this route to any peers, iBGP, or eBGP.
   no-export-subconfed (0xFFFFFF03) - Advertise this route to iBGP peers with the same AS number, but not to other confederation members.
 - Lowest MED wins (many networks set MED=0 when they learn prefixes), used only between two neighboring ASes. It isn't communicated to ASes beyond the neighboring AS.
   TIP: The MED metric you see in the BGP table is never announced to eBGP neighbors. If you want a neighbor to receive a MED, you have to configure an outbound route map to set the MED for this neighbor.
 - Origin Changing (IGP>EGP>Incomplete)

BGP Path Attributes
BGP Path Attributes define facts about a particular route or path through a network (each PA defines something different about the path).
Path attributes fall into four separate categories:
1. Well-known mandatory.
2. Well-known discretionary.   (discretionary - open to choice; at one's discretion)
3. Optional transitive.
4. Optional non-transitive.

BGP implementations MUST recognize all well-known attributes. 
Some of these attributes are mandatory and MUST be included in every UPDATE message that contains NLRI.  Others are discretionary and MAY or MAY NOT be sent in a particular UPDATE message.
Once a BGP peer has updated any well-known attributes, it MUST pass these attributes to its peers in any updates it transmits.
Border Gateway Protocol 4 (BGP-4)
attribute          EBGP                    IBGP
ORIGIN             mandatory               mandatory
AS_PATH            mandatory               mandatory
NEXT_HOP           mandatory               mandatory
MULTI_EXIT_DISC    discretionary           discretionary
LOCAL_PREF         see Section 5.1.5       required         <-may not be included in BGP Updates
ATOMIC_AGGREGATE   see Section 5.1.6 and 9.1.4    <-may not be included in BGP Updates
AGGREGATOR         discretionary           discretionary
1) AS_Path (Autonomous System Path)
Used for several purposes. Lists the ASNs in the end-to-end path.
 - BGP uses the AS_Path PA as its primary loop-prevention tool: When an eBGP peer receives an Update, if its own ASN is already in the received AS_Path, then that route has already been advertised into the local ASN and should be ignored.
 - BGP best path algorithm uses the AS_Path PA to calculate the AS_Path length, which the algorithm considers as one of its many steps.
Influence route direction: Inbound (to our AS)/Outbound (from our AS)

2) Next_Hop (next-hop IP address of a route)
Lists the next-hop IP address used to reach a prefix.

BGP may advertise one of several different IP addresses as a route’s Next_Hop, depending on several factors. To support such features, BGP needs to list the Next_Hop IP address for each path (route), and BGP defines this concept in the Next_Hop PA. The best path algorithm includes a check related to the Next_Hop IP address of the route.
Influence route direction: N/A

3) Weight
A numeric value, range 0 through 2^16– 1, set by a router when receiving Updates, influencing that one router’s route for a prefix. Not advertised to any BGP peers.
Weight is not a BGP PA; it is a Cisco-proprietary feature that acts somewhat like a PA.
Influence route direction: Outbound

4) LOCAL_PREF (Local Preference)
A numeric value, range 0 through 2^32– 1, set and communicated throughout a single AS for the purpose of influencing the choice of best route for all routers in that AS.
Influence route direction: Outbound

Value implying the route was injected into BGP; I (IGP), E (EGP), or ? (incomplete information).
Influence route direction: Outbound
6) MED (Multi Exit Discriminator) (often called metric)
Set and advertised by routers in one AS, impacting the BGP decision of routers in the other AS. Smaller is better.
Influence route direction: Inbound
BGP Best-path 
IGPs choose the best route based on some very straightforward concepts:
 - RIP uses the least number of router hops between a router and the destination subnet.
 - EIGRP uses a formula based on a combination of the fastest bandwidth and least delay.
 - OSPF uses lowest cost but with that cost typically calculated based on bandwidth.

BGP uses a much more detailed process to choose the best BGP route.

BGP checks some conditions before BEST PATH algorithm take place (routers ignore paths):
1) Paths that are marked as not synchronized (show ip bgp longer-prefixes). 
 If BGP synchronization is enabled, there must be a match for the prefix in the IP routing table in order for an internal BGP (iBGP) path to be considered a valid path. BGP synchronization is enabled by default in Cisco IOS® Software. If the matching route is learned from an Open Shortest Path First (OSPF) neighbor, its OSPF router ID must match the BGP router ID of the iBGP neighbor. Most users prefer to disable synchronization with use of the no synchronization BGP subcommand.
 Note: Synchronization is disabled by default in Cisco IOS Software Release 12.2(8)T and later.

2) Paths for which the NEXT_HOP is inaccessible.
 Be sure that there is an Interior Gateway Protocol (IGP) route to the NEXT_HOP that is associated with the path.
 Paths from an external BGP (eBGP) neighbor if the local autonomous system (AS) appears in the AS_PATH.
 Such paths are denied upon ingress into the router and are not even installed in the BGP Routing Information Base (RIB). The same applies to any path that is denied by a routing policy that is implemented via access, prefix, AS_PATH, or community lists, unless you have configured neighbor soft-reconfiguration inbound for the neighbor.

3) If you enabled "bgp enforce-first-as" and the UPDATE does not contain the AS of the neighbor as the first AS number in the AS_SEQUENCE.
In this case, the router sends a notification and closes the session.

4) Paths that are marked as (received-only) in the "show ip bgp longer-prefixes" output
The policy has rejected these paths.
However, the router has stored the paths because you have configured soft-reconfiguration inbound for the neighbor that sends the path.

BGP does not consider router hops, bandwidth, or delay when choosing the best route to reach each subnet.
Instead, BGP defines several items to compare about the competing routes, in a particular order. Some of these comparisons use BGP features that can be set based on the router configuration, allowing network engineers to then influence which path BGP chooses as the best path.

This BGP best path process also requires only simple comparisons by the router to choose the best route for a prefix.

The term BGP best path algorithm refers to the process by which BGP on a single router examines the competing BGP paths (routes) in its BGP table, for a single prefix, choosing one route as the best route.

Cisco: BGP Best Path Selection Algorithm

“We Love Oranges AS Oranges Mean Pure Refreshment”
    W  Weight (Highest)
    L  LOCAL_PREF (Highest)
    O  Self Originated (Locally) routes that are advertise through the "network" or "aggregate" command or redistributed from an IGP.
    AS  AS_PATH (shortest)
    O  ORIGIN Type (IGP > EGP > Incomplete) aka Origin code
    M  MED (lowest)
    P  Paths ( eBGP > iBGP)
    R  RID (prefer lowest Router ID)

Official Guide mnemonic
BGP Decision Process Plus Mnemonic: N WLLA OMNI

Step numbers are not in BGP RFC, just for easier reference
0 N Next hop: reachable? If no route to reach Next_Hop, router cannot use this route.

Nr. Letter Better   What?   
1    W   Highest    WEIGHT is a Cisco-specific parameter. It is local to the router on which it is configured.
2    L   Highest    LOCAL_PREF   (if not set - bgp default local-preference command or have a value of 100 by default
3    L   Prefer locally originated (nexthop then iBGP/eBGP (command: network/redistribute>aggregate-address)
4    A   shortest   AS_PATH length
5    O   lowest     Origin Type:  i>e>?  (IGP=i is lower than ExteriorGatewayP(EGP=e), and EGP is lower than INCOMPLETE=?)
6    M   lowest     MED (only occurs if the first (the neighboring) AS is the same in the two paths)
7    N   Neighbor Type Prefer eBGP over iBGP paths.
8    I   lowest     Prefer the path with the lowest IGP metric to the BGP next hop.
9    Oldest (longest-known) eBGP route
10   Lowest neighbor BGP RID
11   Lowest neighbor IP address

Influencing an Enterprise’s Outbound Routes
WLLA - influence outbound
OMNI - only MED influence inbound
1) Influencing BGP Weight
Router can set the Weight either selectively, per route, using a route map, or for all routes learned from a single neighbor. The router’s best path algorithm then examines the Weight of competing routes, choosing the route with the bigger Weight.
 - Weight cannot be communicated to other neighboring BGP routers.
 - Set on inbound route Updates; influences only that one router’s choice
 - Range 0 through 65,535
 - Bigger values are better
 - 0 for learned routes, 32,768 for locally injected routes
 - config neighbor route-map(per prefix), neighbor weight (all routes learned from this neighbor)

Method 1
ip prefix-list match-181 permit
route-map set-weight-50 permit 10
  match ip address prefix-list match-181
  set weight 50
! Without clause 20, this route map would have matched all other routes with the route map’s implied deny clause
! at the end of every route-map, filtering all other
routes learned from except
route-map set-weight-50 permit 20
router bgp 11
  neighbor route-map set-weight-50 in
clear ip bgp soft
E1# show ip bgp longer-prefixes
Network Next Hop Metric LocPrf Weight Path
* 0  0 1 1811 i
*> 0 50 3 2 50 51 52 1811 i
Method 2
E1(config)# router bgp 11
E1(config-router)# neighbor weight 60
E1# clear ip bgp soft
E1# show ip bgp longer-prefixes
Network Next Hop Metric LocPrf Weight Path
*> 0  60 1 1811 i
* 0 50 3 2 50 51 52 1811 i

2) Setting the Local Preference

The BGP Local Preference (Local_Pref) PA gives the routers inside a single AS a value that they can set per-route, advertise to all iBGP routers inside the AS, so that all routers in the AS agree about which router is the best exit point for packets destined for that prefix.
By design, the Local_Pref can be set by routers as they receive eBGP routes by using an inbound route map. The routers then advertise the Local_Pref in iBGP updates. As a result, all the routers in the same AS can then make the same choice of which route is best, agreeing as to which router to use to exit the AS for each prefix.
 - Identifies the best exit point from the AS to reach a given prefix
 - Throughout the AS in which it was set; not advertised to eBGP peers
 - 0 through 4,294,967,295
 - Default 100 if neighbor is iBGP,
 - Default not set if neighbor is eBGP,  (The local preference is communicated over iBGP but not over eBGP)
 - Note: A path without LOCAL_PREF is considered to have had the value set with the bgp default local-preference command, or to have a value of 100 by default.
 - Changing the default: bgp default local-preference <0-4294967295>
 - Configuration : neighbor route-map command; in option is required for updates from an eBGP peer
 - Higher values are better

Some list a (default) value of 100, and some list nothing. As it turns out, because Updates received from eBGP peers do not include the
Local_Pref PA, IOS lists a null value for Local_Pref for eBGP-learned routes by default. 
Routers advertise their default Local_Pref value of 100 over the iBGP connections.

ip prefix-list match-184 seq 5 permit
ip prefix-list match-185 seq 5 permit
route-map set-LP-150 permit 10
match ip address prefix-list match-185
set local-preference 150
route-map set-LP-150 permit 15
match ip address prefix-list match-184
set local-preference 50
route-map set-LP-150 permit 20
router bgp 11
neighbor route-map set-LP-150 in
! The clearing of BGP neighbor I1-1 is done next, but not shown.

E1# show ip bgp longer-prefixes
Network Next Hop Metric LocPrf Weight Path
*>  0  0 1 2 50 1833 i
*>i184.0.0.0/8  0 100 0 3 2 1844 i
*  0 50 0 1 2 50 51 1844 i
*> 0 150 0 1 2 50 51 52 1855 i

# show ip bgp
Origin IGP, metric 0, localpref 150, valid, external, best
IP Routes Based on BGP Best Paths
When the BGP best path algorithm has gotten through this complexity and chosen a best route for a prefix, the router then tries to add that route to the IP routing table.

However, rather than add the BGP route to the IP routing table directly, BGP actually gives that best BGP route to another process for consideration: The IOS Routing Table Manager (RTM).

The IOS RTM chooses the best route among many competing sources. For example, routes may be learned by an IGP, BGP, or even as connected or static routes. IOS collects the best such route for each prefix and feeds those into the RTM function. The RTM then chooses the best route.
RTM uses the concept of Administrative Distance (AD) to choose the best route among these different sources.
Administrative Distance Route Type
0   connected
1   static (ip/interface)
5   EIGRP summary route
20 eBGP
90 EIGRP internal
100 IGRP
110 OSPF
115 IS-IS
120 RIP
160 ODR (On-Demand-Routing)
170 EIGRP external
200 iBGP
255 unreachable
For the most part, an Enterprise router should not see cases in which a prefix learned with BGP has also been learned as a connected or IGP-learned route. (Conversely, these issues occur more often when implementing MPLS VPNs with BGP/IGP redistribution).

However, it can happen, and when it does, the show ip bgp rib-failures command can be helpful. This command lists routes for which BGP has chosen the route as best, but the RTM function has not placed the route into the Routing Information Base (RIB), which is simply another name for the IP routing table.

Example of a BGP RIB Failure
A route for leaks into the OSPF topology database.

E1 ----eBGP----     <-  AS1 (      ---eBGP---   AS10 (
E2 ---eBGP----    <- AS3 (      ---eBGP---   AS10 (

E1# show ip route longer-prefixes
   B [20/0] via, 00:25:11
! Before leaking, E2 had chosen its iBGP route as its best route for
E2# show ip route longer-prefixes
   O [110/2] via, 00:15:44, FastEthernet0/0
E2# show ip bgp rib-failure
  Network Next Hop RIB-failure RIB-NH Matches Higher admin distance n/a
E2 currently lists its iBGP route through E1 as its current best BGP route for because of the higher Local_Pref configured in Example 15-6. However, after giving this route to the RTM, RTM instead choose the lower-AD OSPF route (AD 110) rather than
the higher-AD iBGP route (AD 200).

BGP and the maximum-paths
Like the IGP protocols, BGP supports the maximum-paths <number-of-paths> subcommand, but BGP uses significantly different logic than the IGPs. Unlike the IGP routing protocols, BGP truly needs to pick one route, and only one route, as the best path for a given prefix/length. In effect, the BGP best path algorithm already breaks the ties for “best” route for each prefix, so from BGP’s perspective, one route for each prefix is always best.

BGP does allow multiple BGP routes for a prefix to be considered to tie, at least for the purpose of adding multiple routes to the IP routing table.

If the BGP best path algorithm does not choose a best path by Step 8 (  I   lowest     Prefer the path with the lowest IGP metric to the BGP next hop.), the routes which still tie for being best path through Step 8 will be allowed into the IP routing table, up to the number defined by the BGP maximum-paths number-of-paths router subcommand.

BGP, by default, will install only one best path in the routing table.
The maximum-paths ibgp command is used to configure equal-cost or unequal-cost multipath load sharing for iBGP peering sessions.
The BGP routing process will still advertise a best path to iBGP peers when iBGP multipath load sharing is configured.
For equal-cost routes, the path from the neighbor with the lowest router ID is advertised as the best path.
To configure BGP equal-cost multipath load sharing, all path attributes must be the same: Weight, Local_Pref, AS_path, origin code, MED, and IGP distance. 

Increasing the Length of the AS_Path Using AS_Path Prepend
The length of the AS_Path may appear to be obvious: Just add the number of ASNs listed in the AS_Path. However, some BGP features outside the scope of this book actually impact the AS_Path length calculation as well.
The AS_Path prepend tool gives engineers a means to increase the length of an AS_Path by adding ASNs to the AS_Path, while not impacting the loop prevention role of the AS_Path PA. By increasing the length of an AS_Path, a route is less likely to become the best route.
Use an inbound route map, using the set as-path prepend 3 3 command to add the two ASNs.
route-map add-two-asns permit 10
  set as-path prepend 3 3
router bgp 11
  neighbor route-map add-two-asns in
E2# show ip bgp longer-prefixes
*>i    0 100    0 1 1811 i
*               0 0    3 3 3 2 50 51 52  1811 i
Note: When using AS_Path prepending, do not prepend just any ASN. BGP still uses the AS_Path for loop avoidance, so:
 - using an ASN already in the AS_Path, like the ASN of the most recently added ASN (for example, ASN 3 in this case),
 - the local ASN (for example, ASN 11 in this case), makes the most sense.
Although presented here as a tool for influencing outbound routes, As_Path prepending can also be used to influence the inbound routes as well.

Influencing an Enterprise’s Inbound Routes with MED

An Enterprise has reasonably good control over its outbound IP routes. The engineers can configure BGP to set and react to Weight, Local_Pref, and AS_Path length, manipulating each to choose a different outgoing link or different router through which to forward packets to the Internet.
An Enterprise has much less control over inbound routes: routes for packets coming back toward the Enterprise.
Inbound routes exist on routers that the Enterprise does not own.

 - Smaller is better.
 - Default = 0
 - Allows an AS to tell a neighboring AS the best way to forward packets into the first AS.
 - Advertised by one AS into another, propagated inside the AS, but not sent to any other autonomous systems.
 - 0 through 4,294,967,295
 - config: neighbor route-map out command, using the set metric command inside the route map.

However, several tools exist that allow some control over the last ASN hop between an ISP and their Enterprise customer.
MED, originally worked for a dual-homed design (single ISP but with multiple links), later expanded to support dual-multihomed designs (2+ ASNs, 2+ links), relying on the concept that ISPs would work together.

MED Concepts
The Enterprise can announce to the ISP a value (MED) that tells the ISP which path into the Enterprise is best. As a result, the ISP can discriminate between the multiple exit points from that ISP to the Enterprise.
BGP MED Concept
Because MED lets the Enterprise ASN tell just the neighboring ASN which link into the Enterprise to use, engineers typically use MED when advertising an Enterprise’s public IP address space.

MED uses smallest-is-best logic.
1) E1 and E2 advertise, setting MED with an outbound route map, to various settings: MED 10 sent by E1 to I1-1, MED 20 sent by E1 to I1-4, and MED 30 sent by E2 to I1-4.
2) I1-1 and I1-4 have an iBGP connection, so they learn each other’s routes and agree as to which route wins based on MED.
3) I1-1 and I4-1 also tell the other routers inside ISP1, causing all inbound traffic to funnel toward router I1-1.

route-map set-med-to-I1-1 permit 10
  match ip address prefix only-public
  set metric 10
route-map set-med-to-I1-4 permit 10
  match ip address prefix only-public
  set metric 20
ip prefix-list only-public permit
router bgp 11
  neighbor route-map set-med-I1-1 out
  neighbor route-map set-med-I1-4 out
I1-1# show ip bgp
    Origin IGP, metric 10, localpref 100, valid, external, atomic-aggregate, best
I1-1# sh ip bgp longer-prefixes
  Network Next Hop Metric LocPrf Weight Path
  *>         10    0    11 i
I1-1# show ip route longer-prefixes
  B [20/10] via, 00:02:18
The MED attribute is a hint to external neighbors about the path preference into an AS. The attribute provides a dynamic way to influence another AS in the way to reach a certain route when there are multiple entry points into that AS. A lower metric value is preferred more.
Unlike local preference, metric is exchanged between ASs. A metric is carried into an AS but does not leave the AS. When an update enters the AS with a certain metric, that metric is used to make decisions inside the AS. When the same update passes on to a third AS, that metric returns to 0. The diagram in this section shows the set of metric. The metric default value is 0.
Unless a router receives other directions, the router compares metrics for paths from neighbors in the same AS.
In order for the router to compare metrics from neighbors that come from different ASs, you need to issue the special configuration command bgp always-compare-med on the router.