An intermittent connectivity outage is one of the costliest incidents to solve on a business network: by the time the engineer arrives, service has usually come back and there’s no evidence of what happened. The usual outcome is a precautionary reboot or a complaint to the carrier, without finding the root cause.
This guide describes the method we use to narrow an outage down layer by layer, and the seven causes we find most often in office infrastructure: from the WAN link to the power supply of the network equipment.
Causes covered
- WAN link outage or instability.
- DNS resolution failures.
- DHCP scope exhaustion and addressing conflicts.
- Layer 2 loops and broadcast storms.
- Resource exhaustion on the perimeter firewall.
- Brief power dips and network equipment restarts.
- Disconnections limited to the wireless network.
First step: characterise the outage
The most valuable information is gathered during the outage itself, not afterwards. Before restarting anything, answer four questions, which on their own rule out most hypotheses:
- Scope: does it affect the whole office, one floor, a specific switch or isolated users? Wired and wireless devices alike?
- Services: is it only internet access that’s lost, or internal resources too (file servers, printers, IP telephony)?
- Name versus IP: does an external destination respond by IP address (for example, a ping to a public resolver) even though websites won’t load by name?
- Time pattern: exact start and end time, duration and whether it repeats at particular times. Correlating that afterwards with the firewall, switch and controller logs is what closes the diagnosis.
As a rule of thumb: if internal resources are lost too, the problem is in the LAN (causes 3, 4 and 6); if the LAN works and the internet fails, it’s in the WAN, DNS or firewall (causes 1, 2 and 5); if only wireless users are affected, it’s the Wi-Fi (cause 7).
1. WAN link outage or instability
It’s the most obvious cause, but it doesn’t always show up as a complete outage. Drops of a few seconds, loss of sync on the carrier’s ONT or router, and bouts of packet loss or high latency in the carrier’s network cause VPN disconnects, broken video calls and cloud app sessions that close, without the link ever showing as down.
Diagnosis: check the WAN interface event log on the firewall or router (state changes, renegotiations, PPPoE or DHCP session renewals) and set up continuous ICMP monitoring against both the carrier’s gateway and external destinations. If loss appears at the first hop, the problem is in the access line; if only further out, it’s in the carrier’s network. The structural fix is a second link from another carrier, with automatic failover or SD-WAN.
2. DNS resolution failures
From the user’s point of view, a DNS failure is indistinguishable from an internet outage: nothing loads. Typical causes are a single internal DNS server with no redundancy (often the domain controller), forwarders pointing at slow or unstable resolvers, or clients receiving a DNS server via DHCP that no longer exists. In Active Directory environments, an internal DNS failure also affects authentication and access to shared resources.
Diagnosis: during the incident, check whether there’s connectivity by IP but not by name. Run queries with nslookup or dig against the client’s configured DNS, the internal DNS and a public resolver, comparing results and response times. The correct setup includes at least two internal DNS servers, redundant forwarders and a DHCP server that hands out both.
3. DHCP scope exhaustion and addressing conflicts
When the DHCP scope runs out, new devices get no address and have no connectivity, while the rest of the office works normally. It’s common on networks where guests, phones and IoT share a segment with corporate devices, with long lease times. IP conflicts, for their part, appear when static addresses are assigned inside the dynamic range, and cause intermittent drops that are hard to reproduce.
Diagnosis: a client with a self-assigned address (169.254.x.x) hasn’t obtained a lease. Check scope usage, lease time and whether there are static addresses inside the range, and look at the conflict logs on the DHCP server or switch. The fix is to segment into VLANs with properly sized scopes, put guests on short leases and document reservations.
4. Layer 2 loops and broadcast storms
A patch cord linking two sockets on the same network, an unmanaged switch under a desk or a video conferencing unit with two bridged interfaces is enough to create a loop. Without protection, broadcast traffic multiplies until it saturates links and switch CPUs, and the whole network stops responding on and off. It’s one of the causes that takes longest to identify if you don’t know the symptom.
Diagnosis: LAN-wide outages, constant activity on every port and high switch CPU point to a loop. Check the spanning tree topology change logs, MAC flapping messages and per-port broadcast counters. Prevention is configuration: RSTP or MSTP properly deployed, BPDU guard on user ports, storm control and removing unmanaged switches from the access layer.
5. Resource exhaustion on the perimeter firewall
An undersized firewall, or one with every inspection feature switched on, can run out of CPU, memory or session table at peak times. The symptom is distinctive: existing connections keep working while new ones fail or are slow to open, or latency jumps suddenly. Headcount growth, adopting cloud apps or an infected device opening mass connections can trigger it.
Diagnosis: check the firewall’s CPU, memory and concurrent session history and compare it with the model’s specifications for the security features in use, not the headline catalogue throughput. Identify the hosts with the most open sessions. If the unit runs close to its limit for sustained periods, adjust the inspection policies or resize.
6. Brief power dips and network equipment restarts
A power dip lasting a fraction of a second can go unnoticed by the lights and still restart a switch, the firewall or the carrier’s ONT. The resulting outage lasts as long as the device takes to boot, often several minutes, and is usually blamed on the carrier. Failing power supplies and heat problems in unventilated racks produce the same symptoms.
Diagnosis: check each network device’s uptime: if one restarted at the time of the outage, the cause is power or hardware, not the network. Check boot logs and temperature and power supply alarms. All critical equipment, including the carrier’s ONT, should be protected by a UPS with known runtime that’s checked regularly.
7. Disconnections limited to the wireless network
If wired devices stay connected and only wireless ones drop, the problem lies in the Wi-Fi. Common causes are authentication failures against the RADIUS server on 802.1X networks, key renewals some clients handle badly, poor roaming between access points, occasional interference or access points restarting for lack of PoE budget.
Diagnosis: on the controller or management platform, check association, deauthentication and authentication failure events for the affected clients, together with the APs’ uptime. If the failures line up with authentication, check the RADIUS server’s availability and response times. Performance problems, as opposed to outages, are covered in our guide on slow corporate Wi-Fi.
No logs, no diagnosis
Intermittent outages are only solved with data from the moment they happen. Sending firewall, switch and controller logs to a central syslog server, syncing every device’s clock via NTP and monitoring availability continuously turns an incident you can’t reproduce into a problem with an identifiable cause.
When specialist help is needed
If outages keep happening with no identified cause, the first step is to instrument the network. With network monitoring we continuously collect availability, latency, interface status and events from every device, so each outage can be correlated with its cause and, often, anticipated.
When the cause is structural, we tackle it through design: WAN redundancy, DNS and DHCP with no single points of failure and layer 2 protection in the network architecture, and a properly sized perimeter in network security.
For a first view of the overall state of your infrastructure, you can use our network self-assessment: twelve checks we review at the start of any audit.