Cisco IOS provides the capability to log matches against access list expressions by appending the log or log-input keyword to a statement. By enabling ACL logging we can harness a great deal more detail than simple packet counters provide. For example, consider the following topology:

An ACL has been created to block SSH traffic on R1, and applied inbound on the FastEthernet0/0 and FastEthernet0/1 interfaces:

Extended IP access list Block_SSH
    10 deny tcp any any eq 22
    20 permit ip any any

When an administrator attempts to SSH to R1 from one of the other routers, the TCP connection is rejected by R1 and its ACL counter increased appropriately:

R2# ssh 1.1.1.1
% Destination unreachable; gateway or host down

R1# show ip access-lists
Extended IP access list Block_SSH
    10 deny tcp any any eq 22 (3 matches)
    20 permit ip any any (24 matches)

The stock ACL counters give us a good idea of how much traffic is being allowed or rejected, but not where that traffic is coming from (or going to). We can alter the first entry in our Block_SSH ACL and append the log keyword to log matches.

R1(config)# ip access-list extended Block_SSH
R1(config-ext-nacl)# no 10
R1(config-ext-nacl)# 10 deny tcp any any eq 22 log
R1(config)# ^Z
R1# show ip access-lists
Extended IP access list Block_SSH
    10 deny tcp any any eq 22 log
    20 permit ip any any (444 matches)

Now SSH traffic will continue to be blocked and the ACL counters to increase, but the router will also generate a log message indicating when the match occurred, where the packet came from, and where the packet was headed:

%SEC-6-IPACCESSLOGP: list Block_SSH denied tcp 10.0.12.2(28467) -> 1.1.1.1(22), 1 packet

This is certainly handy, but what if we expand our topology to include a LAN (192.168.0.0/24) attached to both R1 and R2?

Imagine R2 and R3 are also supposed to be blocking SSH traffic, but one of them has had its ACL mistakenly erased. If a user from the LAN attempts to SSH to R1 via the unsecured router, the traffic will still be blocked at R1, but the log message won't help us determine where the leak is:

%SEC-6-IPACCESSLOGP: list Block_SSH denied tcp 192.168.0.42(30316) -> 1.1.1.1(22), 1 packet

To provide even more detail in our ACL log entries, we can replace the log keyword with log-input. log-input includes all the detail provided by log plus some handy layer two information.

R1(config)# ip access-list extended Block_SSH
R1(config-ext-nacl)# no 10
R1(config-ext-nacl)# 10 deny tcp any any eq 22 log-input
R1(config-ext-nacl)# ^Z
R1# show ip access-lists
Extended IP access list Block_SSH
    10 deny tcp any any eq 22 log-input
    20 permit ip any any (1683 matches)

Here's what the log records when the same SSH attempt from the LAN is repeated:

%SEC-6-IPACCESSLOGP: list Block_SSH denied tcp 192.168.0.42(15111) (FastEthernet0/1
 c203.73ae.0001) -> 1.1.1.1(22), 1 packet

Now we can easily determine both the incoming interface (FastEthernet0/1) and the source MAC address from the prior hop (c203.73ae.0001). Note that this MAC belongs to R3, not the origin host. These attributes clearly point to R3 as the unsecured router, and we can now move to secure it.