Unmanaged Hub Outage on Cisco Catalyst: Err-Disabled Ports, Loops, and Storm Control

A few users on one office floor reported that the network was down. Their PCs could not ping the default gateway. The switch port facing the unmanaged hub they were plugged into was in the err-disabled state. This post covers how the problem was isolated, what the switch can and cannot tell you about the cause, and which Catalyst features limit the damage when an unmanaged hub misbehaves.

Quick Summary

• Observed: 3 to 5 users in one area lost network access. The gateway was unreachable from their PCs. The access switch port connected to their hub was err-disabled.
• Fix that worked: Unplug every device from the hub, keep only the uplink, clear the err-disabled state, then reconnect the devices one at a time and watch the port.
• Not recorded: The exact err-disable reason was not captured, and the switch software version was not noted. This post does not claim a root cause for that incident.
• Why it matters: A hub cannot be monitored or protected, so the switch port it hangs off is the only place to contain it.

What Was Observed

This section describes only what was seen during the incident.

1. Users in one part of a floor reported that the network did not work.
2. An unmanaged hub could not be checked remotely, so troubleshooting started at a PC. The PC could not ping its default gateway.
3. On the access switch, the port connected to the hub was in the err-disabled state.
4. All cables were removed from the hub except the uplink. The err-disabled state was cleared on the switch port.
5. Devices were reconnected one at a time, checking the port after each one.

The outage affected roughly one team, about three to five people. Device models, software versions, and the log messages from the switch were not recorded, so none are shown here as real output.

Why an Unmanaged Hub Is Hard to Troubleshoot

This part is general networking background, not something measured in the incident.

• A hub is a repeater. It sends every frame out of every other port. It does not learn MAC addresses and does not run Spanning Tree Protocol.
• It has no CLI, no SNMP, and no logs. When something goes wrong, the hub cannot tell you.
• The switch port sees the MAC addresses of every device behind the hub as if they were one connection.

Figure 1. One access port sees every MAC address behind the hub. Illustrative diagram, not measured data.

Because of this, the access port on the switch is the only control point. If the hub ends up in a loop or something behind it sends unexpected traffic, the switch port is where the symptom shows up.

How a Layer 2 Loop Turns into a Broadcast Storm

This is general background. It was not measured in the incident described above.

1. A cable, or a second device, creates a second path between two points on the same Layer 2 network.
2. A broadcast frame, such as an ARP request, is flooded out of every port in the VLAN. It reaches the loop and comes back in through another port.
3. Ethernet frames carry no hop count, so nothing removes the copy that keeps circulating. Each pass floods more copies.
4. Traffic grows until it fills the links and the switch CPU. Ordinary traffic, including packets to the gateway, is dropped or delayed.
5. The switch sees the same source MAC address arriving on different ports, which may produce %SW_MATM-4-MACFLAP_NOTIF messages.

Figure 2. General behavior of a Layer 2 loop. Not measured in the incident.

Spanning Tree Protocol exists to stop this by blocking one path. STP only works between devices that run it, and a hub does not. If a cable loops back between two ports of the same hub, no STP device sits on that path, so nothing blocks it and the flood reaches the uplink. If the hub is cabled to two ports on managed switches, the switches may see each other's BPDUs through the hub and block a port, or BPDU Guard may err-disable it. These outcomes follow from how repeaters and STP work. They are inference, not behavior confirmed for this incident.

Verification: Find Out Why the Port Is Err-Disabled

When users report an outage, confirm the port state and the reason before clearing anything. Once you reset the port, the evidence of why it failed is harder to get back.

show interfaces status err-disabled
show errdisable detect
show errdisable recovery
show logging | include ERR_DISABLE|BPDUGUARD|MACFLAP
show mac address-table interface <interface-id>
show spanning-tree interface <interface-id> detail
show storm-control <interface-id>
show port-security interface <interface-id>

show interfaces status err-disabled lists each err-disabled port together with the reason. Cisco documents this command and the show errdisable commands for Catalyst IOS XE. Output format and defaults differ between platforms and releases, so check the guide for your release.

The log lines below show the message format Cisco documents for BPDU Guard. They are a documentation example and were not taken from this incident. The exact text varies by platform, and the BPDU Guard line was not verified on Catalyst 9000.

%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Gi1/0/12 with BPDU Guard enabled. Disabling port.
%PM-4-ERR_DISABLE: bpduguard error detected on Gi1/0/12, putting Gi1/0/12 in err-disable state

A %SW_MATM-4-MACFLAP_NOTIF message is a separate signal. Cisco describes it as the switch seeing the same source MAC in the same VLAN on two ports, which often points to a Layer 2 loop. It is only a notification and does not shut the port down by itself.

What Can Put a Port Behind a Hub into Err-Disabled

The cause in the incident was not recorded. These are documented triggers that fit an access port with a hub behind it. Use them as a checklist of things to rule out.

Trigger	How it relates to a hub	How to check
BPDU Guard	A BPDU arrives on a port with BPDU Guard enabled, either globally on PortFast ports or per interface. This can happen when a switch is added behind the hub, or when a cable loops back to the same switch.	show spanning-tree interface <interface-id> detail, log message
Storm control with the shutdown action	Excess broadcast, multicast, or unicast traffic on the port crosses the configured threshold.	show storm-control <interface-id>
Port security	Port security is off by default. Once enabled, the default maximum is one secure MAC address and the default violation mode is shutdown. A hub puts several MAC addresses on one port.	show port-security interface <interface-id>

Cisco documents each of these as an err-disable cause. Which one applied in this incident is unknown.

Recovery and Isolation

To clear an err-disabled port manually, shut it down and bring it back up:

interface GigabitEthernet1/0/12
 shutdown
 no shutdown

Cisco also lets you recover automatically per cause. Recovery is disabled by default and the default interval is 300 seconds.

errdisable recovery cause bpduguard
errdisable recovery cause storm-control
errdisable recovery cause psecure-violation
errdisable recovery interval 300

Automatic recovery has a cost. If the device or cable that caused the problem is still connected, the port goes down again after each interval and users see repeated short outages. Fix the physical cause first. In this incident the method was to unplug everything, clear the port, and reconnect one device at a time. The steps below add the checks that make that method reliable:

1. Disconnect everything from the hub except the uplink.
2. Clear the err-disabled state on the switch port.
3. Confirm the port stays up with only the hub connected.
4. Reconnect one device at a time. Check show interfaces status err-disabled after each.
5. The device or cable that brings the port down again is the one to inspect.

Figure 3. Unplugging, clearing, and reconnecting one at a time was done in the incident. The dashed checks are added practice.

Prevention on Catalyst IOS XE

Which feature catches a failure depends on what the hub does. The mapping below combines Cisco documentation with general reasoning. It was not lab tested for this post.

Failure behind the hub	Control that responds
A switch, or a looped cable, sends BPDUs back to the access port	BPDU Guard
Frames circulate inside the hub and flood the uplink	Storm control, once the flood crosses its configured threshold
More devices than expected are connected behind one port	Port security maximum

The second row is inference. BPDU Guard acts only when a BPDU reaches the protected port, and storm control acts only when ingress traffic reaches its threshold. Cisco does not describe this exact scenario in the guides cited below.

A starting point for an access port. The values are examples, so baseline your own broadcast traffic before choosing thresholds.

interface GigabitEthernet1/0/12
 description ACCESS-PORT-TO-HUB
 switchport mode access
 spanning-tree bpduguard enable
 storm-control broadcast level 5.00 2.00
 storm-control action shutdown
 switchport port-security
 switchport port-security maximum 5
 switchport port-security violation shutdown

PortFast is left out of this example on purpose. Cisco's guide warns against enabling PortFast on ports that connect hubs or switches, because it can cause temporary bridging loops. Interface-level BPDU Guard works without PortFast.

For ports that connect single end hosts, global BPDU Guard on PortFast ports is configured differently depending on release. The 17.13 guide for Catalyst 9300 uses the form below, while older guides such as 16.9 use spanning-tree portfast edge bpduguard default. Check the guide for your release.

spanning-tree portfast bpduguard default

The best fix is to remove the hub. A managed access switch gives you port counters, logs, and its own Spanning Tree participation. Until then, these port limits reduce how far a misbehaving hub can spread.

Troubleshooting Checklist

• Ping the default gateway from an affected PC. If it fails, move to the switch.
• Run show interfaces status err-disabled and note the reason before clearing the port.
• Save the relevant log lines (show logging) for later analysis.
• Check the MAC address count on the port with show mac address-table interface. A large number behind one access port points to an unmanaged device.
• Disconnect all devices from the hub, clear the port, reconnect one by one.
• Decide whether automatic recovery fits your environment. If you enable it, make sure someone is alerted when a port is err-disabled.

Key Takeaway

The err-disabled port was the evidence. Before clearing it, record the reason and the logs, because an unmanaged hub gives you nothing else to inspect. Then isolate the physical cause by reconnecting devices one at a time.

References

• Cisco: Recover Errdisable Port State on Cisco IOS Platforms
• Cisco: Layer 2 Configuration Guide, IOS XE 17.13.x (Catalyst 9300) - Configuring Optional Spanning-Tree Features
• Cisco: Security Configuration Guide, IOS XE 17.15.x (Catalyst 9300) - Port-Based Traffic Control
• Cisco: Security Configuration Guide, IOS XE 17.14.x (Catalyst 9200) - Port Security
• Cisco: Troubleshoot MAC Address Flap Notification Error
• Cisco: Troubleshoot MAC Flaps/Loop on Cisco Catalyst Switches
• Cisco: Understand Spanning Tree PortFast and BPDU Guard Features

Related post: Cisco CDP Duplex Mismatch: FastEthernet Full, GigabitEthernet Half covers another cause of slow or unstable access ports on Catalyst switches.