How to Configure Port Security on Cisco Switches

Port security looks simple when you first come across it. Limit the number of MAC addresses on a switch port, decide what happens when something unexpected appears, and you are done.

In a real network, it gets more interesting.

A desktop might be straightforward, but what happens when there is an IP phone with a PC connected behind it? What happens when users move between desks, replace a laptop, connect a dock, or plug in a different device? And what happens when a port goes into an err-disabled state at 10am and nobody knows why?

That is where the configuration matters less than the design around it.

This article walks through configuring Cisco port security, including maximum MAC addresses, sticky learning, ageing, violation modes, errdisable recovery and some of the problems that tend to appear once it is deployed.

Note: Cisco IOS and IOS XE syntax and behaviour can vary between switch models and software releases. The examples below use a Catalyst-style interface such as GigabitEthernet1/0/10.

What Cisco port security actually does

Port security allows you to control which MAC addresses can use a switch port.

Without port security, a normal access port will learn MAC addresses through the switch’s forwarding process. Port security adds another layer of control by allowing you to define a maximum number of secure MAC addresses and what should happen when an unexpected MAC address appears.

For example:

• A normal desktop port might allow one device.
• A port connected to an IP phone with a PC behind it may need two MAC addresses.
• A meeting-room port may need a different approach because different users connect to it throughout the day.
• A port in a controlled environment may use statically configured MAC addresses.

The important part is deciding what the port is actually expected to look like.

The defaults matter here. On Cisco switches, port security is disabled by default, and when you enable it the default maximum is one secure MAC address with a violation mode of shutdown. That combination is exactly the one that causes an outage on a phone-and-PC port.

Start with the physical design

Before configuring port security, look at what is physically connected to the port.

A simple desktop might look like:

Switch
  |
  PC

But a typical VoIP deployment may look like:

Switch
  |
  IP Phone
  |
  PC

That second arrangement immediately changes the configuration.

If you configure the port for a maximum of one secure MAC address, the phone may learn successfully but the PC could trigger a violation.

This is one of the easiest ways to create an outage with an otherwise correct port-security configuration.

Check the port before making changes

Start by looking at the existing configuration and interface state.

Switch# show running-config interface GigabitEthernet1/0/10
Switch# show interfaces GigabitEthernet1/0/10 status

You want to know:

• Is the port an access port?
• Which access VLAN is being used?
• Is there a voice VLAN?
• Is anything already connected?
• Is port security already configured?
• Are there existing switchport settings that need to be preserved?

Port security should be added to an understood configuration rather than treated as an isolated command.

Enable port security

For a basic access port:

Switch# configure terminal
Switch(config)# interface GigabitEthernet1/0/10
Switch(config-if)# switchport mode access
Switch(config-if)# switchport port-security

The first two commands are not strictly about port security itself. They make the intended role of the interface explicit.

The switchport mode access line does matter, though. A port left in its default dynamic mode can’t be configured as a secure port, so setting the mode explicitly isn’t optional.

You can then decide how many secure MAC addresses the port should allow.

Set the maximum number of MAC addresses

For a straightforward desktop:

Switch(config-if)# switchport port-security maximum 1

That tells the switch that the port should have one secure MAC address.

For a phone with a PC connected behind it, two may be required:

Switch(config-if)# switchport port-security maximum 2

Some Cisco platforms also provide VLAN-aware variations, for example:

Switch(config-if)# switchport port-security maximum 1 vlan access
Switch(config-if)# switchport port-security maximum 1 vlan voice

The exact VLAN-aware syntax and behaviour varies by platform, so this is one of the places where I would check the documentation for the switch model and IOS/IOS XE release before deploying it.

The broader point is that maximum 2 is not automatically the right answer for every phone port. You need to understand how that particular switch handles secure MAC addresses across the access and voice VLANs.

Static MAC addresses versus sticky MAC learning

You have two common ways of defining secure MAC addresses.

Static secure MAC addresses

You can explicitly configure a MAC address:

Switch(config-if)# switchport port-security mac-address 0011.2233.4455

This gives you a very controlled configuration, but it also creates an administration problem if the device is replaced.

Sticky MAC addresses

Sticky learning allows the switch to learn the MAC address and add it to the running configuration:

Switch(config-if)# switchport port-security mac-address sticky

You can then check what has been learned with:

Switch# show port-security interface GigabitEthernet1/0/10
Switch# show port-security address

There is an important operational detail here.

A sticky MAC learned into the running configuration does not automatically mean it will survive a reload. To preserve dynamically learned sticky addresses across a reboot, you have to write them to the startup configuration after they have been learned:

Switch# copy running-config startup-config

That also means you should think about what happens when the device connected to the port changes.

A user replacing a laptop can leave the old sticky MAC address in the configuration. The new laptop then appears to be an unauthorised device even though it is perfectly legitimate.

That is where ageing can sometimes help.

MAC address ageing

Cisco switches can support secure MAC address ageing using commands such as:

Switch(config-if)# switchport port-security aging time 120
Switch(config-if)# switchport port-security aging type inactivity

Inactivity ageing is particularly useful in environments where devices move between ports, such as hot-desking areas or meeting rooms.

The switch can remove an aged secure address after the configured period of inactivity rather than leaving it there indefinitely.

There is an important limitation with sticky MAC addresses, however. Many Cisco platforms do not support ageing sticky secure addresses in the same way as dynamically learned secure addresses.

So don’t assume that adding an ageing timer will automatically solve stale sticky MAC addresses. Check the behaviour for the platform you are deploying.

What happens when a violation occurs?

This is where port security becomes an operational decision rather than just a configuration exercise.

Cisco’s violation modes differ in more than just whether the port shuts down. They also differ in whether you find out at all.

That table is worth reading carefully, because it corrects a common misunderstanding.

protect is completely silent. No trap, no syslog, not even a violation counter. Traffic simply disappears. If you deploy protect mode, you will not know a violation has occurred unless you happen to be looking at the port when someone complains.

restrict is the only mode that notifies you through every available mechanism while keeping the port up.

shutdown disables the port and increments the counter, but doesn’t send a trap or syslog message in the same way restrict does. You find out because the port is down.

shutdown vlan is worth knowing about on platforms that support it. Instead of disabling the entire interface, it error-disables the offending VLAN. On a phone-and-PC port, that can mean the data VLAN is disabled while the phone continues working, which is a considerably better outcome than losing both.

Configure the mode explicitly:

Switch(config-if)# switchport port-security violation restrict

Or:

Switch(config-if)# switchport port-security violation shutdown

A security control that shuts down a port can also become a support incident if the reason for the violation isn’t understood. Equally, a control that silently drops traffic and tells nobody isn’t providing much security value either.

Errdisable recovery

When port security uses the shutdown violation mode, a violation can put the interface into an err-disabled state.

You can enable automatic recovery for port-security violations:

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

The 300 is the recovery interval in seconds.

One important detail that is easy to miss: the errdisable recovery interval is global, not a separate timer for each individual cause.

You can check the configured recovery behaviour with:

Switch# show errdisable recovery

If the interface has already been disabled, manual recovery can be performed with separate commands:

Switch# configure terminal
Switch(config)# interface GigabitEthernet1/0/10
Switch(config-if)# shutdown
Switch(config-if)# no shutdown

Cisco’s guide to recovering an errdisabled port covers the causes and recovery process in more detail.

Automatic recovery is useful, but it should not replace finding out why the violation occurred. If a genuine unauthorised device is repeatedly appearing on the port, automatically bringing the port back every five minutes does not solve the underlying problem.

Troubleshooting a port-security violation

When someone tells you a switch port has stopped working, I would start with the interface state rather than immediately changing the configuration.

Switch# show interfaces status err-disabled

Then inspect the port-security configuration:

Switch# show port-security interface GigabitEthernet1/0/10

And look at the secure MAC addresses:

Switch# show port-security address

Finally, check whether errdisable recovery is configured:

Switch# show errdisable recovery

This gives you a much clearer picture of what the switch thinks is happening.

The switch will also log the violation. A port-security violation typically produces messages along these lines:

%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by
MAC address aaaa.bbbb.cccc on port GigabitEthernet1/0/10
%PM-4-ERR_DISABLE: psecure-violation error detected on Gi1/0/10, putting
Gi1/0/10 in err-disable state

That first line is the useful one. It tells you the MAC address that caused the violation, which is where the investigation actually starts.

Be careful with clear port-security

There is also a command that sometimes gets suggested when troubleshooting:

Switch# clear port-security all

Don’t treat this as a simple way of resetting port-security counters.

clear port-security all removes static, sticky and dynamically learned secure MAC addresses from the address table. On a port using sticky learning, that means clearing the addresses the port was relying on.

If you only want to clear dynamically learned addresses, the narrower command is:

Switch# clear port-security dynamic

If the problem is a stale sticky MAC address, understand exactly what you are clearing before running either.

The IP phone and PC problem

VoIP is probably the easiest example of why port security needs to match the physical network.

A typical phone port might look something like:

interface GigabitEthernet1/0/10
 switchport mode access
 switchport access vlan 20
 switchport voice vlan 30
 switchport port-security
 switchport port-security maximum 2
 switchport port-security violation restrict
 switchport port-security mac-address sticky

The exact configuration depends on the switch platform and the way your voice network is designed, but the principle is straightforward.

There may be two devices using the physical port:

Switch
  |
  IP Phone
  |
  PC

If you configure the port for one MAC address without considering that arrangement, the second device can trigger the violation.

This is why I would not roll out port security by simply applying the same configuration to every access port.

Laptops, docks and changing devices

Modern desktop environments make static port-security policies harder to maintain.

A user might have:

• A laptop
• A USB-C dock
• A desktop
• An IP phone
• A conference-room device
• A virtual machine using additional MAC addresses

A port that was originally designed for one physical desktop may eventually have a completely different usage pattern.

Sticky learning makes deployment easier because you don’t have to manually enter every MAC address. The trade-off is that the switch is learning and retaining the environment you give it.

If the environment changes frequently, you need a process for dealing with those changes.

Auditing port security

After deploying port security, the configuration should be auditable.

Useful commands include:

show port-security
show port-security interface GigabitEthernet1/0/10
show port-security address

For a larger environment, you could periodically collect this information and compare it against your expected port assignments.

That can reveal things such as:

• Ports with more secure MAC addresses than expected
• Unexpected secure MAC addresses
• Ports with repeated violations
• Sticky addresses that no longer match the assigned device
• Ports where port security has been configured differently from the standard

This is where port security becomes much more useful than simply adding a few commands to a switch template.

Port security versus 802.1X

Port security is a relatively blunt control. It tells the switch which MAC addresses are allowed, but a MAC address is not a strong identity mechanism.

802.1X approaches the problem differently by authenticating the client.

For environments where you need identity-based network access control, 802.1X may be more appropriate than relying solely on port security.

There is also an important platform consideration here. Support for combining port security and 802.1X varies between Cisco platforms and software releases, and some current Catalyst documentation explicitly places restrictions on using them together.

So this isn’t a case of simply enabling both because they sound complementary. Decide which control is providing the access decision and verify the supported design for the platform.

Port security still has useful applications where you want a relatively simple control over unmanaged access ports, but it shouldn’t automatically be treated as a replacement for an identity-based access-control system.

When to stop adding exceptions

The configuration itself is not particularly complicated. The difficult part is deciding whether the policy still makes sense as the network changes.

A useful way to approach a deployment is:

1. Understand what should physically be connected to the port.
2. Set the MAC limit around that design rather than using the same number everywhere.
3. Decide whether static or sticky learning makes sense.
4. Choose the violation mode based on the operational consequence of getting it wrong.
5. Consider ageing where devices genuinely move between ports.
6. Configure errdisable recovery deliberately rather than blindly enabling it.
7. Have a way to identify and clean up stale sticky addresses.
8. Use 802.1X where identity-based access control is the actual requirement.

The biggest mistake is treating port security as a configuration template rather than a control that needs to reflect how the port is actually used.

A single desktop port, a phone-and-PC port and a hot-desk port can all require different decisions.

Once you start thinking about the physical device arrangement, MAC learning, violation behaviour and how the support team will recover a blocked port, the Cisco commands become the easy part.

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.