> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # Switch Administration: SDM Templates, Errdisable Recovery, and CAM Aging - URL: https://www.pinglabz.com/switch-administration-sdm-errdisable/ - Published: 2026-07-12T08:25:28.000Z - Updated: 2026-08-24T09:42:49.000Z - Description: SDM templates, errdisable recovery, and CAM aging: the unglamorous switch administration features that prevent table-full errors, dead ports, and mystery flooding, with real output from a CML lab. - Author: Jaime - Tags: VLAN, Labs, CCIE, #Import 2026-08-01 19:54 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](https://www.pinglabz.com/vlans-layer-2-switching/). ## 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: default A balanced split across MAC, routing, ACL, and QoS. Fine for a general-purpose switch. vlan / access Maximises MAC address capacity at the expense of routing. For a pure L2 access switch that routes nothing. routing Maximises IPv4/IPv6 route capacity at the expense of MAC. For a distribution or core switch doing L3. dual-ipv4-and-ipv6 Reserves meaningful space for IPv6 routes. Essential the moment you run dual-stack - the default often starves IPv6. ``` 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: Auto-recover **udld, link-flap, storm-control** \- usually transient physical faults. Auto-recovery saves a truck roll for a self-clearing problem. Consider carefully **psecure-violation, bpduguard** \- these usually indicate something wrong (rogue device, unauthorised switch). Auto-recovering means the offender gets re-tried every interval. Sometimes you want it to stay down until investigated. 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. That is the build-time view: which causes to arm and how long to set the timer. For the other half, pulling the exact cause off a port that is already down and deciding when a timer is the wrong answer entirely, see [every err-disable cause and how to bring the port back](https://www.pinglabz.com/errdisable-recovery-cisco/). ## 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](https://www.pinglabz.com/expert-layer-2-troubleshooting-scenarios/). The full cluster index lives on the [VLAN and switching pillar](https://www.pinglabz.com/vlans-layer-2-switching/).