0%

Catalyst check TCAM utilization


show platform hardware fed switch active fwd-asic resource tcam utilization
CAM Utilization for ASIC  [0]
 Table                                              Max Values        Used Values
 --------------------------------------------------------------------------------
 Unicast MAC addresses                               32768/1024      1223/21
 L3 Multicast entries                                 8192/512          0/9
 L2 Multicast entries                                 8192/512          0/11
 Directly or indirectly connected routes             24576/8192      4934/1996
 QoS Access Control Entries                           5120            153
 Security Access Control Entries                      5120            246
 Ingress Netflow ACEs                                  256              8
 Policy Based Routing ACEs                            1024             22
 Egress Netflow ACEs                                   768              8
 Flow SPAN ACEs                                       1024             13
 Control Plane Entries                                 512            255
 Tunnels                                               512             17
 Lisp Instance Mapping Entries                        2048              3
 Input Security Associations                           256              4
 SGT_DGT                                              8192/512          0/1
 CLIENT_LE                                            4096/256         35/0
 INPUT_GROUP_LE                                       1024              0
 OUTPUT_GROUP_LE                                      1024              0
 Macsec SPD                                            256              2

shows TCAM (Ternary Content Addressable Memory) utilisation on a Cisco switch ASIC
AM is a limited hardware resource used to store things like routing entries, ACLs, QoS rules
If it fills up, the switch can’t program new entries in hardware (which can cause drops or punt-to-CPU issues).

Some Max Values have 2 values divided by /
First number = hardware maximum
Second number = software or per-region allocation
such as
Unicast MAC addresses 32768/1024 1223/21
Means:
Currently used = 1223 (hardware), 21 (allocated region)
Max hardware = 32,768 MACs
Allocated region = 1,024

MAC Addressing (Layer 2)

Unicast MAC addresses   32768/1024    1223/21
  • Very low usage → ✅ healthy
  • No concern at all

Routing (Layer 3)

Directly or indirectly connected routes   24576/8192   4936/1996
  • This is important
  • You’re using:
    • ~5K out of 24K hardware → ✅ fine
    • ~2K out of 8K allocated → ⚠️ moderate

Watch this if:

  • You add more routes (e.g. BGP, OSPF growth)
  • You hit the 8192 allocation, not just the 24576 max

ACLs (Security & QoS)

Security ACLs

Security Access Control Entries   5120   246

QoS ACLs

QoS Access Control Entries       5120   153

Both are:

  • Very low usage → ✅ no issue

NetFlow / PBR / SPAN

Ingress Netflow ACEs    256    8
Egress Netflow ACEs 768 8
Policy Based Routing 1024 22
Flow SPAN 1024 13

All low → ✅ healthy

Control Plane (IMPORTANT)

Control Plane Entries   512   255

This is the only line worth attention

  • 255 out of 512 = ~50% used
  • Not critical yet, but:
    • Control plane TCAM is small
    • Can fill faster than expected

If this fills:

  • Routing protocols
  • ARP / ICMP handling
  • CPU-bound traffic
    may be impacted

Multicast

L3 Multicast entries   8192/512   0/9
L2 Multicast entries 8192/512 0/11

Basically unused → ✅ fine

Other (IPSec, LISP, TrustSec, etc.)

All very low usage:

  • Tunnels
  • Security Associations
  • SGT / TrustSec
  • MACsec

No concerns

What Actually Matters (Summary)

✅ Healthy Areas

  • MAC table
  • Routing entries
  • ACLs (QoS & Security)
  • NetFlow / PBR
  • Multicast
  • Tunnels / security features

Nearing the software limit

So what happens if software limit is reached but not hardware limit For example for Routing (Layer 3), 8K allocated is reached Does hardware allocate more to software?

No — the hardware will NOT automatically give more TCAM to that feature.

If the software/allocated limit (e.g. 8K for L3 routes) is reached, you can hit problems even if the total hardware TCAM isn’t full

What’s really going on

Think of TCAM like a building:

  • Hardware limit (24K) = total building capacity
  • Software allocation (8K) = rooms assigned to “routing”
  • Other rooms are assigned to ACLs, QoS, etc.

If routing fills its 8K “room”:

  • It cannot spill into other rooms
  • Even if those rooms are empty

What happens when the 8K allocation is hit?

For L3 routes:

1. New routes fail to install in hardware

  • FIB (Forwarding Information Base) can’t program entries into TCAM

2. Traffic impact

Depending on platform:

  • Packets may be dropped
  • Or punted to CPU (slow path → performance issues)

3. You may see logs like:

  • FIB TCAM full
  • Hardware programming failed
  • CEF adjacency install failed

4. Control plane vs data plane mismatch

  • Route exists in routing table (RIB) ✅
  • But not in hardware (FIB) ❌

This is where things break.

Hardware DOES NOT auto-rebalance

Unlike RAM or CPU:

  • TCAM is statically partitioned
  • No dynamic borrowing between features

So what can you do?

1. Change TCAM allocation (SDM template)

On Cisco switches (e.g. Catalyst), you typically use:

  • sdm prefer routing
  • sdm prefer access
  • sdm prefer dual-ipv4-and-ipv6

This redistributes TCAM between:

  • Routing
  • ACLs
  • QoS
  • etc.

Requires reload

2. Reduce route usage

  • Summarisation
  • Filtering (e.g. in BGP)
  • Remove unnecessary routes

3. Move features off TCAM-heavy usage

  • Large ACLs
  • Excess QoS policies

4. Upgrade hardware (if scaling limit hit)

  • Some platforms just have hard ceilings

Leave a Reply

Your email address will not be published. Required fields are marked *

*
*