Conditional Matching

Filtering of Prefixes by Route Policy

The last component for finding missing BGP routes is through the examination of the BGP routing policies. As stated before, BGP route policies are applied before routes are inserted into the Loc-RIB table and as prefixes leave the Loc-RIB before they are advertised to a BGP peer.

IOS and NX-OS devices provide three methods of filtering routes inbound or outbound for a specific BGP peer. Each method could be used individually or simultaneously with other methods. The three methods are as follows:

  1. Prefix-list: A list of prefix matching specifications that permit or deny network prefixes in a top-down fashion similar to an ACL. An implicit deny is associated for any prefix that is not permitted.
  2. AS-Path ACL/Filtering: A list of regex commands that allows for the permit or deny of a network prefix based on the current AS-Path values. An implicit deny is associated for any prefix that is not permitted.
  3. 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 for any prefix that is not permitted.

Conditional Matching

Prefix-lists, AS-Path filtering, route-maps, and route-policy language typically use some form of conditional matching so that only certain BGP prefixes are blocked or accepted. BGP prefixes can be conditionally matched by a variety of path attributes.

The most common techniques for conditionally matching a BGP prefix.

Access Control Lists (ACL)

Originally, 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 a method of identifying networks within a route-map that are then used in routing protocols for filtering or manipulating.

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. When 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 an earlier ACE in the ACL.

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. Extended ACLs were originally the only match criteria used by IOS with BGP before the introduction of prefix-lists.

				
					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 – /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 – /32 prefix length
				
			

Prefix Matching

Prefix lists (IOS and NX-OS) and prefix sets (IOS XR) provide another method of identifying networks in a routing protocol. They identify a specific IP address, network, or network range and allow for the selection of multiple networks with a variety of prefix lengths (subnet masks) by using a prefix match specification. This technique is preferred over the ACLs network selection method because it is easier to understand.

The structure for a prefix match specification contains two parts: high-order bit pattern and 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 length or mask length.

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

Basic Prefix Match Pattern

The prefix match specification logic might look identical to the functionality of an access-list. The true power and flexibility comes by using matching length parameters to identify multiple networks with specific prefix lengths with one statement. The matching length parameter options are as follows:

  • le (less than or equal to <=)
  • ge (greater than or equal to >=) or both

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

Prefix Match Pattern with Matching Length Parameters
  • The 10.168.0.0/13 prefix does not qualify 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 demonstrates a prefix match specification with a high-order bit pattern of 10.0.0.0, a high-order bit count of 8, and the matching length must be between 22 and 26.

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 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, matches.

BGP Communities

Conditionally matching BGP communities allows for selection of routes based upon the BGP communities within the route’s path attributes so that selective processing can occur in IOS route-map or IOS XR route policies. Conditionally matching on IOS and NX-OS devices requires the creation of a community list. A community list shares a similar structure to an ACL, can be standard or expanded, and can be referenced via number or name. Standard community lists are numbered 1-99 and match either well-known commnities or a private community number (as-number:16-bit-number). Expanded community lists are numbered 100-500 and use regex patterns.

Regular Expressions (Regex)

There may be times when conditionally matching off of network prefixes may be too complicated, and identifying all routes from a specific organization is preferred. In this manner, path selection can be made off of the BGP AS-Path.

To parse through the large amount of available ASNs (4,294,967,295), regular expressions (regex) are used. Regular expressions are based on query modifiers to select the appropriate content. The BGP table is parsed with regex using the command show bgp afi safi regexp regex-pattern. NX-OS devices require the regex-pattern to be placed within a pair of double quotes “”.

Regex Query Modifiers

Note: The .^$*+()[]? characters are special control characters that cannot be used without using the backslash (\) escape character. For example, to match on the * in the output you would use the \* syntax.

Examples

Regex Description
^$ Matches an empty AS PATH so it will match all prefixes from the local AS.
^100_ Matches prefixes from AS 100 that is directly connected to our AS.
_100_ Matches prefixes that transit AS 100.
_100$ Matches prefixes that originated in AS 100.
The $ ensures that it’s the beginning of the AS PATH.
^([0-9]+)_100 Matches prefixes from AS 100 where AS 100 is behind one of our directly connected AS’es.
^100_([0-9]+) Matches prefixes from the clients of directly connected AS 100.
^(100_)+([0-9]+) Matches prefixes from the clients of directly connected AS 100,
where AS 100 might be doing AS PATH prepending.
^\65200\) Matches prefixed from confederation peer 65200.

Scenario

UnderScore _

Query Modifier Function: Matches a space.
Scenario: Display only ASs that passed through AS 100.

Caret ^

Query Modifier Function: Indicates the start of the string.
Scenario: Display only routes that were advertised from AS 300.

Dollar Sign $

Query Modifier Function: Indicates the end of the string.
Scenario: Display only routes that originated in AS 40.

Brackets [ ]

Query Modifier Function: Matches a single character or nesting within a range.
Scenario: Display only routes with an AS that contains 11 or 14 in it.

Hyphen -

Query Modifier Function: Indicates a range of numbers in brackets.
Scenario: Display only routes with the last two digits of the AS of 40, 50, 60, 70, or 80.

Caret in Brackets [^]

Query Modifier Function: Excludes the character listed in brackets.
Scenario: Display only routes where the second AS from AS 100 or AS 300 does not start with 3, 4, 5, 6, 7, or 8. The first component of the regex query restricts the AS to the AS 100 or 300 with the regex query ^[13]00_, and the second component filters out ASs starting with 3-8 with the regex filter _[^3-8].

Parentheses ( ) and Pipe |

Query Modifier Function: Nesting of search patterns and provides or functionality.
Scenario: Display only routes where the AS_PATH ends with AS 40 or 45 in it.

Period .

Query Modifier Function: Matches a single character, including a space.
Scenario: Display only routes with an originating AS of 1-99. The regex
query _..$ requires a space, and then any character after that (including other spaces).

Plus Sign +

Query Modifier Function: One or more instances of the character or pattern.
Scenario: Display only routes where they contain at least one 10 in the AS path, but the pattern 100 should not be used in matching. When building this regex expression, the first portion is building the matching pattern of (10)+, and then add the restriction portion of the query of [^(100)]. The combined regex pattern is (10)+[^(100)].

Question Mark ?

Query Modifier Function: Matches one or no instances of the character or pattern.
Scenario: Display only routes from the neighboring AS or its directly connected AS (that is, restrict to two ASs away). This query is more complicated and requires you to define an initial query for identifying the AS, which is [0-9]+. The second component includes the space and an optional second AS. The ? limits the AS match to one or two ASs.

Asterisk *

Query Modifier Function: Matches zero or more characters or patterns.
Scenario: Display all routes from any AS. This may seem like a useless task but may be a valid requirement when using AS-Path access lists.

Leave a Reply

Related Post

BGP CommunitiesBGP Communities

BGP Communities BGP communities are an optional transitive BGP attribute that can traverse from autonomous system to autonomous system. A BGP community is a 32-bit number that can be included

Policy ControlPolicy Control

Policy Control Using BGP Attributes Most commonly used BGP attributes: LOCAL_PREF AS_PATH MED ORIGIN NEXT_HOP WEIGHT BGP picks a best path for a destination IP prefix from multiple paths and