i saw in you prefix-list filtering in EIGRP example you are advertsting loopback in EIGRP using:
R2(config-router)#network 172.16.0.0 0.0.3.255
my question why you are using Wildcard mask 0.0.3.255 for these loopbacks
loopback0 : 172.16.0.0/24
loopback1 : 172.16.1.0/24
loopback2 : 172.16.2.0/24
loopback3 : 172.16.0.3/24
i think it should be 0.0.0.255 beacuse all loopbacks are /24
waiting you
Hello Rafie
This is the topology for the lesson you are referring to:
So within the EIGRP configuration of R2, Rene issues the following command:
R2(config-router)#network 172.16.0.0 0.0.3.255
What this command does is it specifies which networks will participate in EIGRP. If he were to use the 0.0.0.255 wildcard mask, he would have to issue it four times like this, once for each subnet:
R2(config-router)#network 172.16.0.0 0.0.0.255
R2(config-router)#network 172.16.1.0 0.0.0.255
R2(config-router)#network 172.16.2.0 0.0.0.255
R2(config-router)#network 172.16.3.0 0.0.0.255
However, the 0.0.3.255 wildcard mask includes all four subnets, so he needs only one statement. How does it include all four subnets? Remember that the combination of network address and wildcard mask give us a range of addresses. Letās determine that range now.
First letās write out the network address and the wildcard mask in binary:
Network: 10101100.00010000.00000000.00000000
Wildcard Mask: 00000000.00000000.00000011.11111111
Now, letās determine the range of addresses that this includes. Weāll do this by setting all host bits to 0 and then setting all host bits to 1.
Host bits to 0:
Starting address: 10101100.00010000.00000000.00000000
Wildcard Mask: 00000000.00000000.00000011.11111111
Host bits to 1:
Ending address: 10101100.00010000.00000011.11111111
Wildcard Mask: 00000000.00000000.00000011.11111111
So what are the starting and ending addresses in dotted decimal format? They are:
You can see that all four of our subnets are included within that range, all because Rene used a larger wildcard mask. Does that make sense?
I hope this has been helpful!
Laz
āIf I have a network with 10.0.0.0 /21, it will be denied by this prefix list. It falls within the 10.0.0.0 /8 range, but it has a subnet mask of /21. Iām using the le operator, which says that the subnet mask should be /19 or smaller.ā
Iām confusedā¦ a /21 is technically smaller than a /19. Is the ge/le operator referencing the cidr number (more, or fewer bits) itself and not the actual size of the subnet? That is a little confusing. So a āsmallerā subnet mask than /19 is effectively a larger/less-specific subnet, i.e. /18../17../16?
My brain immediately thinks /17 is greater than /19 due to the subnet including more addresses, but i guess if you break it down to binary bits, 10000000 is less than 11000000
Hello Trevor
Yes, youāre correct. In the context of subnet masks, a smaller CIDR notation (like /19) actually represents a larger network because it includes more IP addresses. Conversely, a larger CIDR notation (like /21) represents a smaller network with fewer IP addresses.
Even so, the āleā and āgeā operators used by the prefix lists always refer to āless than or equal toā and āgreater than or equal toā in a numerical context. In other words, /20 is considered āgeā /19.
Think about it this way:
Does that make sense? It can be a bit counter-intuitive, but just remember that the āleā and āgeā operators are referring to the CIDR notation number, not the actual size of the subnet.
I hope this has been helpful!
Laz
summary
172.16.0.0/24
172.16.1.0/24
172.16.2.0/24
172.16.3.0/24
is
172.16.0.0/22 ?
Hello Armando.
Yes, the smallest summary route that will cover all 4 of those prefixes is 172.16.0.0/22. This will essentialy cover anything that falls under 172.16.0.0 - 172.16.3.255
David
Hello Armando
Yes, that is correct. In order to see this, letās represent the last two octets of these networks in binary like so:
172.16.00000000.00000000
172.16.00000001.00000000
172.16.00000010.00000000
172.16.00000011.00000000
As you can see, all of the bits in bold are the same for all four networks. Those are the first 22 bits. Starting at bit 23, the bits are not the same for all four networks. Therefore, it is the first 22 bits that can be used as the subnet mask.
A /22 subnet mask corresponds to 255.255.252.0.
I hope this has been helpful!
Laz
Hello,
Can I have ideas about the difference between a prefix-list without any operator (i.e. le, ge or eq) and a prefix-list with eq operator?
Just take the example in your lesson, what is the difference between the following 2 entries?
ip prefix-list FILTERTHIS seq 5 deny 172.16.1.0/24
vs:
ip prefix-list FILTERTHIS seq 5 deny 172.16.1.0/24 eq 24
Hello Anson
When you issue a command like this:
ip prefix-list FILTERTHIS seq 5 deny 172.16.1.0/24
you are essentially matching that specific network, including both the network and the prefix length. Itās the same as issuing an access list that denies that particular network.
Now if your router allowed you to use the eq operator, then there would essentially be no difference between the two commands. However, the eq operator is actually not part of the syntax. Take a look:
R1(config)#ip prefix-list FILTERTHIS seq 5 deny 172.16.1.0/24 ?
ge Minimum prefix length to be matched
le Maximum prefix length to be matched
<cr> <cr>
R1(config)#ip prefix-list FILTERTHIS seq 5 deny 172.16.1.0/24
Notice thereās no eq. To issue a prefix list to equal a particular prefix, you simply issue the specific prefix without any operator.
I hope this has been helpful!
Laz
Hello,
I recently came across two quite interesting prefix-list statements mentioned in the 350-502 cert guide for the SPCOR exam and thought this might be the right place for some clarification:
10.0.7.10/32 ge 16 le 24
The book states: ā10.0.0.10 to 10.0.255.10, any /32 prefix in this rangeā
10.0.8.0/28 ge 8 le 16
The book states: ā10.0.8.0/26 to 10.255.8.0/26, any /26 prefix in this rangeā
What initially confused me is the fact that those statements arenāt even valid, at least not in IOS (not sure though about IOS XR).
I would be very grateful for some help on this one!
Best regards from Austria,
Leon
Hello Leon
The CERT guide does indeed seem to be incorrect. If you try those specific commands, you get:
R1(config)#ip prefix-list TEST_LIST permit 10.0.7.10/32 ge 16 le 24
% Invalid prefix range for 10.0.7.10/32, make sure: len < ge-value <= le-value
R1(config)#ip prefix-list TEST_LIST2 permit 10.0.8.0/28 ge 8 le 16
% Invalid prefix range for 10.0.8.0/28, make sure: len < ge-value <= le-value
R1(config)#
As you can see, one of the verifications that is applied to the statement is to make sure that the applied length (the / value) is between the ge value and the le value. In both cases, this is violated and fails.
I believe that the CERT text has a typo. What I think they wanted to say is this:
ip prefix-list HOSTS-IN-10 permit 10.0.0.0/16 ge 32 le 32
and
ip prefix-list RANGE-10 permit 10.0.0.0/8 ge 16 le 24
These result in the actual descriptions that they share for each one, respectively. This applies to both IOS and IOS XR (though IOS XR uses prefix-sets with slightly different syntax, the same logical constraints apply). That was a good catch on your part, it means that your understanding of prefix lists is quite solid.
I hope this has been helpful!
Laz
Hi Laz,
Thank you very much for your reply, really appreciate it.
You are probably correct about the typo, I just took another look at the chapter and found some similar mistakes.
Regards,
Leon
Hello Laz,
Quick question. In the part of the lesson where we filter the 172.16.1.0/24 prefix on R1 by applying:
ip prefix-list FILTERTHIS deny 172.16.1.0/24
ip prefix-list FILTERTHIS permit 0.0.0.0/0 le 32
Could we have done this instead:
ip prefix-list FILTERTHIS deny 172.16.0.0/16
ip prefix-list FILTERTHIS permit 0.0.0.0/0 le 32
I thought the above prefix list would have worked in order to filter the 172.16.1.0/24 network from being learned by R1, and also 172.16.0.0/24, 172.16.2.0/24, and 172.16.3.0/24 since they all fall within the 172.16.0.0/16 range, but it didnāt actually filter anything when I tried it on CML.
After experimenting and reading through this forum it seems like if I donāt specify any ge or le arguments in my prefix list, that the range I pick has to match the exact network and subnet mask being advertised by a neighbor if I want to filter it. Iām assuming thatās why my /16 range does not work by itself, but specifying the exact network and subnet mask I want to filter works.
I tried using the general 172.16.0.0/16 range with ge 17 to filter all of the prefixes out and that seemed to have worked, since it would deny all prefixes that fall inside the 172.16.0.0/16 range and have a subnet mask of /17 or greater, which would match the /24 prefixes that I want to deny:
ip prefix-list FILTERTHIS deny 172.16.0.0/16 ge 17
ip prefix-list FILTERTHIS permit 0.0.0.0/0 le 32
I could have even used ip prefix-list FILTERTHIS deny 172.16.0.0/16 le 24 and that should work too.
Is my understanding correct? We have to specify the exact network and subnet mask we want to filter if we skip the ge or le arguments?
Thank You Laz
Hello Paul
Yes, your understanding is absolutely correct! This is a fundamental aspect of how Cisco prefix-lists operate.
When you configure a prefix-list entry without the ge or le operators, the prefix-list requires an exact match of BOTH:
When you configured ip prefix-list FILTERTHIS deny 172.16.0.0/16, the router checked if the first 16 bits match 172.16.0.0, and they do. And then it checked if the subnet mask is exactly /16, and it is not. The result is that there is no match, so the route passes through to the permit statement.
Youāre absolutely right. This matches any route that:
Yes. In this case, this matches any route that:
It looks like your understanding is correct!
I hope this has been helpful!
Laz
HI Rene,
Great lesson, i have a questionā¦ what is the role of a distribute-list, can filtering be done without using the distribute-list, Iāve noticed every prefix-list that you configured a distribute-list is there as well..
Hello Irfan
Thatās a great question! It all comes down to the way that Cisco performs routing policies. Cisco uses a variety of entities to apply it. These include prefix lists, distribute lists, access lists, route maps, and others.
In most cases, you can define what you want to match in one entity, and how/where you want to apply it in another. In this particular case, the prefix-list is being used to define the āwhatā. It is used to match prefixes (routes). The distribute list is used to configure how/where the matching must be applied. In this case, it connects the filter definition to a routing protocol so that it can actually take effect.
A distribute list is an entity that is confined to the routing protocol configuration mode. It is always applied within the configuration of a routing protocol like OSPF or EIGRP. It can be used to reference a prefix list or an ACL and specifies a direction where āinā filters routes being learned, while āoutā filters routes being advertised, and it can optionally specify an interface or neighbor.
Distribute lists are specifically designed for filtering routing protocols, and that is why Rene used them in all of his examples.
However, you can filter without using distribute lists:
For route filtering, just remember, you need both a definition and an application mechanism. Some protocols (like EIGRP) primarily use distribute lists for filtering, while others, like BGP allow multiple methods.
I hope this has been helpful!
Laz