Answers for Part II

So the answers to the exciting tasks at hand….

There was a good amount of activity surrounding answers submitted for the contest!  It was good to see that many people interested in them!  Now, it’s time to go through the answers and stretch the imagination a bit!  Be prepared for some stretching as well!

One quick thing to point out before we get started, there was a question asked about why /24 routes won’t have a “.255″ as the fourth octet.  This really depends on how we are using the ACL.  If we are doing traffic filtering, where packets will obviously come from hosts INSIDE the /24, then yes, I’d use a “.255″ mask.

However, when the entry is being used for a routing filter, and it’s a /24 route…  The fourth octet will, by definition, always be “.0″ and shouldn’t be changed.  So the mask of “.0″ prevents anything from changing!

Now…  On to the answers!

1.  Now, there are a total of 16 things we’re trying to match.  So in the best of worlds, we can do this in a single line (because it’s an exponent of two), but if and ONLY IF we find a total of four bits different across the entire 32-bit address.  So let’s solve it.

Where do we have differences?  All over the place!  So let’s isolate them.

2nd octet:

34    00100010
50    00110010

Only the 16-bit position is different here.  (mask of 00010000)  This could have been discovered by the subtraction method!

3rd octet:

80    01010000
208    11010000

Only the 128-bit position is different here.  (mask of 10000000)  This could have been discovered by the subtraction method!

4th octet:

133    10000101
165    10100101
197    11000101
229    11100101

It’s a little more difficult to use the subtraction method here as well!   But we discover that there are only two bits of difference here, in the 64-bit position and the 32-bit position. (mask of 01100000)

So we DO have a total of four bits across these numbers.  Cool.  One line, right?

But go back to re-read the question.  There’s more to it than that!  The even-numbered bits of the SECOND-HALF of a /24.  Now that’s just plain evil!

So numbers from 128-254, and only the even ones.  Now we’ve done the even numbered thing before.  That’s a mask of “.254″ (11111110) with the starting point of .0…  But here we want only the second half.  So what else is consistent in even numbers OVER 128?  (hint:  the 128-bit position!)

access-list 101 deny ip
access-list 101 permit ip any any

And we’ll assume that the access-list is either applied inbound on a WAN link, or outbound on our LAN link!

2.   Pure summarization now.  But there’s only 12 lines listed.  That doesn’t work out as nicely for single-line summarization!  The best we’ll be able to do is two lines.  but let’s work through the details.

First octet:

19 00010011
79 01001111
83 01010011

Second octet:

55 00110111
56 00111000

Third octet:

4 00000100
5 00000101
12 00001010
13 00001011
20 00010100

Yeah, now all of a sudden that two-line solution isn’t looking nearly as possible!  So let’s start isolating.  (Divide and conquer)

Really our consideration will be with the 19 and 83 address sets.  They each have 4, 5, 12 and 13 in the third octet.  The 79 addresses are completely different in the third octet.

First octet:

19    00010011
83    01010011

One bit of difference there in the 64-bit position.  (mask = 01000000)  This could be solved with subtraction.

Third octet:

4    00000100
5    00000101
12    00001100
13    00001101

While we can’t really do the subtraction method here, at least there’s only two bits of difference here.  (mask = 00001001)  These eight values can be summarized in a single line.  Three bits of difference (2^3 = 8 matches).

access-list 2 permit

Now, the 79-series of addresses.

Second octet:

55    00110111
56    00111000

Lots of differences here (four bits) so we’ll be treating these separately.

Third octet:


Why bother with the math?  Just subtract!  :)   Only the 16-bit position changes.  (mask = 00010000)

access-list 2 permit

So our entire solution:

access-list 2 permit
access-list 2 permit
access-list 2 permit

Hey!  Look!  Two lines.   But it seemed so ugly for a while!  We use “.0″ for the fourth octet because we were told this ACL is for routing updates.  /24′s in a routing update will always have .0 as the fourth octet!

3.  Ooooo..   A big, long, ugly looking one!  Well…  If we count them, there’s only 28 lines.  That’s definitely not going to solve in one line!  Best we can do there is three lines (16 + 8 + 4).  Hmmmmm.  Time to look at binary!

First octet:

124    01111100
132    10000100

Yeah…  That’s not going to happen.  Five bits of difference will get 32 matches.  :)   Even though the subtraction method says “8″ is the difference, since we cross a bit-boundary (128), all bets are off!

Second octet:

130    10000010
194    11000010

This is easier!  There’s one bit of difference between these two.  (mask = 01000000)  This could be solved via subtraction.

The third octet is all “.1″.  So that brings us to the fourth octet:

16    00010000
17    00010001
19    00010011
24    00011000
25    00011001
26    00011010
27    00011011

That’s just plain ugly now.  There are actually three bits of difference in there, but one very important piece to note.  18 is missing from the list, so it’s not all contiguous that way.

But wait…  The task actually says we need to include “18″ as a deny specifically!  So therefore we CAN count it.  Once we do that, three bits of difference makes things work (2^3 = 8 matches).

So let’s put it together now.

access-list 3 deny
access-list 3 deny
access-list 3 permit
access-list 3 permit

line vty 0 15  (optional for grading)
access-class 3 in (optional for grading)

4.  Now we need to first convert a prefix-list into an access-list.  THEN we need to look at the existing access-list and somehow integrate the two together.  Isn’t this just pleasant.

This not only tests you on your knowledge of access-lists and binary functions, but also on your knowledge of BGP distribute-lists!  See, our issue is that the current distribute list only looks at /24 information.  And not necessarily very well, but that’s the intent.  Our prefix-list looks at many mask lengths from /20, /21, /22, /23 and /24!

BGP distribute-lists can use an extended ACL to match the mask information as well!  Oh boy will this be fun.  Actually, it’s not nearly as bad as it looks!

With the prefix list, our binary starting point is all the same.  This is in “regular ACL” masking.  The masks we are looking for are:

So really, we’re matching on third octet values:

240    11110000
248    11111000
252    11111100
254    11111110
255    11111111

So the last four bits, I really don’t care what the values are.  Wait.  If we come up with a mask of 00001111 (15), what happens when we’re presented with a value of 247?  Wouldn’t that match?

Sure, technically it would match the mask we create.  But fortunately for us, there’s no way in reality we’re going to ever see a mask like that!  Route masking can only be done on bit boundaries!   So reality versus technical possibility (e.g. fantasy) are two completely different ideas!

access-list 104 permit

Now, we have to look at the remaining values.  These should be easier as it’s just a summarization question.

Third octet:

0    00000000
1    00000001
2    00000010
3    00000011
4    00000100
5    00000101
6    00000110
7    00000111
8    00001000
9    00001001
10    00001010
11    00001011
12    00001100
13    00001101
14    00001110
15    00001111

Again, the masking will be 00001111 (.15).

access-list 104 permit

So our whole ACL:

access-list 104 permit
access-list 104 permit

Well…  That was fun.  I will tell you, it was likely much more entertaining for me than it was for you.  But good stuff.  If nothing else, getting through these exercises, and having them actually make some semblance of sense to you, there’s NOTHING that the CCIE Lab can come up with that will scare you!

It’s good to be evil.  :)

See the Comments here for the list of winners!

You can leave a response, or trackback from your own site.

8 Responses to “Binary Math – Part II Answers”

  1. This, by the way was a fun exercise set, and I enjoyed all the responses! But, alas, there was no clear winner.

    A number of people were “partially correct”. Many had very simple (almost typographical) errors of putting the right mask value into the wrong octet position! But, in the end, that’s still wrong!

    There was only one person to get Question #4 correct!

    In any event, what we have decided to do, was split the prize. There were two people who answered three out of four correctly. They will each receive 60 tokens!

    Congratulations to Tolu Ogunsina and Csaba Kiss!!! You two may unicast e-mail me and we’ll arrange for your tokens!

    I hope everyone enjoyed these tasks and has learned something as well!

  2. uri says:

    Two notes here:


    [quote] This is

    I can hardly beleive in this :) Did you mean: ?


    150.100/20 is 0.0.15.*255*

    Of course, wildcard will work in case of up to /24 pfx_len matching but fail in case of more specific than /24…

  3. Uri,

    Regarding #1 – Yup. Typo. Fixed. :)

    Regarding #2 though, since we are talking about a distribute-list which will match routing updates, the only bits that change in value will be the last four of the second octet.

    If we see a value of anything but “0″ in the last octet position, then we are in to /25, /26, /27, etc.

    It’s only the route update itself we’re talkig about, not any hosts IN that network!


  4. uri says:

    Regarding #2… OK, as far as all this stuff is closely connected to this *particular* example… I agree — wildcard is enough :)

    P.S. Thank you for quiz!

  5. uri says:

    Btw, following your logic, the 1st entry: 0.1.255.*255*

    … should be optimized into: 0.1.255.*0*


  6. bruce porcelli says:


    I’ve found your article on binary incredible.. One question. Matching in an extended acl’s with Class-maps do they operate the same.. Meaning if I match hosts in an extended acl n nest in a class-map vs a route-filter would i expect anythin differnt

  7. Class-maps are looking at traffic, not routes. So the traffic-filters will utilize extended ACLs in the standard source and destination version rather than a route-filer which has no bearing on destination.


  8. Emma says:

    this is great i learned alot!


Leave a Reply


CCIE Bloggers