Hi,
Can you explain how the below works
ip prefix-list 0.0.0.0/0 -for default route
ip prefix-list 0.0.0.0/0 le 32 - for all routes
Thanks
Hello Sims
Remember that unlike an access list, a prefix-list will give you a list of prefixes to match A prefix is composed of a network address with a subnet mask.
Let’s look at the second one first:
ip prefix-list 0.0.0.0/0 le 32
This will give you a list of prefixes that are composed of 0.0.0.0 and can have subnet masks ranging from 0 to 32. So:
0.0.0.0/0
0.0.0.0/1
0.0.0.0/2
0.0.0.0/3
…
0.0.0.0/32
So this essentially states that this prefix list matches all networks (signified by 0.0.0.0) with any subnet mask (signified by le 32).
For the first one, this prefix list will match anything that has a subnet mask of /0. So only the default route will be matched. Any other network/subnet mask combination, such as 192.168.1.0/24 for example, will not be matched.
I hope this has been helpful!
Laz
Hi Rene,
There is an option in IOS where multiple prefix-list can be matched with one statement.
As an example,
match ip address prefix-list satellite_default dmvpn_default
As indicated above satellite_default and dmvpn_default are separate prefix-list
Please explain how this works
Thanks
1 Like
Hello Talha
When applying a match statement specifically for matching an IP address within a route map, you are able to specify more than one prefix list. Actually, you can specify even more than two. For example:
Router(config-route-map)#$dress prefix-list list1 list2 list3 list4 ?
WORD IP prefix-list name
<cr>
You can see from the above output that after four lists have been entered, there is the option to add an additional one.
The IOS will attempt to match the IP address to the prefix lists in the order they are indicated.
In other words, it will interpret this as a single list that is composed of the concatenated prefix lists, and will go through the statements within those lists in order. Once a match is found, it will not look further.
You are able to do this with access lists as well. See the CLI output below:
Router(config-route-map)#match ip address ACL1 ACL2 ACL3 ACL4 ?
<1-199> IP access-list number
<1300-2699> IP access-list number (expanded range)
WORD IP access-list name
<cr>
So this is not a characteristic of prefix lists, but of the match statements made within a route-map.
I hope this has been helpful!
Laz
1 Like
Hello,
is it more appropriate to use the deny in a prefix list or in the route map?
Example:
ip prefix-list TEST seq 10 deny 1.2.3.4/32
ip prefix-list TEST seq 15 permit 0.0.0.0/0 le 32
route-map TEST permit 10
match ip address prefix-list TEST
Or:
ip prefix-list TEST seq 10 permit 1.2.3.4/32
route-map TEST deny 10
match ip address prefix-list TEST
route-map TEST permit 20
Thanks a lot.
Regards,
Lukas
1 Like
Hello Lukas
Both configurations should bring about the same results, and I believe both are acceptable. In my personal opinion, it is preferable to include the detail of what to permit and what to deny in the “lowest level entity” in the configuration. In this case, this would be the prefix list. In other words, since the route-map calls upon the prefix list to define traffic, the route-map is at a higher level of the configuration.
This makes it easier to modify in the future. All of the permit/deny combinations you want are found within the prefix-list, and you only have to edit this list in order to modify the behaviour. Otherwise, you may have to edit both the prefix-list and the route-map.
I hope this has been helpful!
Laz
2 Likes
Great answer 
Thanks
1 Like
How can i calculate the range in binary ??.
ip prefix-list permit 123.0.0.0/4 le 7
ip prefix-list permit 1.1.0.0/11 ge 15Hello Narad
Let’s take a look at the first prefix list. The address 123.0.0.0 represented in binary is:
01111011.00000000.00000000.00000000
I included the dots for clarity. Now, the prefix list is essentially saying that this matches prefixes with the following characteristics:
- it matches all prefixes within the 123.0.0.0/4 range
- it matches all prefixes that have a subnet mask less than 7
Looking at this in binary, it says that:
- It will match all prefixes that begin with 0111, that is the first four bits of the prefix. In other words it will match any prefix from
01110000.00000000.00000000.00000000to01111111.11111111.11111111.11111111. In decimal that is from 112.0.0.0 to 127.255.255.255. - The prefix must also match any subnet mask less than 7.
You can also approach the second prefix-list in the same manner.
I hope this has been helpful!
Laz
Hi Dear, One question. how and why prefix list is more powerful than access list?
Hello Zahid
An access list can be used to define a specific range of IP addresses. A prefix list can be used to define a specific range of prefixes. Prefix lists include the subnet mask in their matching mechanisms.
For example, let’s say you want to define a list of prefixes that fall within the range of 192.168.0.0/16 but have a subnet mask between /25 and /27. To do this with an access list, it would be quite complicated. With a prefix list, you only need a single line:
ip prefix-list MY_LIST permit 192.168.0.0/16 ge 25 le 27
Remember that access lists will filter specific addresses, prefix lists will filter prefixes (which define a range of addresses since they include subnet masks).
I hope this has been helpful!
Laz
Thanks for the help dear
1 Like
Hi
Thanks for the great explanations. I’m also working through the Encor OCG and have come across the following statement around prefix lists which has confused me:
“Matching to a specific prefix length that is higher than the high-order bit count requires that the ge-value and le-value match.”
Can anyone clear this up ? Thanks.
Hello Nizar
The terminology used can be confusing. Just for clarification, let’s take this example:
R1(config)#ip prefix-list RENETEST3 permit 10.0.0.0/8 ge 16 le 18
The high order bit count is the /8. This essentially indicates the number of high order bits (leftmost bits) in the prefix. So the first 8 bits must always be the same in all prefixes that are to match.
The specific prefix length refers to the ge 16 le 18 parameters at the end of the command. These specify the prefix lengths to be matched.
Now the statement being made is simply saying that if you want to match a specific prefix (as opposed to a range of prefixes) that is higher than the high order bit count, you simply make the ge and le values the same.
For example, if I want to use the above command, but I want to match /20 prefixes (and not a range of prefixes), I would do this:
R1(config)#ip prefix-list RENETEST3 permit 10.0.0.0/8 ge 20 le 20
This matches all networks with a /20 prefix that begin with 10 in the first octet.
Conversely, if you want to match the prefix length that is the same as the high order bit count you would do this:
`R1(config)#ip prefix-list RENETEST3 permit 10.0.0.0/8
By omitting the ge and le parameters, you are saying that you want to match only the /8. This in essence is the same as an ACL.
Just for reference, you can find this specific statement that you mention in your post within the IP Routing on Cisco IOS, IOS XE, and IOS XR: An Essential Guide to Understanding and Implementing IP Routing Protocols Cisco publication.
I hope this has been helpful!
Laz
1 Like
Many thanks. Thats cleared it up for me 
1 Like
Great explanation of the topic as always. I get a good understanding of HOW to perform these tasks, but often in my role I struggle with the WHY to perform some of these tasks.
will admit I am far from creative, but I struggle to think of examples during these lessons on why I would ever want to limit certain subnets from advertising into a certain router and when I would use this in a real world scenario.
I know this training is likely fairly old, however having an example in the beginning of a problem you are trying to solve would help drive home the task at hand. Also maybe a question at the end with another example to get the creative juices flowing on how to problem solve with these newly learned skills
Hello Pietro
Yes, it is always helpful to understand why you perform certain configurations, and under what circumstances they are useful. In this particular case, if you have a large network with hundreds of prefixes, it is always helpful to filter out any prefixes that you won’t be using in a particular portion of your network. Prefix lists are powerful when performing such a function because you can specify ranges of subnet masks in a single command, rather than specifying them individually as separate lines.
The usefulness of this feature only becomes apparent when you have more complex scenarios to deal with. Creating such complex scenarios within a lesson like this one would help in understanding where it is useful, but it probably goes above and beyond what is necessary to learn the actual command and syntax.
Even so, your suggestions are valuable to us and I will pass them on to Rene to keep them in mind as he continually creates new content.
Thanks again and as always, I hope this was helpful!
Laz
Hello, everyone!
I have the following topology built in CML.
The routers are running EIGRP and have both established a neighborship. I’ve configured the following prefix list on R1 and nested it inside a route map
This combination should effectively deny any networks with an exactly /64 prefix length, right? So only the 2001:DB8:2::/64 and 2001:DB8:3::/64 networks.
However, it turns out that none of the IPv6 networks are making it into R1’s RIB.
Any idea what’s going on here?
Thank you in advance.
David
Hello David
I took this one to the lab. I recreated your topology and your exact configuration and I am getting the same results. I’m not sure why, however, it seems that there are no hits on the route map or the prefix list at all. It seems as if this configuration matches some explicit deny statement of either the prefix-list or the route map.
I did a bit of experimentation and found that if I call the prefix list directly using the distribute list like so:
distribute-list prefix-list TEST in
then all prefixes are indeed filtered out except for the two /64 entries. So the prefix list seems to be working, and so is the distribute-list. However, the introduction of the route map seems to throw a monkey wrench into the works.
I’ll send this one to @ReneMolenaar to see if he wants to take a stab at it as well. In the meantime, keep in mind that the simpler configuration is often the better one. Unless you absolutely have to, it’s best to avoid having distribute lists referencing route maps that reference prefix lists if you can achieve this by removing route maps altogether.
I hope this has been helpful!
Laz
Hi @davidilles ,
I took a look, but although technically correct, it’s not working. This might be related to a particular version. I found something in this document:
EIGRP for IPv6 provides route filtering using the distribute-list prefix-list command. Use of the route-map command is not supported for route filtering with a distribute list.
This is a document for Cisco IOS Release 15M&T.
Rene