How to show logs on a deny ACL ?

[carl_townshend]

Hi All

Is it possible to show logs matching a deny ACL rule?

When you add the log keyword to the ACL what exactly does this show you? just hits or will it show you a log of the actual source IP etc?

If the above cannot be achieved, would you need to use the debug IP packet command?

Cheers

[Jens Albrecht]

Hello @carl_townshend,

the exact information shown will depend on the type of ACL that you configured.

In case of an extended ACL matching on protocol and port numbers an entry might look like this:

%SEC-6-IPACCESSLOGP: list <acl-name> denied <tcp/udp> <src-ip>(<src-port>) -> <dst-ip>(<dst-port), <num> packet(s)

In case of standard ACLs you can only see the IP addresses of course.

The logging level for your target has to be set accordingly in order to get these messages and if you use the local buffer the size needs to be adjusted accordingly as well.

HTH!

[carl_townshend]

Hi Jens, will these show up in the buffer? or only monitor / syslog ?

[Jens Albrecht]

Hi @carl_townshend,

this depends on your config. By default the buffer is really small, like 4096 bytes only on many devices.

So the first step is to check the current setup with the command "show logging" which will display the logging levels and buffer size as well the log entries in the buffer. The interesting part might look like this:

    Console logging: level debugging, 209 messages logged, xml disabled,
                     filtering disabled
    Monitor logging: level debugging, 53 messages logged, xml disabled,
                     filtering disabled
    Buffer logging:  level debugging, 209 messages logged, xml disabled,
                    filtering disabled
    Exception Logging: size (4096 bytes)

So in this case the messages will appear at the console, monitor (need 'terminal monitor' command for remote sessions) and saved in the buffer which in this case is only 4k small.

For lab environments the buffer is often sufficient but you need to adjust the size.
The following command increases the buffer size to 1 MB and changes the logging level for the buffer to informational to avoid debug messages filling it up quickly:

logging buffered 1000000 informational

With larger buffer sizes it makes sense to filter the output when checking for interesting entries:

show logging | include %SEC-6-IPACCESSLOGP

For production environments it is common to use a syslog server.
If the device has multiple IP addresses it is best practice to define the source-interface to make sure that the device always appear with the same IP address. Often loopback interfaces are used for this purpose but you can also use any physical interface or SVI for this purpose.

As an example the following config defines a syslog server (you can also define multiple if needed), sets the logging level to informational again, defines a source-interface, stamps the logger messages with a sequence number and finally defines the time/date to include the timezone, msec and year:

logging host <syslog_server_ip>
logging trap informational
logging source-interface Loopback1
service sequence-numbers
service timestamps log datetime msec localtime show-timezone year

HTH!

[paulwelchh]

Yes, you can log denied packets by using the log keyword in your ACL configuration. When you add a log deny rule, it will generate log messages for each packet that matches that rule. These log entries typically include details such as the source IP address, destination IP address, and the type of traffic (e.g., protocol).

[sidshas03]

The issue seems to be related to the logging configuration on the device, not the ACL itself. When using the log keyword in ACLs, the matched packets will generate logs, but these messages will only be visible if the logging levels and destinations (like buffer, console, or syslog) are correctly configured. Please run the show logging command to verify the current buffer size and log levels. If required, increase the buffer size using logging buffered 1000000 informational and ensure logging to console or monitor is enabled with terminal monitor for SSH sessions.

Additionally, if you're using a syslog server in production, make sure the logging trap informational and logging host <IP> commands are correctly set, and that a source-interface is defined. This way, all deny log messages will be visible for monitoring and troubleshooting.