Prefix lists are, for me, the big-boy way to make lists of routes. While they don’t give you the granular ability of an ACL when it comes to layer 4 matching (port numbers), prefix lists are easier to read and offer greater flexibility than access-lists if all you’re trying to do is generate a list of routes to match or deny. I don’t know about you, but no matter how many wildcard masks I’ve looked at in my life, it still takes a few seconds to figure out what nets that wildcard entry is referring to. Prefix-lists, for the way my brain is wired, immediately register with the ol’ gray matter.
There are 2 elements that make up a prefix list:
- The route prefix itself – in other words, the subnet. “Prefix” in the sense that it’s the first part of the network address.
- The prefix length – in other words, the subnet mask. “Length” in the sense that you know how much of that network address belongs to the prefix.
So let’s take an example prefix list and pick it apart. Consider this:
ip prefix-list myPrefixList seq 10 permit 192.168.100.0/24
ip prefix-list myPrefixList seq 20 permit 172.16.0.0/16 le 24
ip prefix-list myPrefixList seq 30 permit 10.0.0.0/8 ge 16 le 24
Here we’ve created a prefix-list called “myPrefixList”. It is sequenced by 10’s. We could insert a new sequence number of 15 later, or delete entry 20, just like in an access list. (Although, I don’t know of a way that you can resequence a prefix-list, which is UNLIKE an access list.) In this list, the following networks would match the prefix list:
- An exact match of 192.168.100.0/24
- Any networks falling in the range of 172.16.0.0/16 that have a /24 or shorter mask. Ergo, 172.16.2.0/23 would match. 172.16.128.0/17 would match. 172.16.99.128/25 would NOT match.
- Any network falling in the range of 10.0.0.0/8 with a mask length between and included 16 and 24 would match. But /9’s would not match; /27’s would not match either.