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 Boson.com (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. https://www.tutorialspoint.com/ipv4/ipv4_address_classes.htm
I currently have set up R2 connected to R4.
R4 is advertising in EIGRP:
192.168.0.1/24
192.168.1.1/30 (255.255.255.252)
192.168.2.1/29 (255.255.255.248
192.168.3.1/28 (255.255.255.240)
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 192.168.0.0/16 ge 28 le 30
R4(config#) ip prefix-list test permit 0.0.0.0/0 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?
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
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.
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 0.0.0.0/1 le 27
R1(config)#ip prefix-list CLASSB permit 128.0.0.0/2 ge 17
In the first case, the 0.0.0.0/1 subnet is all addresses from 0.0.0.0 to 127.255.255.255. 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 10.10.10.32/27, 86.52.14.64/26 and 100.100.128.128/25 and any other class A subnet with a prefix less than or equal to /27.
On the other hand, the second prefix list is 128.0.0.0/2 which contains all addresses from 128.0.0.0 to 191.255.255.255, 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 132.0.0.0/17, 144.144.128.0/18, and 152.55.55.0/24 and any other class B subnet with a prefix greater than or equal to /17.
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.
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 172.16.1.0/24 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 172.16.1.0/24 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 10.0.0.0/8 le 19
It is used to permit only networks that fall within the 10.0.0.0/8 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.
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:
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.
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.
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
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.