I just spent a while learning (the hard way) about Cisco Port Security, so here's what I got out of it.

Cisco Port Security, when enabled, keeps a whitelist of allowed MAC addresses for each port; the list may hold 1 or more entries, and might be statically specified by an administrator or automatically 'learned' by the switch.

Intuitively, you might expect something called "port security" to prevent unapproved hosts from sniffing traffic, as this is the most serious risk. The reality, however, is that the switch has no way of knowing who's listening to a port, only of knowing who's transmitting individual packets, because each packet is 'signed' with the transmitter's MAC address. With PS enabled, the switch silently drops packets from unapproved MACs, preventing them from stealing bandwidth or actively attacking the network. These are useful, but data and credential sniffing are more serious risks, and are not addressed.

Complications

  1. Front-line support may have limited knowledge of security protocols and mechanisms, and is unlikely to have access to directly check the list of banned MACs/ports. Cisco provides a mechanism for alerting, but that does not mean notifications have been configured to reach all the concerned parties.
  2. Sniffing to determine the situation will show the host generating outbound traffic, but will not reflect that these packets are not being forwarded to any other hosts.
  3. Depending on situation, even after PS activates, there may be residual traffic for the blocked device. This can look like responses to current traffic, and mask the fact that the muzzled node is in fact mute.
  4. Using DHCP seems to avoid some of this. I found that using DHCP got an address and enabled full communications. I don't know why.

As Murphy would have it, I had just opened up the server chassis and enabled ipf before PS tripped, so I spent a lot of time looking for a (missing) misconfiguration.

See Also