Hi John,
Regarding the IP prefix list, to be honest, I have never found any good explanation out there... I'll try to make it more clear here.
Basically, IP prefix list is a mechanism to match network addresses and netmasks in routing protocols. Whenever matching a network, it is always necessary to match both network address and its netmask (or, in other words, the prefix length), not just the network address itself. For example, 10.0.0.0/24 and 10.0.0.0/23 are different networks even though their addresses are identical, because the netmasks (the prefix legths) differ. ACLs have proven to be cumbersome and impractical for network address matching - one one hand, they are too general (allowing to match various L4 protocols, ports and other packet attributes which is useless for network address matching), on the other hand, they allow matching the netmask only if an extended ACL is used (the "source" part of an ACL entry then comprises the match for the network address, the "destination" part comprises the match for the network mask). For example, to match networks 10.0.1.0/24, 172.16.0.0/12 and all possible subnets of 192.0.2.64/27, an ACL would look like
access-list 100 permit ip host 10.0.1.0 host 255.255.255.0
access-list 100 permit ip host 172.16.0.0 host 255.240.0.0
access-list 100 permit ip 192.0.2.64 0.0.0.31 255.255.255.224 0.0.0.31
Confusing? Yeah, it sure is. And I am not even talking about the fact that the ACL is used differently in distribute-lists and differently in route-maps... you don't even want to know.
That is why IP prefix lists were introduced. They allow for very straightforward specification of what networks are to be matched. In the easiest form, without the ge and le operators, they simply match exactly the network that is specified. So for example, a prefix list of the form
ip prefix-list PL permit 10.0.1.0/24
ip prefix-list PL permit 172.16.0.0/12
matches exactly these two networks: 10.0.1.0/24 and 172.16.0.0/12.
Sometimes a more complex scenario is necessary. Suppose that you are providing internet connectivity to a customer which has been assigned the IP prefix 192.0.2.64/27. The customer is allowed to subnet this prefix in any way he wants to and he is allowed to advertise the subnets back to you without summarization. There are obviously lots of ways how this range can be split into subnets of various sizes and counts. Still, you want to perform route filtering so that the only networks you accept in routing updates from this customer are the subnets of the network 192.0.2.64/27.
What is typical for such subnets? Well, obviously, they must be located inside the former prefix 192.0.2.64/27 (i.e. somewhere between 192.0.2.64 and 192.0.2.95), otherwise the customer would be using an address range he was not assigned. And how do we know that the networks are indeed subnets? Their mask must be either /27 (the mask of the original prefix, i.e. no subnetting was done by the customer) or more, i.e. /28, /29, /30, /31, or /32.
In other words, if the customer advertises a network W.X.Y.Z/M, then it is a valid subnet of 192.0.2.64/27 if and only if:
- W.X.Y.Z _BITWISE-AND_ /27 = 192.0.2.64 (the address of the network must fall into the range of 192.0.2.64/27)
- /M is at least /27 and obviously less or equal to /32
This can be easily written in a prefix-list as
ip prefix-list PL permit 192.0.2.64/27 le 32
This prefix-list entry matches all subnets of 192.0.2.64/27 whose mask is less or equal to /32 (the prefix-list here automatically makes sure that their mask is at least /27). Truly, these are all possible subnets of the 192.0.2.64/27 prefix.
You may also have a different requirement... you have given the customer a prefix of, say, 192.0.2.0/24. The customer is again free to subnet it as he pleases. However, in order not to clutter your routing tables with a number of tiny subnets, you require that the customer advertises the networks summarized to at least /26 - in other words, you are not willing to accept subnetworks of this space with the netmask of /27 and more.
In other words, if the customer advertises a network W.X.Y.Z/M, then it meets your requirements if and only if:
- W.X.Y.Z _BITWISE-AND_ /24 = 192.0.2.0 (the address of the network must fall into the range of 192.0.2.0/24)
- /M is at least /24 but less or equal to /26
The prefix-list would then contain the following line:
ip prefix-list PL permit 192.0.2.0/24 le 26
Finally, let us assume that for whatever reason, you want to match subnetworks of the 192.0.2.0/24 whose netmask is at least /29 - perhaps you are interested in loopback addresses, addresses on point-to-point links and on smaller networks - doesn't really matter right now.
Again, this requirement is met by a network W.X.Y.Z/M if and only if
- W.X.Y.Z _BITWISE-AND_ /24 = 192.0.2.0 (the address of the network must fall into the range of 192.0.2.0/24)
- /M is at least /29 and obviously less or equal to /32
The prefix-list would be specified as follows:
ip prefix-list PL permit 192.0.2.0/24 ge 29
This entry would match all possible subnetworks of 192.0.2.0/24 whose netmask is at least /29 or more. The upper limit of /32 on the netmask does not need to be specified - if not specified, it is again automatically enforced by the prefix-list.
So to sum it up: a prefix-list of the form
ip prefix-list PL permit A.B.C.D/P
matches only the exact network A.B.C.D/M.
A prefix-list of the form
ip prefix-list PL permit A.B.C.D/P le L
matches networks W.X.Y.Z/M for which W.X.Y.Z & /P = A.B.C.D and P <= M <= L
A prefix-list of the form
ip prefix-list PL permit A.B.C.D/P ge G
matches networks W.X.Y.Z/M for which W.X.Y.Z & /P = A.B.C.D and G <= M <= /32
A prefix-list of the form
ip prefix-list PL permit A.B.C.D/P ge G le L
matches networks W.X.Y.Z/M for which W.X.Y.Z & /P = A.B.C.D and G <= M <= L. Here, in addition, it is required that P < G (if you wanted P <= G then the ge operator was not necessary at all and should be omitted).
A hard reading, I admit! Please feel welcome to ask further!
Best regards,
Peter
