cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1199
Views
4
Helpful
6
Replies

Do more number ports in ACL take more TCAM ?

Vivek Sharma
Level 1
Level 1

Hi,

 

If I use permit tcp any any eq 1 8 10 15 instead of below:

permit tcp any any eq 1

permit tcp any any eq 8

permit tcp any any eq 10

permit tcp any any eq 15

 

Will using all port numbers in the same line use more ACL TCAM ? As per my understanding, if we define a range in an ACL line, that would reserve some part of the TCAM for that range, but there is no TCAM reserved if we define a single port as in permit tcp any any eq 1.

So, will permit tcp any any eq 1 8 10 15 be also reserving a part of TCAM just like by using "range 1-4" and I should take into account the resource utilisation while using this ?

1 Accepted Solution

Accepted Solutions

Hi Vivek,

I see. Well, honestly, I do not know for sure. These issues are extremely platform-specific, and each router and switch platform supporting ACLs can implement these things differently.

One remark: I see you are running a 3945 ISR G2 router. These devices, to my best knowledge, do not have a TCAM and they do not process ACLs in dedicated hardware. ISR (x800) and ISR G2 (x900) routers are software-based, and ACL processing is performed on CPU. Specifically on these platforms, you do not need to worry about TCAM utilization - because there is no TCAM there at all.

Best regards,
Peter

View solution in original post

6 Replies 6

Peter Paluch
Cisco Employee
Cisco Employee

Hi Vivek,

Even a single port referenced in an ACL entry must be programmed into TCAM. You can not perform matching on something that was not installed into TCAM.

It appears, though, that the use of the keywords gt, lt, neq, range is more resource-intensive than a single port referenced with the eq keyword. Various documents about TCAM use in Catalyst switches mention the use of so-called L4Ops (L4 Operations) and LOUs (Logical Operator Units) that are being consumed, and it appears that these LOUs are actually an additional resource besides TCAM that is scarce and may become depleted:

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/118649-technote-lou-00.html

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-4000-series-switches/66978-tcam-cat-4500.html

Therefore, it would appear that the use of keywords gt, lt, neq, range should be kept to a minimum.

So, will permit tcp any any eq 1 8 10 15 be also reserving a part of TCAM just like by using "range 1-4" and I should take into account the resource utilisation while using this ?

This question actually cannot be answered as the "eq 1 8 10 15" does not appear to be a valid syntax. Tested on various platforms and IOS versions, all devices I have checked do not allow specifying multiple ports after the eq keyword. Were you able to use this syntax? If so, what was the platform and IOS version please?

Best regards,
Peter

Hi Peter,

 

Thanks for your reply!

But I have a device in my network which has a few ACL entries like below:

permit tcp a.b.c.d 0.0.0.31 host e.f.g.h eq 389 636

Its a CISCO3945 with version c3900e-universalk9-mz.SPA.151-4.M5

 

I also got a reference from:

http://www.davidsudjiman.info/2010/03/17/cisco-acl-cannot-have-more-than-10-ports/

 

So I want to know how resource intensive could this be.

 

Hi Vivek,

I see. Well, honestly, I do not know for sure. These issues are extremely platform-specific, and each router and switch platform supporting ACLs can implement these things differently.

One remark: I see you are running a 3945 ISR G2 router. These devices, to my best knowledge, do not have a TCAM and they do not process ACLs in dedicated hardware. ISR (x800) and ISR G2 (x900) routers are software-based, and ACL processing is performed on CPU. Specifically on these platforms, you do not need to worry about TCAM utilization - because there is no TCAM there at all.

Best regards,
Peter

Ok, that serves my purpose for now:)

Thanks a lot for your responses Peter, appreciate your help!

 

But I would still appreciate if someone could give me a more affirmative answer on whether defining ACL in this way will exhaust TCAM on devices which have TCAM for ACLs and support this syntax.

 

Thanks!

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Logically, resource utilization should be the same for the same logical function, but that depends on the implementation.  When dealing with TCAM programming, you're getting into some very deep technical issues, much of which is proprietary.

About the best you might be able to ascertain, is for platforms that show TCAM utilization, you can try formatting ACLs, differently, and see if TCAM utilization varies.  Again, I wouldn't expect it to, for the same function, but even if it did, it's unlikely Cisco will "officially" consider it an issue, as long as the functional results are correct (unless the TCAM utilization is very much different).

Usually, it's best to avoid worrying about such considerations, i.e. how to write a config to obtain an optimal TCAM implementation, as its difficult to maintain and is subject to change with a vendor change.

Thanks Joseph,

I'll try to test TCAM utilisation with different ACL formats and see if that shows considerable difference.

Review Cisco Networking products for a $25 gift card