Effective BGP Policy Control

Throughout this book, you have learned that BGP is first and foremost a policy tool. This results in BGP's being used to build very complex policy-based architectures. The protocol itself provides a list of attributes through which you can set policies. Additionally, Cisco IOS software further expands and enhances what is available with additional tools and knobs. This chapter examines these tools and how you can use them to build complex and effective BGP policies.

Policy Control Techniques

BGP employs many common policy control techniques. This section starts with regular expressions and then describes various forms of filter lists, route maps, and policy lists.

Regular Expression

A regular expression is a formula for matching strings that follow a certain pattern. It evaluates text data and returns an answer of true or false. In other words, either the expression correctly describes the data, or it does not.

A regular expression is foremost a tool. For example, a regular expression can help extract the needed information from a large IOS output quickly, as shown in Example 4-1.

Example 4-1 Regular Expression to Extract All Neighbors' Maximum Data Segment Sizes

R2#show ip bgp neighbors | include max data segment
Datagrams (max data segment is 1460 bytes):
Datagrams (max data segment is 1460 bytes):
Datagrams (max data segment is 1460 bytes):

As a formula, a regular expression allows pattern matching in BGP AS_PATH and community policy settings. Example 4-2 shows the use of a regular expression to describe an AS_PATH pattern that matches all AS_PATHs that are originated from the neighboring AS 100.

Example 4-2 Regular Expression Matches AS_PATH Patterns

ip as-path access-list permit ^(100_)+$

Components of a Regular Expression

A regular expression consists of two types of characters:

• Characters to be matched, or regular characters

• Control characters or metacharacters that have special meanings

To really make good use of regular expressions, it is critical to understand the control characters and how they are used. Control characters can be grouped into three types:

• Atom characters, or atoms—An atom is an independent control character or placeholder character that defines or expands the regular characters that are before or after it. Some atoms can be standalone, without regular characters.

• Multiplier characters, or multipliers—A multiplier follows an atom or a regular character and is used to describe repetitions of the character immediately before it. Except for the dot (.) character, all other atom characters must be grouped with regular characters before a multiplier is appended.

• Range characters—Range characters (brackets) specify a complete range.

Table 4-1 lists the common atom characters.

Table 4-1 Common Atom Characters and Their Usage

Some simple examples are listed in Table 4-2.

Table 4-2 Examples of Atoms

Table 4-3 shows the common multiplier characters.

Table 4-3 Multipliers and Their Usage

A multiplier can be applied to a single-character pattern or a multicharacter pattern. To apply a multiplier to a multicharacter pattern, enclose the pattern in parentheses. Some simple examples are shown in Table 4-4.

Table 4-4 Examples of Multipliers

The characters [ ] describe a range. Only one of the characters within the range is matched. You can make the matching exclusive by using the caret (^) character at the start of the range to exclude all the characters within the range. You can also specify a range by providing only the beginning and the ending characters separated by a dash (-). Some simple examples are shown in Table 4-5.

Table 4-5 Examples of Ranges

How to Use Regular Expressions in Cisco IOS Software

Regular expressions in IOS are only a subset of what is available from other operating systems. The use of regular expressions within IOS can be generally described in two categories:

• Filtering the command output

• Pattern matching to define policies

Regular expressions can be used in filtering outputs of show and more commands. The entire line is treated as one string. Table 4-6 shows the three types of filtering that can be done on an output.

Table 4-6 Regular Expressions Used to Perform Three Types of Output Filtering

To filter the output, send the output with a pipe character (|) followed by the keyword and a regular expression. For example, show run | begin router bgp shows the part of the running configuration that begins with router bgp. To interrupt the filtered output, press Ctrl-^ (press Ctrl, Shift, and 6 at the same time). Example 4-3 shows an example of filtering show ip cef output to show all the prefixes associated with the interface Ethernet0/0.

Example 4-3 Filtering show ip cef Output with a Regular Expression

R1#show ip cef | include Ethernet0/0
172.16.0.0/16    192.168.12.2     Ethernet0/0
192.168.12.0/24   attached       Ethernet0/0
192.168.12.2/32   192.168.12.2     Ethernet0/0
192.168.23.0/24   192.168.12.2     Ethernet0/0
192.168.25.0/24   192.168.12.2     Ethernet0/0
192.168.36.0/24   192.168.12.2     Ethernet0/0

Regular expressions are used extensively in pattern matching to define BGP policies, such as AS_PATH filtering. The AS_PATH attribute lists, in reverse order, the AS numbers, separated by blank spaces, that the prefix has traversed. You can use the command show ip bgp regexp to verify the result of the configured regular expressions.

Table 4-7 shows some examples of common AS_PATH pattern matching using regular expressions.

Table 4-7 Examples of AS_PATH Pattern Matching Using Regular Expressions

Filter Lists for Enforcing BGP Policies

Filter lists are used extensively in BGP to define policies. This section covers prefix lists, AS path lists, and community lists.

Prefix Lists

Prefix lists are used to filter IP prefixes and can match both the prefix number and the prefix length. Compared to regular access lists, use of prefix lists provides higher performance (fewer CPU cycles).

A prefix list entry follows the same general format as an IP access control list (ACL). An IP prefix list consists of a name for the list, an action for the list (permit/deny), the prefix number, and the prefix length. Here is the basic format of an IP prefix list:

ip prefix-list name [seq seq] {deny | permit} prefix/length

Any prefixes entered are automatically converted to match the length value entered. For example, entering 10.1.2.0/8 results in 10.0.0.0/8. Example 4-4 shows a simple example of matching 172.16.1.0/24. As with an access list, a deny-all entry is implied at the end of the list.

Example 4-4 Matching 172.16.1.0/24

ip prefix-list out-1 permit 172.16.1.0/24

Optionally, a sequence number can be supplied for each entry. By default, the sequence numbers are automatically generated in increments of 5. They can be suppressed with the command no ip prefix-list seq. Entries are processed sequentially based on the sequence number. The use of sequence numbers offers flexibility when modifying a portion of a prefix list.

With the basic form of the prefix list, an exact match of both prefix number and prefix length is assumed. In Example 4-4, the prefix list matches only the prefix 172.16.1.0/24. The prefixes 172.16.1.128/25 and 172.16.1.0/25, for example, are not matched.

To match a range of prefixes and lengths, additional optional keywords are needed. When a range ends at /32, the greater-than-or-equal-to (ge) can be specified. The value of ge must be greater than the length value specified by prefix/length and not greater than 32. The range is assumed to be from the ge value to 32 if only the ge attribute is specified. If the range does not end at 32, another keyword, le, must be specified. The use of le is discussed later in this section.

Example 4-5 shows an example of matching a portion of 172.16.0.0/16. Notice that the range is between /17 and /32, inclusive. Thus, the network 172.16.0.0/16 is excluded from the match. The legacy extended ACL version is also included for comparison.

Example 4-5 atching a Portion of 172.16.0.0 255.255.0.0

ip prefix-list range-1 permit 172.16.0.0/16 ge 17
!
access-list 100 permit ip 172.16.0.0 0.0.255.255 255.255.128.0 0.0.127.255

access-list 100 deny ip host 172.16.0.0 host 255.255.0.0

access-list 100 permit ip 172.16.0.0 0.0.255.255 255.255.0.0 0.0.255.255

access-list 100 deny ip any 255.255.255.128 0.0.0.127

The range can also be specified by the less-than-or-equal-to (le) attribute, which goes from the length value specified by prefix/length to the le value, inclusive. Example 4-6 shows an example of matching the entire range of 172.16.0.0/16—that is, 172.16.0.0 255.255.0.0 using the regular mask or 172.16.0.0 0.0.255.255 using the inverted mask. If you want to specify a range that does not start from the length, you must specify another keyword, ge, as discussed next.

Example 4-6 Matching the Entire Class B Range of 172.16.0.0/16

ip prefix-list range-2 permit 172.16.0.0/16 le 32

Example 4-7 shows another example. Both the prefix list and the ACL versions are shown.

Example 4-7 Matching 172.16.0.0 255.255.224.0

ip prefix-list range-3 permit 172.16.0.0/19 le 32
!
access-list 100 permit ip 172.16.0.0 0.0.31.255 255.255.224.0 0.0.31.255

When both ge and le attributes are specified, the range goes from the ge value to the le value. A specified ge value and/or le value must satisfy the following condition:

length < ge value <= le value <= 32

The expanded prefix list format follows. Note that the ge attribute must be specified before the le value:

ip prefix-list name [seq #] deny | permit prefix/length [ge value] [le value]

Example 4-8 shows an example of using both ge and le attributes to match a portion of 172.16.1.0/24. The ACL version is also included.

Example 4-8 Matching a Portion of 172.16.1.0 255.255.255.0

ip prefix-list range-3 permit 172.16.1.0/24 ge 25 le 31
!
access-list 100 permit ip 172.16.1.0 0.0.0.255 255.255.255.128 0.0.0.126

Note that 172.16.1.0/24 is not in the range, nor are all the /32s. The matched ranges include all the following prefixes:

• Two /25s—172.16.1.0/25, 172.16.1.128/25

• Four /26s—172.16.1.0/26, 172.16.1.64/26, ..., 172.16.1.192/26

• Eight /27s—172.16.1.0/27, 172.16.1.32/27, ..., 172.16.1.224/27

• 16 /28s—172.16.1.0/28, 172.16.1.16/28, ..., 172.16.1.240/28

• 32 /29s—172.16.1.0/29, 172.16.1.8/29, ..., 172.16.1.248/29

• 64 /30s—172.16.1.0/30, 172.16.1.4/30, ..., 172.16.1.252/30

• 128 /31s—172.16.1.0/31, 172.16.1.2/31, ..., 172.16.1.254/31

Table 4-8 shows more examples of prefix lists.

Table 4-8 Additional Examples of Prefix Lists

AS Path Lists

AS path filters are used to filter the BGP AS_PATH attribute. The attribute pattern is defined by a regular expression string, either permitted or denied per the list's action. With regular expressions and AS path filters, you can build complex BGP policies.

The AS path list is defined by the ip as-path access-list command. The access-list-number is an integer from 1 to 500 that represents the list in the global configuration:

ip as-path access-list access-list-number {permit | deny} as-regular-expression

The filter can be applied in a BGP neighbor command using a filter list or in a route map (discussed in the later section "Route Maps"). Example 4-9 shows the use of an AS path filter to allow incoming routes from peer 192.168.1.1 that are only originated in AS 100.

Example 4-9 Path Filter to Permit Only Routes Originated from AS 100

neighbor 192.168.1.1 filter-list 1 in
!
ip as-path access-list 1 permit _100$

Community Lists

Community lists are used to identify and filter routes by their common community attributes. There are two forms of community lists: numbered and named. Within each category, there are also standard and expanded formats. A standard format allows actual community values or well-known constants, and an expanded format allows communities to be entered as a regular expression string. There is a limit of 100 for either format of the numbered lists (1 to 99 for the standard format and 100 to 199 for the expanded format), but named lists have no limit. The general formats are as follows:

• Standard numbered list:

ip community-list list-number {permit | deny} community-number

• Expanded numbered list:

ip community-list list-number {permit | deny} regular-expression

• Standard named list:

ip community-list standard list-name {permit | deny} community-number

• Expanded named list:

ip community-list expanded list-name {permit | deny} regular-expression

By default, the community-number value is a 32-bit number between 1 and 4294967295. If you enter it in the aa:nn format (the new format), the resulting format is converted to a 32-bit number. If you enable the new format globally using ip bgp-community new-format, the new format is displayed. This change is immediate. Note that the format you choose is important, because the filtering using a regular expression in an expanded list can have different results for different formats.

One or more community numbers (separated by a space) can be entered per entry, or multiple entries can be entered per list number or name. When multiple communities are entered into the same entry, a match is found only when all communities match the condition—that is, an AND comparison. When multiple entries are entered for the same list number or name, a match is found when any entry matches—that is, an OR comparison. Example 4-10 shows two forms of community lists.

Example 4-10 Two Ways of Entering Community Lists

ip community-list 1 permit 100:1 100:2
ip community-list 2 permit 100:1
ip community-list 2 permit 100:2

With list 1, a match is found only when both community values of 100:1 and 100:2 are attached to a prefix. For list 2, a match is found if a prefix has a community with either 100:1 or 100:2 or both. Note that the rules stated here apply only to matching community values. They do not indicate whether a community is permitted or denied. For example, if the community list 2 in Example 4-10 is changed to deny 100:1 and 100:2 and to permit all other community values, a prefix with a community of 100:1 and 100:2 results in a match, and the prefix is denied.

Besides private communities, there are four well-known communities, as discussed in Chapter 2, "Understanding BGP Building Blocks"—internet, no-export, local-as, and no-advertise.

Community values for a prefix can be set or reset in two ways:

• Use a set clause within a route map to set a community value, to add a community value (additive), or to remove all community values:

set community {community-value [additive]} | none

• Use a set clause within a route map to selectively remove some community values:

set comm-list community-list-number delete

This route map set command removes communities from the community attribute of an inbound or outbound update. Each community that matches the given community list is removed from the community attribute. When used with this command, each entry of a standard community list should list only one community.

Route Maps

A route map is a flexible and powerful way to set BGP policies. It can set and reset both prefixes and BGP attributes based on predefined conditions. A route map is often used to define policies toward a BGP peer or during route generation. A route map can filter updates based on prefix, AS_PATH, communities, metrics, next hop, ORIGIN, LOCAL_PREF, WEIGHT, and so on. A route map often uses policy control lists to define BGP policies.

A route map is a named group of filters consisting of one or more instances. Each instance is identified by a unique sequence number that determines the order of processing. Instances are applied sequentially. If a match is found, the rest of the route map is skipped. If the route map is finished without a match, a deny action is performed. When used in the neighbor command, only one route map per type per direction is allowed for each neighbor.

Within each instance, you can set conditions using the match clause and set actions using the set clause. Example 4-11 shows a simple route map named Set-comm, which resets communities to 200:100 when updates are originated from AS 100.

Example 4-11 Simple Route Map Example

ip as-path access-list 1 permit _100$
!
route-map Set-comm permit 10
 match as-path 1
 set community 200:100
route-map Set-comm permit 20

The second instance (with sequence number 20) is important, because without it, all other updates that don't match the first instance are not accepted. When no match clause is specified under an instance, the result is to permit any. This instance basically means that no action should be taken for prefixes that do not match the conditions in the first instance.

There are two ways to match more than one condition. You can enter multiple conditions in the same match command or in different match commands. The processing rules are as follows:

• An OR function is performed between multiple match parameters defined in the same match command, regardless of the type of match commands.

• An OR function is performed when there are multiple match commands of the same type. Actually, IOS converts this form into the form discussed in the preceding bullet.

• An AND function is performed if there are multiple match commands of different types in the same route map instance.

Example 4-12 shows how the preceding rules work. The route map foo matches either community 100:1 or 100:2. With the route map foo2, a match is found only when the prefix and both communities are matched.

Example 4-12 Processing Example When Multiple Conditions Are Set with match Commands

ip community-list 1 permit 100:1
ip community-list 2 permit 100:2
ip community-list 3 permit 100:1 100:2
!
ip prefix-list 1 seq 5 permit 13.0.0.0/8
!
route-map foo permit 10
 match community 1 2
!
route-map foo2 permit 10
 match ip address prefix-list 1
 match community 3

You can use a route map in the following BGP commands:

• neighbor

• bgp dampening

• network

• redistribute

Additionally, you can use route maps in various commands for specific purposes:

• suppress-map

• unsuppress-map

• advertise-map

• inject-map

• exist-map

• non-exist-map

• table-map

Policy Lists

Complex route maps often have more than one match clause of different types. In a medium to large network, many of the same match clauses are reused repeatedly by different route maps. If the same sets of match clauses can be extracted from a route map, they can be reused by more than one route map or in different instances of the same route map. These independent match clauses are called policy lists.

A policy list is a subset of route maps that contains only match clauses. When a policy list is referenced in another route map, all the match clauses are evaluated and processed as if they were configured directly in the route map. Match clauses are configured in policy lists with permit or deny statements. The route map evaluates and processes each match clause and permits or denies routes based on the configuration in the referenced policy list.

A policy list is configured with the ip policy-list command and is referenced within another route map using the match policy-list command. Two or more policy lists can be referenced within a route map, and each entry can contain one or more policy lists. When multiple policy lists are configured in the same match policy-list command, it is an OR operation; when multiple match policy-list statements are configured, it is an AND operation. The policy lists and all other match and set options within a route map instance can coexist.

Example 4-13 shows a route map configuration using policy lists. Two policy lists are configured: as100 and as200. In as100, a match is found when both the AS path starts with AS 100 and the community is 300:105. In as200, a match is found when the AS path starts with AS 200 and the community is 300:105. With the route map foo, first a match is made to select the prefix to be 10.0.0.0/8, and then an OR operation is made for the two policy lists. The final action is to change the local preference to 105 for the updates that match.

Example 4-13 Example of Policy List Configuration

ip prefix-list 1 permit 10.0.0.0/8
ip as-path access-list 1 permit ^100_
ip as-path access-list 2 permit ^200_
ip community-list 1 permit 300:105
!
ip policy-list as100 permit
 match as-path 1
 match community 1
!
ip policy-list as200 permit
 match as-path 2
 match community 1
!
route-map foo permit 10
 match ip address prefix-list 1
 match policy-list as100 as200
 set local-preference 105
route-map foo permit 20

Filter Processing Order

When multiple filters are configured per neighbor, each filter is processed in a specific order, as shown in Figure 4-1. For inbound updates, the filter list is processed first, followed by the route map. The distribute list or prefix list is processed last. On the outbound side, the distribute list or prefix list is processed first, and then the prefix list received via Outbound Route Filtering (ORF), and then the filter list. The route map is processed last.

Figure 4-1 Filter Processing Order

An update has to pass through all the filters. One filter does not take precedence over another. If any filter does not match, the update is not permitted. For example, if an inbound update is permitted by the filter list and the route map but is denied by the prefix list, the update is denied. The same rule applies on the outbound side.

When a policy for a neighbor is configured in the neighbor command but the policy is not defined, the following are the default behaviors:

• For distribute lists and prefix lists, permit any.

• For filter lists and route maps, deny any.