The Use of Prefix Lists for Route Filtering

Using IP prefix lists has several advantages over using an ACL.  Prefix lists match on more than just an IP address, they also match on the prefix length of the route.  This as we have seen maybe an advantage but can also cause problems with routes being filtered that we didn’t intend.  Finally, the internal processing of the IP prefix lists uses an internal tree structure that results in faster matching of routes than with ACLs.

Much like ACLs,  Prefix configuration commands using the same name end up being in the same list.  As with named ACLs, each ip prefix-list command has a sequence number to allow later deletion of individual commands and insertion of commands into a particular sequence position.  Prefix lists are read in order, top to bottom and once a match is found the rest of the list does not get read. Each command has a permit or deny action, but because it is used only for matching routes, and not for packet filtering, the permit or deny keyword just implies whether a route is matched (permit) or not (deny).

Creating a Prefix list uses the following command syntax.

ip prefix-list list-name [seq seq-value] {deny | permit prefix/prefixlength}[ge gevalue] [le le-value]

EX.  Ip prefix-list FILTER_ADV_ROUTES seq 10 permit 172.31.26.0/23 ge 24 le 32

The matching of a Prefix list works much like an ACL. The configured prefix/length (172.31.26.0/23 in our example) means that any IP addresses that fall within that range will be matched (172.31.26.0 thru 172.31.27.255).  Prefix lists though also look at the prefix length of the route.  There are several parameters that we use to specify the prefix length.

  • The required prefix-length parameter
  • The optional ge value (greater than or equal to)
  • The optional le value (less than or equal to)

For your list you have 4 combinations that will allow you to specify the prefix lengths you want to match.  Consider we have the following routing table.

Prefix list Routing table 1

You have the following options for filtering based on Prefix length.

Prefix List Table1

The first case in the table occurs when neither ge nor le is configured. In that case, an exact match of prefix-length must occur between the configured prefix length and a route’s prefix length. The second case in the table occurs when both ge and le are configured. In that case, the route’s prefix length must be between the configured ge and le values, inclusive.  In this case both the ge and le values are 24 so the prefix range is 24 to 24—meaning only routes with prefix length 24 will be matched.  The third case is where only ge is used. In that case the route’s prefix length must be greater or equal to the ge value.  In the last case only le is used.  In this case the route’s prefix length must be between the configured length and the le value.  IOS requires that the configured prefix-length, ge-value, and le-value meet the following requirement; otherwise, IOS rejects the ip prefix-list command.

prefix-length <= ge-value <= le-value.

There are 2 other examples worth noting.

PreFix4

The first will not match any routes in your routing table other than your default route.  The second will match all routes in your table, this is useful  if you want to allow all routes other than 1 or 2 out of your list.  Consider the following routing table.

Prefix List Routing table 2

Say we want to allow all networks except for the 172.31.3.0/24.  We could use a Prefix list like

 ip prefix-list FILTER_ADV_ROUTES seq 10 deny  172.31.3.0/24 le 32

ip prefix-list FILTER_ADV_ROUTES seq 20 permit 0.0.0.0/0 le 32

This would block any addresses in the 172.31.3.0/24 network but allow all other addresses to pass.

I would however caution you to avoid using the ge/le too often. It should be avoided except when absolutely necessary or when allowing a range of prefixes isn’t going to cause breakage (i.e. when we control the routes/advertisements). Excessive use of those basically makes the prefix-list behave like an ACL with wildcard masks.

Consider this fictitious example of a customer with an AXP module:

——–Example IP allocation———

RTR0 Gi0/0 = 172.31.230.1 255.255.255.240

RTR3 Gi0/0 = 172.31.230.2 255.255.255.240

AXP = 172.31.230.3 255.255.255.240

——Router config——–

router eigrp 45

network 172.31.230.0 0.0.0.15

distribute-list route-map FILTER_ADV_ROUTES Gi0/1.x out

!

ip route 172.31.230.3 255.255.255.255 Integrated-Service-Engine1/0 name LOCAL_AXP

!

ip prefix-list FILTER_ADV_ROUTES seq 5 permit 172.31.230.0/28 le 32

!

————————–

Of course you need to allow the local LAN subnet otherwise NAT/PAT breaks, but the “le 32” is really not providing any value here as it allows the 172.31.230.0/28 and the 172.31.230.3/32 through the prefix-list. (Yes, the static route for the AXP is not advertised explicitly but the AXP modules advertise themselves in EIGRP for you… thanks Cisco!) The /28 route is all you need to get any packets destined for that AXP to the router; once the packet gets to the router, there is a more specific route to direct the packet to its final destination.

Across an environment like ours with maybe 25-30 customers with this type of setup this doesn’t present a huge concern. If we had 1000 routers all doing the same thing then you can see how something so seemingly innocent as this can cause a lot of unnecessary routes to be installed in routing tables – the problem is magnified by using EIGRP and its distance vector ways.

It’s important to know how the ge/le options are used and you documented them well, I just don’t think they are an automatic when creating a prefix-list.

Leave a Reply

Your email address will not be published. Required fields are marked *