09-22-2023 06:35 PM - edited 09-22-2023 06:39 PM
I'm experiencing a stranger behavior in the Cat9500, on which I need to apply an ACL in the SVI interface to filter traffic from multiple networks. I have created an extended ACL and applied it in both directions (outbound and inbound) on the SVI, but the traffic is allowed to pass. In the switch configuration, I see many SVIs, DHCP pool, static routes, and etc. and I'm suspect a TCAM limitation or exhaustion that is preventing the ACL from working. I haven't seen any log entries related to TCAM limitations or exhaustion. This is a stack switch (2 members), and there are other ACLs deployed and working well, but only the new ACLs are not working as expected.
This is the show platform hardware fed switch active fwd-asic resource tcam utilization output.
Has anyone ever faced this issue before?
09-22-2023 08:02 PM
can you generate some traffic matching and not matching ACL and share "show platform fed active acl counters hardware"
09-23-2023 01:24 AM
your output shows nothing wrong with TCAM
can you post the new ACL and SVI config which is not working ?
also give us more information what is the source IP and destination IP you testing ?
09-23-2023 01:31 AM
There is some limitations of acl in tcam.
Also I do t think log is work with acl in tcam.
Can I see your racl?
09-23-2023 06:27 AM
Hello,
Here is a sample of the configuration to give you a better view of the test.
interface Vlan10
description SERVER-NETWORK
ip address 10.1.1.254 255.255.255.0
ip access-group test-acl out
!
interface Vlan20
description HML-NETWORK
ip address 10.2.2.254 255.255.255.0
no ip redirects
no ip proxy-arp
!
interface Vlan30
description HML2-NETWORK
ip address 10.3.3.254 255.255.255.0
no ip redirects
no ip proxy-arp
!
ip access-list extended test-acl
10 deny ip 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255 log
20 deny ip 10.3.3.0 0.0.0.255 10.1.1.0 0.0.0.255 log
30 permit ip any any
!
end
The ACL should filter traffic from VLAN20 and VLAN30 to VLAN10, and the counters are not incrementing when I send some traffic from the source to the destination.
Cat9500#show ip access-lists
Extended IP access list test-acl
10 deny ip 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255 log (0 matches)
20 deny ip 10.3.3.0 0.0.0.255 10.1.1.0 0.0.0.255 log (0 matches)
30 permit ip any any (124 matches)
Thanks in advance
09-23-2023 06:30 AM
Remove log' as I mention before any tcam acl not support log.
Remove log and check again
09-23-2023 09:44 AM
It would be interesting to know if any of the ACLs that do work use the log parameter. I agree with @MHM Cisco World that removing the log parameter would be a very good thing to try.
09-23-2023 09:47 AM
what is the version IOS XE
also understand when you using IN and OUT Filter on the interface :
https://www.cisco.com/c/en/us/support/docs/ip/access-lists/26448-ACLsamples.html
09-23-2023 11:02 AM
It is always important to remember the differences in ACL applied IN or applied OUT. In this case it was applied OUT, so it is filtering traffic going out from the switch to connected hosts. And the subnet of the interface was the destination address. So in this case it was correct.
09-23-2023 12:34 PM - edited 09-23-2023 01:57 PM
The current IOS-XE version is 17.6.1.
For me, the outbound direction is the correct because I have multiple sources, and I want to filter traffic closer to the destination.
I will remove the "log" parameter from the ACL and test again.
Could you please explain me why "log" parameter is the issue?
I'll keep you posted.
09-23-2023 07:47 PM
Please do let us know the result of removing "log" from the acl statements. As far as the issue about "log" is concerned I do not have an authoritative answer. I can say with certainty that I have seen situations the using log in the acl did create a problem. That is the reason that I agree with MHM in suggesting that you remove it and let us know the results.
I do have a few thoughts about the log parameter:
- if the acl statement includes log then any packet that matches can not be forwarded using the optimum/hardware based forwarding logic and must be processed by the cpu (the cpu needs to create the log entry).
= most routers will accommodate the performance impact of log in the acl entry, but some switches do not. We suspect that this is one of those cases.
09-24-2023 12:54 AM
17.6.3 (i am using that works for me)
when you initiate the traffic and you see default(permit any any) hits not respected on - that could be wrong traffic so ACL is not matching,
enable debug and check.
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