How to Audit Switch Ports on Cisco Catalyst Switches

What is on each port, should it be, and is the port enforcing that? A real port audit on a Catalyst switch, including a genuine port-security violation that fired mid-lab.

10 Cisco Port Audit Steps for Amazing Network Security - PingLabz Fundamentals article title card

A port audit answers three questions about every port on a switch: what is connected to it, should it be connected, and is the port configured to enforce that? Switch ports accumulate history (temporary connections that became permanent, ports left open after moves, security settings that were "going to be added later"), and an audit is how you pay that debt down. This guide walks a real audit on a Catalyst switch, with every output block captured from a live lab, including a genuine port-security violation that fired during the writing of this article.

Step 1: Inventory what the switch sees

Start with the one-line-per-port view:

SW1# show interfaces status

Port         Name               Status       Vlan       Duplex  Speed Type
Et0/0        Uplink to R1       connected    1            full   auto 10/100/1000BaseTX
Et0/1        Uplink to R2       connected    1            full   auto 10/100/1000BaseTX
Et0/2        Host H1            err-disabled 1            full   auto 10/100/1000BaseTX
Et0/3        Unused - parked    disabled     1            full   auto 10/100/1000BaseTX

Read the Status column like an auditor. connected ports need an owner (the Name field should say what, and the audit verifies it). notconnect ports are candidates for shutdown. disabled means administratively shut, which is what a parked port should look like. And err-disabled means the switch itself took the port down in response to a violation; more on that one below, because this example is real.

The description field is part of the audit. An undocumented connected port is a finding: if nobody can say what is on it, that is exactly the port an auditor (or an attacker) cares about.

Step 2: Identify the neighbors

CDP (or LLDP in mixed-vendor networks) tells you which ports face infrastructure:

SW1# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
R2               Eth 0/1           144               R    Linux Uni Eth 0/1
R1               Eth 0/0           141               R    Linux Uni Eth 0/1

Total cdp entries displayed : 2

Two ports face routers; those are the uplinks, and they get different audit treatment than access ports (no port security on uplinks, and they should be the only ports carrying trunks or multiple MACs). Anything CDP does not list is presumed to face an endpoint, and endpoints get the strict treatment.

Note the flip side: CDP advertises your switch details to whatever is plugged in. Part of the audit is confirming CDP/LLDP is disabled on ports facing untrusted spaces (conference rooms, lobbies, anywhere the public reaches).

Step 3: Map the MAC addresses

SW1# show mac address-table dynamic
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
   1    0000.0c9f.f001    DYNAMIC     Et0/0
   1    aabb.cc00.1410    DYNAMIC     Et0/0
   1    aabb.cc00.1510    DYNAMIC     Et0/1
Total Mac Addresses for this criterion: 3

The questions to ask of this table: does each access port show exactly the number of MACs you expect (usually one, or two with an IP phone)? Do the uplink ports carry the MACs they should? An access port with several MACs behind it means an unmanaged switch or hub someone smuggled under a desk, which quietly defeats every per-port control you have. (The 0000.0c9f.f001 entry above is an HSRP virtual MAC on the router uplink, which is expected on this LAN; recognizing the expected oddities is what makes the unexpected ones stand out.)

To audit a single port: show mac address-table interface Et0/2.

Step 4: Check the enforcement: port security

Inventory says what is there; port security enforces that it stays that way. The audit view:

SW1# show port-security
Secure Port  MaxSecureAddr  CurrentAddr  SecurityViolation  Security Action
                (Count)       (Count)          (Count)
---------------------------------------------------------------------------
      Et0/2              1            1                  1         Shutdown
---------------------------------------------------------------------------

That SecurityViolation count of 1 is not staged. While this lab was being built, a second MAC address appeared behind the host port (a stray address from the host's own container runtime) and port security did exactly what it was configured to do:

*Aug 24 00:38:28.157: %PM-4-ERR_DISABLE: psecure-violation error detected on Et0/2, putting Et0/2 in err-disable state
*Aug 24 00:38:28.158: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address b6d9.476a.e994 on port Ethernet0/2.
*Aug 24 00:38:30.157: %LINK-3-UPDOWN: Interface Ethernet0/2, changed state to down

The per-port detail shows the whole story: the port is down by policy, who caused it, and how the port was configured when it happened:

SW1# show port-security interface Ethernet0/2
Port Security              : Enabled
Port Status                : Secure-shutdown
Violation Mode             : Shutdown
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 1
Last Source Address:Vlan   : 5254.0033.43ad:1
Security Violation Count   : 1

With sticky learning, the learned MAC lands in the running config, which is exactly the kind of evidence an audit wants to see (and to remind you to write memory, because sticky MACs not saved are sticky MACs lost at reload):

SW1# show running-config interface Ethernet0/2
interface Ethernet0/2
 description Host H1
 switchport mode access
 switchport port-security mac-address sticky
 switchport port-security mac-address sticky 5254.0033.43ad
 switchport port-security

Recovery from err-disabled is a manual shutdown / no shutdown on the port after you have decided the violation was legitimate, or automatic if errdisable recovery cause psecure-violation is configured. During this audit the violating MAC turned out to be benign (the host, not an intruder), so the port was reopened with maximum 2 and violation mode restrict, which drops offending frames and logs instead of killing the port:

SW1# show port-security interface Ethernet0/2 | include Port Status|Violation Mode|Maximum
Port Status                : Secure-up
Violation Mode             : Restrict
Maximum MAC Addresses      : 2

That decision (shutdown vs restrict, max 1 vs max 2) is the actual work of the audit: matching the enforcement to what the port legitimately carries.

Step 5: Audit the unused ports

Every port not in use should be administratively shut and parked in an unused VLAN:

interface Ethernet0/3
 description Unused - parked
 switchport mode access
 shutdown

In the show interfaces status output this reads as disabled, which is the correct resting state. A notconnect port that is not shut is live jack waiting for whoever finds it. The audit finding is the delta: ports that are down-but-enabled, and ports that are enabled in VLANs they have no business in. show vlan brief gives you the port-to-VLAN map to check against your addressing plan.

Step 6: Check the physical layer while you are there

SW1# show interfaces Ethernet0/2 | include duplex|MTU|CRC
  MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
  Full-duplex, Auto-speed, media type is 10/100/1000BaseTX
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

Non-zero and growing CRC or input errors mean a physical problem (cable, transceiver, duplex mismatch), and a port audit is the natural time to catch them. Clear the counters after fixing so the next audit starts from zero; the procedure is in resetting counters on Cisco switches.

The audit checklist

show interfaces status
Status per port; find undocumented, notconnect, err-disabled
show cdp neighbors / show lldp neighbors
Which ports face infrastructure; CDP off toward untrusted space
show mac address-table dynamic
MAC count per port; hunt hidden switches
show port-security (+ per interface)
Enforcement present, violations reviewed, sticky MACs saved
show vlan brief + show interfaces trunk
Port-to-VLAN map matches the plan; trunks only where intended
show interfaces <X> error counters
CRC/input errors caught while you are looking anyway

Key takeaways

A port audit is inventory (status, neighbors, MACs), enforcement (port security matched to what each port legitimately carries), and hygiene (unused ports shut and parked, errors investigated, descriptions accurate). Do it on a cadence, because port configuration decays the moment people start plugging things in. And take the err-disabled example above as the argument for the whole exercise: enforcement you configured months ago is quietly deciding what happens on your ports today, and the audit is how you find out what it decided.

Related deep dives: reading every column of show interfaces status and the practical 802.1X configuration lesson for identity-based port control beyond MAC counting.

Read next