Cisco Port Security and Sticky MAC: Violation Modes Explained - 夜莺博客

Cisco Port Security and Sticky MAC: Violation Modes Explained

Cisco port security locks a switch port to a fixed set of MAC addresses; sticky MAC makes it practical by learning the first device automatically and writing that address into the running configuration. Once the port reaches its maximum, any unrecognized source triggers a violation action. This guide configures sticky port security on an access port, explains the three violation modes, and shows how to recover an err-disabled port. The emphasis here is on the violation half of the feature: exactly what counts as a violation, how protect, restrict and shutdown differ in behavior and visibility, which counters and syslog messages each one produces, and how to bring a port back into service automatically with err-disable recovery timers or by hand.

Static vs Dynamic vs Sticky MAC

  • Dynamic — MACs age out of the table on a timer; no security, any device can connect.
  • Static — every MAC typed by hand; maximum security, high admin burden.
  • Sticky — the switch learns MACs and writes switchport port-security mac-address sticky <mac> into the running config automatically; entries survive a reload only after write memory.

Port Security Configuration with Sticky MAC

Port security only runs on access or voice ports — the port must not be a trunk or left in dynamic auto mode:

Switch(config)# interface GigabitEthernet0/1
Switch(config-if)# switchport mode access
Switch(config-if)# switchport port-security
Switch(config-if)# switchport port-security maximum 2
Switch(config-if)# switchport port-security mac-address sticky
Switch(config-if)# switchport port-security violation shutdown
Switch(config-if)# no shutdown
Switch# write memory

The example allows a PC plus an IP phone. Defaults to know: maximum is 1 and the default violation mode is shutdown — so enabling port security without tuning maximum means a second device immediately err-disables the port. For a voice-VLAN port set maximum 2 and bind addresses per VLAN with switchport port-security mac-address sticky <mac> vlan voice.

What Actually Counts as a Security Violation

It is tempting to think a violation only happens when a rogue laptop is plugged in. The switch is stricter than that, and every trigger below raises the same event. If you pick a disruptive violation mode without understanding this list, you will err-disable ports during routine maintenance.

  • Maximum exceeded — the port already holds the configured number of secure addresses, and a frame arrives from a brand-new source MAC.
  • Static address conflict — a MAC bound with switchport port-security mac-address <mac> is seen on a different port, or on this port while it is already assigned elsewhere.
  • Sticky entry moved — a sticky-learned MAC reappears on another secured port; both ports now claim the same address.
  • Trunk overflow — a port configured as a trunk with a low maximum sees dozens of source MACs and trips immediately.
  • Voice-VLAN overflow — the IP phone plus a device daisy-chained through the phone exceeds the per-VLAN allowance.
  • Virtualized host bridging — a hypervisor host running multiple bridged virtual NICs presents several source MACs from one physical cable.

Because the triggers are not all hostile, the right violation mode depends on what the port is for. A locked server port can afford to be brutal; a meeting-room port or an uplink that legitimately carries many MACs must be handled differently or it will spend its life in err-disable.

Violation Modes: Protect, Restrict, Shutdown

  • Protect — silently drops unknown traffic; no log, counter not incremented. Least visible.
  • Restrict — drops the traffic, sends syslog/SNMP, increments the violation counter; port stays up.
  • Shutdown — err-disables the port (default); the most disruptive but the most obvious.

The three modes differ only in how loudly they complain and whether the port is taken down. In all three cases the offending frame is dropped — port security never forwards traffic from an unauthorized source. The table summarizes the exact behavior:

Mode Offending traffic Counter incremented Syslog / SNMP trap Port state after
protect Dropped No No Up (violating host simply has no connectivity)
restrict Dropped Yes Yes Up (violating host blocked, others unaffected)
shutdown Dropped Yes Yes Err-disabled / secure-shutdown until recovered

Protect Mode in Depth

switchport port-security violation protect is the "quiet" mode. Unknown source addresses are dropped in hardware, but the switch increments nothing, logs nothing and sends no SNMP trap. The consequence is that the port stays up and the user reports "the network is down" — the help desk gets a symptom with no matching event on the switch. Use protect only where you never want the switch to react and where the affected device is trivially replaceable. It is a poor choice on a port that anyone depends on, because a security event and a broken cable look identical from the CLI.

Restrict Mode in Depth and Reading the Counters

switchport port-security violation restrict is the usual recommendation for production access ports. Offending frames are dropped and the rest of the port keeps working, but the switch records the event two ways: the violation counter on the interface and a syslog/SNMP notification. The counter is the single most useful number when you are chasing a rogue device:

Switch# show port-security interface GigabitEthernet0/1
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Restrict
Maximum MAC Addresses      : 2
Total MAC Addresses        : 2
Sticky MAC Addresses       : 2
Last Source Address:Vlan   : 0011.2233.4455:10
Security Violation Count   : 3

Here three violations have occurred but the port stayed up. Last Source Address:Vlan tells you exactly which MAC tripped the last one, which is normally enough to identify the offending device (or to discover that a legitimate MAC was simply never learned because the maximum is too low). Pair this with the syslog line Cisco emits — %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0011.2233.4455 on port GigabitEthernet0/1 — to keep a historical record in your central log server.

Shutdown Mode, Err-Disable and the Secure-Shutdown State

violation shutdown is the default and the most aggressive: the port is placed in the error-disable state after a single offending frame. Physically it stops passing traffic, show interfaces status reports err-disabled with reason psecure-violation, and show port-security interface reports Port Status : Secure-shutdown. Two log messages fire, one for the violation and one for the err-disable action:

%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0011.2233.4455 on port GigabitEthernet0/1.
%PM-4-ERR_DISABLE: psecure-violation error detected on Gi0/1, putting Gi0/1 in err-disable state

To see everything the switch has parked, and to confirm the reason, use:

Switch# show interfaces status err-disabled
Switch# show errdisable detect

Shutdown is the right default for fixed infrastructure — a locked data-centre port, a wall port serving a single known device, or an unused port that should never see traffic. It is the wrong choice for a port whose device count legitimately changes, because every new MAC means a manual intervention.

Verification and Recovery

Switch# show port-security interface GigabitEthernet0/1
Switch# show port-security address
Switch# show running-config interface GigabitEthernet0/1

After a violation the port shows Secure-shutdown and the last offending source address. Bring it back manually or automatically:

Switch(config)# interface GigabitEthernet0/1
Switch(config-if)# shutdown
Switch(config-if)# no shutdown
Switch(config)# errdisable recovery cause psecure-violation
Switch(config)# errdisable recovery interval 300

Automatic Recovery with Err-Disable Timers

Manually bouncing every err-disabled port does not scale. The err-disable recovery feature can re-enable a port after a timer expires, and port security violations are one of the causes it understands. Enable it and choose an interval, then verify that the cause is listed as armed:

Switch(config)# errdisable recovery cause psecure-violation
Switch(config)# errdisable recovery interval 300
Switch# show errdisable recovery

The interval is global, so all recovery-enabled causes share the same timer — pick a value you are comfortable with for the fastest-recovering fault type. When the timer fires, the switch logs %PM-4-ERR_RECOVER: Attempting to recover from psecure-violation err-disable state on Gi0/1 and brings the port up. Note that automatic recovery is a convenience, not a fix: if the root cause is a loop or a duplicate MAC address, the port will simply violate again, which is why the syslog trail matters. For a permanent fault, leave recovery disabled and intervene deliberately so the offending device is actually removed.

Violations on Trunk, Voice and Port-Channel Ports

Trunk and multi-VLAN ports behave differently enough to deserve their own plan. Port security is supported on static trunks, but a trunk that carries the MAC addresses of an entire downstream switch or access stack will overflow any small maximum. The usual approaches are to raise the maximum generously and pick restrict so the trunk is never taken down, or to disable port security on the trunk itself and enforce it only on the access ports behind it. When several MACs arrive on one port from different VLANs, the secure addresses are tracked per VLAN, so maximum 2 with a PC on the data VLAN and a phone on the voice VLAN does not mean the two devices share a budget — each VLAN has its own limit unless you override it with switchport port-security maximum 1 vlan voice or similar per-VLAN syntax. On link-aggregated ports, port security is generally configured on the physical members before the bundle, and the correct maximum is the total number of legitimate source MACs the bundle is expected to carry. Getting this wrong is the single most common reason an innocent change err-disables a working uplink.

Migration and Maintenance Without Err-Disabling Ports

Any time you replace a PC, swap a phone, or move a device to a new wall port, you are about to create a violation on a shutdown-mode port. A short pre-change procedure avoids most escalations. First, identify the port and read its current secure addresses with show port-security address and show port-security interface. Second, if the new device must be allowed, clear the stale entry deliberately rather than letting the switch decide, using clear port-security sticky interface GigabitEthernet0/1 or clear port-security configured interface GigabitEthernet0/1. Third, if the change is planned and the port is critical, temporarily set the violation mode to restrict for the maintenance window, do the swap, confirm the new address was learned, and set it back to shutdown. That three-step habit turns a potential outage into a two-minute cutover.

Choosing the Right Violation Mode

  • Locked server / single-device port — shutdown. Any unexpected MAC is a genuine event worth an outage-sized alert.
  • General user access port — restrict with a sensible maximum. Users still work; you get a counter and a log line to investigate.
  • Port that must never drop traffic — protect, but only if you accept that violations are invisible from the CLI.
  • Voice + data port — restrict or shutdown with maximum 2 and per-VLAN sticky addresses so the phone and the PC cannot collide.
  • Unused port — shutdown with maximum 1; nobody should ever plug in.

Limitations and Best Practices

  • Port security cannot be configured on a dynamic-access port, a port in switchport mode dynamic auto, or a port-channel member in some platforms — set a static access or trunk mode first.
  • Sticky addresses live only in the running configuration until you save. A reload without write memory loses every learned sticky MAC.
  • Clear a violated port's learned addresses if you need to start fresh with clear port-security dynamic interface GigabitEthernet0/1 (or clear port-security sticky interface GigabitEthernet0/1).
  • Set the maximum from observed reality: count the MACs the port legitimately sees, then add one spare.
  • Flood the feature with alerting rather than guesswork — forward the PSECURE syslog messages to monitoring so a restrict-mode violation is not silently ignored.

Port security stops rogue devices at the edge but not ARP spoofing — pair it with DHCP snooping (its trusted/untrusted model complements secure ports) and the loop protections in PortFast, BPDU guard and root guard. For the step-by-step Catalyst configuration and how to read each show field, see our Catalyst sticky MAC configuration guide.

原文链接:https://www.netstuts.com/sticky-mac