Sunday, January 29, 2012

BGP Route Filtering

The neighbor {ip-addr | peer-group-name} distribute-list {acl-num | acl-name | ip-prefix name} {in | out} BGP router subcommand filters the routing information to be advertised to a BGP neighbor or peer group based upon the specified access list.

BGP Route Filtering using Distribute List

Below shows that RT2 does not advertise the subnets that match 172.16.0.0 in the first 2 octets to RT1.
RT2#sh ip bgp
BGP table version is 5, local router ID is 24.24.24.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.16.0/24   24.24.24.4               0             0 65004 i
*> 172.16.17.0/24   24.24.24.4               0             0 65004 i
*> 192.168.16.0     23.23.23.3               0             0 65003 i
*> 192.168.17.0     23.23.23.3               0             0 65003 i
RT2#
RT2#sh access-lists
Standard IP access list 1
    10 deny   172.16.0.0, wildcard bits 0.0.255.255 (2 matches)
    20 permit any (2 matches)
RT2#
======================================================================
RT1#sh ip bgp
BGP table version is 3, local router ID is 12.12.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.16.0     12.12.12.2                             0 65002 65003 i
*> 192.168.17.0     12.12.12.2                             0 65002 65003 i
RT1#

Extended ACLs should be used to configure route filtering when using CIDR as they provide the granularity level that is necessary for advanced filtering of network addresses and masks.

Note that distribute lists for BGP have been made obsolete by prefix lists in the Cisco IOS. Prefix lists are available in Cisco IOS Release 12.0 and later. However, note that both the neighbor distribute-list and the neighbor prefix-list BGP router subcommands cannot be applied upon a particular neighbor or peer group in any direction (inbound or outbound). They are mutually exclusive, in which only either one can be applied upon each direction.

The neighbor {ip-addr | peer-group-name} prefix-list {ip-prefix-name} {in | out} BGP router subcommand filters the routing information to be advertised to a BGP neighbor or peer group based upon the specified prefix list.

The prefix list sequence numbers are generated automatically. The no ip prefix-list sequence-number global configuration command disables the automatic generation of sequence numbers for entries in a prefix list.

BGP Route Filtering using Prefix List

By implementing route filtering using prefix list on RT2, RT2 advertises the aggregate route to RT1 without using the summary-only keyword, and therefore no routes are being suppressed.
RT2#sh ip bgp
BGP table version is 7, local router ID is 24.24.24.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0       0.0.0.0                            32768 i
*> 172.16.16.0/24   24.24.24.4               0             0 65004 i
*> 172.16.17.0/24   24.24.24.4               0             0 65004 i
*> 192.168.0.0/16   0.0.0.0                            32768 i
*> 192.168.16.0     23.23.23.3               0             0 65003 i
*> 192.168.17.0     23.23.23.3               0             0 65003 i
RT2#
RT2#sh ip bgp neighbors 12.12.12.1 advertised-routes
BGP table version is 7, local router ID is 24.24.24.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0       0.0.0.0                            32768 i
*> 192.168.0.0/16   0.0.0.0                            32768 i
RT2#
RT2#sh ip prefix-list
ip prefix-list supernet-only: 2 entries
   seq 5 permit 172.16.0.0/16
   seq 10 permit 192.168.0.0/16
RT2#
RT2#sh ip prefix-list detail
Prefix-list with the last deletion/insertion: supernet-only
ip prefix-list supernet-only:
   Description: *** only advertises supernets ***
   count: 2, range entries: 0, sequences: 5 - 10, refcount: 3
   seq 5 permit 172.16.0.0/16 (hit count: 1, refcount: 2)
   seq 10 permit 192.168.0.0/16 (hit count: 1, refcount: 1)
RT2#

The clear ip prefix-list privileged command resets the hit counts shown on prefix list entries.

An ISP always perform inbound filtering upon the routes learned from its customers or peers to restrict them to advertise only the networks that actually assigned to them in order to protect against address hijacking throughout the Internet, eg: the AS7007 incident on 25th Apr 1997.

The earlier sections discuss BGP route filtering based upon prefixes. The following section starts with the discussion of regular expressions and followed by implementing BGP filter list that filter routes based upon AS paths.

A regular expression is a formula for matching text strings according to a certain pattern and returns an answer of TRUE or FALSE – whether the expression describes the data, or it doesn’t. Regular expressions can be used for filtering outputs of the show and more commands.

A regular expression consists of 2 types of characters:
  • Regular characters that represents the characters to be matched.
  • Control characters (or metacharacters) that have special meanings.
Control characters can be grouped into 3 types:
  • Atom characters (or atoms) – an atom is an independent control 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 to describe repetitions of the character immediately before it. Except the dot character (.), all atom characters must be grouped with regular characters before a multiplier is appended.
  • Range characters are brackets that specify a complete range.

Note: Press Ctrl+V (escape sequence for Cisco IOS CLI) followed by ? to input a question mark (?) into a regular expression.
Below lists the common atom characters and their usages:

. (Period / Dot) Matches any single character, including a blank space.
^ (Caret) Matches the beginning character of the input string.
$ (Dollar sign) Matches the ending character of the input string.
_ (Underscore) Matches a comma (,), underscore (_), left brace ({), right brace (}), left parenthesis ((), right parenthesis ()), the beginning of the input string (^), the end of the input string ($), or a blank space.
| (Pipe) Operates as the Boolean OR operand that matches either of 2 strings.
\ (backslash) Escape character that turns a succeeding control character that follows immediately into a regular character.
Below shows some simple examples of atoms:

^a.$ Matches a string that begins with character a and ends with any single character. Ex: ab, ax, a., a!, a0, etc.
^100_ Matches 100, 100 200, 100 200 300, 100 300 400, etc.
^100$ Matches 100 only.
^100_200_ Matches 100 200, 100 200 300, etc.
100$|200$ Matches 100, 2100, 100 200, 200, 100 100, 1100 2200, 400 200, etc.
^\(65000\)$ Matches (65000) only.
Below lists the common multiplier characters and their usages:

* (Asterisk) Matches zero or more occurrences of the preceding character or pattern.
+ (Plus sign) Matches one or more occurrences of the preceding character or pattern.
? (Question mark) Matches zero or one occurrences of the preceding character or pattern.
A multiplier can be applied upon single- or multiple-character patterns.
To apply a multiplier upon a multi-character pattern, enclose the pattern in parenthesis.
Below shows some simple examples of multipliers:

abc*d Matches abd, abcd, abccd, abcccd, xabcccde, abcde, xabcde, cabcd, etc.
abc+d Matches abcd, abccd, abcccd, xabcccde, abcde, xabcde, cabcd, etc.
abc?d Matches abd, abcd, abcde, xabcde, cabcd, etc.
a(bc)?d Matches ad, abcd, cad, cabcd, abcde, xabcde, etc.
a(b.)*d Matches ad, abcd, abcde, xabcde, cad, cabcd, ab0d, ab0b0d, abxd, abxbxd, etc.

The brackets [ ] describe a range of single-character patterns; only one of the characters within the range will be matched. An exclusive match can be made specifying the caret character (^) at the start of the range to exclude (negate) all the characters within the range. The beginning and the ending characters of a range can also be specified using the dash or hyphen character (-).
Below shows some simple examples of multipliers:

[aeiouAEIOU] Matches any string that contains a, e, i, o, u, A, E, I, O, or U.
Ex: a, aa, Aa, eA, x2u, etc.
[a-c1-2]$ Matches any string that ends with a, b, c, 1, or 2.
Ex: a, 1b, a1, 62, xv2, etc.
[^act]$ Matches any string that does not ends with a, c, and t.
Ex: d, efg*, low2, actor, path, etc.
[^a-dA-D] Matches any single character except a, b, c, d, A, B, C, and D.

Regular expressions are used extensively in pattern matching when defining BGP policies, eg: AS Path Filtering. The AS_PATH attribute lists the ASNs that a prefix has traversed, in reverse order and separated by spaces. The show ip bgp regexp {regexp} EXEC command displays BGP routes matching the regular expression upon the AS_PATH attribute information.

Below shows some examples of common AS_PATH pattern matching using regular expressions:

^$ Matches an empty AS path list – all local routes that originated from the local AS.
.* Matches all paths.
^100$ Matches all paths that start and end with AS 100, which are updates that only originated and sent from AS 100, no AS path prepending and no intermediary. The ^ and $ characters define the border of the input string.
_100$ Matches all routes that originated from AS 100, including those prepended with 100, eg: 100, 100 100, 200 100, etc.
The underscore character limits the AS number to be exactly 100 and not 1100 or 2100.
^100_ Matches all paths that received from neighboring AS 100, including those prepended with 100, eg: 100, 100 100, 100 200, 100 200 200, 100 300 200, etc.
_100_ Matches all paths that passed through AS 100 but not necessarily originated from or received directly from AS 100, eg: 100, 100 200, 200 100, 200 100 300, etc.
^100(_100)*(_200)*$ Matches all paths from AS 100 and its immediate neighbor AS 200, eg: 100, 100 100, 100 200, 100 200 200, 100 100 100 200 200, etc.

Filtering based on the AS_PATH information is quite effective as it filters the routing updates that contain certain AS_PATH; compared to inefficiency and complexity of matching thousands of prefixes individually and defining the paths to become members of BGP communities.

AS path filter lists are used to filter prefixes based on the BGP AS_PATH attribute information. An AS path filter list entry matches the AS_PATH attribute pattern using a regular expression along with a permit or deny action. The ip as-path access-list {acl-num} {permit | deny} {as-path-regex} global configuration command configures an autonomous system path filter. The permit and deny keywords permit and deny advertisement based on matching conditions. AS path filters can be applied upon inbound and outbound BGP route advertisements using the neighbor {ip-addr | peer-group-name} filter-list {as-path-filter-acl-num} {in | out} BGP router subcommand. The AS path access list number is in the range of 1 to 500, inclusive. The show ip bgp filter-list {acl-num} EXEC command displays BGP routes that conform to a specified filter list.

Many disastrous Internet outages have occurred over the past due to misconfigurations and software bugs in BGP implementations; false updates, de-aggregation, and prefix hijacking in which an AS announces the routes that it does not have would eventually cause blackholing.

Any serious and security-aware ISP should perform some sanity checks upon the BGP routes received from its customer instead of blindly accepting them. This would prevent a multi-homed customer from advertising BGP routes between its service providers and becomes a transit AS. The simple filter – all BGP routes from a customer should contain only its ASN in the AS path.

BGP Route Filtering using AS Path Filter List

The initial non-scalable approach would be accept only the paths that have exactly the ASN of the customer in the AS path, eg: ip as-path access-list 1 permit ^65001$.
A more generic approach is recognize a single ASN using ^[0-9]+$ instead.
The [0-9] pattern matches a single digit.
The [0-9]+ pattern matches one or more digits – a number.

Both filters above have a problem; they fail when the customer implements AS path prepending. The filter must be able to recognize a single number that is potentially repeating multiple times. Below lists the filters that are applicable for this sample scenario to achieve the mentioned task.
ip as-path access-list 1 permit ^(1001_)+$
ip as-path access-list 1 permit ^1001(_1001)*$
ip as-path access-list 1 permit ^(1001)(_\1)*$

And the more generic filter is ip as-path access-list 1 permit ^([0-9]+)(_\1)*$
The \1 in the filter is used for pattern recall, in which it can match a pattern recognized earlier in the regular expression – the 1st ASN in the AS path as matched by the regular expression within the 1st parenthesis.

The 1st entry in the AS path filter list above is used to deny all paths that contain private ASNs.

BGP Filter Processing Order

When multiple filters (distribute list, prefix list, filter list, route map) are configured for a neighbor, the filters are processed in a specific order as shown in the figure above.
For inbound updates, the filter list is processed first, followed by the route map. The distribute list or prefix list is processed last.
For outbound updates, the distribute list or prefix list is processed first, followed by the prefix list
received via BGP Outbound Route Filtering, and then the filter list. The route map is processed last.

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.
Ex: An inbound update is permitted by a filter list and a route map but is denied by a prefix list, the update is denied. The same rule applies upon the outbound updates.

When a policy is configured for a neighbor but the policy is not defined, the default behaviors are:
  • For distribute lists and prefix lists, permit any. Routes will be advertised to a neighbor configured with an undefined distribute list or prefix list.
  • For filter lists and route maps, deny any. Caution: No routes will be advertised to; and the advertised routes will be withdrawn from a neighbor configured with an undefined filter list or route map. Routes that are not matched by a filter list or route map will also be denied and not being advertised to; or withdrawn from a neighbor.
BGP communities provide a way to group and tag prefixes, which then allow routers to match and followed by setting and manipulating various BGP path attributes upon them for some tasks, eg: route filtering. It is inefficient to implement distribute lists and prefix lists for large networks with complex routing policies, eg: individual neighbor statements along with the corresponding access lists and prefix lists must be configured for each neighbor on each router involved.

Route maps provide the only mechanism to set BGP communities through the set community {comm-value [comm-value…] [additive] | none} route map configuration subcommand. The community value can be entered as a decimal number or in the AA:NN format. Communities are shown as numeric numbers by default. It is recommended to implement the ip bgp-community new-format global configuration command to display BGP communities in the AA:NN format to conform with RFC 1997. This command only affects the format in which BGP communities are displayed; it does not affect communities and community exchange.

Note that the set community command removes existing communities attached to a prefix and replaces them with the new set of communities unless the optional additive keyword is used to specify that a community is to be added to the already existing communities. The none keyword
removes the communities from the prefixes that are being matched and processed by the route map.

The neighbor {ip-addr | peer-group-name} route-map {tag} {in | out} BGP router subcommand applies a route map upon incoming or outgoing updates. The neighbor {ip-addr | peer-group-name} send-community BGP router subcommand specifies that the BGP COMMUNITY path attribute should be send to a BGP neighbor. BGP community exchange is not enabled by default; in which communities are removed in outgoing BGP updates.

The ip community-list {comm-list-num | {[standard | expanded] comm-list-name}} {permit | deny} {comm-value [comm-value…]} global configuration command creates a community list for BGP to perform policy-based access control. The community list number is in the range of 1 to 99 for standard community lists; and 100 to 500 for expanded community lists.

Standard community lists are used to configure well-known communities and specific community numbers. A maximum of 16 communities can be configured in a standard community list. Trailing communities that exceed the limit will be omitted.
Expanded community lists are used to filter communities using a regular expression.

When multiple community values are configured in a single community list statement, a logical AND processing will be performed – all the community values must be matched. When multiple community values are configured in separate community list statements, a logical OR processing will be performed – the first list that matches a condition is processed.

The match community {comm-list-num | comm-list-name} [exact-match] route map subcommand is used to match a BGP COMMUNITY attribute upon a value in a community list. The optional exact-match keyword indicates that an exact match is required, in which all of the communities and only those communities in the community list(s) must be present in the BGP COMMUNITY attribute of a path.

BGP Communities

Below shows the configuration on RT3 and the communities set upon the routes originated from AS 100 and AS 200. Any route whose COMMUNITY attribute matches community list 1 has its WEIGHT attribute set to 100. Community list 1 matches routes with a community value of 100:1 – all the routes that originated from AS 100.
!
router bgp 300
 no synchronization
 bgp log-neighbor-changes
 neighbor 23.23.23.2 remote-as 200
 neighbor 23.23.23.2 route-map CHK-SET-COMM in
 no auto-summary
!
ip bgp-community new-format
ip community-list 1 permit 100:1
ip community-list 2 permit internet
!
route-map CHK-SET-COMM permit 10
 match community 1
 set weight 100
!
route-map CHK-SET-COMM permit 20
 match community 2
!
======================================================================
RT3#sh ip bgp
BGP table version is 7, local router ID is 23.23.23.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.100.1.0/24    23.23.23.2                           100 200 100 i
*> 10.100.2.0/24    23.23.23.2                           100 200 100 i
*> 10.100.3.0/24    23.23.23.2                           100 200 100 i
*> 10.200.1.0/24    23.23.23.2               0             0 200 i
*> 10.200.2.0/24    23.23.23.2               0             0 200 i
*> 10.200.3.0/24    23.23.23.2               0             0 200 i
RT3#
RT3#sh ip bgp 10.100.1.0
BGP routing table entry for 10.100.1.0/24, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  200 100
    23.23.23.2 from 23.23.23.2 (23.23.23.2)
      Origin IGP, localpref 100, weight 100, valid, external, best
      Community: 100:1 200:1
RT3#
RT3#sh ip bgp 10.200.1.0
BGP routing table entry for 10.200.1.0/24, version 5
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  200
    23.23.23.2 from 23.23.23.2 (23.23.23.2)
      Origin IGP, metric 0, localpref 100, valid, external, best
RT3#

No comments:

Post a Comment