BGP Route Filtering with ACLs & Prefix Lists (VII)

BGP Route Filtering with ACLs & Prefix Lists (VII)
In: BGP Cisco

When working with BGP, you'll frequently need to control which routes or prefixes you share with a peer or receive from them. For instance, you might want to send one or a few prefixes with your peer. Similarly, when getting prefixes from a peer, you might want to block a certain prefix while accepting all others. This process of selecting specific routes to advertise or receive is known as BGP filtering.

In Cisco devices, there are four main methods to filter BGP routes.

  • Distribute List - This method uses standard or extended Access Control Lists (ACLs) to filter network prefixes. Any prefix not explicitly permitted by the ACL is denied by default, thanks to an implicit deny at the end of the list.
  • Prefix List - Similar to an ACL, a prefix list specifies criteria to permit or deny network prefixes. The evaluation is done in a top-down manner, and like distribute lists, there's an implicit deny for any prefix not explicitly permitted.
  • AS Path ACL/Filtering - This involves using regex (regular expressions) to permit or deny network prefixes based on their AS path attributes. Any prefix whose AS path does not match the specified criteria is implicitly denied.
  • Route Maps - Route maps offer a versatile and powerful way to match on various prefix attributes and then apply specific actions based on those matches. Actions can range from simple permit or deny to modifying BGP path attributes. Unmatched prefixes are implicitly denied.

These filters can be applied in either the 'IN' direction or the 'OUT' direction. Applying a filter 'IN' affects routes being received from a BGP neighbour. Conversely, applying a filter 'OUT' influences routes being sent out to a BGP neighbour.

  • Standard ACL - Less common, matches network only
  • Extended ACL - Common, matches network and mask, flexible enough
  • Prefix List - Very common, matches network and mask, very flexible
đź’ˇ
Please note that while ACLs can be used for route filtering in BGP, it's not the most common practice. Most network engineers prefer using prefix lists because they are designed specifically for matching on IP prefixes and are more flexible and clear when it comes to filtering routes by prefix length. Nevertheless, there are situations where ACLs might be used, and understanding how to apply them can be beneficial. We will review examples using both standard and extended ACLs to demonstrate how they can be implemented in BGP route filtering scenarios.

BGP Diagram

The examples in this post will reference the network shown in this diagram, where we have four routers each located in a separate Autonomous System (AS). HQ-01 is in AS 1000 and is originating three subnets 100.100.1.0/24, 100.100.2.0/24, and 100.100.3.0/24.

Branch-01 is in AS 100 and also originates two subnets 100.100.55.0/25 and 100.100.60.0/24. Both of these routers are connected through eBGP with ISP-01, which is part of AS 200. Finally, we have ENT-01 in AS 2000, forming an eBGP connection with ISP-01.

In the upcoming sections, we'll explore how to apply BGP route filtering across these connections.

#HQ-01

router bgp 1000
 bgp log-neighbor-changes
 network 100.100.1.0 mask 255.255.255.0
 network 100.100.2.0 mask 255.255.255.0
 network 100.100.3.0 mask 255.255.255.0
 neighbor 12.12.12.2 remote-as 200
#Branch-01

router bgp 100
 bgp log-neighbor-changes
 network 100.100.55.0 mask 255.255.255.128
 network 100.100.60.0 mask 255.255.255.0
 neighbor 12.12.13.2 remote-as 200
#ISP-01

router bgp 200
 bgp log-neighbor-changes
 neighbor 12.12.12.1 remote-as 1000
 neighbor 12.12.13.1 remote-as 100
 neighbor 12.12.14.1 remote-as 2000
#ENT-01

router bgp 2000
 bgp log-neighbor-changes
 neighbor 12.12.14.2 remote-as 200

BGP Filtering with Distribute List and ACLs

BGP Filtering with a distributed list and ACLs is the very basic form for managing the routes advertised to or received from a neighbour. While ACLs are commonly known for traffic filtering, within BGP, they serve the purpose of selectively allowing or denying routes.

Quick Recap on ACLs and Wildcard Masks

In ACLs, wildcards are used to specify which bits in an address should be considered for an exact match and which should not. The wildcard mask is the inverse of a subnet mask, where the binary 0 means "match this bit" and 1 means "ignore this bit" or "don't care."

For example, in the ACL entry 192.168.10.0 0.0.0.255, the address 192.168.10.0 is the network you're specifying, and the wildcard mask 0.0.0.255 tells the router which bits to match. Here, the first three octets (192.168.10) need to match exactly because the wildcard bits are set to 0. The last octet has a wildcard of 255, which translates to "any value is acceptable here." So, any address from 192.168.10.0 to 192.168.10.255 would be matched by this ACL entry. This approach gives you the ability to match a range of IP addresses within a specified network segment.

Standard ACLs

Understanding ACLs in the context of BGP requires a slightly different perspective than basic traffic filtering. Here are examples that demonstrate how standard ACLs are interpreted for BGP route filtering.

  • permit any - This command allows all prefixes to be advertised or received. It's a way of saying "accept all routes" in BGP.
  • permit 100.100.0.0 0.0.255.255 - This line permits any prefixes within the 100.100.0.0/16 range.
  • permit host 100.100.1.1 - This specifically permits only the 100.100.1.1/32 prefix.
  • deny 100.100.3.0 0.0.0.255 - This command denies any networks within100.100.3.0/24 range, preventing it from being advertised or accepted.

The limitation of using standard ACL is that you can't really filter based on the prefix length. For example, you can't say, 'Hey, permit all the networks in 192.168.x.x network with the mask of /25'

đź’ˇ
Remember, ACLs in BGP don't filter traffic but instead filter the routing information—whether a route should be advertised to or accepted from a BGP neighbour.

Let's say the router ENT-01 doesn't want to receive the prefix 100.100.2.0/24 from ISP-01. We can either block this prefix being advertised from ISP-01 (out direction) or block being received on the ENT-01 router (in direction). Let's go with the latter for this example.

What we need is, a standard ACL that 'deny' this prefix and 'allows' everything else.

#ENT-01

ip access-list standard BLOCK-PREFIX
 deny   100.100.2.0 0.0.0.255
 permit any

router bgp 2000
 bgp log-neighbor-changes
 neighbor 12.12.14.2 remote-as 200
 neighbor 12.12.14.2 distribute-list BLOCK-PREFIX in

Adding the distribute-list command to the BGP configuration on ENT-01 might seem like it will start filtering the unwanted prefix immediately. However, BGP won't apply this new filtering rule to routes that have already been received and processed. To activate the filter, you need to prompt BGP to reevaluate the routes. As you can see below, ENT-01 still has 100.100.2.0/24 in its BGP table.

#ENT-01

ENT-01#show ip bgp 

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.1.0/24   12.12.14.2                             0 200 1000 i
 *>  100.100.2.0/24   12.12.14.2                             0 200 1000 i
 *>  100.100.3.0/24   12.12.14.2                             0 200 1000 i
 *>  100.100.55.0/25  12.12.14.2                             0 200 100 i
 *>  100.100.60.0/24  12.12.14.2                             0 200 100 i

One way to do this is with a hard reset using the clear ip bgp x.x.x.x command. This command resets the BGP session, causing the connection to drop and then re-establish, which forces BGP to resend all routes according to the current configuration. However, this approach is disruptive and could lead to temporary loss of connectivity, making it less suitable for use in a live network.

A more graceful approach is to use the soft parameter with the clear ip bgp x.x.x.x soft command. This initiates a soft reset, which allows BGP to refresh its routes without dropping the connection. The router will ask ISP-01 to resend its routes via the ROUTE-REFRESH message, and when these routes are received again, ENT-01 will apply the new distribute-list filter and exclude the specified prefix while keeping the BGP session uninterrupted.

#ENT-01

clear ip bgp 12.12.14.2 soft
#ENT-01

ENT-01#show ip bgp

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.1.0/24   12.12.14.2                             0 200 1000 i
 *>  100.100.3.0/24   12.12.14.2                             0 200 1000 i
 *>  100.100.55.0/25  12.12.14.2                             0 200 100 i
 *>  100.100.60.0/24  12.12.14.2                             0 200 100 i

As you can see above, the prefix 100.100.2.0/24 has now disappeared. Suppose you want to filter out multiple prefixes such as 100.100.1.0/24, 100.100.2.0/24, and 100.100.3.0/24, you could modify the standard ACL to block a range that includes all three subnets. Here’s how you would adjust the ACL.

#ENT-01

ip access-list standard BLOCK-PREFIX
 deny   100.100.0.0 0.0.3.255
 permit any
#ENT-01

ENT-01#show ip bgp 

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.55.0/25  12.12.14.2                             0 200 100 i
 *>  100.100.60.0/24  12.12.14.2                             0 200 100 i

Extended ACLs

Extended ACLs add more flexibility to BGP filtering compared to standard ACLs, allowing you to specify both the network and its subnet mask. With extended ACL, you can filter prefixes based on their length, for instance, accepting only those with a /25 mask while blocking the rest.

  • permit ip 100.100.0.0 0.0.0.0 255.255.0.0 0.0.0.0 - Permits only the 100.100.0.0/16 network (It won't match 100.100.0.0/24 for example, the mask has to match too)
  • permit ip 100.100.0.0 0.0.255.0 255.255.255.0 0.0.0.0 - Permits 100.100.x.0 networks with /24 prefix length
  • permit ip 100.100.0.0 0.0.255.255 255.255.255.128 0.0.0.0 - Permits 100.100.x.x networks with /25 prefix length.
  • permit ip 100.100.0.0 0.0.255.255 255.255.255.0 0.0.0.255 - Permits any network with 100.100.x.x with /24 to /32 prefix length

Before diving into the example, I'm going to remove the filters we applied in the previous example and start from a clean slate.

#ENT-01

router bgp 2000
 no neighbor 12.12.14.2 distribute-list BLOCK-PREFIX in

Just for a change, let's configure the ISP-01 router to filter the routes it advertises to ENT-01. This means we'll be applying our filter in the 'OUT' direction. Here, we want ISP-01 to only advertise networks within the 100.100.x.x range that have a /25 prefix, blocking all others. This is a common scenario where an ISP may want to limit the prefixes it shares with a customer or peer. Let’s proceed with this example and set up the appropriate filtering on ISP-01.

#ISP-01

ip access-list extended PERMIT_25
 permit ip 100.100.0.0 0.0.255.255 255.255.255.128 0.0.0.0

router bgp 200
 bgp log-neighbor-changes
 neighbor 12.12.12.1 remote-as 1000
 neighbor 12.12.13.1 remote-as 100
 neighbor 12.12.14.1 remote-as 2000
 neighbor 12.12.14.1 distribute-list PERMIT_25 out

As you can see below, ENT-01 only receives the single /25 prefix (Remember, there is an implicit deny at the end of the ACL)

#ENT-01

ENT-01#show ip bgp

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.55.0/25  12.12.14.2                             0 200 100 i

BGP Filtering with Prefix Lists

Prefix lists are used for route filtering and can be used as an alternative to ACLs in BGP route filtering commands. Prefix lists offer more flexibility and precision than ACLs, especially when dealing with subnet masks or prefix lengths.

Prefix lists can match on:

  1. The route prefix (subnet)
  2. The prefix length (subnet mask)

The general syntax for a prefix list entry is:

ip prefix-list NAME seq SEQ_NUMBER (permit|deny) PREFIX/LENGTH [ge GE_VALUE] [le LE_VALUE]
  • NAME - The name of the prefix list.
  • SEQ_NUMBER - A sequence number for the entry, which dictates the order of evaluation.
  • (permit|deny) - Specifies whether to allow or block the matching prefixes.
  • PREFIX/LENGTH - The network prefix and its subnet mask length.
  • ge GE_VALUE - Optional. Specifies the minimum prefix length to match, inclusive.
  • le LE_VALUE - Optional. Specifies the maximum prefix length to match, inclusive.

Let's say you want to permit only the subnet 192.168.100.0/24 and any subnets within it up to /30

prefix-list ONLY-192-168-100 seq 10 permit 192.168.100.0/24 le 30

This example creates a prefix list named ONLY-192-168-100

  • It starts with sequence number 10.
  • It permits the 192.168.100.0/24 network.
  • The le 30 condition means it will also allow any prefixes within that range up to a /30 mask, covering 192.168.100.0/25, 192.168.100.0/26, 192.168.100.0/27, 192.168.100.0/28, 192.168.100.0/29, 192.168.100.0/30 , 192.168.100.128/25 and so on.

I'm going to add a couple more loopbacks to the Branch-01 router with different masks to demonstrate the next example. (The last four entries)

#Branch-01

Branch_01#show ip bgp 

 *>  100.100.1.0/24   12.12.13.2                             0 200 1000 ?
 *>  100.100.2.0/24   12.12.13.2                             0 200 1000 ?
 *>  100.100.55.0/25  0.0.0.0                  0         32768 ?
 *>  100.100.60.0/24  0.0.0.0                  0         32768 ?
 *>  100.100.61.0/26  0.0.0.0                  0         32768 ?
 *>  100.100.62.0/27  0.0.0.0                  0         32768 ?

Let's say when Branch-01 sends the BGP routes to ISP-01, we only want to send prefixes in the 100.100.x.x network with masks greater than or equal to /25. So, we only want to send 100.100.55.0/25, 100.100.61.0/26 and 100.100.62.0/27.

This time, I'm going to create the prefix on the Branch-01 router and apply it in the 'OUT' direction to the ISP-01 router.

#Branch-01

ip prefix-list GE_25 seq 5 permit 100.100.0.0/16 ge 25

router bgp 100
 bgp log-neighbor-changes
 redistribute connected
 neighbor 12.12.13.2 remote-as 200
 neighbor 12.12.13.2 prefix-list GE_25 out

As you can see below, ISP-01 is not receiving the 100.100.60.0/24 prefix from Bracnh-01 anymore.

#ISP-01

ISP-01#show ip bgp 

 *>  100.100.1.0/24   12.12.12.1               0             0 1000 ?
 *>  100.100.2.0/24   12.12.12.1               0             0 1000 ?
 *>  100.100.55.0/25  12.12.13.1               0             0 100 ?
 *>  100.100.61.0/26  12.12.13.1               0             0 100 ?
 *>  100.100.62.0/27  12.12.13.1               0             0 100 ?

Let's say now I want to deny the /27 prefix, all you have to do is add a new sequence above the previous one as shown here.

#Branch-01

ip prefix-list GE_25 seq 4 deny 100.100.0.0/16 ge 27 le 27
ip prefix-list GE_25 seq 5 permit 100.100.0.0/16 ge 25
#ISP-01

ISP-01#show ip bgp

 *>  100.100.1.0/24   12.12.12.1               0             0 1000 ?
 *>  100.100.2.0/24   12.12.12.1               0             0 1000 ?
 *>  100.100.55.0/25  12.12.13.1               0             0 100 ?
 *>  100.100.61.0/26  12.12.13.1               0             0 100 ?

As you can see from the output, 100.100.62.0/27 prefix has now gone. This approach is much simpler and more readable than using ACLs with distribute-lists.

Closing Up

I was initially going to add both AS_Path filter and Route Maps in this same post but this is already long enough so, moving them to the next part. If you would like to go through the full BGP Course, please check them out here

BGP Route Filtering with AS_Path Filter & Route Maps
Enter AS_Path filtering, a simple approach to route filtering that focuses on the AS_Path attribute in BGP routes. With AS_Path filters, you can create rules based on the autonomous systems that routes have passed through.
Table of Contents
Written by
Suresh Vina
Tech enthusiast sharing Networking, Cloud & Automation insights. Join me in a welcoming space to learn & grow with simplicity and practicality.
Comments
More from Packetswitch
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Packetswitch.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.