dACLs and TCAM ressources

lap · ‎02-12-2013

Hi all,

We are going to implement dACLs through ISE. This dACLs will have arround 400 ACEs for each user.

The Cisco switch platform will be the following:

4510
4507
3750
2960S

These platforms are already running EEE 802.1x authentication and have SVI ACLs configured. So we want to move from SVI ACLs to dACLs instead.

I would really appreciate if someone could provide me information regarding the following:

1) Are all these platforms supporting dACLs?

2) Regarding the TCAM ressource for each platform, would they be any issue regarding dACLs with arround 400 ACEs per user?

3) What minimum IOS is required for running dACLs?

4) Is there any compatibility issue between dACLs and IEEE 802.1x authentication?

5) Is there any advice regarding this kind of implementation?

Thanks a lot in advance.

Regards,

Laurent

nspasov · ‎02-14-2013

Hello Laurent:

1) Are all these platforms supporting dACLs?

Yes, but you should consult the compatibility guide:

http://www.cisco.com/en/US/docs/security/ise/1.1.1/compatibility/ise_sdt.html

2) Regarding the TCAM resource for each platform, would they be any issue regarding dACLs with arround 400 ACEs per user?

That would depend. How many users do you have? Each platform will be limited but I don't have the actual numbers in front of me. I will have to research each platform individually. Also, I think that sometimes (based on the platform) the actual number can vary based on the version of IOS. Also, isn't there a way for you to consolidate those 400 ACEs into more generic statements? 400 just seems a lot

3) What minimum IOS is required for running dACLs?

You can find this informaiton in the compatibility guide as well

4) Is there any compatibility issue between dACLs and IEEE 802.1x authentication?

As long as it is supported by the platform you should be OK. One thing to remember is that the dACLs on ISE/ACS are not "proof-checked" by the system so you must enter them correctly. If you have a syntax error the switch will simply reject the ACL

5) Is there any advice regarding this kind of implementation?

I would recommend again to either reduce the ACEs or look into assigning specific users to a specific VLAN with the vlan-override function. That way you would have one ACL applied to an SVI instead of the same ACL applied multiple times to different switch ports.

Hope this helps!

Thank you for rating!

lap · ‎02-15-2013

Hi Neno,

Thank you very much for your reply.

We have done the following test on a Cisco 2960s and it is quite amazing for a small platform like that:

What we did is that we created 5 different ACLs with around 250 lines in each. Then we applied each ACL inbound on different ports.

Before applying each ACL to the different ports the TCAM resource was as following:

#######################################################################

TESTLAB_#sh platform tcam utilization asic all

CAM Utilization for ASIC# 0 Max Used

Masks/Values Masks/values

IPv4 security aces: 384/384 36/36

#########################################################################

After applying one ACL on the first port:

###########################################################################

TESTLAB#sh platform tcam utilization asic all

CAM Utilization for ASIC# 0 Max Used

Masks/Values Masks/values

IPv4 security aces: 384/384 272/272

#########################################################################

When adding another ACL to another port, the TCAM ressource for IPv4 security aces just incremented from 272 to 273. So it looks like that the TCAM programming algorithm on this platform is nicely optimized.

It looks like the TCAM of the Cisco 2960s can support a large amount of ACL with many entries. Also we saw that this platform has 2 ASIC, ASIC# 0 and ASIC# 1:

#########################################################################

TESTLAB#sh platform tcam utilization asic all

CAM Utilization for ASIC# 0 Max Used

Masks/Values Masks/values

IPv4 security aces: 384/384 272/272

CAM Utilization for ASIC# 1 Max Used

Masks/Values Masks/values

IPv4 security aces: 384/384 36/36

#########################################################################

So it looks good and it would be nice to know the difference in the TCAM programmering between a Cisco 2960s and a 4510 for example.

Regards,

Laurent

alexey701 · ‎12-11-2013

Hi guys,

Did you face any issues fith tcam utilization in case of stacked switches?

We started to implement dacls in 2960-S stacks of 3 or 4 members. And we started to get complaints from our customer about performance degradation from time to time.

I suspect that in case if tcam becomes overloaded with acls it fallback to process switching. Moreover, for all stack members only master's control plane is used. So it becomes realyy intensive for one cpu to process traffic from 4x48 ports.

What do you think?

Thanks,

Alex

lap · ‎12-12-2013

Hi Alex,

I have never tested dACLs in production in a stack environment. What is the result of sh platform tcam utilization asic all?

Regards,

Laurent

alexey701 · ‎12-12-2013

Hi Laurent,

the ouput is already here:

sh platform tcam utilization asic all

CAM Utilization for ASIC# 0 Max Used

Masks/Values Masks/values

Unicast mac addresses: 8412/8412 7576/7576

IPv4 IGMP groups + multicast routes: 384/384 1/1

IPv4 unicast directly-connected routes: 320/320 7/7

IPv4 unicast indirectly-connected routes: 0/0 7/7

IPv6 Multicast groups: 320/320 11/11

IPv6 unicast directly-connected routes: 256/256 1/1

IPv6 unicast indirectly-connected routes: 0/0 1/1

IPv4 policy based routing aces: 32/32 12/12

IPv4 qos aces: 384/384 41/41

IPv4 security aces: 384/384 133/133

IPv6 policy based routing aces: 16/16 8/8

IPv6 qos aces: 60/60 31/31

IPv6 security aces: 128/128 9/9

Note: Allocation of TCAM entries per feature uses

a complex algorithm. The above information is meant

to provide an abstract view of the current TCAM utilization

CAM Utilization for ASIC# 1 Max Used

Masks/Values Masks/values

Unicast mac addresses: 8412/8412 7576/7576

IPv4 IGMP groups + multicast routes: 384/384 1/1

IPv4 unicast directly-connected routes: 320/320 7/7

IPv4 unicast indirectly-connected routes: 0/0 7/7

IPv6 Multicast groups: 320/320 11/11

IPv6 unicast directly-connected routes: 256/256 1/1

IPv6 unicast indirectly-connected routes: 0/0 1/1

IPv4 policy based routing aces: 32/32 0/0

IPv4 qos aces: 384/384 41/41

IPv4 security aces: 384/384 120/120

IPv6 policy based routing aces: 16/16 0/0

IPv6 qos aces: 60/60 31/31

IPv6 security aces: 128/128 9/9

Note: Allocation of TCAM entries per feature uses

a complex algorithm. The above information is meant

to provide an abstract view of the current TCAM utilization

We see, that there is no problem with ipv4 aces utlilization, because the config wath signifacantly optimized after the compliants. Sorry but I've no the exact show output from the moment of the performance degradation.

But nevertheless, I cant understand, this output shows only the stack master's asics utilization? what about the other stack members tcam? Are they realy used in stack setup or only masters asics are used?

Joe Doran · ‎12-13-2013

So you want to deploy a dACL 400 lines long?