Limit in ACL on Cisco 6807

[Sonflaa]

Hello!

I have a Cisco C6807-XL running s6t64-adventerprisek9-mz.SPA.155-1.SY7.bin.
On this I have a standard ACL with a lot of denies on various malicious hosts.

This is the end of the ACL:

1414 deny 185.220.100.254

1415 deny 62.233.41.1

10000 permit any (56107 matches)

If I add the following:

1416 deny 109.234.164.207

1417 deny 122.201.124.75

1418 deny 81.88.53.111

1419 deny 72.167.85.170

1420 deny 195.201.194.248

1421 deny 109.234.165.69

1422 deny 38.76.31.13

They don't appear. I have tried to resequense and writing to memory, but still no dice. This worked perfectly until I hit the seq number 1415 (it goes from seq number 1).

The strange this is that if I add a subnet, it appears in the ACL.

Another strange thing is that I tried to set up a new ACL with the same addresses, and that one stops at sequence number 1345. I have also tried to delete the entire ACL and set it up again, but the same thing happens.

This one stops at 1415 if I add hosts, but I can add more subnets.

 

This one stops at 1345, but I can add more subnets

Here I added a subnet, and that stays:

I guess I will need to open a Cisco TAC ticket, but any help from you guys would be much appreciated.

Please tell me if I should provide any more information.

[Joseph W. Doherty]

Did you checked syslog and console for any messages?

Have you tried:

deny host #.#.#.#

Or

deny #.#.#.# 0.0.0.0

?

Have you tried dropping ACL and rebuilding it w/o sequence numbers?

[Sonflaa]

I tried both of these also, but still the same issue. No messages in syslog regarding TCAM or ACL at all.

[MHM Cisco World]

These ACL add to TCAM, I am not sure know but try DRY RUN to check TCAM can support these ACL or not 

MHM

[Joseph W. Doherty]

Ah, a feature of which I was unaware, i.e. https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-0SY/configuration/guide/15_0_sy_swcg/ios_acl_support.html#96752

TCAM exhaustion occurred to me too, which is why I suggested checking syslog and console for messages.  In the past I've seen issues where no message is sent to a VTY session, but is to the syslog and/or console.