Access Lists and Binary Math! Eeek!

[TonyZ]

I bought the Cisco CCNA flash card exam pack.
One of the questions asks:
Create a standard access list that permits the following networks:
192.168.200.0
192.168.216.0
192.168.232.0
192.168.248.0

One of the answers they give is:

access-list 10 permit 192.168.200.0 0.0.48.255

They then proceed to show how that answer is derived, by converting all of the third octet values to binary, and finding the bits that don't match.
200=11001000
216=11011000
232=11101000
248=11111000

Since all bits match, except the 3rd and 4th, we turn those bits on and get 48.

OK, while I'm sure this is valid, do we need to have this skill for the CCNA test? Todd wen't out of his way to avoid binary math and provide fabulous shortcuts for doing the job. Todd even said that, "you can only specify the exact amount as the block size value," in a wildcard mask, which this is not.

Please help with this confusion!

Thanks,

Tony

[lammle]

although I show how to convert binary math in my chapter 1, I have drank more than 10 bottles of Crown Royal since then so I can't help you...I only use block sizes...
I am sure there are plenty of people on this forum that are smarter than me that can help you on this forum!
I don't do binary - "see my chapter 3"... :)
Todd

[TonyZ]

Only 10 bottles?
You must not be spending enough time with routers! :)

[Fuzz]

0.0.48.255 is invalid as a wildcard mask. Wilcard masks are always odd numbers in the interesting octet, and are always one less than the block size. To calculate the wildcard mask, first find your block size (bypassing the binary maths!) and subtract one from it in your interesting octet. That's your wc mask.

The method they show for which bits are similar is flawed. The wildcard mask must be contiguous.

200=11001000
216=11011000
232=11101000
248=11111000

Yes the 3rd and 4th bits (actually, it's the 5th and 6th bits as the left hand side is the high order bit, we read bits from the right) are the only dissimilar ones, but as they are halfway through the mask, you must drop any bits preceeding. So only the 1st through 4th are contigually similar. Turn those and the dissimilar bits on and you get 63 (00111111). Why? Because the highest order bits that are similar are part of the same network address. As those addresses fit into a block size of 64, that fits with Todds method of not needing to do binary maths - both methods reach the same result.

Again though, there is a problem. A block size of 64 starting on 192.168.200.0 is not possible, as this would include address 192.168.263.0, which is obviously invalid. For this to work, you would have to start at address 192.168.192.0 and use the wildcard of 0.0.63.255.

If you don't want to include the 192.168.192.0 subnet in the access list, you will need more than one line in your ACL to filter out the correct subnet - two with a block size of 8, one with a block size of 32.

Basically, that question is awful as the networks aren't contiguous, and must have VLSM in order to work.

[HermeszData]

0.0.48.255 is invalid as a wildcard mask. Wilcard masks are always odd numbers in the interesting octet, and are always one less than the block size. To calculate the wildcard mask, first find your block size (bypassing the binary maths!) and subtract one from it in your interesting octet. That's your wc mask.

The method they show for which bits are similar is flawed. The wildcard mask must be contiguous.

200=11001000
216=11011000
232=11101000
248=11111000

Yes the 3rd and 4th bits (actually, it's the 5th and 6th bits as the left hand side is the high order bit, we read bits from the right) are the only dissimilar ones, but as they are halfway through the mask, you must drop any bits preceeding. So only the 1st through 4th are contigually similar. Turn those and the dissimilar bits on and you get 63 (00111111). Why? Because the highest order bits that are similar are part of the same network address. As those addresses fit into a block size of 64, that fits with Todds method of not needing to do binary maths - both methods reach the same result.

Again though, there is a problem. A block size of 64 starting on 192.168.200.0 is not possible, as this would include address 192.168.263.0, which is obviously invalid. For this to work, you would have to start at address 192.168.192.0 and use the wildcard of 0.0.63.255.

If you don't want to include the 192.168.192.0 subnet in the access list, you will need more than one line in your ACL to filter out the correct subnet - two with a block size of 8, one with a block size of 32.

Basically, that question is awful as the networks aren't contiguous, and must have VLSM in order to work.

Or you could just make the assumption that they left out some of the network blocks and use a block size of 8 (this is how I would read the question if posed as the OP has!) This would yeild a mask of:

0.0.7.255.

Or ....

i may be completely off as well!

[Fuzz]

Agreed, however they gave an answer and explained why, which is totally misleading. The question shoudl also have subnet mask information, else you can not tell exactly which subnets need matching.

[anurag007]

agreed wid Fuzz....
NCe AnsWEr.............

[TonyZ]

I decided to test the above access-list in a SIM, and it appears to be valid.

I applied "access-list 10 permit 192.168.200.0 0.0.48.255" outbound on an interface.
Hosts on the 192.168.200.0, 192.168.216.0, 192.168.232.0, and 192.168.248.0 networks were all allowed to ping through the access list.
Other hosts (like 192.168.150.0, or 172.16.0.0) were sent "Destination host unreachable" messages from the router.

I also tried another variation:

"access-list 10 permit 0.0.10.10 255.255.0.0"
It would seem this would effectively let any packet with a source address ending in 10.10 through.
With this appled outbound on an interface, hosts 10.5.10.10 and 172.16.10.10 could ping a host connected to that interface, but hosts 10.5.11.11 and 172.16.0.1 received the "Destination host unreachable" message.


Tony

[TonyZ]

I also wanted to see what happened with a mask like: 0.0.0.21
In binary, the last octet is 00010101.
Bit values 1,4, and 16 are turned on.

Going through all the possible variations, this should match on
00000001 = 1
00000100 = 4
00000101 = 5
00010000 = 16
00010001 = 17
00010100 = 20
00010101 = 21

I wrote an access list:
access-list 10 permit 192.168.0.0 0.0.0.21 and applied it to an interface.

Sure enough, 192.168.0.1,4,5,16,17,20, and 21 matched the list.
But 192.168.0.22, or 192.168.0.100 did not match.

So it would appear that wildcard masks to not require contiguous 1's and the 1's do not have to start in the least significant bit position!
Let's hope this doesn't appear on a CCNA test anytime soon.
Tony