Goal
Produce accurate, current documentation of my home network: what devices are connected, what IPs they hold, how DNS resolves names, and what the traffic path looks like from a device to the internet.
Environment
- ISP: Verizon (home broadband)
- Router/Gateway: Verizon-provided router
- Subnet: 192.168.1.0/24
- Desktop PC — wired ethernet
- Raspberry Pi 4 — wired ethernet, static lease
- Personal devices — wireless (phone, tablet)
Network topology
Discovery process
Ran ipconfig /all on the desktop to note the IP, subnet mask, default gateway (192.168.1.1), DNS servers, and MAC address. This is always step one — know where you are before mapping anything else.
Ran arp -a to see all devices the machine had recently communicated with. Cross-referenced MAC prefixes to identify device types — router, Pi, phones.
Logged into the Verizon router admin panel (192.168.1.1) and pulled the DHCP lease table. This gave hostnames alongside IP and MAC — filled in gaps the ARP table left, and confirmed which devices were wired vs. wireless.
The Raspberry Pi needs a consistent IP since it's running Nginx and accepting SSH connections. Set a static reservation in the router tied to the Pi's MAC address so the address persists across reboots and lease renewals.
Used Resolve-DnsName google.com to confirm DNS was working through the router, and Resolve-DnsName raspberrypi.local to verify mDNS resolution of the Pi's hostname without needing to memorize its IP.
Used tracert 8.8.8.8 to see the hop from the PC → Verizon router → ISP → Google. Confirmed there's a single internal hop before leaving the LAN.
Commands run
# Step 1 — Local adapter info ipconfig /all IPv4 Address: 192.168.1.100 Default Gateway: 192.168.1.1 DNS Servers: 192.168.1.1 # Step 2 — ARP table (who's on the LAN) arp -a 192.168.1.1 (router) — Verizon gateway 192.168.1.42 (Pi) — dc-a6-32-xx-xx-xx # Step 5 — DNS resolution Resolve-DnsName raspberrypi.local Name: raspberrypi.local → 192.168.1.42 # Step 6 — Trace path to internet tracert 8.8.8.8 1 <1ms 192.168.1.1 (Verizon router) 2 14ms x.x.x.x (Verizon ISP hop) 3 15ms 8.8.8.8 (Google DNS) # Ping sweep — find all active hosts in /24 1..254 | ForEach-Object { Test-Connection "192.168.1.$_" -Count 1 -Quiet }
Screenshots
Key findings
The Verizon router is the single point for DHCP leases and DNS forwarding. All client DNS queries go to 192.168.1.1, which forwards upstream to Verizon's resolvers. Devices don't query external DNS directly.
The Raspberry Pi's IP (192.168.1.42) is pinned via a DHCP reservation tied to its MAC address. Won't shift on reboot or lease renewal — safe to use as a consistent SSH and web server target.
All devices share a single 192.168.1.0/24 subnet — the Pi, desktop, phones, and any IoT devices are on the same broadcast domain. VLANs would be the right next step if the lab grows or IoT devices are added.
What I learned
arp -a shows devices your machine has recently talked to. A ping sweep first, then re-run ARP, fills in the rest of the subnet.
Setting a DHCP reservation in the router is cleaner than hardcoding an IP on the Pi — the router stays in control of addressing, and the Pi's config doesn't need touching.
I assumed traffic went directly from my router to Google. tracert showed an ISP intermediate hop I hadn't accounted for — useful for understanding where latency actually comes from.
Writing this up as a handoff doc forced me to verify every detail rather than assume. Found two devices I'd forgotten were connected and one IP I had listed wrong.