CCNA: The Explicit Deny All

One of the key facts regarding Access Control Lists (ACLs) that we drill into your head during CCNA is the fact that the lists you create end with what is called the “implicit” deny all. You do not see it, but the effect is undeniable. Any packets that do not match any of the permit statements in your list get deny treatment. In the case of our filtering access lists, this means the packets are dropped. As you recall from the course, this is why we desperately require at least one permit entry in all of our filtering access control lists.
But what if we want to track what we actually drop as a result of this powerful implicit deny all effect? Well, a clever trick is to end the list with an explicit deny statement and log the result. In this post, we will examine this technique.
Let’s create a named, standard ACL that permit packets sourced from the 10.x.x.x address space.

ip access-list standard AL_PERMIT_10
permit 10.0.0.0 0.255.255.255

Now I will apply this ACL inbound to a router interface and generate some traffic that matches this statement. When we run the command show access-lists, we can see from the “hit counter” that the permit has caught some matches. But what about packets that have failed?

R1(config-std-nacl)#int fa0/0
R1(config-if)#ip access-group AL_PERMIT_10 in
R1(config-if)#end
R1#
R1#show access-lists
Standard IP access list AL_PERMIT_10
10 permit 10.0.0.0, wildcard bits 0.255.255.255 (57 matches)

In order to be alerted about packets that hit the implicit deny all, we need to create an explicit one. If we are really concerned about packets that do not match any permits, we can add the log option so we can be alerted at the command line, in addition to being notified when we do the show access-list command.

R1(config)#ip access-list standard AL_PERMIT_10
R1(config-std-nacl)#deny any log

After this configuration change, watch what happens when someone from 1.1.1.1 tries to ping into R1 through our interface:

R1#
*Mar  1 00:12:23.251: %SEC-6-IPACCESSLOGNP: list AL_PERMIT_10 denied 0 1.1.1.1 -> 10.0.0.1, 1 packet
R1#show access-lists
Standard IP access list AL_PERMIT_10
10 permit 10.0.0.0, wildcard bits 0.255.255.255 (117 matches)
20 deny   any log (5 matches)

One question I often get from students at this point is: why did we only get one notification (of one packet) via the command line system message, but there were in fact 5 packets that were blocked (as depicted in the show command output)?
The answer is that the IOS is being smart here and it will batch up the log messages so that the system is not overwhelmed in trying to show us all of these matches in real time.