06-03-2016 11:44 AM - edited 03-08-2019 06:04 AM
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
Solved! Go to Solution.
06-05-2016 05:37 PM
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
06-03-2016 12:32 PM
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
06-04-2016 12:07 AM
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
06-04-2016 10:30 AM
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
06-04-2016 08:47 PM
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
06-05-2016 05:37 PM
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
06-06-2016 09:12 AM
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
06-06-2016 10:41 AM
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
06-12-2016 12:46 AM
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
06-12-2016 02:37 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide