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.

Figure 15-54. Two-ISP Network Running EBGP

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.

Figure 15-55. Problem-Resolution Flowchart

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.