Switch ACL vs dACL

[patterson_p]

I am trying to rollout device profiling through ISE 2.4 for our enterprise small branch offices. In the past we have been using extended ACLs on the switch SVI to manage access. The introduction of ISE profiling seems appealing, but I am unsure about using one versus the other in terms of benefit. 

Can someone tell me the benefit of using the old switch ACL per SVI vs applying a dACL per port via ISE?

How do the two compare in terms of switch resources? 

Is there a best practice? 

Thanks for the help!

Paul

[Francesco Molino · Accepted solution]

Hi

Dacl will be better for security purposes because you'll limit a traffic on a per port basis depending on the authorization result while svi acl will be a common acl for all hosts within this vlan.
When using dacl, it doesn't "really" matter on which vlan your user is assigned to but what matters is which communication is he allowed to do.

It terms of best practices, we usually recommend a maximum of 64 ACEs per dACL.
You can build some ACLs with more ACEs if you want. What you need to take into consideration is your TCAM limit depending on switch devices you have. This limit is different per platform and the information can be found on the switch (sh platform tcam utilization asic all) or on the datasheet.

[Cristian Matei]

Hi,

     1. In general it's better to stop everything closer to the source, right? So PACL/dACL wins over SVI/routed ACL.

     2. At some point routed ACL may not scale, while a PACL/dACL will scale better (it depends on how many ACE entries you'll be having in the end).

     3. Just moving away from the old/traditional way of doing things, the routed ACL, gives you opportunity, in future or even now (assuming you have the right HW), and fully embrace Trustec, with SGT. What i'm trying to say is move on, don't be dragged behind, sooner or later it's gonna hit you.

    4. Not sure if dACL or RACL consumes more resources on the NAD, but never had issues with dACL and switch performance (TCAM level). 

    5. Something else to consider; a layer 2 filter (dACL/PACL/VACL) does not generate an ICMP message back, it's a silent drop. While a layer 3 filter, like on the SVI, you will have to make the switch generate ICMP messages, which these are processed switched. You would say, no problem, i disable ICMP unreachable to save the CPU. What if you fail to do that, or you hit a bug?

Regards,

Cristian Matei.

Regards,

Cristian Matei.

[patterson_p]

I definitely agree that closer to the source is always better. Rest assured, I definitely prefer to move in the direction of dACLs as opposed to RACLs...there's no disagreement there. I guess my thought was that the NAD would have to process every ACE line for every switchport if using dACLs which would use up more resources. (FYI...we are talking about 80 ACEs in this particular ACL) This would be a major concern of mine being that we are still using 2960s in our environment. 

[Mike.Cifelli]

Totally agree with both @Francesco Molino and @Cristian Matei .  To add a few additional benefits:

-Utilizing dacls and pushing via ISE policy allows you to centrally manage everything.  This saves you time instead of potentially having to update multiple SVI acls.

-Provides the luxury of being able to drive policy based on specific endpoint or client and NOT entire subnet.

-Provides mobility in regard to clients moving switchports and/or to different switches

-Newer network solutions rely more on dacl/sgacl with potentially implemented CTS