How to create Complex Wildcard Masks

Rene,

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

Thanks,

bruce

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.

Rene

Rene,

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 192.168.10.0 0.0.248.255 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 0.0.48.255 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:

00
01
10
11

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

Now look at your wildcard (0.0.248.255) :

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:

0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1100
1101
1110
1111

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…

Rene

Rene,

Excellent explanation!

Thank you.

bruce

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

56 0011 1010
should be

58 0011 1010

Thanks,
Barry

Thanks Barry, just fixed it.

Hi Rene,

Instead of below command,

R2(config)#ip access-list standard EVEN
R2(config-std-nacl)#permit 192.168.0.0 0.0.254.255

May we show like below?

R2(config)#ip access-list standard EVEN
R2(config-std-nacl)#permit 0.0.1.0 255.255.254.255

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.

Rene

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
deny 0.0.0.0 255.254.255.255
deny 0.0.1.0 255.255.254.255
permit any

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

ip access-list standard ACL_COMBO
deny 0.0.1.0 255.254.254.255
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:

10.0.0.1
10.0.1.1
10.1.0.1
10.1.1.1
10.2.0.1
10.2.1.1

Then here’s all that is left afterwards:

10.0.0.1
10.1.0.1
10.1.1.1
10.2.0.1

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

10.0.0.1 = 00000000 00000000
10.0.1.1 = 00000000 00000001
10.1.0.1 = 00000001 00000000
10.1.1.1 = 00000001 00000001
10.2.0.1 = 00000010 00000000
10.2.1.1 = 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:

10.0.1.1
10.2.1.1

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

Does this help? :slight_smile:

Rene

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:
10.1.0.1

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):
10.0.0.1
10.1.0.1 <------ Also the result of ACL_ODDEVEN
10.1.1.1
10.2.0.1

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)
----------------------------
deny 0.0.0.0 255.254.255.255
deny 0.0.1.0 255.255.254.255
----------------------------

#2 (ACL_Combo, essentially)
----------------------------
deny 0.0.1.0 255.254.254.255
----------------------------

#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.

Rene

Thank you for this great explanation.
Make much more sense now :slight_smile:

19 posts were merged into an existing topic: How to create Complex Wildcard Masks

Hi Rene ,

Great article ever :slight_smile:

How i will filter only odd ip from the block 192.168.0.0/24 and allow Even IP from this ??

br//
zaman

The simplest way (which permits only even IPs from 192.168.0.0/24) would be this:

ip access-list standard ACL_PERMIT-EVEN
 permit 192.168.0.0 0.0.0.254

Remember that ACLs have an implicit deny all at the end, so nothing other than what is matched would be allowed. If you wanted to let everything through except the odd IPs from 192.168.0.0/24, you would have to tweak this a bit:

ip access-list standard ACL_DENY-ODD
 deny 192.168.0.1 0.0.0.254
 permit any

--Andrew

Hi Rene,

When find the wildcard mask for the Even subnet you mentioned:
'The first two octets are the same for all the subnets so we use all zeroes for the wildcard mask. In the third octet we use a 1 (don’t care) for all bits except for the 8th bit…it has to match. ’

Use 1 for all bits except the 8th bit (which is 0) will produce 1111 1110 which gives you a wildcard mask of 0.0.254.255.
Why is it that (except the 8th bit) doesn’t apply to Uneven subnet where the 8th bit is 1? As Uneven subnet also uses wildcard mask of 0.0.254.255,

Hello Kenneth.

Using the same example as that found in the lesson, if you want to specify only the EVEN subnets, then you will use a network address of 192.168.0.0 and a wildcard mask of 0.0.254.255. Note the following:

192.168.0.0   11000000	10101000	00001000	00000000
0.0.254.255   00000000	00000000	11111110	11111111

The last bit of the third octet of the network address must remain 0 since the wildcard mask has a 0 in that position. If that remains 0, then all the values of the third octet will be EVEN, such as 0, 2, 4, 6, 8, 10 and so on.

Alternatively, if you want to specify only the ODD subnets, you will still use the same wildcard mask, BUT, you will use a different subnet address. In this case you would use 192.168.1.0 and a wildard mask of 0.0.254.255. Note the following:

192.168.1.0   11000000	10101000	00001001	00000000
0.0.254.255   00000000	00000000	11111110	11111111

In this case, the last bit of the third octet of the network address must remain 1 since the wildcard mask has a 0 in that position. If that remains 1, then all the values of the third octet will be ODD, such as 1, 3, 5, 7, 9, 11 and so on.

So it is the initial subnet address that indicates whether it is the ODD or EVEN subnets that will be specified and not only the wildcard mask itself.

I hope this has been helpful!

Laz