How to create Complex Wildcard Masks

This topic is to discuss the following lesson:


great article about wildcard masks :slight_smile:
People ask me “Daniel, what is the need for a wildcard? We have Subnetmasks, haven’t we?”
Especially when configuring EIGRP and using the network-command the first time, it is a bit confusing for others.

This is a perfect example of the powerful value of wildcards.

Thank you for that good post.


Hi Daniel,

It is confusing for sure :slight_smile: Wildcards let us do some of these funky things…glad you liked it!


Hi Rene. your site is really useful. it is comprehensive and I really enjoy reading your articles. I have a question, I’m a bit confused about wildcard mask for even and odd networks. I calculated the WC as “” but you have calculated “”.
what was my mistake? could you plz explaint it more?

Hi Parastoo,

Let’s say we have the following networks: /24 /24 /24 /24

This is what the 3rd octet looks like in binary:

0 = 0000 0000
1 = 0000 0001
2 = 0000 0010
3 = 0000 0011

What the even networks have in common is that the last bit is always a 0, the uneven networks always have a 1 as the last bit. That’s something we can match on:

Wildcard 254 = 1111 1110 and means “don’t look at the first 7 bits but the last bit HAS to match”.

Wildcard 14 = 0000 1110 and means that the first 4 bits have to match, we don’t care about bit 5,6 and 7 but the last bit also has to match.

We don’t care about those first 4 bits, only the last bit is interesting if we want to match on even or uneven networks.

Also your last octet should be 255 (not 0). We don’t care about the last octet in this example.


Tx alot, I got it.excellent explanation.


That “NOT_SO_RANDOM” ACL is some crazy logic. I had no idea you could match like that.



Hi Bruce,

Yes it is, does help to really understand how the wildcards work. It’s something you probably only could see on a R&S lab though.



I’m able to follow the wildcard mask logic. However, why the ‘.10’ in the third octet? I’m guessing that’s the most uniform bits starting at the lowest significant bit position.

Would acomplish the same thing?

Hi Bruce,

I used the .10 in the third octet since that’s the first network we try to match. With the wildcard bits we only match on those 4 networks. Let’s zoom in on those 4 networks and the wildcard:

10 = 0000 1010
26 = 0001 1010
42 = 0010 1010
56 = 0011 1010

wc = 0011 0000

by setting all bits to “0” we lock them, only the 3th and 4th bit is allowed to change:


Those are the only 4 combinations you can make, resulting in network,, and…nothing else is matched.

Now look at your wildcard ( :

10 = 0000 1010
26 = 0001 1010
42 = 0010 1010
56 = 0011 1010

wc = 1111 0000

Now only the last 4 bits are “locked” and we are allowed to change the first 4 bits. This wildcard will match the above networks but it also matches a lot of other networks, everything that starts with:


So if this was a CCIE lab, you’d have to read the task closely…see if they say “match these 4 networks” or “match ONLY these 4 networks” :slight_smile:

Hope this helps…



Excellent explanation!

Thank you.


Great tutorial. Finally!!! Just a little typo :

56 0011 1010
should be

58 0011 1010


Thanks Barry, just fixed it.

Hi Rene,

Instead of below command,

R2(config)#ip access-list standard EVEN

May we show like below?

R2(config)#ip access-list standard EVEN

Hi Onur,

That will match all even subnets yes, no matter what the network address is. In my example we are matching all even subnets only in the 192.168.x.x range.


Hey Rene,
I wanted to ask about using access-lists to solve that classic problem of filtering odd or even routes. Suppose you were asked to create a filter that would allow a route if it were odd in the 2nd octet, and even in the 3rd octet. Obviously, you can accomplish it with this:

ip access-list standard ACL_ALLOWODDEVEN
permit any

But what isn’t obvious to me, is why the following does NOT work:

ip access-list standard ACL_COMBO
permit any

I thought they accomplished the same thing, but doing this in the lab proves me wrong.

Any thoughts?

Hi Andrew,

These questions can be tricky…we’ll have to look at some binary numbers, especially the 2nd and 3th octect:

2nd + 3rd = 00000000 00000001
wildcard = 11111110 11111110

So the only bits we care about are the 8th bit (has to be 0) and the 16th bit (has to be a 1).
Once I apply your access-list on these addresses:

Then here’s all that is left afterwards:

Let’s look at all addressses’ 2nd and 3th octet in binary: = 00000000 00000000 = 00000000 00000001 = 00000001 00000000 = 00000001 00000001 = 00000010 00000000 = 00000010 00000001

Now take a close look at the 8th and 16th bit of each address…if the 8th bit is a 0 and the 16th bit a 1 then we deny it. this applies to:

Everything else is permitted. This explains why you see these results.

Does this help? :slight_smile:


I must be slow today. I have read over your analysis many times, but I am still not understanding this. Let’s continue to use your range of 10 addresses for the example.

If I take the entire set of 10. addresses, and run them through the ACL_ODDEVEN filter, just one is left:

If I take the entire set of 10. addresses, and run them through the ACL_COMBO filter, a total of four is left (which is what you found above): <------ Also the result of ACL_ODDEVEN

If we look at the results of the ACL_COMBO in binary (just the 2nd and 3rd octet):
00000000 00000000 <------ This should have been filtered
00000001 00000000 <------ Correct, also the result of ACL_ODDEVEN
00000001 00000001 <------ This should have been filtered
00000010 00000000 <------ This should have been filtered

I have bolded the bits that would have caused the set of numbers above to have failed ACL_ODDEVEN. The question is why isn’t ACL_COMBO also failing these? Is there some kind of logic change between these?
#1 (ACL_ALLOWODDEVEN, essentially)

#2 (ACL_Combo, essentially)

#1 looks for an exact match of the least significant bit of the 2nd octet for the first line, then
looks for an exact match of the least significant bit of the 3rd octet for the second line.

#2 looks for an exact match of the least significant bit of both the 2nd and 3rd octet.

So in both cases, an exact value is being matched on in the second and third octet. The difference is #1 does it in two statements, while #2 does it in one statement.

In the lab, these two behave differently.

Ok, I feel like a dope. I finally broke down and charted out what was happening in a spreadsheet. After doing this it became clear.

Basically, it comes down to this–the ACL_COMBO is doing an “AND” while the ACL_ALLOWEVENODD is doing an “OR”.

Part of the confusion here is that we are using the ACLs to deny, or filter out, routes (so the logic is flipped). The ACL_COMBO is written too restrictively (hence the resulting filtered set is too large).

ACL_COMBO is saying “You are denied only if the last bit of the second octet is a zero AND the last bit of the 3rd octet is a one.”

ACL_ALLOWODDEVEN is saying, “You are denied if the last bit of the second octet is a zero OR if the last bit of the third octet is a one.”

Sheesh. I need more vitamin B-12, I suppose. Thanks for helping me think through this!

Hi Andrew,

Good to hear you figured it out :slight_smile: You are indeed denying everything with a even number in the 2nd octet and odd number in the 3th octet but that means that a lot of networks are still permitted.

If you want only networks with an odd 2nd octet and even 3rd octet then it’s better to create a statement that only permits those.