Switch Administration: SDM Templates, Errdisable Recovery, and CAM Aging

The switching features that make headlines are the protocols - spanning tree, VLANs, EtherChannel. The features that actually keep a switch running are the unglamorous administrative ones: how the hardware tables are carved up, what happens when a port is disabled by a protection feature, and how long the switch remembers a MAC. Ignore them and you get mysterious "table full" errors, ports that never come back after a transient fault, and traffic flooding for no obvious reason.

This article covers SDM templates, errdisable recovery, and CAM aging, with real output from a CML lab. For the fundamentals, start at the complete VLAN and switching guide.

SDM templates: carving up the hardware

A switch's forwarding intelligence lives in a fixed-size chunk of specialised memory (TCAM). That memory has to hold MAC addresses, IPv4 routes, IPv6 routes, ACL entries, QoS entries, multicast state - all of it, in one finite space. You cannot have maximum capacity for everything at once. So the switch offers SDM templates: preset allocations that trade one resource against another.

show sdm prefer

Typical templates on a Catalyst access switch:

Switch(config)#sdm prefer routing
! Requires a reload to take effect
Switch#reload

The critical operational fact: changing the SDM template requires a reload. It re-carves the hardware memory, which cannot be done on a running switch. Plan it into a maintenance window.

The failure mode this prevents is nasty and non-obvious. A switch running the default template in an IPv6 deployment can silently run out of IPv6 TCAM, at which point IPv6 routes stop being installed in hardware and get punted to software - which cripples IPv6 forwarding performance while IPv4 looks perfectly healthy. show platform tcam utilization (or the platform-specific equivalent) shows you the usage; if a category is near 100%, you need a different template.

Platform note: SDM templates are a physical-hardware concept - they carve up a real TCAM. Virtual IOL-L2 in CML has no TCAM, so show sdm prefer returns % Invalid input. This is a hardware feature you configure on real Catalyst switches; we mention it here for completeness and are honest that the virtual lab cannot demonstrate it.

Errdisable recovery: the safety net

A whole family of protection features respond to a violation by errdisabling the port - shutting it down and leaving it down. Port security violation, BPDU guard, UDLD, storm control, DHCP rate limit, DAI rate limit, link flap - all of them err on the side of "cut it off and wait for a human".

That is the safe default, but it means every transient fault requires manual intervention. A patch cable reseated, a device rebooted, an SFP cleaned - and the port stays dead until someone runs shutdown / no shutdown. Errdisable recovery automates that.

errdisable recovery cause psecure-violation
errdisable recovery cause udld
errdisable recovery cause bpduguard
errdisable recovery interval 300

From the lab:

SW1#show errdisable recovery
ErrDisable Reason            Timer Status
bpduguard                    Enabled
udld                         Enabled
storm-control                Disabled
psecure-violation            Disabled
...
Timer interval: 60 seconds

Each enabled cause has its port re-tried automatically after the interval. Watch it work: we triggered a port-security violation, the port went errdisable, then after enabling recovery it came back:

SW3#show interfaces Ethernet0/2 status
Et0/2                           err-disabled 10          <-- shut by the violation

! ... after errdisable recovery cause psecure-violation, and the timer/bounce:
SW3#show interfaces Ethernet0/2 status
Et0/2                           connected    10          <-- back in service

Choosing which causes to auto-recover

Not every cause should recover automatically:

The interval is a genuine trade-off. Too short (the 30-second minimum) and a persistently-faulty link flaps in and out of service constantly, which is worse than staying down. 300 seconds is a sensible default - long enough that a genuinely broken link is not thrashing, short enough that a transient fault self-heals within five minutes.

CAM aging: how long a MAC is remembered

The CAM table (the MAC address table) is how a switch forwards unicast intelligently - it learns which MAC lives on which port and sends frames only there. Entries are learned dynamically and aged out after a period of inactivity, default 300 seconds.

mac address-table aging-time 300

The aging time interacts with your spanning tree design in a way that causes real, hard-to-diagnose problems:

• Too long, and a topology change causes black-holing. When STP reconverges and a host's path changes, the switch may still have the old (now wrong) CAM entry for up to the aging time - 5 minutes of traffic sent out the wrong port. This is exactly why STP topology change notifications exist: a TCN tells switches to shorten their CAM aging to the forward delay (15 seconds) temporarily, flushing stale entries fast after a topology change.
• Too short, and you flood. If entries age out faster than hosts send traffic, the switch keeps forgetting where things are and floods unknown-unicast to relearn. On a quiet-but-important flow (a heartbeat, a backup channel) this looks like intermittent unicast flooding, and it is baffling until you connect it to aging.

The classic symptom of a too-short aging time (or an asymmetric-routing situation where the switch never learns a MAC from returning traffic) is persistent unicast flooding: you see traffic for a specific destination appearing on ports it has no business being on. Check show mac address-table - if the destination is not in the table, the switch is flooding it, and you need to find out why it never learns it.

Switch#show mac address-table interface Ethernet0/2
Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
  10    5254.004e.11c0    DYNAMIC     Et0/2

Switch#show mac address-table aging-time
Switch#show mac address-table count

You can also pin critical MACs with a static entry so they never age out - useful for a default gateway or a critical server whose flooding you want to eliminate entirely:

mac address-table static 0011.2233.4455 vlan 10 interface Ethernet0/1

The administration checklist for a new access switch

1. Pick the right SDM template for the switch's role and reload. Dual-stack? Use a template that reserves IPv6 space.
2. Configure errdisable recovery for the transient causes (udld, link-flap, storm-control) at a 300-second interval. Leave security-violation causes to manual review if your policy demands it.
3. Leave CAM aging at default (300s) unless you have a specific reason. Ensure STP topology change handling is working so it shortens automatically after a reconvergence.
4. Pin critical MACs statically if you have a specific flooding problem to eliminate.

Key takeaways

• SDM templates carve the fixed hardware TCAM between MAC, routes, ACLs, and QoS. Pick the template for the switch's role; changing it requires a reload. Dual-stack needs an IPv6-aware template or IPv6 silently starves.
• Errdisable recovery auto-re-enables ports shut by protection features after an interval. 300 seconds is a good default - short enough to self-heal transients, long enough to avoid flapping.
• Auto-recover physical causes (udld, link-flap, storm-control); think twice before auto-recovering security causes (port-security, BPDU guard), which usually mean something is wrong.
• CAM aging defaults to 300s. Too long causes post-topology-change black-holing (which is why STP TCNs shorten it); too short causes unicast flooding.
• Persistent unicast flooding to a specific destination almost always means the switch is not learning that MAC - check show mac address-table.
• SDM is a hardware feature; virtual IOL-L2 in CML cannot demonstrate it (no TCAM). Errdisable recovery and CAM aging work fully.

Next: five broken Layer 2 scenarios, ticket style. The full cluster index lives on the VLAN and switching pillar.