Cisconinja’s Blog

Using ACLs with discontiguous wildcard bitmasks – an example

Posted by Andy on November 21, 2008

Suppose we’ve been given the requirement to permit the following 3 (randomly chosen) addresses:

 

#1 – 131.47.104.88

#2 – 203.42.155.67

#3 – 90.143.32.224

 

and to deny the following 3 (also randomly chosen) addresses:

 

#4 – 152.209.18.22

#5 – 8.25.99.150

#6 – 79.242.201.57

 

using only a single line access list.  Conventional access list knowledge would say that this is impossible, because even the very first bit differs between the 3 addresses that we must permit.  However, the truth is that each bit of an ACL is treated individually, and wildcard masks do not need to be contiguous.  In order to find the most specific address and wildcard mask that will match the first 3 addresses, we first convert each of them to binary:

 

#1 – 131.47.104.88  =  10000011 . 00101111 . 01101000 . 01011000

#2 – 203.42.155.67  =  11001011 . 00101010 . 10011011 . 01000011

#3 – 90.143.32.224  =  01011010 . 10001111 . 00100000 . 11100000

 

Next, we perform a logical AND on these 3 addresses to obtain the address portion of our ACL statement:

 

  10000011 . 00101111 . 01101000 . 01011000

  11001011 . 00101010 . 10011011 . 01000011

AND    01011010 . 10001111 . 00100000 . 11100000

————————————————————————————

   00000010 . 00001010 . 00000000 . 01000000  =  2.10.0.64

 

Next, we perform a logical XOR on these 3 addresses to obtain the wildcard mask portion of our ACL statement:

 

  10000011 . 00101111 . 01101000 . 01011000

  11001011 . 00101010 . 10011011 . 01000011

XOR   01011010 . 10001111 . 00100000 . 11100000

————————————————————————————

  11011001 . 10100101 . 11111011 . 10111011  =  217.165.251.187

 

Why AND the addresses to find the address portion and XOR them to find the wildcard mask?  The logic works as follows:

1.  If all addresses have the same value in a given bit position, use that value in the address portion of the ACL entry.  This bit will be ‘checked’ (Step #3), so the value of that bit in the address portion must match the value of that bit in all the addresses we want to permit.

2. If not all addresses have the same value in a given bit position, use zero as the value for that bit.  This bit will not be ‘checked’ anyway (Step #4) because doing so would only allow a subset of the addresses that we want to match.  We could, in fact, use either a zero or one here without affecting the matching logic since it is not checked anyway, but standard practice is to use a zero.

3. If all addresses have the same value in a given bit position, place a zero in that position in the wildcard mask portion.  This means that we will ‘check’ this bit, meaning we will require it to match the value that we specified for this bit position in the address portion.  This should always result in a match, because in Step #1 we placed the value that all of these addresses have in common in that position.

4. If not all addresses have the same value in a given bit position, place a one in that position in the wildcard mask portion.  This is considered a ‘don’t care’ bit, and means that we do not require it to match.

 

Ok, so the address and wildcard mask that we came up with meet our requirement of permitting the first 3 addresses, but what about denying the next 3?  Start with the wildcard mask and look at all bit positions that contain a zero.  We’ve specified that these bits must match our address portion of the ACL, so allow the address bits to ‘pass through’ the wildcard bits where the wildcard bit is a zero and cross out all other bit positions that we are not checking:

 

ACL Address    00000010 . 00001010 . 00000000 . 01000000

ACL Wildcard   11011001 . 10100101 . 11111011 . 10111011

————————————————————————————————-

 Filter              xx0xx01x . x0x01x1x . xxxxx0xx . x1xxx0xx 

 

Next, compare each of the addresses that we want to deny against this filter.  If any bit that isn’t crossed out differs, the address will be denied.

 

#4 – 152.209.18.22   =  10011000 . 11010001 . 00010010 . 00010110

#5 – 8.25.99.150       =  00001000 . 00011001 . 01100011 . 10010110

#6 – 79.242.201.57  =   01001111 . 11110010 . 11001001 . 00111001

 

Addresses #4 and #5 will be denied by the 3rd bit that we are checking (7th bit, 1st octet).  Address #6 will be denied by the 2nd bit that we are checking (6th bit, 1st octet).  It appears that our address and wildcard will accomplish what we need.  Our ACL statement becomes:

 

access-list 1 permit 2.10.0.64 217.165.251.187

 

 However, note that the usefulness of an ACL like this is very limited, because it permits much more than we need to.  Because there are 22 ‘don’t care’ bits in the wildcard mask, this ACL will permit a total of 2^22 (4,194,304) different addresses.  A randomly chosen address will have a 1 in 2^10 (1/1024) chance of being permitted by our single line ACL.

Finally, let’s test it out and see if it works correctly.  We will use a simple 2 router topology as shown below:

acl-lab1

R1 will be using 6 loopbacks to simulate our addresses and sourcing pings from each of them to R2.  R2 will use the ACL we created inbound on F0/0.  The relevant portions of each router’s configuration are shown below: 

 

acl-lab-r1-config1

 

acl-lab-r2-config2

 

 

 

Now we can initiate pings on R1 to R2 sourced from each of our 6 addresses:

 

acl-lab-results

The first 3 addresses are permitted and second 3 are denied, just as we expected.

 

One final note on using discontiguous wildcard masks is that not all IOS features will allow them.  Attempting to use the same address and wildcard mask to enable OSPF on the first 3 loopback interfaces of R1 gives the following result:

acl-lab-ospf

Advertisements

2 Responses to “Using ACLs with discontiguous wildcard bitmasks – an example”

  1. Passing Through said

    Good tutorial, one thing:


    131 1000 0011
    203 1100 1011
    90 0101 1010
    1101 1001 = 217

    217 for the wildcard, not 221.

  2. Andy said

    Oops, you’re right. Fixed.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: