Chapter 12. Advanced BGP

This chapter covers the following subjects:

BGP Multihoming: This section reviews the methods of providing resiliency through redundant BGP connections, along with desired and undesired design considerations for Internet and MPLS connections (branch and data center).

Conditional Matching: This section provides an overview of how network prefixes can be conditionally matched with ACLs, prefix lists, and regular expressions.

Route Maps: This section explains the structure of a route map and how conditional matching and conditional actions can be combined to filter or manipulate routes.

BGP Route Filtering and Manipulation: This section expands on how conditional matching and route maps work by applying real-world use cases to demonstrate the filtering or manipulation of BGP routes.

BGP Communities: This section explains the BGP well-known mandatory path attribute and how it can be used to tag a prefix to have route policies applied by routers in the same autonomous system or in an external autonomous system.

Understanding BGP Path Selection: This section describes the logic used by BGP to identify the best path when multiple routes are installed in the BGP table.

Border Gateway Protocol (BGP) can support hundreds of thousands of routes, making it the ideal choice for the Internet. Organizations also use BGP for its flexibility and traffic engineering properties. This chapter expands on Chapter 11, “Border Gateway Protocol (BGP),” explaining BGP’s advanced features and concepts involved with the BGP routing protocol, such as BGP multihoming, route filtering, BGP communities, and the logic for identifying the best path for a specific network prefix.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read the entire chapter. If you miss no more than one of these self-assessment questions, you might want to move ahead to the “Exam Preparation Tasks” section. Table 12-1 lists the major headings in this chapter and the “Do I Know This Already?” quiz questions covering the material in those headings so you can assess your knowledge of these specific areas. The answers to the “Do I Know This Already?” quiz appear in Appendix A, “Answers to the ‘Do I Know This Already?’ Quiz Questions.”

Table 12-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section

Questions

BGP Multihoming

1

Conditional Matching

2–4

Route Maps

5–6

BGP Route Filtering and Manipulation

7

BGP Communities

8

Understanding BGP Path Selection

9–10

1. Transit routing between a multihomed enterprise network and a service provider is generally not recommend in which scenarios? (Choose all that apply.)

  1. Internet connections at data centers

  2. Internet connections at branch locations

  3. MPLS data centers

  4. MPLS branch locations

2. True or false: An extended ACL used to match routes changes behavior if the routing protocol is an IGP rather than BGP.

  1. True

  2. False

3. Which network prefixes match the prefix match pattern 10.168.0.0/13 ge 24? (Choose two.)

  1. 10.168.0.0/13

  2. 10.168.0.0/24

  3. 10.173.1.0/28

  4. 10.104.0.0/24

4. What is the correct regular expression syntax for matching a route that originated in AS 300?

  1. ^300_

  2. $300!

  3. _300_

  4. _300$

5. What happens when the route map route-map QUESTION permit 20 does not contain a conditional match statement?

  1. The routes are discarded, and a syslog message is logged.

  2. All routes are discarded.

  3. All routes are accepted.

  4. An error is assigned when linking the route map to a BGP peer.

6. What happens to a route that does not match the PrefixRFC1918 prefix list when using the following route map?

route-map QUESTION deny 10
  match ip address prefix-list PrefixRFC1918
route-map QUESTION permit 20
  set metric 200
  1. The route is allowed, and the metric is set to 200.

  2. The route is denied.

  3. The route is allowed.

  4. The route is allowed, and the default metric is set to 100.

7. True or false: A BGP AS_Path ACL and a prefix list can be applied to a neighbor at the same time.

  1. True

  2. False

8. Which of the following is not a well-known BGP community?

  1. No_Advertise

  2. Internet

  3. No_Export

  4. Private_Route

9. Which of the following techniques is the second selection criterion for the BGP best path?

  1. Weight

  2. Local preference

  3. Origin

  4. MED

10. True or false: For MED to be used as a selection criterion, the routes must come from different autonomous systems.

  1. True

  2. False

Answers to the “Do I Know This Already?” quiz:

1 A, B, D

2 A

3 B, C

4 D

5 C

6 A

7 A

8 D

9 B

10 B

Foundation Topics

The Internet has become a vital component for businesses today. Internet connectivity is required for email and research at a minimum. In addition, some organizations host e-commerce servers, use Voice over IP (VoIP) telephony, or terminate VPN tunnels through private MPLS connections. An organization must incorporate redundancies in the network architecture to ensure that there are not any single points of failure (SPOF) with network connectivity to support the needs of the business.

A company can connect to the Internet with a simple default route using a single connection. However, if a company wants to use multiple service providers (SPs) for redundancy or additional throughput, BGP is required. BGP is the routing protocol used on the Internet.

A company’s use of BGP is not limited to Internet connectivity. If the company uses MPLS L3VPN from a service provider, it is probably using BGP to exchange the LAN networks with the service provider. Routes are typically redistributed between BGP and the LAN-based routing protocol. In both of these scenarios, BGP is used at the edge of the network (Internet or WAN) and has redundant connections to ensure a reliable network. It provides advanced path selection and connectivity for an organization. This chapter focuses on troubleshooting BGP edge architectures.

BGP Multihoming

The simplest method of providing redundancy is to provide a second circuit. Adding a second circuit and establishing a second BGP session across that peering link is known as BGP multihoming because there are multiple sessions to learn routes and establish connectivity. BGP’s default behavior is to advertise only the best path to the RIB, which means that only one path for a network prefix is used when forwarding network traffic to a destination.

Resiliency in Service Providers

Routing failures can occur within a service provider network, and some organizations chose to use a different SP for each circuit. A second service provider could be selected for a variety of reasons, but the choice typically comes down to cost, circuit availability for remote locations, or separation of the control plane.

By using a different SP, if one SP has problems in its network, network traffic can still flow across the other SP. In addition, adding more SPs means traffic can select an optimal path between devices due to the BGP best-path algorithm, discussed later in this chapter.

Figure 12-1 illustrates four common multihoming scenarios:

  • Scenario 1: R1 connects to R3 with the same SP. This design accounts for link failures; however, a failure on either router or within SP1’s network results in a network failure.

  • Scenario 2: R1 connects to R3 and R4 with the same SP. This design accounts for link failures; however, a failure on R1 or within SP1’s network results in a network failure.

  • Scenario 3: R1 connects to R3 and R4 with the different SPs. This design accounts for link failures and failures in either SP’s network, and it can optimize routing traffic. However, a failure on R1 results in a network failure.

  • Scenario 4: R1 and R2 form an iBGP session with each other. R3 connects to SP1, and R4 connects to SP2. This design accounts for link failures and failures in either SP’s network, and it can optimize routing traffic.

The four common BGP multi-homing scenarios are shown.

Figure 12-1 Common BGP Multihoming Scenarios

Internet Transit Routing

If an enterprise uses BGP to connect with more than one service provider, it runs the risk of its autonomous system (AS) becoming a transit AS. In Figure 12-2, AS 500 is connecting to two different service providers (SP3 and SP4) for resiliency.

A figure demonstrates enterprise transit routing.

Figure 12-2 Enterprise Transit Routing

Problems can arise if R1 and R2 use the default BGP routing policy. A user that connects to SP3 (AS 300) routes through the enterprise network (AS 500) to reach a server that attaches to SP4 (AS 400). SP3 receives the 100.64.1.0/24 prefix from AS 100 and AS 500. SP3 selects the path through AS 500 because the AS_Path is much shorter than going through SP1 and SP2’s networks.

The AS 500 network is providing transit routing to everyone on the Internet, which can saturate AS 500’s peering links. In addition to causing problems for the users in AS 500, this situation has an impact on traffic from the users that are trying to transverse AS 500.

Transit routing can be avoided by applying outbound BGP route policies that only allow for local BGP routes to be advertised to other autonomous systems. This is discussed later in this chapter, in the section “BGP Route Filtering and Manipulation.”

Branch Transit Routing

Proper network design should take traffic patterns into account to prevent suboptimal routing or routing loops. Figure 12-3 shows a multihomed design using multiple transports for all the sites. All the routers are configured so that they prefer the MPLS SP2 transport over the MPLS SP1 transport (active/passive). All the routers peer and advertise all the routes via eBGP to the SP routers. The routers do not filter any of the prefixes, and all the routers set the local preference for MPLS SP2 to a higher value to route traffic through it.

A network setup demonstrates the deterministic routing during fail-over.

Figure 12-3 Deterministic Routing

When the network is working as intended, traffic between the sites uses the preferred SP network (MPLS SP2) in both directions. This simplifies troubleshooting when the traffic flow is symmetric (same path in both directions) as opposed to asymmetric forwarding (a different path for each direction) because the full path has to be discovered in both directions. The path is considered deterministic when the flow between sites is predetermined and predictable.

During a link failure within the SP network, there is a possibility of a branch router connecting to the destination branch router through an intermediary branch router. Figure 12-4 shows the failure scenario with R41 providing transit connectivity between Site 3 and Site 5.

A network setup demonstrates the non-deterministic routing during fail-over.

Figure 12-4 Nondeterministic Routing During Failover

Unplanned transit connectivity presents the following issues:

  • The transit router’s circuits can become oversaturated because they were sized only for that site’s traffic and not the traffic crossing through them.

  • The routing patterns can become unpredictable and nondeterministic. In this scenario, traffic from R31 may flow through R41, but the return traffic may take a different return path. The path might be very different if the traffic were sourced from a different router. This prevents deterministic routing, complicates troubleshooting, and can make your NOC staff feel as if they are playing whack-a-mole when troubleshooting network issues.

Multihomed environments should be configured so that branch routers cannot act as transit routers. In most designs, transit routing of traffic from another branch is undesirable, as WAN bandwidth may not be sized accordingly. Transit routing can be avoided by configuring outbound route filtering at each branch site. In essence, the branch sites do not advertise what they learn from the WAN but advertise only networks that face the LAN. If transit behavior is required, it is restricted to the data centers or specific locations as follows:

  • Proper routing design can accommodate outages.

  • Bandwidth can be sized accordingly.

  • The routing pattern is bidirectional and predictable.

Note

Transit routing at the data center or other planned locations is normal in enterprise designs as they have accounted for the bandwidth. Typically, this is done when a portion of branches are available only with one SP, and the other branches connect with a different SP.

Conditional Matching

Applying bulk changes to routes on a neighbor-by-neighbor basis (or interface-by-interface basis for IGPs) does not easily allow for tuning of the network. This section reviews some of the common techniques used to conditionally matching a route—using access control lists (ACLs), prefix lists, regular expressions (regex), and AS path ACLs.

Access Control Lists

Originally, access control lists (ACLs) were intended to provide filtering of packets flowing into or out of a network interface, similar to the functionality of a basic firewall. Today, ACLs provide packet classification for a variety of features, such as quality of service (QoS), or for identifying networks within routing protocols.

ACLs are composed of access control entries (ACEs), which are entries in the ACL that identify the action to be taken (permit or deny) and the relevant packet classification. Packet classification starts at the top (lowest sequence) and proceeds down (higher sequence) until a matching pattern is identified. Once a match is found, the appropriate action (permit or deny) is taken, and processing stops. At the end of every ACL is an implicit deny ACE, which denies all packets that did not match earlier in the ACL.

Note

ACE placement within an ACL is important, and unintended consequences may result from ACEs being out of order.

ACLs are classified into two categories:

  • Standard ACLs: Define packets based solely on the source network.

  • Extended ACLs: Define packets based on source, destination, protocol, port, or a combination of other packet attributes. This book is concerned with routing and limits the scope of ACLs to source, destination, and protocol.

Standard ACLS use a numbered entry 1–99, 1300–1999, or a named ACL. Extended ACLs use a numbered entry 100–199, 2000–2699, or a named ACL. Named ACLs provide relevance to the functionality of the ACL, can be used with standard or extended ACLs, and are generally preferred.

Standard ACLs

The following is the process for defining a standard ACL:

Step 1. Define the ACL by using the command ip access-list standard {acl-number | acl-name} and placing the CLI in ACL configuration mode.

Step 2. Configure the specific ACE entry with the command [sequence] {permit | deny } source source-wildcard. In lieu of using source source-wildcard, the keyword any replaces 0.0.0.0 0.0.0.0, and use of the host keyword refers to a /32 IP address so that the source-wildcard can be omitted.

Table 12-2 provides sample ACL entries from within the ACL configuration mode and specifies the networks that would match with a standard ACL.

Table 12-2 Standard ACL-to-Network Entries

ACE Entry

Networks

permit any

Permits all networks

permit 172.16.0.0 0.0.255.255

Permits all networks in the 172.16.0.0 range

permit host 192.168.1.1

Permits only the 192.168.1.1/32 network

Extended ACLs

The following is the process for defining an extended ACL:

Step 1. Define the ACL by using the command ip access-list extended {acl-number | acl-name} and placing the CLI in ACL configuration mode.

Step 2. Configure the specific ACE entry with the command [sequence] {permit | deny} protocol source source-wildcard destination destination-wildcard. The behavior for selecting a network prefix with an extended ACL varies depending on whether the protocol is an IGP (EIGRP, OSPF, or IS-IS) or BGP.

IGP Network Selection

When ACLS are used for IGP network selection, the source fields of the ACL are used to identify the network, and the destination fields identify the smallest prefix length allowed in the network range. Table 12-3 provides sample ACL entries from within the ACL configuration mode and specifies the networks that would match with the extended ACL. Notice that the subtle difference in the destination wildcard for the 172.16.0.0 network affects the network ranges that are permitted in the second and third rows of the table.

Table 12-3 Extended ACL for IGP Route Selection

ACE Entry

Networks

permit ip any any

Permits all networks

permit ip host 172.16.0.0 host 255.240.0.0

Permits all networks in the 172.16.0.0/12 range

permit ip host 172.16.0.0 host 255.255.0.0

Permits all networks in the 172.16.0.0/16 range

permit host 192.168.1.1

Permits only the 192.168.1.1/32 network

BGP Network Selection

Extended ACLs react differently when matching BGP routes than when matching IGP routes. The source fields match against the network portion of the route, and the destination fields match against the network mask, as shown in Figure 12-5. Until the introduction of prefix lists, extended ACLs were the only match criteria used with BGP.

A BGP extended ACL entry is shown. It reads "permit protocol source source-wildcard destination destination-wildcard." The matching networks are "source source-wildcard" and the matching network mask are "destination destination-wildcard."

Figure 12-5 BGP Extended ACL Matches

Table 12-4 demonstrates the concept of the wildcard for the network and subnet mask.

Table 12-4 Extended ACL for BGP Route Selection

Extended ACL

Matches These Networks

permit ip 10.0.0.0 0.0.0.0 255.255.0.0 0.0.0.0

Permits only the 10.0.0.0/16 network

permit ip 10.0.0.0 0.0.255.0 255.255.255.0 0.0.0.0

Permits any 10.0.x.0 network with a /24 prefix length

permit ip 172.16.0.0 0.0.255.255 255.255.255.0 0.0.0.255

Permits any 172.16.x.x network with a /24 to /32 prefix length

permit ip 172.16.0.0 0.0.255.255 255.255.255.128 0.0.0.127

Permits any 172.16.x.x network with a /25 to /32 prefix length

Prefix Matching

Prefix lists provide another method of identifying networks in a routing protocol. A prefix list identifies a specific IP address, network, or network range and allows for the selection of multiple networks with a variety of prefix lengths by using a prefix match specification. Many network engineers prefer this over the ACL network selection method.

A prefix match specification contains two parts: a high-order bit pattern and a high-order bit count, which determines the high-order bits in the bit pattern that are to be matched. Some documentation refers to the high-order bit pattern as the address or network and the high-order bit count as the length or mask length.

In Figure 12-6, the prefix match specification has the high-order bit pattern 192.168.0.0 and the high-order bit count 16. The high-order bit pattern has been converted to binary to demonstrate where the high-order bit count lies. Because there are not additional matching length parameters included, the high-order bit count is an exact match.

A basic prefix match pattern is shown. prefix match 192.168.0.0 (high-order bit pattern (network)) / 16 (high-order bit count (length)). For prefix 192.168.0.0/16 there are 32 binary values. The first 16 binary values are high order bits (11000000 10101000) and the prefix length is 16.

Figure 12-6 Basic Prefix Match Pattern

At this point, the prefix match specification logic looks identical to the functionality of an access list. The true power and flexibility comes in using matching length parameters to identify multiple networks with specific prefix lengths with one statement. The matching length parameter options are

  • le: Less than or equal to, <=

  • ge: Greater than or equal to, >=

Figure 12-7 demonstrates the prefix match specification with the high-order bit pattern 10.168.0.0 and high-order bit count 13; the matching length of the prefix must be greater than or equal to 24.

A figure shows the prefix match specification with matching length parameters.

Figure 12-7 Prefix Match Pattern with Matching Length Parameters

The 10.168.0.0/13 prefix does not meet the matching length parameter because the prefix length is less than the minimum of 24 bits, whereas the 10.168.0.0/24 prefix does meet the matching length parameter. The 10.173.1.0/28 prefix qualifies because the first 13 bits match the high-order bit pattern, and the prefix length is within the matching length parameter. The 10.104.0.0/24 prefix does not qualify because the high-order bit pattern does not match within the high-order bit count.

Figure 12-8 demonstrates a prefix match specification with the high-order bit pattern 10.0.0.0, high-order bit count 8, and matching length between 22 and 26.

A figure shows the prefix match specification with ineligible matched prefixes.

Figure 12-8 Prefix Match with Ineligible Matched Prefixes

The 10.0.0.0/8 prefix does not match because the prefix length is too short. The 10.0.0.0/24 network qualifies because the bit pattern matches, and the prefix length is between 22 and 26. The 10.0.0.0/30 prefix does not match because the bit pattern is too long. Any prefix that starts with 10 in the first octet and has a prefix length between 22 and 26 will match.

Note

Matching to a specific prefix length that is higher than the high-order bit count requires that the ge-value and le-value match.

Prefix Lists

Prefix lists can contain multiple prefix matching specification entries that contain a permit or deny action. Prefix lists process in sequential order in a top-down fashion, and the first prefix match processes with the appropriate permit or deny action.

Prefix lists are configured with the global configuration command ip prefix-list prefix-list-name [seq sequence-number] {permit | deny} high-order-bit-pattern/high-order-bit-count [ge ge-value] [le le-value].

If a sequence is not provided, the sequence number auto-increments by 5, based on the highest sequence number. The first entry is 5. Sequencing enables the deletion of a specific entry. Because prefix lists cannot be resequenced, it is advisable to leave enough space for insertion of sequence numbers at a later time.

IOS and IOS XE require that the ge-value be greater than the high-order bit count and that the le-value be greater than or equal to the ge-value:

high-order bit count < ge-value <= le-value

Example 12-1 provides a sample prefix list named RFC1918 for all of the networks in the RFC 1918 address range. The prefix list only allows /32 prefixes to exist in the 192.168.0.0 network range and not exist in any other network range in the prefix list.

Notice that sequence 5 permits all /32 prefixes in the 192.168.0.0/13 bit pattern, and sequence 10 denies all /32 prefixes in any bit pattern, and sequences 15, 20, and 25 permit routes in the appropriate network ranges. The sequence order is important for the first two entries to ensure that only /32 prefixes exist in the 192.168.0.0 network in the prefix list.

Example 12-1 Sample Prefix List

ip prefix-list RFC1918 seq 5 permit 192.168.0.0/13 ge 32
ip prefix-list RFC1918 seq 10 deny 0.0.0.0/0 ge 32
ip prefix-list RFC1918 seq 15 permit 10.0.0.0/7 ge 8
ip prefix-list RFC1918 seq 20 permit 172.16.0.0/11 ge 12
ip prefix-list RFC1918 seq 25 permit 192.168.0.0/15 ge 16
IPv6 Prefix Lists

The prefix matching logic works exactly the same for IPv6 networks as for IPv4 networks. The most important thing to remember is that IPv6 networks are notated in hex and not in binary when identifying ranges. Ultimately, however, everything functions at the binary level.

IPv6 prefix lists are configured with the global configuration command ipv6 prefix-list prefix-list-name [seq sequence-number] {permit | deny} high-order-bit-pattern/high-order-bit-count [ge ge-value] [le le-value].

Example 12-2 provides a sample prefix list named PRIVATE-IPV6 for all the networks in the documentation and benchmarking IPv6 space.

Example 12-2 Sample IPv6 Prefix List

ipv6 prefix-list PRIVATE-IPV6 seq 5 permit 2001:2::/48 ge 48
ipv6 prefix-list PRIVATE-IPV6 seq 10 permit 2001:db8::/32 ge 32

Regular Expressions (regex)

There may be times when conditionally matching on network prefixes may be too complicated, and identifying all routes from a specific organization is preferred. In such a case, path selection can be made by using a BGP AS_Path.

Regular expressions (regex) are used to parse through the large number of available ASNs (4,294,967,295). Regular expressions are based on query modifiers used to select the appropriate content. The BGP table can be parsed with regex by using the command show bgp afi safi regexp regex-pattern.

Table 12-5 provides a brief list and description of the common regex query modifiers.

Table 12-5 RegEx Query Modifiers

Modifier

Description

_ (underscore)

Matches a space

^ (caret)

Indicates the start of a string

$ (dollar sign)

Indicates the end of a string

[] (brackets)

Matches a single character or nesting within a range

- (hyphen)

Indicates a range of numbers in brackets

[^] (caret in brackets)

Excludes the characters listed in brackets

() (parentheses)

Used for nesting of search patterns

| (pipe)

Provides OR functionality to the query

. (period)

Matches a single character, including a space

* (asterisk)

Matches zero or more characters or patterns

+ (plus sign)

Matches one or more instances of the character or pattern

? (question mark)

Matches one or no instances of the character or pattern

Learning regex can take time, but the most common ones used in BGP involve the ^, $, and _. Table 12-6 displays some common BGP regex.

Table 12-6 Common BGP Regular Expressions

Regular Expression

Meaning

^$

Local originating routes

permit ^200_

Only routes from neighbor AS 200

permit _200$

Only routes originating from AS 200

permit _200_

Only routes that pass through AS 200

permit ^[0-9]+ [0-9]+ [0-9]+?

Routes with three or fewer AS_Path entries

Note

Hands-on experience is helpful when learning technologies such as regex. There are public servers called looking glasses that allow users to log in and view BGP tables. Most of these devices are Cisco routers, but some are from other vendors. These servers allow network engineers to see if they are advertising their routes to the Internet as they had intended and provide a great method to try out regular expressions on the Internet BGP table.

A quick search on the Internet will provide website listings of looking glass and route servers. We suggest http://www.bgp4.as.

Route Maps

Route maps provide many different features to a variety of routing protocols. At the simplest level, route maps can filter networks much the same way as ACLs, but they also provide additional capability through the addition or modification of network attributes. To influence a routing protocol, a route map must be referenced from the routing protocol. Route maps are critical to BGP because they are the main component in modifying a unique routing policy on a neighbor-by-neighbor basis.

A route map has four components:

  • Sequence number: Dictates the processing order of the route map.

  • Conditional matching criteria: Identifies prefix characteristics (network, BGP path attribute, next hop, and so on) for a specific sequence.

  • Processing action: Permits or denies the prefix.

  • Optional action: Allows for manipulations, depending on how the route map is referenced on the router. Actions can include modification, addition, or removal of route characteristics.

A route map uses the command syntax route-map route-map-name [permit | deny] [sequence-number]. The following rules apply to route map statements:

  • If a processing action is not provided, the default value permit is used.

  • If a sequence number is not provided, the sequence number is incremented by 10 automatically.

  • If a matching statement is not included, an implied all prefixes is associated with the statement.

  • Processing within a route map stops after all optional actions have processed (if configured) after matching a conditional matching criterion.

Example 12-3 provides a sample route map to demonstrate the four components of a route map shown earlier. The conditional matching criterion is based on network ranges specified in an ACL. Comments have been added to this example to explain the behavior of the route map in each sequence.

Example 12-3 Sample Route map

route-map EXAMPLE permit 10
 match ip address ACL-ONE
! Prefixes that match ACL-ONE are permitted. Route-map completes processing upon a match

route-map EXAMPLE deny 20
 match ip address ACL-TWO
! Prefixes that match ACL-TWO are denied. Route-map completes processing upon a match

route-map EXAMPLE permit 30
 match ip address ACL-THREE
 set metric 20
! Prefixes that match ACL-THREE are permitted and modify the metric. Route-map completes
! processing upon a match                                                               

route-map EXAMPLE permit 40
! Because a matching criteria was not specified, all other prefixes are permitted  
! If this sequence was not configured, all other prefixes would drop because of the
! implicit deny  for all route-maps                                                

Note

When deleting a specific route-map statement, include the sequence number to prevent deleting the entire route map.

Conditional Matching

Now that the components and processing order of a route map have been explained, this section expands on how a route can be matched. Table 12-7 provides the command syntax for the most common methods for conditionally matching prefixes and describes their usage. As you can see, there are a number of options available.

Table 12-7 Conditional Match Options

match Command

Description

match as-path acl-number

Selects prefixes based on a regex query to isolate the ASN in the BGP path attribute (PA) AS path. The AS path ACLs are numbered 1 to 500. This command allows for multiple match variables.

match ip address {acl-number | acl-name}

Selects prefixes based on network selection criteria defined in the ACL. This command allows for multiple match variables.

match ip address prefix-list prefix-list-name

Selects prefixes based on prefix selection criteria. This command allows for multiple match variables.

match local-preference local-preference

Selects prefixes based on the BGP attribute local preference. This command allows for multiple match variables.

match metric {1-4294967295 | external 1-4294967295}[+- deviation]

Selects prefixes based on a metric that can be exact, a range, or within acceptable deviation.

match tag tag-value

Selects prefixes based on a numeric tag (0 to 4294967295) that was set by another router. This command allows for multiple match variables.

Multiple Conditional Match Conditions

If there are multiple variables (ACLs, prefix lists, tags, and so on) configured for a specific route map sequence, only one variable must match for the prefix to qualify. The Boolean logic uses an OR operator for this configuration.

In Example 12-4, sequence 10 requires that a prefix pass ACL-ONE or ACL-TWO. Notice that sequence 20 does not have a match statement, so all prefixes that are not passed in sequence 10 will qualify and are denied.

Example 12-4 Multiple Match Variables Route Map Example

route-map EXAMPLE permit 10
 match ip address ACL-ONE ACL-TWO
!
route-map EXAMPLE deny 20

Note

In Example 12-4, sequence 20 is redundant because of the implicit deny for any prefixes that are not matched in sequence 10.

If there are multiple match options configured for a specific route map sequence, both match options must be met for the prefix to qualify for that sequence. The Boolean logic uses an AND operator for this configuration.

In Example 12-5, sequence 10 requires that the prefix match ACL-ONE and that the metric be a value between 500 and 600. If the prefix does not qualify for both match options, the prefix does not qualify for sequence 10 and is denied because another sequence does not exist with a permit action.

Example 12-5 Multiple Match Options Route Map Example

route-map EXAMPLE permit 10
 match ip address ACL-ONE
 match metric 550 +- 50
Complex Matching

Some network engineers find route maps too complex if the conditional matching criteria use an ACL, an AS path ACL, or a prefix list that contains a deny statement. Example 12-6 shows a configuration where the ACL uses a deny statement for the 172.16.1.0/24 network range.

Reading configurations like this should follow the sequence order first and conditional matching criteria second, and only after a match occurs should the processing action and optional action be used. Matching a deny statement in the conditional match criteria excludes the route from that sequence in the route map.

The prefix 172.16.1.0/24 is denied by ACL-ONE, which implies that there is not a match in sequences 10 and 20; therefore, the processing action (permit or deny) is not needed. Sequence 30 does not contain a match clause, so any remaining routes are permitted. The prefix 172.16.1.0/24 would pass on sequence 30 with the metric set to 20. The prefix 172.16.2.0/24 would match ACL-ONE and would pass in sequence 10.

Example 12-6 Complex Matching Route Maps

ip access-list standard ACL-ONE
 deny   172.16.1.0 0.0.0.255
 permit 172.16.0.0 0.0.255.255
route-map EXAMPLE permit 10
 match ip address ACL-ONE
!
route-map EXAMPLE deny 20
 match ip address ACL-ONE
!
route-map EXAMPLE permit 30
 set metric 20

Note

Route maps process using a particular order of evaluation: the sequence, conditional match criteria, processing action, and optional action in that order. Any deny statements in the match component are isolated from the route map sequence action.

Optional Actions

In addition to permitting the prefix to pass, route maps can modify route attributes. Table 12-8 provides a brief overview of the most popular attribute modifications.

Table 12-8 Route Map Set Actions

Set Action

Description

set as-path prepend {as-number-pattern | last-as 1-10}

Prepends the AS path for the network prefix with the pattern specified or from multiple iterations from a neighboring AS.

set ip next-hop { ip-address | peer-address | self }

Sets the next-hop IP address for any matching prefix. BGP dynamic manipulation uses the peer-address or self keywords.

set local-preference 0-4294967295

Sets the BGP PA local preference.

set metric {+value | -value | value}

(where value parameters are 0–4294967295)

Modifies the existing metric or sets the metric for a route.

set origin {igp | incomplete}

Sets the BGP PA origin.

set tag tag-value

Sets a numeric tag (0–4294967295) for identification of networks by other routers

set weight 0–65535

Sets the BGP PA weight.

The continue Keyword

Default route map behavior processes the route map sequences in order, and upon the first match, it executes the processing action, performs any optional action (if feasible), and stops processing. This prevents multiple route map sequences from processing.

Adding the keyword continue to a route map allows the route map to continue processing other route map sequences. Example 12-7 provides a basic configuration. The network prefix 192.168.1.1 matches in sequences 10, 20, and 30. Because the keyword continue was added to sequence 10, sequence 20 processes, but sequence 30 does not because a continue command was not present in sequence 20. The 192.168.1.1 prefix is permitted, and it is modified so that the metric is 20, with the next-hop address 10.12.1.1.

Example 12-7 Route Map with the continue Keyword

ip access-list standard ACL-ONE
 permit 192.168.1.1 0.0.0.0
 permit 172.16.0.0 0.0.255.255
 !
ip access-list standard ACL-TWO
 permit 192.168.1.1 0.0.0.0
 permit 172.31.0.0 0.0.255.255
!
route-map EXAMPLE permit 10
 match ip address ACL-ONE
 set metric 20
 continue                                                                                        
!
route-map EXAMPLE permit 20
 match ip address ACL-TWO
 set ip next-hop 10.12.1.1
!
route-map EXAMPLE permit 30
 set ip next-hop 10.13.1.3

Note

The continue command is not commonly used because it adds complexity when troubleshooting route maps.

BGP Route Filtering and Manipulation

Route filtering is a method of selectively identifying routes that are advertised or received from neighbor routers. Route filtering may be used to manipulate traffic flows, reduce memory utilization, or improve security. For example, it is common for ISPs to deploy route filters on BGP peerings to customers. Ensuring that only the customer routes are allowed over the peering link prevents the customer from accidentally becoming a transit AS on the Internet.

Figure 12-9 shows the complete BGP route processing logic. Notice that the routing policies occur on inbound route receipt and outbound route advertisement.

A flowchart demonstrates the BGP route policy processing logic.

Figure 12-9 BGP Route Policy Processing

IOS XE provides four methods of filtering routes inbound or outbound for a specific BGP peer. These methods can be used individually or simultaneously with other methods:

  • Distribute list: A distribute list involves the filtering of network prefixes based on a standard or extended ACL. An implicit deny is associated with any prefix that is not permitted.

  • Prefix list: A list of prefix-matching specifications permit or deny network prefixes in a top-down fashion, similar to an ACL. An implicit deny is associated with any prefix that is not permitted.

  • AS path ACL/filtering: A list of regex commands allow for the permit or deny of a network prefix based on the current AS path values. An implicit deny is associated with any prefix that is not permitted.

  • Route maps: Route maps provide a method of conditional matching on a variety of prefix attributes and taking a variety of actions. Actions could be a simple permit or deny; or could include the modification of BGP path attributes. An implicit deny is associated with any prefix that is not permitted.

Note

A BGP neighbor cannot use a distribute list and prefix list at the same time for receiving or advertising routes.

The following sections explain each of these filtering techniques in more detail. Imagine a simple scenario with R1 (AS 65100) that has a single eBGP peering with R2 (AS 65200), which then may peer with other autonomous systems (such as AS 65300). The relevant portion of the topology is that R1 peers with R2 and focuses on R1’s BGP table, as shown in Example 12-8, with an emphasis on the network prefix and the AS path.

Example 12-8 Reference BGP Table

R1# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.3.3.0/24      10.12.1.2               33             0 65200 65300 3003 ?
 *   10.12.1.0/24     10.12.1.2               22             0 65200 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  10.23.1.0/24     10.12.1.2              333             0 65200 ?
 *>  100.64.2.0/25    10.12.1.2               22             0 65200 ?
 *>  100.64.2.192/26  10.12.1.2               22             0 65200 ?
 *>  100.64.3.0/25    10.12.1.2               22             0 65200 65300 300 ?
 *>  192.168.1.1/32   0.0.0.0                  0         32768 ?
 *>  192.168.2.2/32   10.12.1.2               22             0 65200 ?
 *>  192.168.3.3/32   10.12.1.2             3333             0 65200 65300 ?

Distribute List Filtering

Distribute lists allow the filtering of network prefixes on a neighbor-by-neighbor basis, using standard or extended ACLs. Configuring a distribute list requires using the BGP address-family configuration command neighbor ip-address distribute-list {acl-number | acl-name} {in|out}. Remember that extended ACLs for BGP use the source fields to match the network portion and the destination fields to match against the network mask.

Example 12-9 provides R1’s BGP configuration, which demonstrates filtering with distribute lists. The configuration uses an extended ACL named ACL-ALLOW that contains two entries. The first entry allows for any network that starts in the 192.168.0.0 to 192.168.255.255 range with any length of network. The second entry allows for networks that contain 100.64.x.0 pattern with a prefix length of /26 to demonstrate the wildcard abilities of an extended ACL with BGP. The distribute list is then associated with R2’s BGP session.

Example 12-9 BGP Distribute List Configuration

R1
ip access-list extended ACL-ALLOW
 permit ip 192.168.0.0 0.0.255.255 host 255.255.255.255
 permit ip 100.64.0.0 0.0.255.0 host 255.255.255.128
!
router bgp 65100
 address-family ipv4
  neighbor 10.12.1.2 distribute-list ACL-ALLOW in

Example 12-10 displays the routing table of R1. Two local routes are injected into the BGP table by R1 (10.12.1.0/24 and 192.168.1.1/32). The two loopback networks from R2 (AS 65200) and R3 (AS 65300) are allowed because they are within the first ACL-ALLOW entry, and two of the networks in the 100.64.x.0 pattern (100.64.2.0/25 and 100.64.3.0/25) are accepted. The 100.64.2.192/26 network is rejected because the prefix length does not match the second ACL-ALLOW entry. Example 12-8 can be referenced to identify the routes before the BGP distribute list was applied.

Example 12-10 Viewing Routes Filtered by BGP Distribute List

R1# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.12.1.0/24     0.0.0.0                  0         32768 ?
 *>  100.64.2.0/25    10.12.1.2               22             0 65200 ?
 *>  100.64.3.0/25    10.12.1.2               22             0 65200 65300 300 ?
 *>  192.168.1.1/32   0.0.0.0                  0         32768 ?
 *>  192.168.2.2/32   10.12.1.2               22             0 65200 ?
 *>  192.168.3.3/32   10.12.1.2             3333             0 65200 65300 ?

Prefix List Filtering

Prefix lists allow the filtering of network prefixes on a neighbor-by-neighbor basis, using a prefix list. Configuring a prefix list involves using the BGP address family configuration command neighbor ip-address prefix-list prefix-list-name {in | out}.

To demonstrate the use of a prefix list, we can use the same initial BGP table from Example 12-8 and filter it to allow only routes within the RFC 1918 space. The same prefix list from Example 12-1 is used and will be applied on R1’s peering to R2 (AS 65200). Example 12-11 shows the configuration of the prefix list and application to R2.

Example 12-11 Prefix List Filtering Configuration

R1# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)# ip prefix-list RFC1918 seq 5 permit 192.168.0.0/13 ge 32
R1(config)# ip prefix-list RFC1918 seq 10 deny 0.0.0.0/0 ge 32
R1(config)# ip prefix-list RFC1918 seq 15 permit 10.0.0.0/7 ge 8
R1(config)# ip prefix-list RFC1918 seq 20 permit 172.16.0.0/11 ge 12
R1(config)# ip prefix-list RFC1918 seq 25 permit 192.168.0.0/15 ge 16
R1(config)# router bgp 65100
R1(config-router)# address-family ipv4 unicast
R1(config-router-af)# neighbor 10.12.1.2 prefix-list RFC1918 in

Now that the prefix list has been applied, the BGP table can be examined on R1, as shown in Example 12-12. Notice that the 100.64.2.0/25, 100.64.2.192/26, and 100.64.3.0/25 networks were filtered as they did not fall within the prefix list matching criteria. Example 12-8 can be referenced to identify the routes before the BGP prefix list was applied.

Example 12-12 Verification of Filtering with a BGP Prefix List

R1# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.3.3.0/24      10.12.1.2               33             0 65200 65300 3003 ?
 *   10.12.1.0/24     10.12.1.2               22             0 65200 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  10.23.1.0/24     10.12.1.2              333             0 65200 ?
 *>  192.168.1.1/32   0.0.0.0                  0         32768 ?
 *>  192.168.2.2/32   10.12.1.2               22             0 65200 ?
 *>  192.168.3.3/32   10.12.1.2             3333             0 65200 65300 ?

AS Path ACL Filtering

Selecting routes from a BGP neighbor by using the AS path requires the definition of an AS path access control list (AS path ACL). Regular expressions, introduced earlier in this chapter, are a component of AS_Path filtering.

Example 12-13 shows the routes that R2 (AS 65200) is advertising toward R1 (AS 65100).

Example 12-13 AS Path Access List Configuration

R2# show bgp ipv4 unicast neighbors 10.12.1.1 advertised-routes | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.3.3.0/24      10.23.1.3               33             0 65300 3003 ?
 *>  10.12.1.0/24     0.0.0.0                  0         32768 ?
 *>  10.23.1.0/24     0.0.0.0                  0         32768 ?
 *>  100.64.2.0/25    0.0.0.0                  0         32768 ?
 *>  100.64.2.192/26  0.0.0.0                  0         32768 ?
 *>  100.64.3.0/25    10.23.1.3                3             0 65300 300 ?
 *>  192.168.2.2/32   0.0.0.0                  0         32768 ?
 *>  192.168.3.3/32   10.23.1.3              333             0 65300 ?

Total number of prefixes 8

R2 is advertising the routes learned from R3 (AS 65300) to R1. In essence, R2 provides transit connectivity between the autonomous systems. If this were an Internet connection and R2 were an enterprise, it would not want to advertise routes learned from other ASs. Using an AS path access list to restrict the advertisement of only AS 65200 routes is recommended.

Processing is peformed in a sequential top-down order, and the first qualifying match processes against the appropriate permit or deny action. An implicit deny exists at the end of the AS path ACL. IOS supports up to 500 AS path ACLs and uses the command ip as-path access-list acl-number {deny | permit} regex-query for creating an AS path ACL. The ACL is then applied with the command neighbor ip-address filter-list acl-number {in|out}.

Example 12-14 shows the configuration on R2 using an AS path ACL to restrict traffic to only locally originated traffic, using the regex pattern ^$ (refer to Table 12-5). To ensure completeness, the AS path ACL is applied on all eBGP neighborships.

Example 12-14 AS Path Access List Configuration

R2
ip as-path access-list 1 permit ^$
!
router bgp 65200
 address-family ipv4 unicast
  neighbor 10.12.1.1 filter-list 1 out
  neighbor 10.23.1.3 filter-list 1 out

Now that the AS path ACL has been applied, the advertised routes can be checked again. Example 12-15 displays the routes being advertised to R1. Notice that all the routes do not have an AS path, confirming that only locally originating routes are being advertised externally. Example 12-13 can be referenced to identify the routes before the BGP AS path ACL was applied.

Example 12-15 Verification of Local Route Advertisements with an AS Path ACL

R2# show bgp ipv4 unicast neighbors 10.12.1.1 advertised-routes | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.12.1.0/24     0.0.0.0                  0         32768 ?
 *>  10.23.1.0/24     0.0.0.0                  0         32768 ?
 *>  100.64.2.0/25    0.0.0.0                  0         32768 ?
 *>  100.64.2.192/26  0.0.0.0                  0         32768 ?
 *>  192.168.2.2/32   0.0.0.0                  0         32768 ?

Total number of prefixes 5

Route Maps

As explained earlier, route maps provide additional functionality over pure filtering. Route maps provide a method to manipulate BGP path attributes as well. Route maps are applied on a BGP neighbor basis for routes that are advertised or received. A different route map can be used for each direction. The route map is associated with the BGP neighbor with the command neighbor ip-address route-map route-map-name {in|out} under the specific address family.

Example 12-16 shows the BGP routing table of R1, which is used here to demonstrate the power of a route map.

Example 12-16 BGP Table Before Applying a Route Map

R1# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.1.1.0/24      0.0.0.0                  0         32768 ?
 *>  10.3.3.0/24      10.12.1.2               33             0 65200 65300 3003 ?
 *   10.12.1.0/24     10.12.1.2               22             0 65200 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  10.23.1.0/24     10.12.1.2              333             0 65200 ?
 *>  100.64.2.0/25    10.12.1.2               22             0 65200 ?
 *>  100.64.2.192/26  10.12.1.2               22             0 65200 ?
 *>  100.64.3.0/25    10.12.1.2               22             0 65200 65300 300 ?
 *>  192.168.1.1/32   0.0.0.0                  0         32768 ?
 *>  192.168.2.2/32   10.12.1.2               22             0 65200 ?
 *>  192.168.3.3/32   10.12.1.2             3333             0 65200 65300 ?

Route maps allow for multiple steps in processing as well. To demonstrate this concept, our route map will consist of four steps:

  1. Deny any routes that are in the 192.168.0.0/16 network by using a prefix list.

  2. Match any routes originating from AS 65200 that are within the 100.64.0.0/10 network range and set the BGP local preference to 222.

  3. Match any routes originating from AS 65200 that did not match step 2 and set the BGP weight to 65200.

  4. Permit all other routes to process.

Example 12-17 demonstrates R1’s configuration, where multiple prefix lists are referenced along with an AS path ACL.

Example 12-17 R1’s Route Map Configuration for Inbound AS 65200 Routes

R1
ip prefix-list FIRST-RFC1918 permit  192.168.0.0/15 ge 16
ip as-path access-list 1 permit _65200$
ip prefix-list SECOND-CGNAT permit 100.64.0.0/10 ge 11
!
route-map AS65200IN deny 10
 description Deny any RFC1918 networks via Prefix List Matching
 match ip address prefix-list FIRST-RFC1918
!
route-map AS65200IN permit 20
 description Change local preference for AS65200 originate route in 100.64.x.x/10
 match ip address prefix-list SECOND-CGNAT
 match as-path 1
 set local-preference 222
!
route-map AS65200IN permit 30
 description Change the weight for AS65200 originate routes
 match as-path 1
 set weight 65200
!
route-map AS65200IN permit 40
 description Permit all other routes un-modified
!
router bgp 65100
 address-family ipv4 unicast
  neighbor 10.12.1.1 route-map AS65200IN in

Example 12-18 displays R1’s BGP routing table. The following actions have occurred:

  • The 192.168.2.2/32 and 192.168.3.3/32 routes were discarded. The 192.168.1.1/32 route is a locally generated route.

  • The 100.64.2.0/25 and 100.64.2.192/26 networks had the local preference modified to 222 because they originated from AS 65200 and are within the 100.64.0.0/10 network range.

  • The 10.12.1.0/24 and 10.23.1.0/24 routes from R2 were assigned the locally significant BGP attribute weight 65200.

  • All other routes were received and not modified.

Example 12-18 Verifying Changes from R1’s Route Map to AS 65200

R1# show bgp ipv4 unicast | b Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.1.1.0/24      0.0.0.0                  0         32768 ?
 *>  10.3.3.0/24      10.12.1.2               33             0 65200 65300 3003 ?
 r>  10.12.1.0/24     10.12.1.2               22         65200 65200 ?
 r                    0.0.0.0                  0         32768 ?
 *>  10.23.1.0/24     10.12.1.2              333         65200 65200 ?
 *>  100.64.2.0/25    10.12.1.2               22    222      0 65200 ?
 *>  100.64.2.192/26  10.12.1.2               22    222      0 65200 ?
 *>  100.64.3.0/25    10.12.1.2               22             0 65200 65300 300 ?
 *>  192.168.1.1/32   0.0.0.0                  0         32768 ?

Note

It is considered a best practice to use a different route policy for inbound and outbound prefixes for each BGP neighbor.

Clearing BGP Connections

Depending on the change to the BGP route manipulation technique, a BGP session may need to be refreshed in order to take effect. BGP supports two methods of clearing a BGP session. The first method is a hard reset, which tears down the BGP session, removes BGP routes from the peer, and is the most disruptive. The second method is a soft reset, which invalidates the BGP cache and requests a full advertisement from its BGP peer.

Routers initiate a hard reset with the command clear ip bgp ip-address [soft] and a soft reset by using the optional soft keyword. All of a router’s BGP sessions can be cleared by using an asterisk * in lieu of the peer’s IP address.

When a BGP policy changes, the BGP table must be processed again so that the neighbors can be notified accordingly. Routes received by a BGP peer must be processed again. If the BGP session supports route refresh capability, the peer re-advertises (refreshes) the prefixes to the requesting router, allowing for the inbound policy to process using the new policy changes. The route refresh capability is negotiated for each address family when the session is established.

Performing a soft reset on sessions that support route refresh capability actually initiates a route refresh. Soft resets can be performed for a specific address family with the command clear bgp afi safi {ip-address|*} soft [in | out]. Soft resets reduce the number of routes that must be exchanged if multiple address families are configured with a single BGP peer. Changes to the outbound routing policies use the optional out keyword, and changes to inbound routing policies use the optional in keyword. You can use an * in lieu of specifying a peer’s IP address to perform that action for all BGP peers.

BGP Communities

BGP communities provide additional capability for tagging routes and for modifying BGP routing policy on upstream and downstream routers. BGP communities can be appended, removed, or modified selectively on each attribute as a route travels from router to router.

BGP communities are an optional transitive BGP attribute that can traverse from AS to AS. A BGP community is a 32-bit number that can be included with a route. A BGP community can be displayed as a full 16-bit number (0–4,294,967,295) or as two 16-bit numbers (0–65535):(0–65535), commonly referred to as new format.

Private BGP communities follow a particular convention where the first 16 bits represent the AS of the community origination, and the second 16 bits represent a pattern defined by the originating AS. A private BGP community pattern can vary from organization to organization, does not need to be registered, and can signify geographic locations for one AS while signifying a method of route advertisement in another AS. Some organizations publish their private BGP community patterns on websites such as http://www.onesc.net/communities/.

In 2006, RFC 4360 expanded BGP communities’ capabilities by providing an extended format. Extended BGP communities provide structure for various classes of information and are commonly used for VPN services. RFC 8092 provides support for communities larger than 32 bits (which are beyond the scope of this book).

Well-Known Communities

RFC 1997 defines a set of global communities (known as well-known communities) that use the community range 4,294,901,760 (0xFFFF0000) to 4,294,967,295 (0xFFFFFFFF). All routers that are capable of sending/receiving BGP communities must implement well-known communities. Following are three common well-known communities:

  • Internet: This is a standardized community for identifying routes that should be advertised on the Internet. In larger networks that deploy BGP into the core, advertised routes should be advertised to the Internet and should have this community set. This allows for the edge BGP routers to only allow the advertisement of BGP routes with the Internet community to the Internet. Filtering is not automatic but can be done with an outbound route map.

  • No_Advertise: Routes with this community should not be advertised to any BGP peer (iBGP or eBGP).

  • No_Export: When a route with this community is received, the route is not advertised to any eBGP peer. Routes with this community can be advertised to iBGP peers.

Enabling BGP Community Support

IOS and IOS XE routers do not advertise BGP communities to peers by default. Communities are enabled on a neighbor-by-neighbor basis with the BGP address family configuration command neighbor ip-address send-community [standard | extended | both] under the neighbor’s address family configuration. If a keyword is not specified, standard communities are sent by default.

IOS XE nodes can display communities in new format, which is easier to read, with the global configuration command ip bgp-community new-format. Example 12-19 displays the BGP community in decimal format first, followed by the new format.

Example 12-19 BGP Community Formats

! Decimal Format
R3# show bgp 192.168.1.1
! Output omitted for brevity
BGP routing table entry for 192.168.1.1/32, version 6
Community: 6553602 6577023
! New-Format                                                                           
R3# show bgp 192.168.1.1
! Output omitted for brevity                                                           
BGP routing table entry for 192.168.1.1/32, version 6
Community: 100:2 100:23423

Conditionally Matching BGP Communities

Conditionally matching BGP communities allows for selection of routes based on the BGP communities within the route’s path attributes so that selective processing can occur in route maps. Example 12-20 demonstrates the BGP table for R1, which has received multiple routes from R2 (AS 65200).

Example 12-20 BGP Routes from R2 (AS 65200)

R1# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.1.1.0/24      0.0.0.0                  0         32768 ?
 *   10.12.1.0/24     10.12.1.2               22             0 65200 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  10.23.1.0/24     10.12.1.2              333             0 65200 ?
 *>  192.168.1.1/32   0.0.0.0                  0         32768 ?
 *>  192.168.2.2/32   10.12.1.2               22             0 65200 ?
 *>  192.168.3.3/32   10.12.1.2             3333             0 65200 65300 ?

In this example, say that you want to conditionally match for a specific community. The entire BGP table can be displayed with the command show bgp afi safi detail and then you can manually select a route with a specific community. However, if the BGP community is known, all the routes can be displayed with the command show bgp afi safi community community, as shown in Example 12-21.

Example 12-21 Displaying the BGP Routes with a Specific Community

R1# show bgp ipv4 unicast community 333:333 | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.23.1.0/24     10.12.1.2              333             0 65200 ?

Example 12-22 displays the explicit path entry for the 10.23.1.0/24 network and all the BGP path attributes. Notice that two BGP communities (333:333 and 65300:333) are added to the path.

Example 12-22 Viewing BGP Path Attributes for the 10.23.1.0/24 Network

R1# show ip bgp 10.23.1.0/24
BGP routing table entry for 10.23.1.0/24, version 15
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 3
  65200
    10.12.1.2 from 10.12.1.2 (192.168.2.2)
      Origin incomplete, metric 333, localpref 100, valid, external, best
      Community: 333:333 65300:333
      rx pathid: 0, tx pathid: 0x0

Conditionally matching requires the creation of a community list that shares a similar structure to an ACL, can be standard or expanded, and can be referenced by number or name. Standard community lists are numbered 1 to 99 and match either well-known communities or a private community number (as-number:16-bit-number). Expanded community lists are numbered 100 to 500 and use regex patterns.

The configuration syntax for a community list is ip community-list {1-500 | standard list-name | expanded list-name} {permit | deny} community-pattern. After defining the community list, the community list is referenced in the route map with the command match community 1-500.

Note

When multiple communities are on the same ip community list statement, all communities for that statement must exist in the route. If only one out of many communities is required, you can use multiple ip community list statements.

Example 12-23 demonstrates the creation of a BGP community list that matches on the community 333:333. The BGP community list is then used in the first sequence of route-map COMMUNITY-CHECK, which denies any routes with that community. The second route map sequence allows for all other BGP routes and sets the BGP weight (locally significant) to 111. The route map is then applied on routes advertised from R2 toward R1.

Example 12-23 Conditionally Matching BGP Communities

R1
ip community-list 100 permit 333:333
!
route-map COMMUNITY-CHECK deny 10
 description Block Routes with Community 333:333 in it
 match community 100
route-map COMMUNITY-CHECK permit 20
 description Allow routes with either community in it
 set weight 111
!
router bgp 65100
 address-family ipv4 unicast
  neighbor 10.12.1.2 route-map COMMUNITY-CHECK in

Example 12-24 shows the BGP table after the route map has been applied to the neighbor. The 10.23.1.0/24 network prefix was discarded, and all the other routes learned from AS 65200 had the BGP weight set to 111.

Example 12-24 R1’s BGP Table After Applying the Route Map

R1# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.1.1.0/24      0.0.0.0                  0         32768 ?
 *   10.12.1.0/24     10.12.1.2               22           111 65200 ?
 *>                   0.0.0.0                  0         32768 ?
 *>  192.168.1.1/32   0.0.0.0                  0         32768 ?
 *>  192.168.2.2/32   10.12.1.2               22           111 65200 ?
 *>  192.168.3.3/32   10.12.1.2             3333           111 65200 65300 ?

Setting Private BGP Communities

A private BGP community is set in a route map with the command set community bgp-community [additive]. By default, when setting a community, any existing communities are over-written but can be preserved by using the optional additive keyword.

Example 12-25 shows the BGP table entries for the 10.23.1.0/24 network, which has the 333:333 and 65300:333 BGP communities. The 10.3.3.0/24 network has the 65300:300 community.

Example 12-25 Viewing the BGP Communities for Two Network Prefixes

R1# show bgp ipv4 unicast 10.23.1.0/24
! Output omitted for brevity                                             
BGP routing table entry for 10.23.1.0/24, version 15
  65200
    10.12.1.2 from 10.12.1.2 (192.168.2.2)
      Origin incomplete, metric 333, localpref 100, valid, external, best
      Community: 333:333 65300:333
R1# show bgp ipv4 unicast 10.3.3.0/24
! Output omitted for brevity                                                  
BGP routing table entry for 10.3.3.0/24, version 12
  65200 65300 3003
    10.12.1.2 from 10.12.1.2 (192.168.2.2)
      Origin incomplete, metric 33, localpref 100, valid, external, best
      Community: 65300:300

Example 12-26 shows the configuration where the BGP community is set to the 10.23.1.0/24 network. The additive keyword is not used, so the previous community values 333:333 and 65300:333 are overwritten with the 10:23 community. The 10.3.3.0/24 network has the communities 3:0, 3:3, and 10:10 added to the existing communities. The route map is then associated to R2 (AS 65200).

Example 12-26 Setting Private BGP Community Configuration

ip prefix-list PREFIX10.23.1.0 seq 5 permit 10.23.1.0/24
ip prefix-list PREFIX10.3.3.0 seq 5 permit 10.3.3.0/24
!
route-map SET-COMMUNITY permit 10
 match ip address prefix-list PREFIX10.23.1.0
 set community 10:23
route-map SET-COMMUNITY permit 20
 match ip address prefix-list PREFIX10.3.3.0
 set community 3:0 3:3 10:10 additive
route-map SET-COMMUNITY permit 30
!
router bgp 65100
 address-family ipv4
  neighbor 10.12.1.2 route-map SET-COMMUNITY in

Now that the route map has been applied and the routes have been refreshed, the path attributes can be examined, as demonstrated in Example 12-27. As anticipated, the previous BGP communities were removed for the 10.23.1.0/24 network but were maintained for the 10.3.3.0/24 network.

Example 12-27 Verifying BGP Community Changes

R1# show bgp ipv4 unicast 10.23.1.0/24
! Output omitted for brevity                                                    
BGP routing table entry for 10.23.1.0/24, version 22
  65200
    10.12.1.2 from 10.12.1.2 (192.168.2.2)
      Origin incomplete, metric 333, localpref 100, valid, external, best
      Community: 10:23
R1# show bgp ipv4 unicast 10.3.3.0/24
BGP routing table entry for 10.3.3.0/24, version 20
  65200 65300 3003
    10.12.1.2 from 10.12.1.2 (192.168.2.2)
      Origin incomplete, metric 33, localpref 100, valid, external, best
      Community: 3:0 3:3 10:10 65300:300

Understanding BGP Path Selection

The BGP best-path selection algorithm influences how traffic enters or leaves an AS. Some router configurations modify the BGP attributes to influence inbound traffic, outbound traffic, or inbound and outbound traffic, depending on the network design requirements. A lot of network engineers do not understand BGP best-path selection, which can often result in suboptimal routing. This section explains the logic used by a router that uses BGP when forwarding packets.

Routing Path Selection Using Longest Match

Routers always select the path a packet should take by examining the prefix length of a network entry. The path selected for a packet is chosen based on the prefix length, where the longest prefix length is always preferred. For example, /28 is preferred over /26, and /26 is preferred over /24.

This logic can be used to influence path selection in BGP. Assume that an organization owns the 100.64.0.0/16 network range but only needs to advertise two subnets (100.64.1.0/24 and 100.64.2.0/24). It could advertise both prefixes (100.64.1.0/24 and 100.64.2.0/24) from all its routers, but how can it distribute the load for each subnet if all traffic comes in on one router (such as R1)?

The organization could modify various BGP path attributes (PAs) that are advertised externally, but an SP could have a BGP routing policy that ignores those path attributes, resulting in random receipt of network traffic.

A more elegant way that guarantees that paths are selected deterministically outside the organization is to advertise a summary prefix (100.64.0.0/16) out both routers. Then the organization can advertise a longer matching prefix out the router that should receive network traffic for that prefix. Figure 12-10 shows the concept, with R1 advertising the 100.64.1.0/24 prefix, R2 advertising the 100.64.2.0/24 prefix, and both routers advertising the 100.64.0.0/16 summary network prefix.

A figure depicts BGP path selection using longest match. It shows two routers R1 and R2 that belongs to an enterprise network. R1 advertises the prefix 100.64.1.0/24 to AS 100 and R2 advertises 100.64.2.0/24 to AS 200. Both R1 and R2 advertise 100.64.0.0/16 to AS 100 and AS 200. As 100 and AS 200 are connected through internet.

Figure 12-10 BGP Path Selection Using Longest Match

Regardless of an SP’s routing policy, the more specific prefixes are advertised out only one router. Redundancy is provided by advertising the summary address. If R1 crashes, devices use R2’s route advertisement of 100.64.0.016 to reach the 100.64.1.0/24 network.

Note

Ensure that the network summaries that are being advertised from your organization are within only your network range. In addition, service providers typically do not accept IPv4 routes longer than /24 (for example, /25 or /26) or IPv6 routes longer than /48. Routes are restricted to control the size of the Internet routing table.

BGP Best Path Overview

In BGP, route advertisements consist of Network Layer Reachability Information (NLRI) and path attributes (PAs). The NLRI consists of the network prefix and prefix length, and the BGP attributes such as AS_Path, origin, and so on are stored in the PAs. A BGP route may contain multiple paths to the same destination network. Every path’s attributes impact the desirability of the route when a router selects the best path. A BGP router advertises only the best path to the neighboring routers.

Inside the BGP Loc-RIB table, all the routes and their path attributes are maintained with the best path calculated. The best path is then installed in the RIB of the router. If the best path is no longer available, the router can use the existing paths to quickly identify a new best path. BGP recalculates the best path for a prefix upon four possible events:

  • BGP next-hop reachability change

  • Failure of an interface connected to an eBGP peer

  • Redistribution change

  • Reception of new or removed paths for a route

BGP automatically installs the first received path as the best path. When additional paths are received for the same network prefix length, the newer paths are compared against the current best path. If there is a tie, processing continues until a best-path winner is identified.

The BGP best-path algorithm uses the following attributes, in the order shown, for the best-path selection:

  1. Weight

  2. Local preference

  3. Local originated (network statement, redistribution, or aggregation)

  4. AIGP

  5. Shortest AS_Path

  6. Origin type

  7. Lowest MED

  8. eBGP over iBGP

  9. Lowest IGP next hop

  10. If both paths are external (eBGP), prefer the first (oldest)

  11. Prefer the route that comes from the BGP peer with the lower RID

  12. Prefer the route with the minimum cluster list length

  13. Prefer the path that comes from the lowest neighbor address

The BGP routing policy can vary from organization to organization, based on the manipulation of the BGP PAs. Because some PAs are transitive and carry from one AS to another AS, those changes could impact downstream routing for other SPs, too. Other PAs are non-transitive and only influence the routing policy within the organization. Network prefixes are conditionally matched on a variety of factors, such as AS_Path length, specific ASN, BGP communities, or other attributes.

The best-path algorithm is explained in the following sections.

Weight

BGP weight is a Cisco-defined attribute and the first step for selecting the BGP best path. Weight is a 16-bit value (0 to 65,535) assigned locally on the router; it is not advertised to other routers. The path with the higher weight is preferred. Weight can be set for specific routes with an inbound route map or for all routes learned from a specific neighbor. Weight is not advertised to peers and only influences outbound traffic from a router or an AS. Because it is the first step in the best-path algorithm, it should be used when other attributes should not influence the best path for a specific network.

Example 12-28 displays the BGP table for the 172.16.1.0/24 network prefix on R2. On the third line of the output, the router indicates that two paths exist, and the first path is the best path. By examining the output of each path, the path learned through AS 65300 has a weight of 123. The path through AS 65100 does not have the weight, which equates to a value of 0; therefore, the route through AS 65300 is the best path.

Example 12-28 An Example of a BGP Best-Path Choice Based on Weight

R2# show bgp ipv4 unicast 172.16.1.0/24
BGP routing table entry for 172.16.1.0/24, version 3
Paths: (2 available, best #1, table default)
  Refresh Epoch 2
  65300
    10.23.1.3 from 10.23.1.3 (192.18.3.3)
      Origin IGP, metric 0, localpref 100, weight 123, valid, external, best
  Refresh Epoch 2
  65100
    10.12.1.1 from 10.12.1.1 (192.168.1.1)
      Origin IGP, metric 0, localpref 100, valid, external
Local Preference

Local preference (LOCAL_PREF) is a well-known discretionary path attribute and is included with path advertisements throughout an AS. The local preference attribute is a 32-bit value (0 to 4,294,967,295) that indicates the preference for exiting the AS to the destination network. The local preference is not advertised between eBGP peers and is typically used to influence the next-hop address for outbound traffic (that is, leaving an autonomous system). Local preference can be set for specific routes by using a route map or for all routes received from a specific neighbor.

A higher value is preferred over a lower value. If an edge BGP router does not define the local preference upon receipt of a prefix, the default local preference value of 100 is used during best-path calculation, and it is included in advertisements to other iBGP peers. Modifying the local preference can influence the path selection on other iBGP peers without impacting eBGP peers because local preference is not advertised outside the autonomous system.

Example 12-29 shows the BGP table for the 172.16.1.0/24 network prefix on R2. On the third line of the output, the router indicates that two paths exist, and the first path is the best path. The BGP weight does not exist, so then the local preference is used. The path learned through AS 65300 is the best path because it has a local preference of 333, while the path through AS 65200 has a local preference of 111.

Example 12-29 An Example of a BGP Best-Path Choice Based on Local Preference

R2# show bgp ipv4 unicast 172.16.1.0/24
BGP routing table entry for 172.16.1.0/24, version 4
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 4
  65300
    10.23.1.3 from 10.23.1.3 (192.18.3.3)
      Origin IGP, metric 0, localpref 333, valid, external, best
  Refresh Epoch 4
  65100
    10.12.1.1 from 10.12.1.1 (192.168.1.1)
      Origin IGP, metric 0, localpref 111, valid, external
Locally Originated via Network or Aggregate Advertisement

The third decision point in the best-path algorithm is to determine whether the route originated locally. Preference is given in the following order:

  • Routes that were advertised locally

  • Networks that have been aggregated locally

  • Routes received by BGP peers

Accumulated Interior Gateway Protocol

Accumulated Interior Gateway Protocol (AIGP) is an optional nontransitive path attribute that is included with advertisements throughout an AS. IGPs typically use the lowest-path metric to identify the shortest path to a destination but cannot provide the scalability of BGP. BGP uses an AS to identify a single domain of control for a routing policy. BGP does not use path metric due to scalability issues combined with the notion that each AS may use a different routing policy to calculate metrics.

AIGP provides the ability for BGP to maintain and calculate a conceptual path metric in environments that use multiple ASs with unique IGP routing domains in each AS. The ability for BGP to make routing decisions based on a path metric is a viable option because all the ASs are under the control of a single domain, with consistent routing policies for BGP and IGPs.

In Figure 12-11, AS 100, AS 200, and AS 300 are all under the control of the same service provider. AIGP has been enabled on the BGP sessions between all the routers, and the IGPs are redistributed into BGP. The AIGP metric is advertised between AS 100, AS 200, and AS 300, allowing BGP to use the AIGP metric for best-path calculations between the autonomous systems.

A figure depicts AIGP path attributes exchange between autonomous systems.

Figure 12-11 AIGP Path Attribute Exchange Between Autonomous Systems

The following guidelines apply to AIGP metrics:

  • A path with an AIGP metric is preferred to a path without an AIGP metric.

  • If the next-hop address requires a recursive lookup, the AIGP path needs to calculate a derived metric to include the distance to the next-hop address. This ensures that the cost to the BGP edge router is included. The formula is

    Derived AIGP metric = (Original AIGP metric + Next-hop AIGRP metric)

    • If multiple AIGP paths exist and one next-hop address contains an AIGP metric and the other does not, the non-AIGP path is not used.

    • The next-hop AIGP metric is recursively added if multiple lookups are performed.

  • AIGP paths are compared based on the derived AIGP metric (with recursive next hops) or the actual AIGP metric (non-recursive next hop). The path with the lower AIGP metric is preferred.

  • When a router R2 advertises an AIGP-enabled path that was learned from R1, if the next-hop address changes to an R2 address, R2 increments the AIGP metric to reflect the distance (the IGP path metric) between R1 and R2.

Shortest AS Path

The next decision factor for the BGP best-path algorithm is the AS path length. The path length typically correlates to the AS hop count. A shorter AS path is preferred over a longer AS path.

Prepending ASNs to the AS path makes it longer, thereby making that path less desirable compared to other paths. Typically, the AS path is prepended with the network owner’s ASN.

In general, a path that has had the AS path prepended is not selected as the BGP best path because the AS path is longer than the non-prepended path advertisement. Inbound traffic is influenced by prepending AS path length in advertisements to other ASs, and outbound traffic is influenced by prepending advertisements received from other ASs.

Example 12-30 shows the BGP table for the 172.16.1.0/24 network prefix on R2. The second route learned through AS 65100 is the best path. There is not a weight set on either path, and the local preference is identical. The second path has an AS path length of 1, while the first path has an AS path length of 2 (65300 and 65300).

Example 12-30 An Example of a BGP Best-Path Choice Based on AS Path Length

R2# show bgp ipv4 unicast 172.16.1.0/24
BGP routing table entry for 172.16.1.0/24, version 6
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 8
  65300 65300
    10.23.1.3 from 10.23.1.3 (192.18.3.3)
      Origin IGP, metric 0, localpref 100, valid, external
  Refresh Epoch 8
  65100
    10.12.1.1 from 10.12.1.1 (192.168.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best

Note

The ASNs are repeated in the first entry, which indicates that AS 65300 prepended its BGP advertisement to steer network traffic.

Note

Peering with different Internet providers provides optimal routing to most companies because one SP may be one AS path hop away (or provide connectivity to other tier 2/3 SPs), while a different SP may have a shorter AS path to other customers.

Origin Type

The next BGP best-path decision factor is the well-known mandatory BGP attribute named origin. By default, networks that are advertised through the network statement are set with the IGP or i origin, and redistributed networks are assigned the Incomplete or ? origin attribute. The origin preference order is

  1. IGP origin (most)

  2. EGP origin

  3. Incomplete origin (least)

Example 12-31 shows the BGP table for the 172.16.1.0/24 network prefix on R2. The second path learned through AS 65100 is the best path because it has an origin of IGP, while first path has an origin of incomplete, which is the least preferred.

Example 12-31 An Example of a BGP Best-Path Choice Based on Origin Type

R2# show bgp ipv4 unicast 172.16.1.0/24
BGP routing table entry for 172.16.1.0/24, version 6
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 10
  65300
    10.23.1.3 from 10.23.1.3 (192.18.3.3)
      Origin incomplete, metric 0, localpref 100, valid, external
  Refresh Epoch 10
  65100
    10.12.1.1 from 10.12.1.1 (192.168.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
Multi-Exit Discriminator

The next BGP best-path decision factor is the non-transitive BGP attribute named multiple-exit discriminator (MED). MED uses a 32-bit value (0 to 4,294,967,295) called a metric. BGP sets the MED automatically to the IGP path metric during network advertisement or redistribution. If the MED is received from an eBGP session, it can be advertised to other iBGP peers, but it should not be sent outside the AS that received it. MED’s purpose is to influence traffic flows inbound from a different AS. A lower MED is preferred over a higher MED.

Note

For MED to be an effective decision factor, the paths being decided upon must come from the same ASN.

RFC 4451 guidelines state that a prefix without a MED value should be given priority and, in essence, should be compared with a value of 0. Some organizations require that a MED be set to a specific value for all the prefixes and declare that paths without the MED should be treated as the least preferred. By default, if the MED is missing from a prefix learned from an eBGP peer, devices use a MED of 0 for the best-path calculation. IOS routers advertise a MED of 0 to iBGP peers.

Example 12-32 shows the BGP table for the 172.16.1.0/24 network prefix on R2. Notice that R2 is peering only with AS 65300 for MED to be eligible for the best-path selection process. The first path has a MED of 0, and the second path has a MED of 33. The first path is preferred as the MED is lower.

Example 12-32 An Example of a BGP Best-Path Choice Based on MED

R2# show bgp ipv4 unicast 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 9
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 4
  65300
    10.12.1.1 from 10.12.1.1 (192.168.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
  Refresh Epoch 14
  65300
    10.23.1.3 from 10.23.1.3 (192.18.3.3)
      Origin IGP, metric 33, localpref 100, valid, external

Note

It is possible for the SP to forget to advertise the MED from both peers and configure only one. This might have unintended consequences and can be easily fixed.

eBGP over iBGP

The next BGP best-path decision factor is whether the route comes from an iBGP, eBGP, or confederation member AS (sub-AS) peering. The best-path selection order is

  1. eBGP peers (most desirable)

  2. Confederation member AS peers

  3. iBGP peers (least desirable)

Note

BGP confederations are beyond the scope of the CCNP and CCIE Enterprise Core ENCOR 350-401 exam and are not discussed in this book.

Lowest IGP Metric

The next decision step is to use the lowest IGP cost to the BGP next-hop address. Figure 12-12 illustrates a topology where R2, R3, R4, and R5 are in AS 400. AS 400 peers in a full mesh and establishes BGP sessions using Loopback 0 interfaces. R1 advertises the 172.16.0.0/24 network prefix to R2 and R4.

R3 prefers the path from R2 compared to the iBGP path from R4 because the metric to reach the next-hop address is lower. R5 prefers the path from R4 compared to the iBGP path from R2 because the metric to reach the next-hop address is lower.

A lowest IGP metric topology is shown.

Figure 12-12 Lowest IGP Metric Topology

Prefer the Oldest eBGP Path

BGP can maintain large routing tables, and unstable sessions result in the BGP best-path calculation executing frequently. BGP maintains stability in a network by preferring the path from the oldest (established) BGP session.

The downfall of this technique is that it does not lead to a deterministic method of identifying the BGP best path from a design perspective.

Router ID

The next step for the BGP best-path algorithm is to select the best path using the lowest router ID of the advertising eBGP router. If the route was received by a route reflector, then the originator ID is substituted for the router ID.

Minimum Cluster List Length

The next step in the BGP best-path algorithm is to select the best path using the lowest cluster list length. The cluster list is a non-transitive BGP attribute that is appended (not overwritten) by a route reflector with its cluster ID. Route reflectors use the cluster ID attribute as a loop-prevention mechanism. The cluster ID is not advertised between ASs and is locally significant. In simplest terms, this step locates the path that has traveled the lowest number of iBGP advertisement hops.

Note

BGP route reflectors are beyond the scope of the CCNP and CCIE Enterprise Core ENCOR 350-401 exam and are not discussed in this book.

Lowest Neighbor Address

The last step of the BGP best-path algorithm is to select the path that comes from the lowest BGP neighbor address. This step is limited to iBGP peerings because eBGP peerings used the oldest received path as the tie breaker.

Figure 12-13 demonstrates the concept of choosing the router with the lowest neighbor address. R1 is advertising the 172.16.0.0/24 network prefix to R2. R1 and R2 have established two BGP sessions using the 10.12.1.0/24 and 10.12.2.0/24 networks. R2 selects the path advertised from 10.12.1.1 as it is the lower IP address.

A figure depicts the concept of choosing the router with lowest IP address.

Figure 12-13 Lowest IP Address

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 30, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 12-9 lists these key topics and the page number on which each is found.

Table 12-9 Key Topics for Chapter 12

Key Topic Element

Description

Page

Section

Resiliency in service providers

287

Section

Internet transit routing

288

Section

Extended ACL IGP network selection

292

Section

Extended ACL BGP network selection

292

Paragraph

Prefix match specifications

293

Paragraph

Prefix matching with length parameters

293

Section

Prefix lists

295

Section

Regular expressions

296

List

Route map components

297

List

Route map syntax and processing

297

Section

Route map conditional matching

298

Section

Route map matching with multiple conditions

299

Section

Route map optional actions

300

Section

BGP distribute list filtering

303

Section

BGP prefix list filtering

304

Paragraph

BGP AS path ACL

305

Section

BGP route maps for neighbors

306

Section

BGP communities

309

Section

Enabling BGP community support

310

Paragraph

BGP community list

311

Section

Setting private BGP communities

312

Section

Routing path selection using longest match

314

List

BGP best-path algorithm

315

Complete Tables and Lists from Memory

There are no memory tables in this chapter.

Define Key Terms

Define the following key terms from this chapter and check your answers in the Glossary:

AS path access control list (ACL)

BGP community

BGP multihoming

distribute list

prefix list

regular expression (regex)

route map

transit routing

Use the Command Reference to Check Your Memory

Table 12-10 lists the important commands from this chapter. To test your memory, cover the right side of the table with a piece of paper, read the description on the left side, and see how much of the command you can remember.

Table 12-10 Command Reference

Task

Command Syntax

Configure a prefix list

{ip | ipv6} prefix-list prefix-list-name [seq sequence-number] {permit | deny} high-order-bit-pattern/high-order-bit-count [ge ge-value] [le le-value]

Create a route map entry

route-map route-map-name [permit | deny] [sequence-number]

Conditionally match in a route map by using the AS path

match as-path acl-number

Conditionally match in a route map by using an ACL

match ip address {acl-number | acl-name}

Conditionally match in a route map by using a prefix list

match ip address prefix-list prefix-list-name

Conditionally match in a route map by using a local preference

match local-preference local-preference

Filter routes to a BGP neighbor by using an ACL

neighbor ip-address distribute-list {acl-number | acl-name} {in|out}

Filter routes to a BGP neighbor by using a prefix list

neighbor ip-address prefix-list prefix-list-name {in | out}

Create an ACL based on the BGP AS path

ip as-path access-list acl-number {deny | permit} regex-query

Filter routes to a BGP neighbor by using an AS path ACL

neighbor ip-address filter-list acl-number {in|out}

Associate an inbound or outbound route map with a specific BGP neighbor

neighbor ip-address route-map route-map-name {in|out}

Configure IOS-based routers to display the community in new format for easier readability of BGP communities

ip bgp-community new-format

Create a BGP community list for conditional route matching

ip community-list {1-500 | standard list-name | expanded list-name} {permit | deny} community-pattern

Set BGP communities in a route map

set community bgp-community [additive]

Initiate a route refresh for a specific BGP peer

clear bgp afi safi {ip-address|*} soft [in | out].

Display the current BGP table, based on routes that meet a specified AS path regex pattern

show bgp afi safi regexp regex-pattern

Display the current BGP table, based on routes that meet a specified BGP community

show bgp afi safi community community

References in This Chapter

RFC 4360, BGP Extended Communities Attribute, by Yakov Rekhter, Dan Tappan, and Srihari R. Sangli. https://www.ietf.org/rfc/rfc4360.txt, February 2006.

RFC 8092, BGP Large Communities Attribute, by John Heasley, et. al. https://www.ietf.org/rfc/rfc2858.txt, February 2017.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset