Selecting the Best Path
BGP selects only one route to a destination as the best path. When multiple routes to a given destination exist, BGP must determine which of these routes is the best. BGP puts the best path in its routing table and advertises that path to its BGP neighbors.
If only one route exists to a particular destination, BGP installs that route. If multiple routes exist for a destination, BGP uses tie-breaking rules to decide which one of the routes to install in the BGP routing table.
The BGP Path Decision Algorithm
BGP determines the best path to each destination for a BGP speaker by comparing path attributes according to the following selection sequence:
- Select a path with a reachable next hop.
- Select the path with the highest weight.
- If path weights are the same, select the path with the highest local preference value.
- Prefer locally originated routes (network routes, redistributed routes, or aggregated routes) over received routes.
- Select the route with the shortest AS-path length.
- If all paths have the same AS-path length, select the path based on origin: IGP is preferred over EGP; EGP is preferred over Incomplete.
- If the origins are the same, select the path with lowest MED value.
- If the paths have the same MED values, select the path learned via EBGP over one learned via IBGP.
- Select the route with the lowest IGP cost to the next hop.
- Select the route received from the peer with the lowest BGP router ID.
The following sections discuss the attributes evaluated in the path decision process. Examples show how you might configure these attributes to influence routing decisions.
Configuring Next-Hop Processing
Routes sent by BGP speakers include the next-hop attribute. The next hop is the IP address of a node on the network that is closer to the advertised prefix. Systems that have traffic destined for the advertised prefix send the traffic to the next hop. The next hop can be the address of the BGP speaker sending the update or of a third-party node. The third-party node does not have to be a BGP speaker.
The next-hop attributes conform to the following rules:
- The next hop for EBGP sessions is the IP address of the peer that advertised the route.
- The next hop for IBGP sessions is one of the following:
- If the route originated inside the AS, the next hop is the IP address of the peer that advertised the route.
- If the route originated outside the AS—that is, it was injected into the AS via an EBGP session—the next hop is the IP address of the external BGP speaker that advertised the route.
- For routes advertised on multiaccess media—such as Frame Relay, ATM, or Ethernet—the next hop is the IP address of the originating router's interface that is connected to the medium.
Next Hops
If you use the neighbor remote-as command to configure the BGP neighbors, the next hop is passed according to the rules provided above when networks are advertised. Consider the network configuration shown in Figure 1-22. Router Jackson advertises 192.168.22.0/23 internally to router Memphis with a next hop of 10.2.2.1. Router Jackson advertises the same network externally to router Topeka with a next hop of 10.1.13.1.
Router Memphis advertises 172.24.160/19 with a next hop of 10.2.2.2 to router Jackson. Router Jackson advertises this same network externally to router Topeka with a next hop of 10.1.13.1.
Router Topeka advertises network 192.168.32.0/19 with a next hop of 10.1.13.2 to router Jackson. Because this network originates outside AS 604, router Jackson then internally advertises this network (192.168.32.0/19) to router Memphis with the same next hop, 10.1.13.2 (the IP address of the external BGP speaker that advertised the route).
When router Memphis has traffic destined for 192.168.32.0/19, it must be able to reach the next hop via an IGP, because it has no direct connection to 10.1.13.2. Otherwise, router Memphis will drop packets destined for 192.168.32.0/19 because the next-hop address is not accessible. Router Memphis does a lookup in its IP routing table to determine how to reach 10.1.13.2:
The next hop is reachable via router Jackson, and the traffic can be forwarded.
The following commands configure the routers as shown in Figure 1-22:
host1(config)#router bgp 604
host1(config-router)#neighbor 10.1.13.2 remote-as 25
host1(config-router)#neighbor 10.2.2.2 remote-as 604
host1(config-router)#network 192.168.22.0 mask 255.255.254.0
host2(config)#router bgp 604
host2(config-router)#neighbor 10.2.2.1 remote-as 604
host2(config-router)#network 172.24.160.0 mask 255.255.224.0
host3(config)#router bgp 25
host3(config-router)#neighbor 10.1.13.1 remote-as 604
host3(config-router)#network 172.31.64.0 mask 255.255.192.0
Additional configuration is required for routers Biloxi, Memphis, and Jackson; the details depend on the IGP running in AS 604.
neighbor remote-as
- Use to add an entry to the BGP neighbor table.
- Specifying a neighbor with an AS number that matches the AS number specified in the router bgp command identifies the neighbor as internal to the local AS. Otherwise, the neighbor is considered external.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
- This command takes effect immediately.
- Use the no version to remove an entry from the table.
Next-Hop-Self
In some circumstances, using a third-party next hop causes routing problems. These configurations typically involve nonbroadcast multiaccess (NBMA) media.To better understand this situation, first consider a broadcast multiaccess (BMA) media network, as shown in Figure 1-23.
Routers Toledo, Madrid, and Barcelona are all on the same Ethernet network, which has a prefix of 10.19.7.0/24. When router Toledo advertises prefix 192.168.22.0/23 to router Madrid, it sets the next-hop attribute to 10.19.7.5. Before router Madrid advertises this prefix to router Barcelona, it sees that its own IP address, 10.19.7.7, is on the same subnet as the next hop for the advertised prefix. If router Barcelona can reach router Madrid, then it should be able to reach router Toledo. Router Madrid therefore advertises 192.168.22.0/23 to router Barcelona with a next-hop attribute of 10.19.7.5.
Now consider Figure 1-24, which shows the same routers on a Frame Relay—NBMA—network.
Routers Toledo and Madrid are EBGP peers, as are routers Madrid and Barcelona. When router Toledo advertises prefix 192.168.22.0/23 to router Madrid, router Madrid makes the same comparison as in the BMA example, and leaves the next-hop attribute intact when it advertises the prefix to router Barcelona. However, router Barcelona will not be able to forward traffic to 192.168.22.0/23, because it does not have a direct PVC connection to router Toledo and cannot reach the next hop of 10.19.7.5.
You can use the neighbor next-hop-self command to correct this routing problem. If you use this command to configure router Madrid, the third-party next hop advertised by router Toledo is not advertised to router Barcelona. Instead, router Madrid advertises 192.168.22.0/23 with the next-hop attribute set to its own IP address, 10.19.7.7. Router Barcelona now forwards traffic destined for 192.168.22.0/23 to the next hop, 10.19.7.7. router Madrid then passes the traffic along to router Toledo.
To disable third-party next-hop processing, configure router Madrid as follows:
host1(config)#router bgp 319
host1(config-router)#neighbor 10.19.7.8 remote-as 211
host1(config-router)#neighbor 10.19.7.8 next-hop-self
neighbor next-hop-self
- Use to prevent third-party next hops from being used on NBMA media such as Frame Relay. This command is useful in nonmeshed networks such as Frame Relay or where BGP neighbors may not have direct access to the same IP subnet.
- Forces the BGP speaker to report itself as the next hop for an advertised route it learned from a neighbor.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override the characteristic for a specific member of the peer group.
- New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command.
To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
- Use the no version to disable this feature (and therefore enable next-hop processing of BGP updates). Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
Assigning a Weight to a Route
You can assign a weight to a route when more than one route exists to the same destination. A weight indicates a preference for that particular route over the other routes to that destination. The higher the assigned weight, the more preferred the route. By default, the route weight is 32768 for paths originated by the router, and 0 for other paths.
In the configuration shown in Figure 1-25, routers Boston and NY both learn about network 192.68.5.0/24 from AS 200. Routers Boston and NY both propagate the route to router LA. Router LA now has two routes for reaching 192.68.5.0/24 and must decide the appropriate route. If you prefer that router LA direct traffic through router Boston, you can configure router LA so that the weight of routes coming from router Boston are higher—more preferred—than the routes coming from router NY. Router LA subsequently prefers routes received from router Boston and therefore uses router Boston as the next hop to reach network 192.68.5.0/24.
You can use any of the following three ways to set the weights in routes coming in from router Boston:
Using the neighbor weight Command
The following commands assign a weight of 1000 to all routes router LA receives from AS 100 and assign a weight of 500 to all routes router LA receives from AS 300:
host1(config)#router bgp 400
host1(config-router)#neighbor 10.5.5.1 remote-as 100
host1(config-router)#neighbor 10.5.5.1 weight 1000
host1(config-router)#neighbor 10.72.4.2 remote-as 300
host1(config-router)#neighbor 10.72.4.2 weight 500
Router LA sends traffic through router Boston in preference to router NY.
Using a Route Map
A route map instance is a set of conditions with an assigned number. The number after the permit keyword designates an instance of a route map. For example, instance 10 of route map 10 begins with the following:
host1(config)#route-map 10 permit 10
In the following commands to configure router LA, instance 10 of route map 10 assigns a weight of 1000 to any routes from AS 100. Instance 20 assigns a weight of 500 to routes from any other AS.
host1(config)#router bgp 400
host1(config-router)#neighbor 10.5.5.1 remote-as 100
host1(config-router)#neighbor 10.5.5.1 route-map 10 in
host1(config-router)#neighbor 10.72.4.2 remote-as 300
host1(config-router)#neighbor 10.72.4.2 route-map 20 in
host1(config-router)#exit
host1(config)#route-map 10
host1(config-route-map)#set weight 1000
host1(config-route-map)#route-map 20
host1(config-route-map)#set weight 500
See ERX Routing Protocols Configuration Guide, Vol. 1, Chapter 1, Configuring Routing Policy for more information on using route maps.
Using an AS-Path Access List
The following commands assign weights to routes filtered by AS-path access lists on router LA:
host1(config)#router bgp 400
host1(config-router)#neighbor 10.5.5.1 remote-as 100
host1(config-router)#neighbor 10.5.5.1 filter-list 1 weight 1000
host1(config-router)#neighbor 10.72.4.2 remote-as 300
host1(config-router)#neighbor 10.72.4.2 filter-list 2 weight 500
host1(config-router)#exit
host1(config)#ip as-path access-list 1 permit ^100_
host1(config)#ip as-path access-list 2 permit ^300_
Access list 1 permits any route whose AS-path attribute begins with 100 (specified by ^). This permits routes that pass through router Boston, whether they originate in AS 100 (AS path = 100) or AS 200 (AS path = 100 200) or AS 300 (AS path = 100 200 300). Access list 2 permits any route whose AS-path attribute begins with 300. This permits routes that pass through router NY, whether they originate in AS 300 (AS path = 300) or AS 200 (AS path = 300 200) or AS 100 (AS path = 300 200 100).
The neighbor filter-list commands assign a weight attribute of 1000 to routes passing through router Boston and a weight attribute of 500 to routes passing through router NY. Regardless of the origin of the route, routes learned through router Boston are preferred.
ip as-path access-list
- Use to define a BGP access list; use the neighbor filter-list command to apply a specific access list.
- You can apply access list filters on inbound or outbound BGP routes, or both.
- You can permit or deny access for a route matching the condition(s) specified by the regular expression.
- If the regular expression matches the representation of the AS path of the route as an ASCII string, then the permit or deny condition applies.
- The AS path allows substring matching. For example, the regular expression 20 matches AS path = 20 and AS path = 100 200 300, because 20 is a substring of each path. To disable substring matching and constrain matching to only the specified attribute string, place the underscore (_) metacharacter on both sides of the string, for example _20_.
- The AS path does not contain the local AS number.
- Use the no version to remove a single access list entry if permit or deny and a path-expression are specified. Otherwise, the entire access list is removed.
neighbor filter-list
- Applies an AS-path access list to advertisements inbound from or outbound to the specified neighbor, or assigns a weight to incoming routes that match the AS-path access list.
- You can specify an optional weight value with the weight keyword to assign a relative importance to incoming routes matching the AS-path access list.
- The name of the access list is a string of up to 32 characters.
- You can apply the filter to incoming or outgoing advertisements with the in or out keywords.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer. However, you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy
- New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command.
To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
neighbor weight
- Use to assign a weight to a neighbor connection.
- All routes learned from this neighbor will have the assigned weight initially.
- The route with the highest weight will be chosen as the preferred route when multiple routes are available to a particular network.
- The weights assigned with the set weight commands in a route map override the weights assigned with the neighbor weight and neighbor filter-list commands.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
- New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command.
To apply the new policy to routes that are already present in the BGP RIB, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
See Access Lists (p 1-62) for more information on using access lists.
Configuring the Local-Pref Attribute
The local-pref attribute specifies the preferred path among multiple paths to the same destination. The preferred path is the one with the higher preference value. Local preference is used only within an AS, to select an exit point.
To configure the local preference of a BGP path, you can do one of the following:
- Use the bgp default local-preference command to set the local-preference attribute.
- Use a route map to set the local-pref attribute.
Using the bgp default local-preference Command
In Figure 1-26, AS 873 receives updates for network 192.168.5.0/24 from AS 32 and AS 17.
The following commands configure router LA:
host1(config-router)#router bgp 873
host1(config-router)#neighbor 10.72.4.2 remote-as 32
host1(config-router)#neighbor 10.2.2.4 remote-as 873
host1(config-router)#bgp default local-preference 125
The following commands configure router SanJose:
host2(config-router)#router bgp 873
host2(config-router)#neighbor 10.5.5.1 remote-as 17
host2(config-router)#neighbor 10.2.2.3 remote-as 873
host2(config-router)#bgp default local-preference 200
Router LA sets the local preference for all updates from AS 32 to 125. Router SanJose sets the local preference for all updates from AS 17 to 200. Because router LA and router SanJose exchange local preference information within AS 873, they both recognize that routes to network 192.168.5.0/24 in AS 293 have a higher local preference when they come to AS 873 from AS 17 than when they come from AS 32. As a result, both router LA and router SanJose prefer to reach this network via router Boston in AS 17.
bgp default local-preference
- Use to change the default local preference value.
- Changes apply automatically whenever BGP subsequently runs the best-path decision process for a destination prefix; that is, whenever a best route is picked for a given prefix.
To force BGP to run the decision process on routes already received, you must use the clear ip bgp command to perform an inbound soft clear or hard clear of the current BGP session.
Using a Route Map to Set the Local Preference
When you use a route map to set the local preference you have more flexibility in selecting routes for which you can set a local preference based on many criteria, including AS. In the previous section, all updates received by router SanJose were set to a local preference of 200.
Using a route map, you can specifically assign a local preference for routes from AS 17 that pass through AS 293.
The following commands configure router SanJose.
host2(config-router)#router bgp 873
host2(config-router)#neighbor 10.2.2.3 remote-as 873
host2(config-router)#neighbor 10.5.5.1 remote-as 17
host2(config-router)#neighbor 10.5.5.1 route-map 10 in
host2(config-router)#exit
host2(config)#ip as-path access-list 1 permit ^17 293$
host2(config)#route-map 10 permit 10
host2(config-route-map)#match as-path 1
host2(config-route-map)#set local-preference 200
host2(config-route-map)#exit
host2(config)#route-map 10 permit 20
Router SanJose sets the local-pref attributes to 200 for routes originating in AS 293 and passing last through AS 17. All other routes are accepted (as defined in instance 20 of the route map 10), but their local preference remains at the default value of 100, indicating a less-preferred path.
Understanding the Origin Attribute
BGP uses the origin attribute to describe how a route was learned at the origin—the point where the route was injected into BGP. The origin of the route can be one of three values:
- IGP - indicates that the route was learned via an IGP and, therefore, is internal to the originating AS. All routes advertised via the network command have an origin of IGP.
- EGP - indicates that the route was learned via an EGP.
- Incomplete - indicates that the origin of the route is unknown—that is, learned from something other than IGP or EGP. All routes advertised via the redistribute command—such as static routes—have an origin of Incomplete. An origin of Incomplete occurs when a route is redistributed into BGP.
Consider the sample topology shown in Figure 1-27. Because routers Albany and Boston are not directly connected, they learn the path to each other via an IGP (not illustrated).
The following commands configure router Boston:
host1(config)#ip route 172.31.125.100 255.255.255.252
host1(config)#router bgp 100
host1(config-router)#neighbor 10.2.25.1 remote-as 100
host1(config-router)#neighbor 10.4.4.1 remote-as 100
host1(config-router)#neighbor 10.3.3.1 remote-as 300
host1(config-router)#network 172.19.0.0
host1(config-router)#redistribute static
The following commands configure router NY:
host2(config)#router bgp 100
host2(config-router)#neighbor 10.4.4.1 remote-as 100
host2(config-router)#neighbor 10.2.25.2 remote-as 100
host2(config-router)#network 172.28.8.0 mask 255.255.248.0
The following commands configure router Albany:
host3(config)#router bgp 100
host3(config-router)#neighbor 10.4.4.2 remote-as 100
host3(config-router)#neighbor 10.2.25.2 remote-as 100
host3(config-router)#network 192.168.33.0 mask 255.255.255.0
The following commands configure router LA:
host4(config)#router bgp 300
host4(config-router)#neighbor 10.3.3.2 remote-as 100
host4(config-router)#network 192.168.204.0 mask 255.255.252.0
host4(config-router)#redistribute isis
Consider how route 172.21.10.0/23 is passed along to the routers in Figure 1-27:
- IS-IS injects route 172.21.10.0/23 from router Chicago into BGP on router LA. BGP sets the origin attribute to Incomplete (because it is a redistributed route) to indicate how BGP originally became aware of the route.
- Router Boston learns about route 172.21.10.0/23 via EBGP from router LA.
- Router NY learns about route 172.21.10.0/23 via IBGP from router Boston.
The value of the origin attribute for a given route remains the same, regardless of where you examine it. Table 1-14 shows this for all the routes known to routers NY and LA.
As a matter of routing policy, you can specify an origin for a route with a set origin clause in a redistribution route map. Changing the origin enables you to influence which of several routes for the same destination prefix is selected as the best route. In practice, changing the origin is rarely done.
Understanding the AS-path Attribute
The AS-path attribute is a list of the ASs through which a route has passed. Whenever a route enters an AS, BGP prepends the AS number to the AS-path attribute. This feature enables network operators to track routes, but it also enables the detection and prevention of routing loops.
Consider the following sequence of events for the systems shown in Figure 1-28:
- Route 172.21.10.0/23 is injected into BGP via router London in AS 47.
- Suppose router London advertises that route to router Paris in AS 621. As received by router Paris, the AS-path attribute for route 172.21.10.0/23 is 47.
- Router Paris advertises the route to router Berlin in AS 11. As received by router Berlin, the AS-path attribute for route 172.21.10.0/23 is 621 47.
- Router Berlin advertises the route to router London in AS 47. As received by router London, the AS-path attribute for route 172.21.10.0/23 is 11 621 47.
A routing loop would exist if router London accepts the route from router Berlin. Router London can choose not to accept the route from router Berlin because it recognizes from the AS-path attribute (11 621 47) that the route originated in its own AS 47.
As a matter of routing policy, you can prepend additional AS numbers to the AS-path attribute for a route with a set as-path prepend clause in an outbound route map. Changing the AS path enables you to influence which of several routes for the same destination prefix is selected as the best route.
Configuring a Local AS
You can change the local AS of a BGP peer or peer group within the current address family with the neighbor local-as command. By using different local AS numbers for different peers, you can avoid or postpone AS renumbering in the event the ASs are merged.
neighbor local-as
- Use to assign a local AS to the given BGP peer or peer group.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
- This command takes effect immediately and automatically bounces the BGP session.
- Use the no version for an individual peer to restore the value set for the peer group, if present, or set globally for BGP with the router bgp command. Use the no version for a peer group to restore the value set globally for BGP.
The following example commands change the local AS number for peer 104.4.2 from the global local AS of 100 to 32:
host1(config)#router bgp 100
host1(config-router)#address-family ipv4 unicast vrf boston
host1(config-router)#neighbor 10.4.4.2 remote-as 645
host1(config-router)#neighbor 10.4.4.2 local-as 32
Configuring the MED Attribute
If two ASs connect to each other in more than one place, one link or path might be a better choice to reach a particular prefix within or behind one of the ASs. The MED value is a metric expressing a degree of preference for a particular path. Lower MED values are preferred.
Whereas the Local Preference attribute is used only within an AS (to select an exit point), the MED attribute is exchanged between ASs. A router in one AS sends the MED to tell a router in another AS which path the second router should use to reach particular destinations. If you are the administrator of the second AS, you must therefore trust that the router in the first AS is providing information that is truly beneficial to your AS.
You configure the MED on the sending router by using the set metric command in an outbound route map. Unless configured otherwise, a receiving router compares MED attributes only for paths from external neighbors that are members of the same AS. If you want MED attributes from neighbors in different ASs to be compared, you must issue the bgp always-compare-med command.
In Figure 1-29, router London in AS 303 can reach 192.168.33.0/24 in AS 73 through router Paris or through router Nice to router Paris.
The following commands configure router London:
host1(config)#router bgp 303
host1(config-router)#neighbor 10.4.4.2 remote-as 73
host1(config-router)#neighbor 10.3.3.2 remote-as 73
host1(config-router)#neighbor 10.5.5.2 remote-as 4
host1(config-router)#network 122.28.8.0 mask 255.255.248.0
The following commands configure router Paris:
host2(config)#router bgp 73
host2(config-router)#neighbor 10.4.4.1 remote-as 303
host2(config-router)#neighbor 10.4.4.1 route-map 10 out
host2(config-router)#neighbor 10.2.25.1 remote-as 73
host2(config-router)#neighbor 10.6.6.1 remote-as 4
host2(config-router)#neighbor 10.6.6.1 route-map 10 out
host2(config-router)#network 192.168.33.0 mask 255.255.255.0
host2(config-router)#exit
host2(config)#route-map 10 permit 10
host2(config-route-map)#set metric 50
The following commands configure router Nice:
host3(config)#router bgp 73
host3(config-router)#neighbor 10.3.3.1 remote-as 303
host3(config-router)#neighbor 10.3.3.1 route-map 10 out
host3(config-router)#neighbor 10.2.25.2 remote-as 73
host3(config-router)#network 172.19.0.0
host3(config-router)#exit
host3(config)#route-map 10 permit 10
host3(config-route-map)#set metric 100
The following commands configure router Dublin:
host4(config)#router bgp 4
host4(config-router)#neighbor 10.5.5.1 remote-as 303
host4(config-router)#neighbor 10.5.5.1 route-map 10 out
host4(config-router)#neighbor 10.6.6.2 remote-as 73
host4(config-router)#network 172.14.27.0 mask 255.255.255.0
host4(config-router)#exit
host4(config)#route-map 10 permit 10
host4(config-route-map)#set metric 25
Router London receives updates regarding route 192.168.33.0/24 from both router Nice and router Paris. Router London compares the MED values received from the two routers: Router Nice advertises a MED of 100 for the route, whereas router Paris advertises a MED of 50. On this basis, router London prefers the path through router Paris.
Because BGP by default compares only MED attributes of routes coming from the same AS, router London can compare only the MED attributes for route 192.168.33.0/24 that it received from routers Paris and Nice. It cannot compare the MED received from router Dublin, because router Dublin is in a different AS than routers Paris and Nice.
However, you can use the bgp always-compare-med command to configure router London to consider the MED attribute from router Dublin as follows:
host1(config)#router bgp 303
host1(config-router)#neighbor 10.4.4.2 remote-as 73
host1(config-router)#neighbor 10.3.3.2 remote-as 73
host1(config-router)#neighbor 10.5.5.2 remote-as 4
host1(config-router)#network 122.28.8.0 mask 255.255.248.0
host1(config-router)#bgp always-compare-med
Router Dublin advertises a MED of 25 for route 192.168.33.0/24, which is lower—more preferred—than the MED advertised by router Paris or router Nice. However, the AS path for the route through router Dublin is longer than that through router Paris. The AS path is the same length for router Paris and router Nice, but the MED advertised by router Paris is lower than that advertised by router Nice. Consequently, router London prefers the path through router Paris.
Suppose, however that router Dublin was not configured to set the MED for route 192.168.33.0/24 in its outbound route map 10. Would router London receive a MED of 50 passed along by router Paris through router Dublin? No, because the MED attribute is nontransitive. Router Dublin does not transmit any MED that it receives. A MED is only of value to a direct peer.
bgp always-compare-med
- Use to enable the comparison of the MED for paths from neighbors in different ASs.
- Unless you specify the bgp always-compare-med command, the router compares MED attributes only for paths from external neighbors that are in the same AS.
- The BGP path decision algorithm selects a lower MED value over a higher one.
- Unlike local preferences, the MED attribute is exchanged between ASs, but does not leave the AS.
- The value is used for decision making within the AS only.
- When BGP propagates a route received from outside the AS to another AS, it removes the MED.
- Example
host1(config-router)#bgp always-compare-med
- Changes apply automatically whenever BGP subsequently runs the best-path decision process for a destination prefix; that is, whenever a best route is picked for a given prefix.
To force BGP to run the decision process on routes already received, you must use the clear ip bgp command to perform an inbound soft clear or hard clear of the current BGP session.
set metric
- Use to set the metric value—for BGP, the MED—for a route.
- Sets an absolute metric. You cannot use both an absolute metric and a relative metric within the same route map sequence. Setting either metric overrides any previously configured value.
- Example
host1(config)#route-map nyc1 permit 10
host1(config-route-map)#set metric 10
Missing MED Values
By default, a route that arrives with no MED value is treated as if it had a MED of 0, the most preferred value. You can use the bgp bestpath missing-as-worst command to specify that a route with any MED value is always preferred to a route that is missing the MED value.
bgp bestpath missing-as-worst
- Use to set a missing MED value to infinity, the least preferred value.
- After issuing this command, a route missing the MED is always preferred less than any route that has a MED configured.
- Example
host1(config-router)#bgp bestpath missing-as-worst
- Changes apply automatically whenever BGP subsequently runs the best-path decision process for a destination prefix; that is, whenever a best route is picked for a given prefix.
To force BGP to run the decision process on routes already received, you must use the clear ip bgp command to perform an inbound soft clear or hard clear of the current BGP session.
- Use the no version to restore the default condition, where a missing MED value is set to 0, the most preferred value.
Comparing MED Values Within a Confederation
A BGP speaker within a confederation of sub-ASs might need to compare routes to determine the best path to a destination. By default, BGP does not use the MED value when comparing routes originated in different sub-ASs within the confederation to which the BGP speaker belongs. (Within the confederation, routes learned from different sub-ASs are considered to have originated in different places.) You can use the bgp bestpath med confed command to force the consideration of MED values within a confederation.
bgp bestpath med confed
- Use to specify that BGP consider the MED when comparing routes originated in different sub-ASs within the confederation to which the BGP speaker belongs.
- This command does not affect the comparison of routes that are originated in other ASs and does not affect the comparison of routes that are originated in other confederations.
- Example
host1(config-router)#bgp bestpath med confed
- Changes apply automatically whenever BGP subsequently runs the best-path decision process for a destination prefix; that is, whenever a best route is picked for a given prefix.
To force BGP to run the decision process on routes already received, you must use the clear ip bgp command to perform an inbound soft clear or hard clear of the current BGP session.
Example
Suppose a BGP speaker has three routes to prefix 10.10.0.0/16:
- Route 1 is originated by sub-AS 1 inside the confederation.
- Route 2 is originated by sub-AS 2 inside the confederation.
- Route 3 is originated by AS 3 outside the confederation.
BGP compares these routes to each other to determine the best path to the prefix. If you have issued the bgp bestpath med confed command, BGP considers the MED when comparing Route 1 with Route 2. However, BGP does not consider the MED when comparing Route 3 with either Route 1 or Route 2, because Route 3 originates outside the confederation.
Capability Negotiation
The system accepts connections from peers that perform capability negotiation. Capabilities are negotiated using the open messages that are exchanged when the session is established. The system supports the following capabilities:
- Cisco-proprietary route refresh - capability code 128
- Cooperative route filtering- capability code 3
- Dynamic capability renegotiation - capability code 66
- Four-octet AS numbers - capability code 65
- Multiprotocol extensions - capability code 1
- address family IPv4 unicast - AFI 1 SAFI 1
- address family IPv4 multicast - AFI 1 SAFI 2
- address family IPv4 unicast and multicast - AFI 1 SAFI 3
- address family VPN-IPv4 unicast - AFI 1 SAFI 128
The system advertises these capabilities—except for the cooperative route filtering capability—by default. You can prevent the advertisement of specific capabilities with the no neighbor capability command. You can also use this command to prevent all capability negotiation with the specified peer.
Cooperative Route Filtering
The cooperative route filtering capability—also referred to as outbound route filtering (ORF)—enables a BGP speaker to send an inbound route filter to a peer and have the peer install it as an outbound filter on the remote end of the session.
You must specify both the type of inbound filter (ORF type) and the direction of ORF capability. The system currently supports prefix-lists as the inbound filter sent by the BGP speaker. The inbound filter sent by the BGP speaker can be a prefix list or a Cisco proprietary prefix list.The BGP speaker must indicate whether it will send inbound filters to peers, accept inbound filters from peers, or both. The system supports both standard and Cisco-proprietary orf messages.
Dynamic Capability Negotiation
If both peers acknowledge support of dynamic capability negotiation, then at any subsequent point after the session is established, either peer can send a capabilities message to the other indicating a desire to negotiate another capability or to remove a previously negotiated capability.
Four-Octet AS Numbers
BGP speakers that support four-octet AS and sub-AS numbers are sometimes referred to as "new" speakers. The four-octet AS numbers are employed by the AS-path and aggregator attributes. "Old" speakers are those that do not support the four-octet numbers.
Two new transitional optional attributes, new-as-path and new-aggregator, are used to carry the four-octet numbers across the old speakers. A new speaker communicating with an old speaker will send the new attributes with the four-octet numbers for locally-originated and propagated routes. The old speaker propagates the new attributes for received routes. The new speaker also sends the AS-path and aggregator attributes with two-octet numbers; any AS number greater than 65535 is replaced with a reserved AS number, 23456.
Route Refresh
If the system detects that a peer supports both Cisco-proprietary and standard route refresh messages, it will prefer to use the standard route refresh messages.
neighbor capability
- Use to control the advertisement of BGP capabilities to peers. Capability negotiation and advertisement of all capabilities is enabled by default.
- You can specify the dynamic-capability-negotiation, four-octet-as-numbers, orf, route-refresh, and route-refresh-cisco capabilities. The graceful restart capability is controlled by specific graceful-restart commands.
- If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
- You cannot configure the receive direction for the orf capability for a peer that is a member of a peer group or for a peer.
- Example
host1(config-router)#neighbor 10.6.2.5 capability orf prefix-list both
- If you issue the route-refresh or route-refresh-cisco keywords, takes effect immediately. If dynamic capability negotiation was negotiated for the session, a capability message is sent to inform the peer of the new capability configuration. If dynamic capability negotiation was not negotiated for the session, the session is bounced automatically.
- If you issue the dynamic-capability-negotiation, four-octet-as-numbers, or negotiation keywords, takes effect immediately and bounces the session.
- If you issue the orf keyword, takes effect immediately and automatically bounces the BGP session.
- Use the no version to prevent advertisement of the specified capability or use the negotiation keyword with the no version to prevent all capability negotiation with the specified peer.