cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Nexus 7000 ACL logging (OAL)

36173
Views
10
Helpful
8
Comments
Robert Taylor
Cisco Employee

Introduction:

As many customers have opened TAC cases about logging access-lists on the n7k platform, I have put together this quick configuration guide and explanation to serve as a reference to eliminate some of the confusion.

Keep in mind that ACL logging in NX-OS does not look like traditional IOS acl logging.  We do not see a log message EVERY time there is an acl hit.  Instead we see hit notifications sent at specific intervals.

Optimized Access-list Logging is a feature that was introduced on the 6500 platform a while back.  The Nexus 7000 uses this same infrastructure to keep the CPU protected from ACL logging that customers may implement.

"OAL provides hardware support for ACL logging...OAL permits or drops packets in  hardware and uses an optimized routine to send information  to the RP to generate the logging messages"

- 6500 configuration guide  http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/acl.html#wp1090858

On the 6500/7600, OAL was optional, and you could still use CPU intensive acl logging if desired (on by default).

On the Nexus 7000, OAL is the only option for ACL logging.

So now lets look at the n7k specific implementation of ACL Logging, or OAL.

My setup uses the following topology:

host(10.0.0.2)---(10.0.0.1)e2/10__N7k__e2/11(11.0.0.1)---(11.0.0.2)host

Two access lists are applied to the same interface, e2/10.  TEST is applied inbound, and TEST2 is applied as outbound.

interface Ethernet2/10
  ip access-group TEST in
  ip access-group TEST2 out
  ip address 10.0.0.1/30

IP access list TEST
        10 permit ip any 11.0.0.2/32 log
        20 permit ip any any

IP access list TEST2
        10 permit ip any 10.0.0.2/32 log
        20 permit ip any any

Configuration:

By default, if you have an access-list configured with the log parameter, you will not see any logs in the buffer.  However, you will be able to see them in the OAL cache (this output comes after sending 5 pings with source 10.0.0.2 to 11.0.0.2):

RP_7k2# show log ip access-list cache
Source IP         Destination IP    S-Port  D-Port    Interface   Protocol   Hits
--------------------------------------------------------------------------------
11.0.0.2         10.0.0.2           0       0         Ethernet2/11     (1)ICMP    5
10.0.0.2         11.0.0.2           0       0         Ethernet2/10     (1)ICMP    5

Number of cache entries: 2
--------------------------------------------------------------------------------
RP_7k2#

* Note that the above output shows the "Interface" value as Ethernet2/11  for the first flow.  This is the ingress interface for that packet, not  the interface where the ACL was applied.

The cache entry persists while the flow is active, but the hit counters are cleared at a set interval (configurable).  This interval is also used to set frequency of the actual log messages that are displayed.  In other words, once the flow is created, you will receive a log message every [interval] seconds with an update showing the current hit counters for that flow (while that flow is still active in the cache).

By default, the following settings are applied, which do not have to be changed.

RP_7k2(config)# show log ip access-list status
Max flow        = 8000
Alert interval  = 300
Threshold value = 0
RP_7k2(config)#

OAL specific parameter configuration:

logging ip access-list cache {{entries num_entries} | {interval seconds} | {threshold num_packets}}

entries - sets the (Max Flow) number of cache entries;

interval - sets the interval between logging messages for each flow, and the timeout value for the flow;

threshold - sets the hit counter value at which we start logging this acl cache entry;

Default OAL values are sufficient to get the logging enabled.

Required non-default changes for logging

switch(config)# logging level acllog 3

switch(config)# acllog match-log-level 3

switch(config)# logging logfile [name] 3

As shown above, the logging level for the "acllog" facility must be configured to be greater than or equal to the "acllog match-log-level" setting, and the "logging logfile" severity must be equal to or greater than that setting as well.  Otherwise, the log messages do not show up in the logs.  I used the value of 3 by choice, but is not a required setting.

Once this is configured, you can see the logs show up as desired:

RP_7k2# show log logfile

2010 Nov 16 18:08:14 RP_7k2 %ACLLOG-3-ACLLOG_FLOW_INTERVAL: Source IP: 10.0.0.2,
Destination IP: 11.0.0.2, Source Port: 0, Destination Port: 0, Source Interface
: Ethernet2/10, protocol: "ICMP"(1),  Hit-count = 5
2010 Nov 16 18:08:17 RP_7k2 %ACLLOG-3-ACLLOG_FLOW_INTERVAL: Source IP: 11.0.0.2,
Destination IP: 10.0.0.2, Source Port: 0, Destination Port: 0, Source Interface
: Ethernet2/11, protocol: "ICMP"(1),  Hit-count = 5


RP_7k2#

As you can see, each active flow updates the log with the number of hits during the current interval, and will continue to do so while the flow is active.

And that's it!  The settings can be tweaked to match your needs, but you now have acl logging, without impacting the cpu!

8 Comments