topic Re: DACL with over 100 lines in Network Access Control

DACL with over 100 lines

umahar — Tue, 25 Jul 2017 14:12:17 GMT

I have a customer who is creating DACLs going beyond 100 IPs.

I have never encountered such use case but just wanted to get confirmation if this is recommended or not recommended due to TCAM utilization issues.

Also what is the best recommended DACL size in 3850s with 48 port ?

Re: DACL with over 100 lines

kthiruve — Tue, 25 Jul 2017 17:15:57 GMT

Hi Utkarsh,

Not sure if this is pertaining to ISE. Please post this question in the switching community.

If you are using ISE, here is the scalability and performance community site you may need.

https://communities.cisco.com/docs/DOC-68347

and

https://communities.cisco.com/docs/DOC-63901

Thanks

Krishnan

Re: DACL with over 100 lines

paul — Tue, 25 Jul 2017 17:41:35 GMT

I haven't done TCAM limit checking on 3850s but look at this:

Troubleshoot Security ACL TCAM Exhaustion on Catalyst 3850 Switches - Cisco

The command "show platform tcam utilization asic all" looks like a promising command to tell you exactly how many ACL entries are supported. Have them run tests with big DACLs to confirm how the usage maps to that command.

Re: DACL with over 100 lines

hariholla — Tue, 25 Jul 2017 23:26:01 GMT

Hi Utkarsh,

We typically recommend using max 64 ACEs for dACLs. This is not a hard limit, but a best practice recommendation, because some platforms can do more. The collective ACE limit on the 3850 is around 3000 ACEs.

c3850-switch#show sdm prefer

Showing SDM Template Info

This is the Advanced (high scale) template.

Number of VLANs: 4094

Unicast MAC addresses: 32768

Overflow Unicast MAC addresses: 512

IGMP and Multicast groups: 8192

Overflow IGMP and Multicast groups: 512

Directly connected routes: 16384

Indirect routes: 7168

Security Access Control Entries: 3072

QoS Access Control Entries: 2816

Policy Based Routing ACEs: 1024

Netflow ACEs: 768

Wireless Input Microflow policer ACEs: 256

Wireless Output Microflow policer ACEs: 256

Flow SPAN ACEs: 512

Tunnels: 256

Control Plane Entries: 512

Input Netflow flows: 8192

Output Netflow flows: 16384

SGT/DGT entries: 4096

SGT/DGT Overflow entries: 512

These numbers are typical for L2 and IPv4 features.

Some features such as IPv6, use up double the entry size;

so only half as many entries can be created.

Hope this helps..

-Hari

Re: DACL with over 100 lines

umahar — Thu, 27 Jul 2017 18:03:46 GMT

Thank You all for you responses

Re: DACL with over 100 lines

Brian Taylor — Fri, 31 May 2019 08:20:59 GMT

Checking my switches, these seem to be the hard TCAM limits.

9400 = 18432
9300 = 5120
4500 = 4096
3850 = 3072
3560x = 924
2960 = 384

Re: DACL with over 100 lines

Parag Mahajan — Thu, 03 Sep 2020 03:35:44 GMT

deleted

Re: DACL with over 100 lines

einarnn — Thu, 23 Jan 2020 12:34:31 GMT

For future reference, please disregard the feedback on dACL size limitation:

dACLs are not delivered via accounting packets
Longer dACLs may be fragmented across multiple requests from a switch to a policy server

Cheers,

Einar

Re: DACL with over 100 lines

chyps — Thu, 13 Feb 2020 17:16:22 GMT

As often the case, there is a grain of truth in each source of information, but often that truth becomes distorted in translation!

The first point of confusion is the references to RADIUS Accounting (RFC 2866). These references are incorrect and instead should be a reference simply to RADIUS (RFC 2865). Per-User ACLs and downloadable ACLs (dACLs) do not use RADIUS Accounting, but RADIUS auth for transmitting ACL content. That said, there is still a single packet maximum of 4096 bytes for RADIUS packets, notwithstanding RFCs advocating support for larger RADIUS packets.

The second point of confusion is that there is a functional difference between Per-User ACLs and downloadable ACLs (dACLs). Per-User ACLs are sent via RADIUS auth and Access Control Entries (ACEs) are returned as individual vendor-specific attributes (VSAs) in Access-Accept messages. These are the ACL type which appear to be most commonly referenced in the Cisco documentation and communities. However, these are distinct from dACLs which are an optimization to the RADIUS authorization process.

More specifically, unlike Per-User ACLs which use a direct authorization response to a Cisco switch, for example, where the AAA server returns all of the VSAs in an authorization response (Access Accept packet), dACLs use a flow where the AAA server first sends down the name of the dACL as an authorization. The switch then makes a separate RADIUS auth request for the ACL by name. If the dACL contents have changed since a prior download (as tracked by the dACL hash extension), the current dACL contents are sent down to the RADIUS client (ex: switch). Unlike per-user ACLs that are limited to a single Access-Accept packet (max 4096 bytes), dACL contents can be returned over multiple packets, thus not limited to the same 4096-byte size restrictions as Per-User ACLs.

Hope that clarifies the sources of prior responses, each holding a bit of fact, but easily confused without understanding terminology and specific use cases.

Craig

Re: DACL with over 100 lines

Brian Taylor — Fri, 14 Feb 2020 01:29:16 GMT

Hi Craig,

Can you screenshot the per-user and dACL to clarify where each is configured?

Thanks,

Brian

Re: DACL with over 100 lines

chyps — Fri, 14 Feb 2020 02:41:43 GMT

Brian, Before creating new sample entries in ISE from scratch, I did a quick search and found a site that posted decent ISE configuration examples of a dACL, Per-User ACL, as well as the IETF standard ACL (Filter-Id): Delivering ACLs for MAB/DOT1x Authentication

Per-User ACLs are rarely used. There was a time you could leverage them in multi-match policy rule set to allow ACL entries from multiple policy rules to be concatenated into a single ACL by matching individual rules. This rule logic was removed in earlier ISE 2.x releases so not seen too often. I recall ASA Remote Access VPN also supporting such logic with Dynamic Access Policy (DAP). In any case, they are nice in that they allow central configuration, but you rarely see them deployed in production due to the availability of dACLs which can scale larger, detect ACE modifications, and simpler to configure. The ISE interface allows contents to be copied and pasted from another source as text rather than entered as singular AV-pair entries in Advanced Settings, and ISE dACLs include a syntax checker.

Filter-ID is still used, but primarily with 3rd-party equipment that lack dACL support. A major downside of the IETF Filter-Id option is that the ACL must be pre-configured on each access device before it can be referenced in an authorization response.

Hope this helps.