Prefix-lists are typically used by router “features” to provide filtering. They “pass” permitted networks to a filtering feature which will actually do the filtering.
They are used by distribute-lists, filter-lists, route-maps.
Table of Contents
Basics
Some quick points which will guide you on understanding the basics.
- IP prefix list can match on sub netmask of route (ranges).
- They also use the same concept of permit or deny clause (just like ACLs).
- Prefix lists use an internal tree structure that results in faster matching than ACLs.
- Prefix lists are used to match routes not for packet filtering.
- The permit keyword implies that the route is matched
- Deny implies it’s not matched.
- Prefix lists do not use wild card masks.
- There’s always a default deny at the end of your list.
To add an implicit allow at the end of the prefix-list just use the next sequence with the following:
ip prefix-list <name> seq <sequence number> permit 0.0.0.0 le 32
Let’s begin with examples.
I’m assuming you have knowledge of the following:
basic Cisco CLI, ACL logic, route-filtering concepts, subnetting
Examples
Example 1
Ip prefix-list test1 seq 10 deny 10.10.10.0/24
Ip prefix-list test1 seq 20 permit 0.0.0.0 le 32
If we didn’t have a le or ge parameter then our prefix-list would match the prefix, and the subnet mask exactly.
Let’s use a routing update example, we receive these routes:
10.10.10.32 /27
10.10.10.0 /23
10.10.10.0 /24
If we had the above prefix-list configured, only the last prefix would be filtered out from that.
The rest would be allowed from sequence 20 because we replaced the invisible deny any at the end.
We can also define that we want to match on a range of subnet masks. This means we want to filter prefixes, AND the subnet mask range.
Example 2
Ip prefix-list test2 seq 10 permit 10.10.0.0/16 ge 20 le 30
Now don’t forget we have an implicit deny at the end that is invisible here just like ACLs.
Let’s use some inbound routing update examples.
10.10.10.0/24
10.10.0.0/8
192.168.1.0/24
Let’s look at the first prefix. The /16 is only looking to match the prefix bits and not the subnet mask. This is because we defines a less than or equal to (le) and or a greater than or equal to (ge) parameter. This means it will try to match 10.10.x.x which in this case it passes the first check, then it will check if the subnet mask is 20-30. In our case it is 24 so it passes the second check. This first prefix has been matched!
Let’s look at the second prefix. Remember we have to pass two checks. Does it match 10.10.x.x ? Yes! Second check now. Is the subnet mask between 20 to 30? NO! This has failed to match our first seq. That means it will move on to the next one. The next sequence is the implicit deny so this prefix will not be permitted.
Let’s look at the third prefix now. Does it match 10.10.x.x ? NO! We can stop there because this will move onto the second sequence which is the implicit deny!
Be careful because your greater than or equal to parameter cannot be the same as your prefix’s length. It needs to be bigger. However that will cause trouble for you if want to filter a /24 length and subnet mask because then you will never filter /24s!
Example 3
Ip prefix-list test3 seq 20 permit 10.10.10.0/24 ge 25 le 30
Sounds good right? It matches our rule. Sure we will pass the first check, we will match 10.10.10.x however we won’t ever filter out any /24 subnet masks, only 25 to 30. To fix this you need a sequence before those range match.
Recall above I used sequence 20, now I will put something in front of that.
Ip prefix-list test3 seq 10 permit 10.10.10.0/24
With these two sequences I can now match 10.10.10.x/24 and 10.10.10.x/25-30!
Also be aware, your “le” parameter needs to be the same or greater than your “ge” parameter.
Of course we could also match exact subnet masks with ge and le.
Example 4
Ip prefix-list test4 seq 10 permit 10.0.0.0/8 ge 9 le 9
This will match all prefixes starting with 10.x.x.x with a subnet mask of /9
Let’s look at an inbound routing update.
10.12.12.0/8
Does it pass the first check, yup it starts with 10.x.x.x. Does it pass the second check? Nope it’s subnet mask is 8 it must match 9 exactly.
We can also have prefix-lists with JUST ge OR le.
Example 5
Ip prefix-list test5 seq 10 permit 192.0.0.0/8 ge 24
Let’s look at some inbound routing updates to see what will happen.
192.168.1.0/24
172.16.0.0/16
192.168.5.5/32
Does 192.168.1.0/24 pass the first check? Yup it starts with 192.x.x.x that’s all we care about. Does it pass the second check? Is it’s subnet mask greater to or equal to 24? Yup, this prefix will be permitted.
Next prefix. Does 172.16.0.0/16 pass the first check? Nope it doesn’t begin with 192 so it won’t be matched! We can stop there because we only have one sequence so the implicit deny will stop it from passing.
Next. Does 192.168.5.5/32 pass the first check? Yup it begins with 192.x.x.x. Is its subnet mask greater to or equal to 24? Yup this is a host route with a /32 subnet mask it will pass!
And lastly denying default routes.
To deny a default route use the following command:
ip prefix-list <name> seq <sequence number> deny 0.0.0.0/0
Conclusion
At this point you should have a clear understanding of how prefix logic works, and how it interacts with route matching features. I suggest attempting the above examples in a lab with route filtering or redistribution to really solidify your understanding of the logic. You could do some EIGRP route filtering and manipulate the paths with prefix-lists. Or do some route-filtering in OSPF.