An access switch in the civic center is filling its MAC address table, and staff worry they are also exhausting ACL capacity. How do CAM and TCAM roles differ?
Select an answer to reveal the explanation.
Short Explanation
CAM is the guestbook of MAC addresses the switch learned at the door. TCAM is the fancy lookup engine that can match wildcards for ACLs and QoS. Filling the guestbook does not automatically mean the ACL engine is full—and confusing them leads to the wrong upgrade conversation.
Full Explanation
Content-Addressable Memory and Ternary CAM serve different hardware lookup jobs on campus switches. CAM typically stores MAC learning used for Layer 2 forwarding decisions—the switch consults it to decide which port owns a MAC inside a VLAN. TCAM supports features that need flexible parallel matches with ternary care/don't-care bits, such as ACLs and QoS classifications. When a civic-center access switch fills its MAC table, that pressure is primarily a CAM/MAC-learning concern; worrying about ACL capacity points at TCAM scale for security and QoS entries, which is a separate resource.
Saying CAM only stores OSPF routes while TCAM only stores wireless SSIDs misassigns both tables. Claiming TCAM replaces Spanning Tree while CAM encrypts CAPWAP tunnels invents roles neither memory type performs. Treating CAM and TCAM as identical tables that hold only default gateways erases the Layer 2 learning versus ternary feature lookup distinction ENCOR expects.
Exam caveat: CAM ≈ MAC learning/L2 forwarding; TCAM ≈ ACL/QoS-style ternary hardware entries. Keep those lanes separate when symptoms mention both MAC table pressure and ACL capacity.
Operational check: monitor MAC table utilization and flooding behavior separately from ACL/QoS programming failures, and when new ACL entries fail to install, inspect TCAM utilization rather than assuming CAM aging alone is responsible.