BGP Conditional Matching

provides an overview of how network prefixes can be conditionally matched with ACLs, prefix lists, regular expressions.

• 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 match a route—using access control lists (ACLs), prefix lists, regular expressions (regex), and AS path ACLs.

Access Control Lists

Originally, ACLs intended to filter packets flowing in or out of a network interface, similar to a firewall. Today, ACLs provide packet classification for a variety of features, such as 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. 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 and Extended:

• 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.
• Named ACLs – provide relevance to the functionality of the ACL, can be used with standard or extended ACLs, and are generally preferred.

Note: This course is concerned with routing and limits the scope of ACLs to source, destination, and protocol.

Standard ACLs

Standard ACLS use a numbered entry 1–99, 1300–1999, or a named ACL. 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 Standard ACL-to-Network Entries

Extended ACLs

Extended ACLs use a numbered entry 100–199, 2000–2699 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.

Extended ACL 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. The table provides sample ACL entries 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.  

Extended ACL 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. permit protocol source source-wildcard destination destination-wildcard

Prefix Match Specifications

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 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 mask length.

Prefix Matching with Length Parameters

The power of prefix matching 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. In this example, the matching length of the prefix must be greater than or equal to 24.

Prefix Matching with Length Parameters

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.     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. 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 – IPv4

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 a permit or deny action. Prefix lists are configured with the command ip prefix-list prefix-listname [seq sequence-number] {permit | deny} high-order-bit-pattern/high-order-bit-count [ge ge-value] [le le-value] The sequence number auto-increments by 5, based on the highest sequence number. The first entry is 5. 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

Prefix Lists – IPv6

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/highorder-bit-count [ge ge-value] [le le-value]. Example 12-2 provides a sample prefix list named PRIVATE-IPV6.

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). The BGP table can be parsed with regex by using the command show bgp afi safi regexp regex-pattern.

• indicates the start of a string, $ indicates the end of a string, _ matches a space, + matches one or more instance, ? matches one or no instances, [] match a single character or nesting within a range, – is for a range

Table 12-6 Common BGP Regular Expressions

  Other useful information:

• Full ENCOR Course
• CCNP Enterprise Certificate Information
• 350-401 ENCOR Exam Questions and Solutions
• 350-401 ENCOR Exam Topics