Cat9500 RACL is not filtering traffic

[maverick0]

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?

[ammahend]

can you generate some traffic matching and not matching ACL and share "show platform fed active acl counters hardware"

[balaji.bandi]

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 ?

[MHM Cisco World]

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?

[maverick0]

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

[MHM Cisco World]

Remove log' as I mention before any tcam acl not support log.

Remove log and check again 

[Richard Burts]

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.

[balaji.bandi]

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

[Richard Burts]

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.

[maverick0]

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. 

[Richard Burts]

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.

[balaji.bandi]

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.