CAM and TCAM Tables
The MAC address table is stored in Content Addressable Memory (CAM).
- RAM queries a specific memory address, and then returns the data or content stored at that address location.
- CAM operates essentially in the reverse, and does not require that a memory address be provided. Instead, CAM queries for the desired content, and then returns all matching results, including any associated content.
- CAM is significantly faster than RAM, as it searches the entire memory content in one cycle, instead of a single address at a time. However, CAM is more expensive than RAM.
When performing a MAC address table lookup, the MAC address itself is the content being queried. For any matching results, CAM will return the destination port (the associated content).
Cisco uses the terms MAC address table and CAM table interchangeably. This guide will use the term CAM table moving forward. Idle entries in the CAM are purged after 300 seconds, by default. This timer is reset every time a frame is received with the associated MAC address on the correct port. If a host moves to a different port on a switch, the CAM table entry for the previous port will be purged immediately. This is desirable behavior – a MAC address is unique, and should never exist on more than one switch port unless a switching loop or other issue exists.
Ternary Content Addressable Memory (TCAM) tables provide high-speed lookups for two additional functions:
- Filtering traffic using access-lists
- Prioritizing traffic using QoS
Multi-layer switches utilize the Forwarding Information Base (FIB) table for L3 forwarding decisions.
Ternary Content Addressable Memory (TCAM)
Recall that switches utilize TCAM tables for two purposes:
- Filtering traffic using access-lists
- Prioritizing traffic using QoS
Some Layer-3 devices store the routing table in TCAM as well. Most Layer-3 switches support multiple TCAM tables, to separately manage the access-lists for inbound and outbound traffic, and for QoS.
The TCAM consists of two components:
- Feature Manager (FM) – Automatically integrates access-lists intothe TCAM.
- Switching Database Manager (SDM) – Supports partitioning theTCAM for separate functions (supported on only some Cisco models).
Each entry in the TCAM table contains three components, defined by access-list entries:
Switch(config)# access-list WEB permit tcp 10.1.1.0 0.0.0.255 host 10.2.1.1 eq 443 Switch(config)# access-list WEB deny tcp 10.1.0.0 0.0.0.255 host 10.2.1.1 eq 80
The Feature Manager (FM) will automatically integrate the access-list named WEB into the TCAM. Configuring the TCAM consists solely of creating the necessary access-lists. However, the access-list will not take effect until it’s applied to an interface or VLAN.
Cisco operating system – Cisco offers two brands of network switches:
|Catalyst 1200||Catalyst 29xx||Nexus 1000V|
|Catalyst 2948||Catalyst 35xx||Nexus 3000|
|Catalyst 4000||Catalyst 36xx||Nexus 4000|
|Catalyst 4500||Catalyst 37xx||Nexus 5000|
|Catalyst 5000||Catalyst 38xx||Nexus 7000|
|Catalyst 5500||Catalyst 4500||Nexus 9000|
|Catalyst 6000||Catalyst 4900|
|Catalyst 6500||Catalyst 6500|
- Catalyst – Cisco’s flagship switching platform,with a large selection of models spanning access, distribution, and core layers.
- Nexus – high-end switches focused at data center environments.
Depending on the brand and model, Cisco supports one of three switch operating systems:
- Catalyst OS (CatOS) – interface based onset commands, that is almost entirely deprecated. CatOS will not be covered in this guide. IOS – interface that is nearly identical to the Cisco router IOS, except for switching-specific commands.
- NX-OS – interface supported exclusively on Nexus brand switches.
The following details the supported operating system for various Cisco platforms:
Some catalyst switches support being Switch port error condition stacked – essentially, multiple physical switches connected together to form one logical switch. Configuration commands must reflect the stack, module, and interface number,in the following format: stack/module/interface.
Switch(config)# interface range gi2/3 , gi2/5 , gi2/7
Macros can be created for groups of interfaces that are configured often:
Switch(config)# define interface-range Mobatime gi2/10 – 15
Switch(config)# interface range macro Mobatime
If an interface does not have an accurate description, there are two methods of determining what is connected to it:
- Trace the physical cable to the host (always fun).
- Leverage the CAM table to identify a host by its MAC address.
Switch port error condition
Following events can put a port into err-disable state:
|arp-inspection||Error with dynamic ARP inspection, used to prevent ARP poisoning.|
|bpduguard||BPDU is received on an interface configured for STP Portfast and BPDU guard.|
|channel-misconfig||Error with an Etherchannel configuration|
|dhcp-rate-limit||Error with DHCP Snooping|
|dtp-flat||Flapping between trunk encapsulation (ISL or 802.1Q)|
|gbic-invalid||Invalid SFP or GBIC module|
|ilpower||Error with inline power|
|loopback||Interface is looped (received a keep alive packet that it sent out).|
|l2tpguard||Error with L2 tunneling|
|link-flap||Interface is flapping between an up or down state|
|mac-limit||Violation of MAC address limit|
|pagp-flap||Flapping of an Etherchannel during PaGP negotiation, usually due to misconfiguration|
|psecure-violation||Violation of port-security|
|rootguard||BPDU from a root bridge received on a non-designated port|
|security-violation||Violation of 802.1x security|
|storm-control||Broadcast storm detected|
|udld||Unidirectional link detected|
|unicast-flood||Violation of unicast flooding limit|
All err-disable conditions are enabled by default. To disable a specific err-disable condition:
Switch(config)# no errdisable detect cause link-flap
It is also possible to disable all errdisable conditions:
Switch(config)# no errdisable detect cause all
To enable errdisable conditions again, either individually or collectively:
Switch(config)# errdisable detect cause udld
Switch(config)# errdisable detect cause all
An interface can be manually recovered from an errdisable state by performing a shutdown and then no shutdown:
Switch(config)# interface gi3/10
Switch(config-if)# no shut
However, if the error condition still exists, the interface will be placed back into an err-disable state again. Thus, an interface should not be recovered until the root cause is resolved.
Interfaces can also automatically recover from an error condition. First, the errdisable conditions that should auto-recover must be individually or collectively identified:
Switch(config)# errdisable recovery cause udld
Switch(config)# errdisable recovery cause all
By default, an interface will recover from an errdisable state in 300 seconds. This timer can be adjusted:
Switch(config)# errdisable recovery interval 250
To view which errdisable conditions are currently enabled for recovery:
Switch# show errdisable recovery
By default, automatic err-disable recovery is disabled for all conditions. Note that all err-disable commands are applied globally, and thus apply to all interfaces on the switch.
Switch# show interface status
Switch# show interface status err-disabled