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/21Means:
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 fullHardware programming failedCEF 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 routingsdm prefer accesssdm 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