DACL with over 100 lines

[umahar]

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 ?

[kthiruve]

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

[paul]

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.

[hariholla · Accepted solution]

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

[umahar]

Thank You all for you responses

[Brian Taylor]

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

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

[Parag Mahajan]

deleted

[einarnn]

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

[chyps]

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

[Brian Taylor]

Hi Craig,

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

Thanks,

Brian

[chyps]

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.