Troubleshooting BGP Filtering
BGP offers a powerful filtering mechanism when advertising or receiving BGP routes. Filtering rules are defined based on the BGP peering relationship. An ISP might want to exchange full BGP routes to another ISP but might want to give only partial routes to its enterprise customer. On the other hand, an enterprise customer might want to advertise IP blocks that run in its network only to its provider (say, ISP 1) and might want to filter advertisements from all other Internet routes received from another provider (say, ISP 2). Such requirement easily might be met by using powerful filtering options available in Cisco BGP, which can use access-list filters (both standard and extended), AS_PATH filtering, community filtering, and prefix-list filtering. All of these filtering methods can be applied modularly through Cisco IOS Software route maps on a per-neighbor basis or directly to the neighbors. The only exception is community-based filtering, which can be applied only through the route map. This section discusses issues related to access-list, prefix-list, and AS_PATH–based filtering.
Problem: Standard Access List Fails to Capture Subnets
In IP networks, IP prefixes are sliced in different subnets, and the subnet mask carried in the routing table does identification of these subnets. The current Internet BGP table has many IP prefixes with identical network numbers but different masks. Example 15-98 shows such an example in which R4 has three different masked prefixes of 13.13.0.0. To illustrate this point, static routes are created in R4, as shown by output in Example 15-98. Furthermore, these static routes are advertised in BGP by the highlighted redistribute static command.
Example 15-98 Three Different Masked Static Routes of Same Network and Their Advertisement in BGP
R4#show ip route static 13.0.0.0/8 is variably subnetted, 3 subnets, 3 masks S 13.13.0.0/20 is directly connected, Serial 0 S 13.13.0.0/16 is directly connected, Serial 1 S 13.13.1.0/24 is directly connected, Serial 2 R4# router bgp 2 redistribute static neighbor 131.108.1.1 remote-as 1 no auto-summary
R1 is an EBGP neighbor of R4. R1’s goal is to receive only 13.13.0.0/16 and to filter any more specific routes of 13.13.0.0. Typically, R1 would use some sort of filtering to block these unwanted, more specific routes. Distribute lists are used commonly to block or allow paths in BGP. A BGP operator might use a standard or extended access list in concert with distribute lists. Standard access list do not allow filtering based on the subnet mask of the route, and this is the most common mistake that BGP operators do when applying standard access lists in distribute lists. Chapter 14 describes in some detail the difference between standard and extended access lists when used with distribute lists or in route maps.
Figure 15-53 shows the flowchart to follow to resolve this problem.
Debugs and Verification
Example 15-99 shows the BGP configuration of R1, with neighbor relationships and the distribute-list command using access list 1.
Example 15-99 BGP Configuration in R1 Using Standard Access List in distribute-list Command
R1# router bgp 1 neighbor 131.108.1.2 remote-as 2 neighbor 131.108.1.2 distribute-list 1 in access-list 1 permit 13.13.0.0 0.0.255.255
distribute-list 1 means that any BGP updates that come from 131.108.1.2 will be examined by access list 1.
Access list 1 has a permit statement for 13.13.0.0 with an exact match of the first two octets (13.13); it doesn’t care about the last two octets (0.0).
Standard access list 1 has no mention of a mask of 13.13.0.0, so all masks are accepted. The out-put in Example 15-100 shows that the BGP table in R1 is receiving all three masks of 13.13.0.0.
Example 15-100 Mask of BGP Update Is Ignored When a Distribute List Uses a Standard Access List
R1# show ip bgp BGP table version is 5, local router ID is 141.108.13.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - interna Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 13.13.0.0/20 131.108.1.2 0 0 2 ? *> 13.13.0.0/16 131.108.1.2 0 0 2 ? *> 13.13.1.0/24 131.108.1.2 0 0 2 ?
Solution
Use extended access lists or prefix lists that support proper mask check of routes when received in BGP. Example 15-101 shows usage of extended access list 101, which checks not only the network number (13.13.0.0) but also the mask of the update.
Example 15-101 Extended Access List Checks the Subnet Mask of the Prefix
R1# router bgp 1 neighbor 131.108.1.2 remote-as 2 neighbor 131.108.1.2 distribute-list 101 in access-list 101 permit ip 13.13.0.0 0.0.255.255 255.255.0.0 0.0.0.0
The extended access list has two parts:
The network part— 13.13.0.0 0.0.255.255, which allows 13.13.x.x, where x can any number between 0 and 255.
The mask part— 255.255.0.0 0.0.0.0. With all 0s in wildcard, the mask can only be 255.255.0.0, meaning /16.
The output in Example 15-102 shows that R1 is receiving only 13.13.0.0/16 after applying this change.
Example 15-102 Confirming Extended Access List Filters Routes Successfully
R1 #show ip bgp BGP table version is 5, local router ID is 141.108.13.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 13.13.0.0/16 131.108.1.2 0 0 2 ?
Problem: Extended Access Lists Fails to Capture the Correct Masked Route
To reduce the size of Internet BGP/routing tables, BGP operators are forced to advertise aggregated prefixes and suppress subnetted IP blocks. To achieve this, almost all ISPs expect their peering ISPs and customers to advertise aggregated blocks of, say, /21 (255.255.248.0) of IP blocks and will refuse to accept any prefix with a mask greater than /21. Proper BGP filtering must be in place at peering points so that prefixes with masks greater than /21 can be filtered out and only prefixes with masks less than /21 are accepted.
Many times, use of extended access lists is not understood properly, resulting in failure to capture subnetted prefixes with masks greater than /21, for example.
Figure 15-54 shows a simple two-ISP network running EBGP. ISP AS 109 is supposed to be advertising only three prefixes to ISP 2 AS 110. The expected prefixes are 100.100.100.0/21, 99.99.99.0/21, and 89.89.89.0/21. However, AS 109 has subdivided these IP blocks into smaller subnets, to assign them internally in the network.
Mistakenly, AS 109 is advertising all the tiny subnets to AS 110, resulting in its unnecessary increase in BGP and IP routing table size. This problem has two causes:
- AS 109 should filter subnets and advertise only the aggregated three prefixes.
- AS 110 should filter subnets and accept only the aggregated three prefixes.
Figure 15-55 shows the flowchart to follow to resolve this problem.
Debugs and Verification
Example 15-103 shows R1’s configuration to define static routes for subnetted blocks and BGP configuration to advertise these subnetted blocks to R2.
Example 15-103 Configuration in R1 to Create and Advertise Smaller Subnet Routes to R2
R1# ip route 100.100.100.0 255.255.248.0 Null0 ip route 100.100.100.128 255.255.255.128 serial 0 ip route 100.100.100.192 255.255.255.192 serial 1 ip route 99.99.99.0 255.255.248.0 Null 0 ip route 99.99.99.128 255.255.255.128 serial 2 ip route 99.99.99.192 255.255.255.192 serial 3 ip route 89.89.89.0 255.255.248.0 Null 0 ip route 89.89.89.128 255.255.255.128 serial 4 ip route 89.89.89.192 255.255.255.192 serial 5 router bgp 109 neighbor 131.108.1.2 remote-as 110 redistribute static no auto-summary
The redistribute static command redistributes these subnets in BGP and advertises to only neighbor R2 (131.108.1.2) in AS 110.
Example 15-104 shows R2 receiving all the subnets in its BGP table.
Example 15-104 R2 BGP Table Shows All Subnets Received
R2# show ip bgp BGP table version is 5, local router ID is 141.108.13.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 100.100.100.0/21 131.108.1.1 0 0 109 ? *> 100.100.100.128/25 131.108.1.1 0 0 109 ? *> 100.100.100.192/26 131.108.1.1 0 0 109 ? *> 99.99.99.0/21 131.108.1.1 0 0 109 ? *> 99.99.99.128/25 131.108.1.1 0 0 109 ? *> 99.99.99.192/26 131.108.1.1 0 0 109 ? *> 89.89.89.0/21 131.108.1.1 0 0 109 ? *> 89.89.89.128/25 131.108.1.1 0 0 109 ? *> 89.89.89.192/26 131.108.1.1 0 0 109 ?
The highlighted prefixes are the only prefixes that should have been accepted by R2. Moreover, those are only prefixes that R1 should have advertised to R2.
Solution
To solve this problem, either R1 should advertise only the /21s and block all the higher-mask prefixes, or R2 should block higher-mask prefixes and accept only /21s. This section discusses two methods to address this problem. Both solutions are generic enough for R1 and R2 to apply. If R1 uses the solution, it must apply the configuration on the outbound policy for R2; if R2 is applying the change, it must apply it as an inbound policy to R1.
The two solutions are as follows:
- Use an extended access list.
- Use a prefix list.
Extended Access List Solution
A generic filter needs to be created that can apply to any IP network but that has a tight filter for the mask of the prefix. With BGP filtering, you would use the following extended access list:
access-list 101 permit ip NETWORK WILD-CARD MASK WILD-CARD
A WILD-CARD of 0 means an exact match, whereas a WILD-CARD of 1 means “don’t care.”
An extended access list that would permit any IP network whose mask is /21 or lower (20, 19, and so on) is configured as follows:
access-list 101 permit ip 0.0.0.0 255.255.255.255 255.255.248.0 255.255.248.0 0.0.0.0 255.255.255.255 means any IP network.
255.255.248.0 255.255.248.0 means that a mask of this prefix can be only /21 or lower (/20, /19, and so on). Cisco IOS Software has an implicit deny at the end of each access list, so all prefixes whose masks are greater than 21 are denied.
Examples 15-105 and 15-106 demonstrate two methods in which access list 101 can be applied in R1.
Example 15-105 Applying Access List 101 with the distribute-list Command to the Neighbor
R1# router bgp 109 neighbor 131.108.1.2 remote-as 110 neighbor 131.108.1.2 distribute-list 101 Out
Example 15-106 Applying Access List 101 with the route-map Command to the Neighbor
router bgp 109 neighbor 131.108.1.2 remote-as 110 neighbor 131.108.1.2 route-map FILTERING out route-map FILTERING permit 10 match ip address 101
Both commands have the same effect of blocking the advertisement of any prefix with a mask greater than /21.
Examples 15-107 and 15-108 demonstrate two methods in which access list 101 can be applied in R2.
Example 15-107 Applying Access List 101 with the distribute-list Command to the Neighbor
R2# router bgp 110 neighbor 131.108.1.1 remote-as 109 neighbor 131.108.1.1 distribute-list 101 in
Example 15-108 Applying Access List 101 with the route-map Command to the Neighbor
R2# router bgp 110 neighbor 131.108.1.1 remote-as 109 neighbor 131.108.1.1 route-map FILTERING in route-map FILTERING permit 10 match ip address 101
Both commands have the same effect of blocking any prefix with a mask greater than /21.
Apart from distribute lists, prefix lists can be used to achieve the same goal.
You can apply the following prefix list to R1 and R2 in a similar fashion as a distribute list with both the neighbor statement and with a route map:
ip prefix-list FILTERING seq 5 permit 0.0.0.0/0 le 21
0.0.0.0 means any prefix, and /0 le 21 means that the mask of any prefix could be from 0 and less than or equal (le) to 21. All other higher-masked prefixes (/22, /25, /26, and so on) will be denied because of an implicit deny at the end of each Cisco IOS Software filter.
After applying the distribute list or prefix list in R1 or R2, Example 15-109 shows that the output of the BGP table in R2 is reduced to receiving just /21 prefixes.
Example 15-109 Proper Filtering Resulted in Reduction in BGP Table Size
R2 #show ip bgp BGP table version is 5, local router ID is 141.108.13.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 100.100.100.0/21 131.108.1.1 0 0 109 ? *> 99.99.99.0/21 131.108.1.1 0 0 109 ? *> 89.89.89.0/21 131.108.1.1 0 0 109 ?
The distribute list and prefix list take effect when updates come from a neighbor. If BGP updates already have been received, applying the distribute list or prefix list will have no effect. To receive updates from neighbors, routers must restart the BGP session by using the commands clear ip bgp neighbor or clear ip bgp neighbor soft in, if soft reconfiguration is enabled. Refer to the Cisco IOS Software manual for more details on this command. A recent feature of Cisco IOS Software called route refresh automatically requests fresher updates from a neighbor when any policy, such as a distribute list or a prefix list, gets applied. This feature does not require clearing of the current BGP session.
Problem: AS_PATH Filtering Using Regular Expressions
All BGP updates that contain an announcement of IP prefixes have an AS_PATH field that lists all the autonomous systems that this update has traversed. BGP operators use filtering against this AS_PATH field to allow or deny IP prefixes and also to apply BGP policy based on AS_PATH filtering. This method offers greater flexibility in applying just a single line of filtering and not listing all IP prefixes, as in the case of distribute lists or prefix lists.
Commonly seen problems are mostly the result of a lack of understanding of UNIX-like BGP regular expressions. Chapter 14 sections on AS_PATH cover the most commonly used regular expression in AS_PATH filtering in Cisco.