How to configure Prefix-List on Cisco Router

Hi Rene,

Thanks for this great tutorial. So if I put seq 10 permit before any other prefix lines, like

seq 10 permit
seq 20 permit
seq 30 permit

seq 20 and 30 won’t matter because the seq 10 already covered everything? Thanks!

Hello Barry.

Yes you are correct.


I was so confused by this at first. I know its simple but its also a brain teaser for some reason.
first I pulled up my boson subnet tool its free tool by the way on the (just need to create an account) website. At first I was thinking that first two bits mean the first two spots _ _ thinking it could be anything from 0 to 192 that it did not matter if it was a zero or a one. However after putting into the subnet calculator it helped me to see.

The next really helpful thing for me was when I went ahead and enabled the command with distribute-list prefix CLASSB in all of a sudden all my 10.x.x.x networks disappeared which shot my first theory to crap along with supporting the boson subnet calculator.

So seeing it in play in a lab really made sense. I think the confusion goes back to the rule on how the classes are setup. When we was learning sub-netting classes that you read and say oh ok but as time goes on you just get use to seeing the numbers themselves and that they are a certain class.

I am betting everyone that had a problem with this does not use the Class A, B, C rule anymore but instead over time have subconsciously just memorized the 1-127 is A, 128-191 is B, 192-223 is C and does not really think of the rule about class A the first bit always being 0, and class b the first two bits being set to 10, and class C having its first three bits set to 110… (hoping me explaining this in writing will actually help me remember it! lol)

So its like trying to do a math problem and finally that silly rule in math never used much is key to how the expression functions.

anyway below is some more information reinforcing Rene info.


posted the rule below in greater detail that Rene implicitly mentioned briefly in his post I am one of those type that can sometimes be slow seeing something the way it should be seen until I experience it for myself.



Hello rene

there is a problem with the second video ! Can u update it


Hi Yasser,

Did it not play for you? I just re-added it. Does it work now?



I currently have set up R2 connected to R4.
R4 is advertising in EIGRP: ( ( (

I’m simply just practicing with prefix-list and wanted to filter out the /30 /29 /28 routes, and only advertise the /24

On R4 I have done:

R4(config#) ip prefix-list test deny ge 28 le 30
R4(config#) ip prefix-list test permit le 32

R4(config-router#) distribute-list test out serial0/0/0

However, R2 is still showing all of the above mentioned routes in its routing table. I also tried filtering the same routes IN on R2 but to no effect. Where am I going wrong?

Thank you so much!

I have been going crazy trying to figure this out the past 24 hours. Finally figured out that I was leaving out the keyword ‘prefix’ in my “distribute-list” command syntax. Basically the distribute-list was looking for an ACL (that never existed) because I didn’t specify ‘prefix’ in the command. A little more tricky since leaving out ‘prefix’ is an acceptable command. It’s working as it should now :grinning:


I do things like this all the time XD

1 Like

Hello Alex!

Great to hear that you solved the issue on your own. Thanks very much for sharing your solution with us, it means so much for the community to have active and responsive participants. It helps us all when we share our experiences in this way.


Thanks for sharing! I couldn’t figure out at first as well. but why did you use “”? I thought this is a class c /24 or higher?

Hello Rene,

I am new to this Forum, Your lessons are helping me a lot, the way of explanation is very simple.
But I have a doubt:
I didn’t get the point for below 2 statments why we use Le 27 for class A and ge 17 for class B

R1(config)#ip prefix-list CLASSA permit le 27
R1(config)#ip prefix-list CLASSB permit ge 17


Hello Minali

In the first case, the subnet is all addresses from to This is the class A range of addresses. The le 27 keywords indicate that each subnet matched by the prefix will have a subnet mask less than or equal to 27. So this prefix list matches things like, and and any other class A subnet with a prefix less than or equal to /27.

On the other hand, the second prefix list is which contains all addresses from to, which are class B addresses. The ge 17 keywords indicate that each subnet matched by the prefix will have a subnet mask greater than or equal to 17. So this prefix list matches things like,, and and any other class B subnet with a prefix greater than or equal to /17.

I hope this has been helpful!




Why in this example did you add the permit statement, but in the others you didn’t? You said the permit statement was like a permit any any statement in an ACL, so I guess I’m not clear why you didn’t use this permit statement in every example.

R1(config)#ip prefix-list FILTERTHIS seq 5 deny
R1(config)#ip prefix-list FILTERTHIS seq 10 permit le 32

Hello Andy

It really depends on what you want to achieve. In the specific example you are referring to, Rene is filtering out anything that matches the first statement, that is, anything within the network. This means he is denying traffic matching this statement. You must remember that like access lists, prefix lists have an implicit deny statement at the end. This means that if the prefix list had only the first statement then, anything matching the network would be denied, and then, everything else would be denied as well.

For this reason, the second statement was included, permitting everything. Now this statement is only necessary when you want to deny traffic that matches a very specific criteria, as is the case in this example. If your purpose is to permit traffic for a very specific range of addresses, as Rene did in a later example, then you don’t need the permit statement at the end. Indeed you mustn’t include it, otherwise your prefix list wouldn’t work correctly. For example, take a look at this prefix list:

R1(config)#ip prefix-list RENETEST permit le 19

It is used to permit only networks that fall within the range and have a subnet mask of /19 or less. Everything else must be denied, and everything else is denied because of the implicit deny everything at the end of a prefix list.

I hope this has been helpful!



Can you explain how the below works

ip prefix-list  -for default route

ip prefix-list le 32 - for all routes


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 le 32

This will give you a list of prefixes that are composed of and can have subnet masks ranging from 0 to 32. So:

So this essentially states that this prefix list matches all networks (signified by 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 for example, will not be matched.

I hope this has been helpful!


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


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

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

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!



is it more appropriate to use the deny in a prefix list or in the route map?


ip prefix-list TEST seq 10 deny
ip prefix-list TEST seq 15 permit le 32

route-map TEST permit 10 
 match ip address prefix-list TEST


ip prefix-list TEST seq 10 permit

route-map TEST deny 10 
 match ip address prefix-list TEST
route-map TEST permit 20 

Thanks a lot.



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!


1 Like