ACL logging on Cisco 3850 - ACL matches working but not showing (uness LOG is used)

[SJ K]

Hi guys,

I have a 2x3850 stacked switch.

                                             H/W   Current
Switch#   Role    Mac Address     Priority Version  State
------------------------------------------------------------
*1       Active   9c57.ad5f.2480     10     V06     Ready
 2       Standby  9c57.ad86.2400     1      V06     Ready

I have created an ACL and applied it on the IN routed port.

show ip int gi1/0/3 

....

Inbound  access list is INBOUNDACL

show ip int gi2/0/3

....

 Inbound  access list is INBOUNDACL

show ip access-lists INBOUNDACL

10 permit ICMP host 192.168.6.10 host 192.168.0.50

20 permit eigrp any any

30 deny ip any any log

Pings from 192.168.6.10  are going IN through the gi1/0/3 or gi2/0/3 interface before it can reach 192.168.0.50

T1) From 192.168.6.10, I execute repeated ping to 192.168.0.50 , ping goes through
T2) show ip access-lists INBOUNDACL , don't see any matches for entry 10

T3)  Change entry 10 to

10 deny ICMP host 192.168.6.10 host 192.168.0.50

T4) ping from 192.168.6.10 to 192.168.0.50 failed

T5) show ip access-lists INBOUNDACL, don't see any matches for entry 10 !

T6) add a "log" to entry 10 , show ip access-lists INBOUNDACL - matches start showing.

T7) change entry 10 friom deny to permit -> "10 permit ICMP host 192.168.6.10 host 192.168.0.50 log", ping start flowing through again

T8) show ip access-list INBOUNDACL, matches start showing too.

q1) Why do we need a "log"  to have the matches showing ?!

Is this behaviour normal ?!

q2) just want to be sure, for return traffic

e.g. 192.168.0.50 ping 192.168.6.10 and  192.168.6.10 return icmp reply to 192.168.0.50,  is it consider a match ?

Regards,

Noob

[Richard Burts]

Noob

I believe that what you are seeing is one of the effects of using a layer 3 switch to do routing. In the traditional router all of the routing and processing of access lists was done in software. And when there was a match to an ACE the software could count it up and report how many hits in the access list. But with newer devices such as the layer 3 switches much of the processing is now done in hardware. The IP forwarding logic works in hardware and the logic of enforcing the access list is done in hardware. So the policy established in the access list is enforced. But the hardware does not report back how many matches occurred in the access list.

The reason that you do see the results in the access list when you add the log parameter is that when it must log the result it processes that in software and now the software sees the match and can count and display the result. 

HTH

Rick

[SJ K]

Hi Rick,

Thanks for the wonderful reply.

It was my initial thought as well.  (since I ever read about having the "log" on ACE will disable CEF switching).

But I didn't realize that it will not show the matches even I did not have the "log" keyword.

Actually, I am abit skeptical about the meaning of "hardware"  processing - I mean hardware are just physical electronic/magnetic circuits/devices, surely there are some "software/firmware" that drives the logic processing , isn't it ?  That being said, why can't the "software/firmware"  on the hardware handle the count as well ?  (or it probably just speed, the less coding, the faster it can go).

Regards,
Noob

[Richard Burts]

Noob

There certainly is some software/firmware involved. And the hardware is not just electronic/magnetic circuits. These switches have ASICs which are programable. There probably is some aspect of the less coding the faster they go, but I believe that there is another aspect to consider. Part of what they are doing is to push the processing logic to the ASIC and to minimize communication and dependencies between the central CPU and the ASIC. If the ASIC maintained the counter then it would have to communicate the counter increments and coordinate with the central CPU. I think that minimizing communication between the ASIC and the CPU is the main thing.

HTH

Rick

[SJ K]

Hi Rick,

Perfect explanation !

But there's still one point which I don't get it -> why does the ASIC need to communicate/coordinate with the central CPU, if they/themselves are the ones that maintain the counters ?    (wild guess* -> CPU needs to read the counters from them to display to us ; and thus the communication ?)

Regards,
Noob

[Richard Burts · Accepted solution]

Noob

Your guess is pretty much on the mark. If you think about it your command to show access-list is processed by the main CPU. And the output for that command contains only things that the main CPU knows about. So for you to get accurate counters the ASIC would have to send a message to the CPU and wait for an acknowledgement every time it processed a match to an ACE.

I did find an interesting explanation in one of the Cisco documents:

When you enter the show ip access-lists privileged EXEC command, the match count displayed does not account for packets that are access controlled in hardware. Use the show platform acl counters hardware privileged EXEC command to obtain some basic hardware ACL statistics for switched and routed packets.

for additional details see this link:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/3se/security/configuration_guide/b_sec_3se_3850_cg/b_sec_3se_3850_cg_chapter_01010.html#ID1459

HTH

Rick

[SJ K]

Hi Rick,

Wonderful ! The link perfectly proves your guess in the earlier of the thread (kudos to you !)  and answer the behavior on my switch.

However, raising a ticket to Cisco support earlier in the day -> their 3850 switch is showing ACL matches.  ( I will be doing a webex with them tomorrow) -> will keep you updated on why the discrepancy.

Regards,
Noob

[Richard Burts]

Noob

It is very interesting that their 3850 does show ACL matches. Here are a couple of thoughts about this:

- are they getting ACL matches for every packet through the switch or just on some packets (which I believe that you got matches on some - but not all packets.

- are they running the same version of code that you are? Sometimes behaviors change in different releases.

- is there something in their environment that is sending more packets to the central CPU for processing?

Please do keep us posted on what you learn from them about this behavior.

HTH

Rick

[SJ K]

Hi Richard,

Just want to keep you updated, i have done a webex with cisco, they have confirm the issue on my switch and is suspecting it is due to hardware switch packets.

They are pending further hardware check and i will update you again here ;)

Regards,

Noob

[Richard Burts]

Noob

Thank you for the update. It is good that they confirm the issue on your switch. Please do let us know as they provide any explanation for what is happening.

HTH

Rick