Asr1000 Tcam Document

White Paper
CISCO CONFIDENTIAL
ASR 1000 Packet Classification and TCAM
Introduction:
Features like QoS, PBR etc., enable user to provide better services to
certain flows. Similarly security features like ACL enables user to prevent
unauthorized flows from accessing services on the router. To provide
these services, the flow must first be identified. This procedure is known
as classification. The classification of a flow is usually done by matching
packet fields like match on source and/or destination ip addresses, L4 port
num, IP TOS bits etc. Classification can be implemented using memory
(like DRAM) but reading from RAM is very slow in datapath and can not
keep up with high rate of traffic. ASR1000 uses high speed TCAM4
device for this purpose.
Ternary Content Addressable Memory (TCAM):

TCAM device is used for high speed look-ups in networking applications.
This device supports read, write and search operations. Search will be
done in parallel on all TCAM entries and returns the first hit in the list.
Because of this the time taken to complete a lookup is the same for any
ACL or QoS policy irrespective of its size .
Unlike in RAM (bit can have 0 or 1), there are three states for every bit of
data in TCAM. These are 0, 1 and don't care. To implement this, TCAM
uses two memory cells per bit.
• Data cell - Stores the actual value of the data.

• Mask cell - Used to create the don't care state (match either '0' or
'1'). If mask cell is set to 0 then the corresponding data bit will be
ignored (don’t care) during lookup.
Early generations of TCAM use block-ternary. In this TCAM multiple

data words share the common mask word (ex: TCAM2 uses 8:1 data
words to mask word ratio). That means the mask used for one data word
will be applicable for all data words in that block.
ASR1000 uses 4th generation of TCAM. In TCAM4 there is a 1:1 data

words to mask word ratio. Each word will have its own mask. TCAM4's
entry width and size is also bigger than previous generations TCAM.
© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Confidential Information. Page 1 of 24
White Paper
CISCO CONFIDENTIAL
TCAM4:
• Fourth generation specification.
• Full-ternary addressable memory (1:1 ratio between data word &
mask word).
• Dynamically configurable widths of 80, 160 & 320 bit Keys
• Supports for 250M lookups per seconds on 80 & 160 bit Keys and
125M lookups per second for 320 bit keys.
• Available densities 5Mb, 10Mb, 20Mb and 40Mb.
ASR1000 TCAM configurations:

ESP10:
 There is only one TCAM and its size is 10Mb.
 These can be configured as
80 bit cells - 128K or
Mix of any of the above sizes
ESP20:
 There are two TCAMs of size 20Mb each.
 These can be configured as
320 bit cells - 128K. or
Mix of any of the above sizes.
 ASR1000 currently uses only 160 bit & 320 bit cells (does not
use 80 bit cell entries).
 TCAM is divided into cell blocks. Each cell block contains 4K
80bit cells. TCAM cells will be allocated one cell block at a
time to 160bit or 320bit regions based on demand .
 There is no pre-reservation/allocation of cells to any of these
regions. So, entire TCAM can be used for 160 bit keys or
320bit keys or mix of both.
 ESP20 power limitation: Due to hw power limitation only
160K (80 bit) cells are allowed in single lookup on each of the
two TCAMs. That means no single policy can be bigger than
320K (80bit) cells on set of two TCAMs. Note: All 512K
(80bit) cells of these TCAMs can be used through multiple
policies.
White Paper
CISCO CONFIDENTIAL
System flow:
Policy/ACL attach:
Control plane:
When user attaches an ACL or QOS policy (or any other policy) to
an interface, classification code does the following.
i. Looks at all fields in the policy and select appropriate key

(160 bit or 320 bit key). Most of the ipv4 policies/ACL fit
into one of the 160 bit keys. Some IPV6 ACL/policies and
policies with match packet length may use 320 bit keys.
ii. Allocates a unique 16 bit label for this policy/ACL. If this

policy/ACL is already attached to some other interface(s) in
the same direction (in or out) then assigns the same label so
that all these interfaces share the same TCAM entries.
(Note: TCAM can support up to 64 K different labels).
iii. Most of the policy/ACL fields will be programmed as is in

the TCAM except range fields like src/dest port ranges,
vlan ranges, packet length ranges etc. ASR converts range
into a single value by using ARL (ACL Range Lookup)
registers table. There is limited number of ARL registers
(128) in ASR. If ASR can not fit the given range of any
ACE into the ARL table then it expands that ACE into
multiple entries. Details of this operation are given in ARL
section.
iv. Optimize and merge the above entries. Classification code

uses different optimization algorithms for different features
based on its requirements. After this step, there may or may
not be one to one mapping between user configured policy
entries and TCAM entries.
Ex: Some examples
 One to many: One user policy entry (or rule) may

be converted into multiple TCAM entries (ex: range
expansion)
 Many to one: Multiple policy entries (or rule) may

be collapsed into one TCAM entry (ex: using
address prefixes)
White Paper
CISCO CONFIDENTIAL
 No TCAM entry: Some policy entries (or rules)

may not be programmed into TCAM (ex: if the first
policy entry shadows the second one)
v. Once the final list is ready then it creates VMR (value,

mask & result) for each entry in the list and program
TCAM using these VMRs. Only value & mask goes into
TCAM. Result will be stored in to TCAM entry’s
corresponding fast memory.
vi. Stores the label & lookup key info into datapath structures.
DataPath:
If a policy or ACL is applied on an interface then for each packet coming
on that interface, datapath prepares TCAM lookup key using info in the
packet, label and then sends it to TCAM. If there is any match then TCAM
returns the corresponding result of that entry. Datapath takes necessary
action based on the result.
If there are multiple classification features attached to an interface (like

ACL & QOS) then there will be separate TCAM lookup for each feature.
Modifying an Attached ACL or policy:

Currently ASR uses make before break approach to modify an
ACL/Policy to avoid any security holes during modification. In this
process ASR first loads the entire modified ACL (or policy) into TCAM
using new label and informs the datapath to use new label in the lookup.
Then it removes the old ACL (or policy) from TCAM. Because of this
approach there should be always some free space in TCAM. This free
space should be equal to or greater than the biggest ACL or policy
configured in the TCAM.
EX:
Suppose user attaches 10 ACLs to 10 different interfaces. The smallest
ACL occupies 100 (160 bit) TCAM entries and the largest ACL occupies
200 (160 bit) TCAM entries. In this scenario there should be > 200 (160
bit) free TCAM entries to allow edit operation on largest ACL.
White Paper
CISCO CONFIDENTIAL
ACL Range Lookup (ARL) Table:

There are 128 registers in the ARL table on ESP10 & ESP20. Currently
this table is partitioned into multiple sub tables for different field ranges
like src port, dest port, vlan, packet len etc. Table size is not the same for
all these sub tables. Ex. Dest port table has more registers than pkt len
table.
These are global tables. All ACLs/Policies configured on the router share
these tables. If two or more ACEs of different (or the same) ACLs uses the
same range then all these ACEs shares the same entries in the ARL table.
Each range takes one or two entries in the table. If the range is like < 50
then it takes one ARL entry because there is always a zero range entry in
the ARL table for lower limit. If the range has min & max values like min
20 max 100, then it takes 2 table entries.
Note: Single value like “eq 240” or range 240 240, does not use ARL
table. This value will be used as is in the TCAM entry.
ASR1000 first try to use ARL table entry for the ranges. For most of the
configurations, ranges fit into these tables. If it can not fit the range in
ARL table then it expands that ACE (or policy math rule) into multiple
entries. In this case single ACL ACE (or policy rule) uses multiple TCAM
entries. The number of these entries depends on the given range.
Example: For the following ACL
> ip access-list range-test2

> 10 permit udp 10.0.0.0 0.255.255.255 range 25 50 any
Case 1: If the “range 25 50” fits in the src port ARL table then there will
be only one entry in TCAM. This entry will be like (only fields required
for this discussion are shown here)
Src_addr addr-mask arl-id arl-id-mask src-port port-mask dest_addr mask

0a000000 ff000000 4 0x6 0 0 0 0
Note: mask ‘0’ means don’t care. Here, ARL id is used for the port range
not the port number itself. So src-port field in the TCAM entry will be
disabled by setting its mask to 0.
White Paper
CISCO CONFIDENTIAL
Case 2: If the range 25 50 does not fit in the src port ARL table then this
ACE will be expanded into 6 TCAM entries (not 25 entries) using source
port prefix mask . These TCAM entry contents will be like.
Src_addr addr-mask arl-id arl-id-mask src-port port-mask dest_addr mask

0a000000 ff000000 0 0 0x32 0xffff 0 0
0a000000 ff000000 0 0 0x30 0xfffe 0 0
0a000000 ff000000 0 0 0x20 0xfff0 0 0
0a000000 ff000000 0 0 0x19 0xffff 0 0
0a000000 ff000000 0 0 0x1a 0xfffe 0 0
0a000000 ff000000 0 0 0x1c 0xfffc 0 0
Note: Here ARL ids are not used. So arl-id field is disabled by setting its
mask to 0.
Ranges fail to fit into ARL table because of two reasons:

For most of the user configurations, ARL table is big enough to
accommodate user ranges. If config have several different ranges then
some ranges may fail to fit into the ARL table. The reasons are
1) Ran out of entries in the table (ARL table is full).

2) Sometimes new range can not be inserted into ARL table even though
there is free space in the table. This happens when user configures a
new range which falls in between the existing ranges in the ARL table.
There may not be any free space to insert new range. So the order in
which ACLs/policies are applied on the router makes difference.
Suggestion:
• If possible configure policies with most used ranges first.
• If user has prior knowledge of ranges used in their
policies/ACLs then they can create a small temporary policy
with most used ranges and apply this first to a dummy interface
(interface which is not used). ARL code receives all these
ranges at once. Code gets a chance to arrange these ranges in
optimal order into ARL table. Configuration which applied
later will share these entries. Users can keep or remove this
temporary policy after they loaded their production config.
White Paper
CISCO CONFIDENTIAL
Show commands:
The commands provided in this section are unpublished and intended
for internal use only. The syntax and output format may change from
release to release without notification.
.
1) Command to display TCAM usage:
Command: sh platform hardware qfp active tcam resource-manager
Example: on ESP10
MPC-1#sh platform hardware qfp active tcam resource-

manager usage
QFP TCAM Usage Information
80 Bit Region Information

--------------------------
Name : Leaf Region #0
Number of cells per entry : 1
Current 80 bit entries used : 0
Current used cell entries : 0
Current free cell entries : 0

--------------------------
Current 160 bits entries used : 20806

--------------------------
Current 320 bits entries used : 0
Total TCAM Cell Usage Information

----------------------------------
Name : TCAM #0 on CPP #0
Total number of regions : 3
Total tcam used cell entries : 41612
Total tcam free cell entries : 89460
Threshold status : below critical limit
White Paper
CISCO CONFIDENTIAL
2) Command to display ARL table:
Command:
sh platform hardware qfp active classification feature-manager arl
Example: on ESP10
MPC-1#sh platform hardware qfp active classification feature-manager

arl
QFP Classification ARL
Reg Number Table Id Range Type Compare Value Interval

----------------------------------------------------------
0 3 PKT LEN 0 0
1 3 PKT LEN 0 0
2 3 PKT LEN 0 0
3 3 PKT LEN 0 0
4 3 PKT LEN 0 0
5 3 PKT LEN 0 0
6 3 PKT LEN 0 0
7 3 PKT LEN 0 0
8 0 SRC PORT 0 0
9 0 SRC PORT 2048 4
10 0 SRC PORT 3050 6
11 0 SRC PORT 49152 7
12 0 SRC PORT 49152 7
13 0 SRC PORT 49152 7
14 0 SRC PORT 49152 7
15 0 SRC PORT 49152 7
16 1 DEST PORT 0 0
17 1 DEST PORT 20 128
18 1 DEST PORT 23 192
19 1 DEST PORT 24 224
20 1 DEST PORT 1024 256
--More—
3) Command to display TCAM entries of an ACL/ policy attached

to an interface
NOTE: This command is a limited or no use to the customer. Most

of the output of this command is cryptic and useful only to Cisco
engineers.
This is a two step command. First get the class-group id of policy or

ACL.
Step 1:
White Paper
CISCO CONFIDENTIAL
For ACL:
MCP-1# sh platform software access-list F0 summary | inc range-test2
range-test2 17 1 1
Here 17 (0x11) is the class-group id of ACL range-test2
For Qos Policy:

MPC-1#sh cce cp id | beg MF-Classifier
MF-Classifier
class-group 0078EFD0 337AC32C N
Here 0x78EFD0 is class-group id for policy MF-Classifier.
Step 2:
Command: sh plat hard qfp act cla fea cla tcam [acl | cce]
<cg_id> interface <name> [input output] [brief | detail]
MPC-1#sh platform hardware qfp act classification feature-manager

class-group tcam acl 17 in GigabitEthernet0/3/3 input brief
QFP classification class group TCAM
class-group[acl-cg:17] (classes:1,total number of vmrs: 1)

key name: 160_01 value size: 160 result size: 16
region id: 1 vmr id: 4 number of vmrs: 1
Note:
number of vmrs: TCAM entries used by this ACL.
Value size: Tells 160bit cell or 320 bit cell.
White Paper
CISCO CONFIDENTIAL
TECH NOTE: The Deny-Jump TCAM Exhaustion Issue
Abstract
This tech note details the problem of Ternary Content Addressable Memory (TCAM) entry
explosion for traffic classification based on Access Control Lists (ACLs) containing
“DENY” criteria.
The most common algorithm for ACL based traffic classification in TCAM (known as
Platform Independent Ordered merge (POD)) uses recursion to deal with DENY criteria
and does not scale even for a modest number of classes and/or DENY criteria. Due to its
recursive nature, the required number of entries can easily exceed the capacity of TCAM
devices.
Introduction
Understanding the concept of deny-jump action is crucial for the understanding of the
problem of TCAM expansion and exhaustion
Traffic classification is one of the most basic functionalities found in routers and switches,
with more and more applications and features requiring the infrastructure devices to
provide these differentiated services for different users based on their quality
requirements, or features based on their classification requirements. Therefore, routers
need to have the capability to distinguish and classify traffic based on the matching
criteria provided. Traffic classification needs to meet some requirements for success,
such as speed, flexibility and scalability. The traffic classification process should be very
fast so that the throughput of router/switch should not be greatly degraded. The
implementation should be flexible enough to allow users to configure various matching
criteria to meet the demands from various applications. TCAM (Ternary content-
addressable-memory) has been widely used in high-speed router/switch because of its
high performance and deterministic lookup time. However, the number of TCAM entries
is limited.
On Cisco platforms, several features such as QoS, Policy-Based Routing, IPsec, Firewall,
etc. support classification based on Access Control Lists (ACLs), often allowing the
definition of different classes of traffic based on different ACLs. For the ASR1000 these
features make use of TCAM for these ACL classifications, unlike software platforms like
the ISR’s and 7200’s.
ACLs are basically lists of Access Control Entries (ACEs), each of which define network
matching criteria (e.g. L3 source and/or destination addresses, etc.) as well as a grant
attribute (PERMIT or DENY). Originally designed for traffic filtering purposes, ACLs
White Paper
CISCO CONFIDENTIAL
were later also used for traffic classification. The semantics of the grant attribute varies
depending on how the ACL is actually used.
When ACLs are used for filtering purposes, a match on a PERMIT entry means that the
packet is granted permission to be processed while a match on a DENY entry that the
packet must be dropped. However, when ACLs are used for classification, a match on a
PERMIT entry simply means that the packet belongs to the traffic class, while a match on
a DENY entry simply means that the packet does not belong to that class; the packet is
not dropped, and classification “jumps” to check the packet against the next class, if there
is one. This is an extremely important concept, as this deny-jump concept only exists
where there are multiple sequences in one classification policy. Some examples being a
QoS policy with multiple classes, each of which have a “mix” of deny and permit
statements where the deny is not the implicit deny. Likewise an IPSec crypto-map policy,
or a policy-routing policy with multiple sequences will use the same deny-jump concept.
The following example illustrates a hypothetical networking feature that defines classes
of traffic based on ACLs. We first define the ACLs themselves:
acl A
permit a1
deny a2
permit a3
acl B
permit b1
deny b2
permit b3
acl C
permit c1
deny c2
permit c3
And then a feature policy based on the ACLs:

feature-policy P
acl A
action-1
acl B
action-2
acl C
action-3
Logically speaking, packets are compared against the ACLs sequentially, starting with
the first ACE in the first ACL, moving down until a matching PERMIT ACE is found.
When matching DENY entries are found, classification simply jumps to the following
class. In the example above, suppose a packet that matches criteria ‘a2’, ‘a3’ and ‘b1’.
The packets are first evaluated against ACL A. Because it matches entry “DENY a2”,
classification jumps to ACL B, and it is never compared to entry “PERMIT a3”. This
process is commonly referred to as deny-jump.
White Paper
CISCO CONFIDENTIAL
On ACL B, the packet does match entry ‘PERMIT b1’ so it is deemed as belonging to
ACL B, which causes action-2 to be executed.
Many features support the concepts of default action, which is the action to be executed if
the packet does not match any of the defined ACLs.
Notice: we are using here ACL related terminology (ACLs, ACEs, PERMIT / DENY
attribute) for convenience purposes. On Cisco platforms, different features use different
ways to define the behaviors described above. For example, Cisco Common
Classification Policy Language (C3PL) based features, in addition to ACL based
classification, also support deny-jump behavior on class-maps through the ‘match not
<criteria>’ command; Policy Based Routing (PBR) supports similar behavior through the
‘deny’ keyword on entire route-maps, and so on.
Problem Definition / Current Cisco Implementation
High-speed switches and routers commonly use Ternary Content-Addressable Memory

(TCAM) for traffic classification. TCAM devices are composed of individually
programmable entries of fixed bit width. During a TCAM Lookup, given a search key,
the TCAM device performs massively simultaneous comparisons (e.g. tens of thousands
of entries), returning the index and/or associated lookup result of the “first” matching
entry (i.e. the one with lowest index). Despite its very high throughput, TCAM devices
usually have limited capacity.
Since TCAM lookups return the first matching entry, the “deny-jump” behavior is
obviously not directly implementable on TCAM. Some extra work is necessary to
eliminate the DENY entries for TCAM to handle the deny-jump behavior.
In several Cisco platforms such as C12K, C10K, Cat6K, ASR1K, ASR 9K and Nexus
x000 series, which utilize TCAM based classification, the handling of the deny-jump
behavior is handled by the Platform-independent Ordered Dependent merge (POD)
algorithm, explained in below.
The POD algorithm handles the deny-jumps by converting the DENY entries into
PERMIT ones using cross product. POD generates a new final list out of the original ones.
When it finds a DENY entry in a class, POD expands it to a list of entries by recursively
merging that DENY entry with all entries of all subsequent classes. In this expansion
process, when a PERMIT entry is found in a subsequent class, if there is some
intersection across the criteria of all entries to be merged, POD generates a new entry
using the action pointed to by the PERMIT entry; when a DENY entry is found, POD
recursively applies the same expansion logic to all subsequent classes. If no PERMIT is
White Paper
CISCO CONFIDENTIAL
found after checking the last subsequent class, a new entry is created to point to a default
action.
This process is illustrated below, using the example from the previous section. POD
would generate the following final list:
a1 => action-1
a2 & b1 => action-2
a2 & b2 & c1 => action-3
a2 & b2 & c2 => default-action
a2 & b2 & c3 => action-3
a2 & b2 => default-action
a2 & b3 => action-2
a2 & c1 => action-3
a2 & c2 => default-action
a2 & c3 => action-3
a2 => default-action
a3 => action-1
b1 => action-2
b2 & c1 => action-3
b2 & c2 => default-action
b2 & c3 => action-3
b2 => default-action
b3 => action-2
c1 => action-3
c2 => default-action
c3 => action-3
(Where: ‘&’ means a merge of entries criteria, and ‘=>’ means the action to be taken if a packet matches this entry.)
The main problem with this approach is that the recursive nature of the algorithm can
cause the required number of entries to “explode”. In theory, the number of created
entries would be , where is the average number of entries in each ACL and is
the number of lists. So the number of created entries would grow exponentially when
grows.
The number of TCAM entries may be exploded because of the deny entries in the
configuration. The total number of the final TCAM entries are heavily dependent on the
configuration, including the number of deny entries, and their positions in the
configuration.
Below is one further example to illustrate this.
White Paper
CISCO CONFIDENTIAL
There exists a policy-map as follows:
Policy-map abc
Match Class A
Set prec 1
Match class B
Set prec 2
Match class C
Set prec 3
Class-map match-any A
match a1 (permit)
match not a2 (deny)
match a3 (permit)
class-map match-any B
match b1 (permit)
match b2 (permit)
class-map match-any C
match c1 (permit)
match not c2 (deny)
match c3 (permit)
The final list will become
Match a1
Match a2&b1
Match a2&b2
Match a2&c1
Match a2&c3
Match a3
Match b1
Match b2
Match c1
Match c3
The deny a2 causes four extra entries, while c2 contributes none.
White Paper
CISCO CONFIDENTIAL
The number of extra entries heavily depends on the number of deny statements, the
number of classes in the configuration as well as the position of the deny entries. In
general a deny, or multiple deny statements in a class further up the sequence will cause
this exponential TCAM expansion, so same ACL could not have any problem used in one
policy-map, but run out the TCAM in the other, because its position and the other classes
in the configuration are different.
This behavior is tracked by CSCsx16234, which can be realized by ASR 1000 customers
when they move from 7200 platforms to the ASR 1000. Original configuration works
fine on 7200, but cause TCAM exhaustion on the ASR1000.
Configuration Solutions/Workarounds.
The easiest way to avoid this TCAM expansion if one sees a configuration with
multiple sequences (e.g. multiple classes in a policy-map, or multiple crypto-map
entries) and deny statements above or intermingled with permit statements is to
attempt to rationalize the configuration to one using only permit statements and
rely on the implicit deny all. Or alternatively, mostly in QoS policies, configure a
separate class to first permit networks you want to deny and give them no
bandwidth (service)
QOS EXAMPLE:
As an example of what you could do to eliminate the deny statements in a QoS

policy; permit the specific subnets you DO NOT WANT to have any bandwidth
first and drop them. This is generally good practice for QOS policies; more
specific first, and prescribe a specific action for that class.
In the QoS example it is the SAME network (deny statement) added to EVERY
ACL - the POSITION of this deny is critical - as this would incur the deny-jump
algorithm.
Problem Configuration:
ip access-list extended acc-in

deny ip 192.168.0.0 0.0.127.255 any
permit ip any 192.168.85.0 0.0.0.31
permit ip any 192.168.90.0 0.0.0.31
ip access-list extended cmb-in

deny ip 192.168.0.0 0.0.127.255 any
permit ip any 192.168.16.0 0.0.1.255
White Paper
CISCO CONFIDENTIAL
permit ip any 192.168.18.0 0.0.0.255
ip access-list extended esn-in

deny ip 192.168.0.0 0.0.127.255 any
permit ip any 192.168.64.0 0.0.0.255
ip access-list extended esnmed-in

deny ip 192.168.0.0 0.0.127.255 any
permit ip any 192.168.64.128 0.0.0.31
ip access-list extended gwa-in

deny ip 192.168.0.0 0.0.127.255 any
permit ip any 192.168.27.0 0.0.0.31
ip access-list extended ifs-in

deny ip 192.168.0.0 0.0.127.255 any
permit ip any 192.168.97.0 0.0.0.31
ip access-list extended iim-in

permit ip any 192.168.19.0 0.0.0.31
ip access-list extended iti-in

deny ip 192.168.0.0 0.0.127.255 any
permit ip any 192.168.98.0 0.0.0.31
!
class-map match-all esnmed-in

match access-group name esnmed-in
class-map match-all cmb-in

match access-group name cmb-in
class-map match-all iim-in

match access-group name iim-in
class-map match-all acc-in

match access-group name acc-in
class-map match-all vpa-in

match access-group name vpa-in
class-map match-all nsf-in

match access-group name nsf-in
White Paper
CISCO CONFIDENTIAL
class-map match-all esn-in

match access-group name esn-in
class-map match-all ifs-in

match access-group name ifs-in
class-map match-all gwa-in

match access-group name gwa-in
class-map match-all iti-in

match access-group name iti-in
!
policy-map slt-in
class iim-in
bandwidth 128
class esn-in
bandwidth 1344
class gwa-in
bandwidth 128
class acc-in
bandwidth 128
class cmb-in
bandwidth 6720
class esnmed-in
bandwidth 384
class ifs-in
bandwidth 512
class iti-in
bandwidth 2048
!
policy-map shaper120
class learnip-in
shape average 1200000000
service-policy slt-in
A much cleaner configuration is to permit the specific networks you want to deny
and give them no bandwidth. This avoids the deny jump algorithm
Solution:
Ip access-list extended DROP_ACL

permit ip 192.168.0.0 0.0.127.255 any
White Paper
CISCO CONFIDENTIAL
!
ip access-list extended acc-in
permit ip any 192.168.85.0 0.0.0.31
permit ip any 192.168.90.0 0.0.0.31
ip access-list extended cmb-in

permit ip any 192.168.16.0 0.0.1.255
permit ip any 192.168.18.0 0.0.0.255
ip access-list extended esn-in

permit ip any 192.168.64.0 0.0.0.255
ip access-list extended esnmed-in

permit ip any 192.168.64.128 0.0.0.31
ip access-list extended gwa-in

deny ip 192.168.0.0 0.0.127.255 any
permit ip any 192.168.27.0 0.0.0.31
ip access-list extended ifs-in

permit ip any 192.168.97.0 0.0.0.31
ip access-list extended iim-in

permit ip any 192.168.19.0 0.0.0.31
ip access-list extended iti-in

permit ip any 192.168.98.0 0.0.0.31
!
class-map match-all DROP
match access-group name DROP_ACL
class-map match-all esnmed-in

match access-group name esnmed-in
class-map match-all cmb-in

match access-group name cmb-in
class-map match-all iim-in

match access-group name iim-in
class-map match-all acc-in

match access-group name acc-in
White Paper
CISCO CONFIDENTIAL
class-map match-all vpa-in

match access-group name vpa-in
class-map match-all nsf-in

match access-group name nsf-in
class-map match-all esn-in

match access-group name esn-in
class-map match-all ifs-in

match access-group name ifs-in
class-map match-all gwa-in

match access-group name gwa-in
class-map match-all iti-in

match access-group name iti-in
!
policy-map slt-in
class DROP
police 8000 conform-action drop
class iim-in
bandwidth 128
class esn-in
bandwidth 1344
class gwa-in
bandwidth 128
class acc-in
bandwidth 128
class cmb-in
bandwidth 6720
class esnmed-in
bandwidth 384
class ifs-in
bandwidth 512
class iti-in
bandwidth 2048
!
policy-map shaper120
class learnip-in
shape average 1200000000
service-policy slt-in
White Paper
CISCO CONFIDENTIAL
CRYPTO-MAP EXAMPLE:
Crypto-map configurations using traditional crypto-map sequencing can realize

the same TCAM deny-jump expansion. The example below shows a
configuration that would incur the deny-jump algorithm.
Problem Configuration:
ip access-list extended IPSEC-3DES-TUN700

deny icmp host 192.168.1.102 any
deny tcp host 192.168.1.102 any eq 22
deny tcp any eq 22 host 192.168.1.102
permit ip host 192.168.1.102 host 192.168.1.118
crypto ipsec transform-set IPSEC-3DES esp-3des esp-sha-hmac

mode transport
!
White Paper
CISCO CONFIDENTIAL
crypto map CRYPTO-MAP 700 ipsec-isakmp

set peer 192.168.1.118
set transform-set IPSEC-3DES
match address IPSEC-3DES-TUN700
set peer 192.168.1.18
set peer 192.168.1.110
set peer 192.168.223.2
set peer 192.168.1.10
set peer 192.168.1.42
Solution Configuration:
The most appropriate solution is to define exactly what needs to be encrypted and
only permit this traffic in an ACL and let the implicit deny-all send the rest of the
traffic clear text.
From the example above, if the desired goal is to encrypt the GRE tunneled traffic
(GRE over IPSec) then the ACL can be modified to:

permit gre host 192.168.1.102 host 192.168.1.118
White Paper
CISCO CONFIDENTIAL
Another way to avoid using multiple crypto map statements in a sequenced order
is to simply collapse all the peers into one crypto-map and use one ACL to permit
peers
ip access-list extended ipsec-3des

!
crypto isakmp policy 100
encr 3des
authentication rsa-encr
group 2
crypto isakmp keepalive 10 5
!
crypto ipsec security-association replay disable
!
White Paper
CISCO CONFIDENTIAL
crypto ipsec transform-set ipsec-3des esp-3des esp-sha-hmac

mode transport
!
crypto map IPSEC-3DES local-address GigabitEthernet0/0/2
crypto map IPSEC-3DES 200 ipsec-isakmp
description JUST USE ONE ACL WITH MULTIPLE PEERS
set peer 192.168.223.2
set peer 192.168.1.10
set peer 192.168.1.18
set peer 192.168.1.42
set peer 192.168.1.46
set peer 192.168.1.50
set peer 192.168.1.54
set peer 192.168.1.58
set peer 192.168.1.110
set peer 192.168.1.118
set peer 192.168.1.66
set peer 192.168.1.70
set peer 192.168.1.62
set peer 192.168.1.166
set peer 192.168.1.86
set peer 192.168.1.74
set peer 192.168.1.78
set peer 192.168.1.90
set peer 192.168.1.134
set peer 192.168.1.146
set peer 192.168.1.174
set peer 192.168.1.170
set peer 192.168.1.142
set peer 192.168.1.94
set peer 192.168.1.202
set peer 192.168.1.206
set peer 192.168.1.218
set peer 192.168.1.210
set transform-set ipsec-3des
match address ipsec-3des
!
interface GigabitEthernet0/0/2
ip address 192.168.1.102 255.255.255.252
crypto map IPSEC-3DES
One final option is to move to the tunnel protection method of encryption – where
and IPSec profile is simply applied to each GRE tunnel and all traffic traversing
White Paper
CISCO CONFIDENTIAL
the tunnel is encrypted. This method does not rely on TCAM at all, as there are
no ACL’s defined to classify the traffic. One design note is that if you are using
GRE/IPSec with keep-alive then this is not supported when using tunnel
protections.
See the following link:
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a008
048cffc.shtml

Asr1000 Tcam Document

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Asr1000 Tcam Document

Uploaded by

Copyright:

Available Formats

White Paper

ASR 1000 Packet Classification and TCAM

Ternary Content Addressable Memory (TCAM):

• Data cell - Stores the actual value of the data.

Early generations of TCAM use block-ternary. In this TCAM multiple

ASR1000 uses 4th generation of TCAM. In TCAM4 there is a 1:1 data

ASR1000 TCAM configurations:

i. Looks at all fields in the policy and select appropriate key

ii. Allocates a unique 16 bit label for this policy/ACL. If this

iii. Most of the policy/ACL fields will be programmed as is in

iv. Optimize and merge the above entries. Classification code

Ex: Some examples

 One to many: One user policy entry (or rule) may

 Many to one: Multiple policy entries (or rule) may

 No TCAM entry: Some policy entries (or rules)

v. Once the final list is ready then it creates VMR (value,

If there are multiple classification features attached to an interface (like

Modifying an Attached ACL or policy:

ACL Range Lookup (ARL) Table:

Example: For the following ACL

> ip access-list range-test2

Src_addr addr-mask arl-id arl-id-mask src-port port-mask dest_addr mask

Src_addr addr-mask arl-id arl-id-mask src-port port-mask dest_addr mask

Ranges fail to fit into ARL table because of two reasons:

1) Ran out of entries in the table (ARL table is full).

Command: sh platform hardware qfp active tcam resource-manager

MPC-1#sh platform hardware qfp active tcam resource-

QFP TCAM Usage Information

80 Bit Region Information

160 Bit Region Information

320 Bit Region Information

Total TCAM Cell Usage Information

2) Command to display ARL table:

MPC-1#sh platform hardware qfp active classification feature-manager

Reg Number Table Id Range Type Compare Value Interval

3) Command to display TCAM entries of an ACL/ policy attached

NOTE: This command is a limited or no use to the customer. Most

This is a two step command. First get the class-group id of policy or

Here 17 (0x11) is the class-group id of ACL range-test2

For Qos Policy:

Here 0x78EFD0 is class-group id for policy MF-Classifier.

MPC-1#sh platform hardware qfp act classification feature-manager

class-group[acl-cg:17] (classes:1,total number of vmrs: 1)

TECH NOTE: The Deny-Jump TCAM Exhaustion Issue

And then a feature policy based on the ACLs:

Problem Definition / Current Cisco Implementation

High-speed switches and routers commonly use Ternary Content-Addressable Memory

Below is one further example to illustrate this.

There exists a policy-map as follows:

The final list will become

The deny a2 causes four extra entries, while c2 contributes none.

As an example of what you could do to eliminate the deny statements in a QoS

ip access-list extended acc-in

ip access-list extended cmb-in

permit ip any 192.168.18.0 0.0.0.255

ip access-list extended esn-in

ip access-list extended esnmed-in

ip access-list extended gwa-in

ip access-list extended ifs-in

ip access-list extended iim-in

ip access-list extended iti-in

class-map match-all esnmed-in

class-map match-all cmb-in

class-map match-all iim-in