How to Diagnose a Home Network After Router Failure

After a router or access-point failure, diagnose the local network from the bottom up: power, links, switching, DHCP, DNS, Wi-Fi, discovery, and only then the internet service. A speed test cannot validate the layers below it.

What the lightning actually removed

The failed equipment was doing more than passing internet traffic. My MikroTik hAP ac² had been the router, and a MikroTik cAP supplied part of the wireless layer. Both went out in the same incident. The temporary arrangement moved gateway and DHCP duties to the AT&T BGW320-505. An older MikroTik RB2011 stayed in service only as an unmanaged stand-in switch, with its DHCP server disabled.

That distinction matters. The BGW320 could hand out addresses, route traffic, and hold the required port forwards. The RB2011 could connect Ethernet devices. Neither fact meant the previous topology, wireless coverage, DNS behavior, monitoring, or recovery path had magically returned.

A speed test collapses all of that into one attractive number. If a laptop can reach a nearby test server at several hundred megabits per second, the result says the path between that laptop and that server was fast for the duration of the test. It says nothing about a difficult Wi-Fi room, local DNS, or whether Home Assistant can still find an ESP32 light.

Home Assistant makes the local network visible

My house has devices that are useful precisely because their control path is local. The Lutron Caséta integration is classified by Home Assistant as Local Push. The WLED integration normally receives real-time updates from each ESP32 controller over a local WebSocket connection. Bond, Matter devices, HomeBase 3, and the Eufy Omni S2 add their own discovery and availability assumptions.

Those devices do not become healthy because a browser can load a website. Home Assistant can have internet access while a WLED controller is stranded on the wrong wireless segment. A phone can stream video while multicast discovery fails. A Matter device can remain powered while the controller that gives it useful context cannot reach it.

This is why I separate “the internet is up” from “the house is working.” The first asks whether traffic can leave the property. The second asks whether local clients received the right configuration and can reach the local services and devices they need.

The dependencies have an order

One of my WireGuard clients exposes a less obvious version of the problem. Its peer is configured with a hostname rather than a fixed address. At boot, wg-quick has to resolve that hostname before it can bring up the tunnel. A routable address alone is not enough; DNS also has to be ready.

The machine now has a small retry service ordered after both network-online.target and nss-lookup.target. It restarts on failure after a short delay. The retry exists because a passive peer cannot repair a tunnel that never established an endpoint in the first place.

Systemd describes network-online.target as the point at which the network manager considers a configured, routable address available. That is useful, but it is not a promise that every upstream dependency is responsive. The retry handles the remaining gap without pretending that “online” means “all name resolution and remote services are ready.”

This is a small detail until a reboot follows an outage. Then it is the difference between a tunnel returning by itself and a tunnel staying down until someone notices.

Dynamic DNS is another control loop

I also treat dynamic DNS as a separate service, not a property of the fiber connection. Two clients check and update the home WAN records on staggered five-minute schedules. Staggering prevents both from reacting at the same instant, while duplication keeps one host failure from silently freezing the records.

That design still has boundaries. A working update client does not prove the router forwards the required traffic. A correct public record does not prove the local resolver returns the intended answer from inside the house. A port forward does not prove the destination service is listening. Each layer can be right while the complete path is wrong.

Two DNS servers can create an intermittent house

My Pi-hole incident supplied the cleanest example. One resolver allowed a domain that I needed; the other still blocked it. Clients were given both resolvers, so the same request could work or fail depending on which server answered. The internet connection was healthy throughout.

Adding more DNS servers is not redundancy when they enforce different policy. It is nondeterminism. I now treat resolver configuration as replicated infrastructure: the important question is not merely whether both servers respond, but whether both return the same intended result.

The same principle applies to DHCP. Two accidental DHCP servers do not make address assignment more reliable. They create a race between potentially different gateways, DNS servers, and lease policies.

My outage sequence starts below the speed test

I check the path in dependency order. That keeps a failed name lookup from turning into an hour of router replacement guesses.

The order is not sacred, but the separation is. If a client cannot reach its local gateway, changing public DNS is noise. If it can reach a public address but not a hostname, buying a faster access point is noise. If Home Assistant can reach a device by address but discovery fails, the problem is likely in multicast handling or segmentation rather than bandwidth.

A temporary network should say that it is temporary

The current arrangement also taught me not to let emergency roles become invisible architecture. The provider gateway is now the authority for leases and forwarding. The older MikroTik is intentionally just a switch. The failed router remains in the inventory as expected-unreachable history, not as a target that automation should keep trying to configure.

Those labels prevent a future change from making a bad assumption. If an Ansible play treated the stand-in switch as the active router, or if a monitoring alert kept reporting the lightning-damaged unit as a surprise outage, the configuration would describe the network I used to have rather than the one carrying traffic today.

I want the permanent replacement to restore deliberate ownership: one documented place for routing and leases, access points placed for the building, resolver policy that matches on both servers, and a recovery procedure that does not depend on remembering which box inherited which emergency job. Until then, the temporary state stays explicit. That makes it less elegant on paper and much safer to operate.

What I would buy next—and what I would not

I would not choose a replacement router or access point from an internet-speed headline. Before buying, I need the physical coverage problem, Ethernet and PoE needs, VLAN plan, port count, provider-gateway boundary, configuration backup, and replacement procedure written down. The best hardware is the hardware that fits those requirements and can be restored after the next failure.

I also would not pay for a faster fiber tier to solve a room with weak Wi-Fi. That purchase changes the ceiling on the provider side of the gateway. It cannot change walls, access-point placement, radio interference, or the path between two local devices.

The temporary BGW320 and RB2011 arrangement is intentionally boring. It restores basic service while I decide what the permanent network must own. That is better than making a rushed affiliate-shaped hardware recommendation after a lightning strike. I will name a replacement model only after the requirements and the installed result are real.

The useful definition of “up”

For this house, “up” means more than a successful speed test. Clients need stable leases. Both DNS servers need matching policy. Home Assistant needs local reachability to Lutron, WLED, Bond, Matter, and the Eufy equipment. Remote access needs DNS and WireGuard to recover after boot. The pieces need to fail in a way I can diagnose.

Fiber is still valuable. It gives the network a fast external connection. The mistake is asking that connection to compensate for everything behind the gateway. Lightning made the boundary unusually obvious: the fast pipe was only one component, and it was not the component I had lost.

What I measured and what I did not

The system behavior in this article comes from a read-only review of my current private home-infrastructure repository and its incident notes. The startup distinction is cross-checked against systemd’s official network-online documentation. The local-device behavior is cross-checked against Home Assistant’s official Lutron Caséta and WLED integration documentation.

I did not change the gateway, reboot the WireGuard client, simulate another outage, test wireless coverage, or benchmark the fiber connection for this article. I omitted private addresses, hostnames, tunnel endpoints, DNS record names, and credentials. The outage date, failed hardware, temporary roles, retry behavior, and staggered update design come from the maintained configuration and notes rather than a fresh destructive test.