A small switch is added to give a desk more Ethernet ports. Soon several users lose access, phones disconnect and Wi-Fi appears unreliable too. The internet provider may be healthy: a local switching loop is one possible explanation that deserves investigation.
A network loop can let traffic circulate through unintended redundant paths. Symptoms alone do not prove it. This guide explains what an office manager should preserve and ask an authorised network administrator to check, without turning a live outage into an uncontrolled cabling experiment.
The artwork illustrates an unwanted redundant path conceptually. It is not a wiring instruction or a photograph of a client network.
Record the last physical change
Identify when the disruption started, which areas are affected and what was connected immediately beforehand. Note the desk switch, wall sockets, patch-panel labels and any extra cable. Keep a photograph or sketch for the administrator, with sensitive labels redacted before external sharing.
Do not reconnect an unfamiliar cable just because it appears unused. Two wall sockets can return to the same upstream network. Wireless bridges and other devices can also create paths that are not obvious from the desk. A simple device list is less useful than a map showing where each connection goes.
Distinguish a loop hypothesis from other faults
Ubiquiti's network-loop guidance describes disruption from circulating traffic and explains how STP or RSTP can block redundant paths. A port in a blocking state may therefore be doing its intended protective job, rather than indicating failed hardware.
Ask the administrator to compare the timeline with switch events, port state and traffic observations. Other causes include a failing cable, power loss or incorrect VLAN configuration. If only new devices fail while existing devices work, the DHCP address-pool guide covers another hypothesis. Avoid declaring a loop from one symptom.
Use a controlled isolation plan
A proposed incident sequence is to preserve the available evidence, identify the recently changed edge segment and agree a reversible isolation step. The administrator should know what will be disconnected and what business function depends on it, including phones, cameras or payment devices.
Where evidence points to the new desk connection, removing that identified path may help narrow the fault. Record the result rather than repeatedly unplugging unrelated uplinks or rebooting every switch. If the network has intentional redundancy or link aggregation, treat it as a designed topology that needs review, not as spare wiring to remove blindly.
A review of office switching, cabling and loop protection can establish the topology and recovery plan. Request an Office Switching Review with the affected area, switch models and recent changes.
Check protection settings before re-enabling a port
UniFi's switch-settings reference distinguishes global, device and port controls. Confirm the actual hardware and software capabilities, including any unmanaged or third-party switches, before applying a general recommendation.
The loop guidance also distinguishes STP from UniFi Loop Protection. Loop Protection can keep a port disabled until administrator intervention. Identify and correct the triggering condition before re-enabling it; repeatedly restoring the port can reintroduce the fault. Do not disable protection merely to clear an alert.
Ask which switch should be the topology's root and which connections are intended for end devices or downstream switches. Root priorities, edge settings and guarding need an administrator's design review. Copying another site's port settings without that context can cause a different outage.
Make the evidence reach an owner
UniFi Alarm Manager supports scoped events and notification actions, including a switch-port loop example. Availability depends on the installed platform and version. Agree who receives relevant alerts, how they reach that person and what the response procedure is.
An alert configuration is not proof of notification delivery. Validate the monitoring route using an approved method that does not create a real loop on the production network. If evidence was unavailable during the incident, record that limitation and improve readiness for the next investigation.
Verify recovery and prevent the same cabling mistake
After the approved fix, verify representative staff devices and the affected business applications. Record remaining blocked ports, topology changes and any services still degraded. A phone reconnecting is useful evidence, but does not establish that every network segment has recovered.
Label the relevant sockets and uplinks, document approved desk switches and give staff a clear way to request additional ports. Include capacity and power in that plan; the PoE power-budget guide covers devices that depend on switch power.
Request an Office Switching Review to discuss the cabling map, switch roles, protection settings and incident evidence. Share a description through the form below rather than router passwords or an unredacted network configuration.
Official Ubiquiti documentation reviewed 22 October 2026. The incident sequence is proposed review guidance, not a diagnosis or a substitute for an authorised network change plan.
