I have written about my tiny yet powerful homelab before. It runs quite a few things for my home, including Pi-hole and a Kubernetes cluster, so when its network goes down I notice it very quickly!
This time the trouble started with an unexpected power trip. After I restored the power, the homelab network did not come back. There was no obvious error anywhere. My routers were online, the modem had reconnected and all the usual lights looked normal. But services were still unreachable and my Kubernetes control plane could not start properly.
I started spot-checking the network configuration and noticed that the DHCP advertisement was wrong. One of my Ubuntu VMs had received a completely different IP address, gateway and DNS server. That was a useful clue, but I still had no idea which device was sending it or why.
So I asked Amp to investigate.
Amp connected to the VM over SSH and checked its addresses, routes and DHCP lease. It then went through the old system logs and found a very clear before and after. Before the power trip, the VM always received its reserved address from my main router. After the power came back, another device started giving it two-minute leases with the wrong gateway and DNS server.
At first I suspected Pi-hole, because it can also run a DHCP server. Amp checked its configuration and backups and ruled that out. It then identified the unexpected DHCP server as one of my TP-Link powerline extenders.
It turned out that the extender has a feature called Smart DHCP. If it cannot find another DHCP server, it starts one by itself to make initial setup easier. During the recovery from the power trip it could not see the router’s DHCP service, so it began handing out its own network configuration. Everything looked online, but devices were quietly being told to use the wrong gateway and DNS server.
Amp also worked out that the Kubernetes failure was not a separate problem. The control plane was configured with the VM’s reserved address, but that address no longer existed on the VM. Kubernetes quite rightly refused to start its networking.
After I disabled Smart DHCP on the powerline extender and rebooted the VM, Amp checked everything again. The lease was coming from the correct router, the VM had its reserved address and gateway, Pi-hole was resolving DNS, and every Kubernetes node was healthy again.
Without Amp, I would probably have spent hours rebooting devices and changing settings one by one. Instead, it followed the evidence from DHCP to Linux networking, Pi-hole and finally Kubernetes, then made sure the fix really worked.
What a gem! This is exactly the sort of problem where an AI coding agent is surprisingly useful. It did not just give me a list of commands to try. It investigated the actual machines, connected all the symptoms and stayed with the problem until my homelab was back.
Also, stay tuned! A version 2 build of my homelab is already in progress. I will write more about the new setup, what I am changing and everything I learn from rebuilding it from scratch.