When reset doesn't ... reset?

Mon, 03 Aug 2026 00:00:00 +0000

A friend asked me to change his WiFi password — too many neighbors had it, and he suspected they were leeching off him. Simple enough, except he’d forgotten the router’s admin login. No problem, I thought. Factory reset, use the default credentials printed on the sticker, done in two minutes.

It was not done in two minutes.

Attempt One: Reset That Wasn’t

I held the reset pinhole until all the lights on the router blinked off, let go, and waited for it to come back up. Once it did, I tried the default credentials from the sticker.

They didn’t work.

Weirder — the PC plugged directly into the router via LAN cable had no internet either. Not WiFi, not wired, nothing. That’s the part that actually stumped me for a bit, because a dead WiFi password is one thing, but a wired PC losing connectivity too meant something deeper was off.

Here’s what I didn’t realize at the time: holding the reset button until the lights go out just means the router rebooted — it doesn’t confirm a factory reset actually happened. Most consumer routers need the button held for a specific duration (often 10+ seconds, sometimes longer) before they actually wipe the NVRAM config. A shorter hold can just power-cycle the device instead of resetting it.

So I wasn’t logging into a fresh, default router at all. I was logging into the exact same router, with my friend’s forgotten custom password still fully intact. The default creds never had a chance of working.

Attempt Two: Actually Waiting

Second try, I held the button for a genuinely long time — well past the point where the lights went out — and then just… waited. Didn’t touch anything.

A minute or two later, a YouTube tab that had been sitting open the whole time suddenly started playing audio on its own. Nobody clicked anything. The network had just quietly come back to life in the background.

That’s DHCP doing its job. Here’s the sequence that was actually happening, invisibly, the whole time:

The reset genuinely wiped the config this time, restoring the router to factory defaults — which is why the sticker credentials finally worked.
DHCP service takes time to come back online after a real reset — not just the interface, but the actual service that hands out IP addresses.
The PC’s DHCP client was sitting there requesting a lease the entire time and getting nothing back, because the router’s DHCP server wasn’t up yet to respond.
The moment the DHCP server came online, it answered the PC’s next DHCP request, handed out a lease, and the PC silently picked up a valid IP — no reconnect, no manual renewal, nothing. The song just started because the network stack quietly finished its job in the background.

The Actual Lesson

The mistake wasn’t router weirdness — it was assuming a short button hold equals a full reset, when the first attempt was really just a reboot. And even after a genuine reset, DHCP lease negotiation and service startup aren’t instant; they take real time that’s easy to mistake for “something’s broken” when really it’s just “something’s still booting.”

Small, dumb, easily fixed moment — but it’s the kind of thing that sticks with you a lot better than reading “DHCP assigns IP addresses” in a textbook ever did.

Multi-Site Network Redistribution

Fri, 10 Apr 2026 00:00:00 +0000

A simulated enterprise network connecting a headquarters, an ISP transit point, and three branch offices — built to practice how real organizations stitch together different routing domains, not just configure a single flat network.

Overview

Designed and configured a simulated enterprise network connecting a headquarters, an ISP transit point, and three branch offices — each running a different routing protocol on purpose. The goal wasn’t just to get devices talking to each other, but to practice the harder, more realistic problem: getting different routing domains to interoperate the way a real organization’s network often ends up looking after years of growth, mergers, or mixed vendor equipment.

Key Features

Routing Design

Static routing on the HQ ↔ ISP link — a deliberate choice for a single, predictable edge connection where a dynamic protocol would add unnecessary overhead
OSPF as the core protocol for Branch A and Branch B, chosen for fast convergence on a growing internal network
RIPv2 on Branch C, simulating a smaller or legacy office segment still running a simpler distance-vector protocol
Mutual redistribution configured on Branch B’s router, bridging the OSPF and RIP domains so every site can reach every other site despite running different protocols

Network Services

Per-site DHCP pools, so end devices on every LAN receive addressing automatically rather than being statically configured
Full IP addressing scheme across 5 routers and 3 LANs, cleanly subnetted with /30 point-to-point links between routers

Technical Highlights

The Redistribution Problem

The real center of this project is Branch B’s router, which sits at the boundary between the OSPF and RIP domains. Getting redistribution right here meant making sure routes learned from RIP were correctly injected into OSPF (and vice versa) without creating routing loops or unreachable segments — a common real-world pain point when networks are stitched together from parts that didn’t originally share a protocol.

Convergence, Verified

Rather than just claiming the network works, I tested it — a ping from HQ to a Branch B host showed the first packet timing out (as OSPF/ARP resolution completed across the static-to-OSPF handoff), then subsequent replies landing in single-digit milliseconds. That’s a small but real demonstration of why convergence time matters, not just whether a network eventually responds.

Architecture

 [ISP - R5]
 / \
 Static/ \Static
 / \
 [R1 - HQ] [R2 - Branch A] --- OSPF Area 0 --- [R3 - Branch B]
192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
 |
 Redistribution (R3)
 |
 RIPv2
 |
 [R4 - Branch C]
 192.168.4.0/24

Challenges & Solutions

Challenge 1: Bridging Two Routing Protocols

Problem: Branch C’s legacy RIP segment had no way to exchange routes with the OSPF-based core network.

Solution: Configured mutual redistribution on Branch B’s router (redistribute rip inside the OSPF process, redistribute ospf inside the RIP process), effectively making it a translator between the two domains.

Challenge 2: Choosing the Right Protocol Per Segment

Problem: Using one protocol everywhere would have been simpler, but wouldn’t reflect how real hybrid networks are actually built.

Solution: Matched protocol choice to purpose — static for a stable, single-path edge link, OSPF for a fast-converging core, RIP for a small/legacy segment — rather than defaulting to “one protocol for everything.”

Tech Stack Details

Simulation Environment

Cisco Packet Tracer

Protocols & Services

Static Routing
OSPF (Open Shortest Path First)
RIPv2
Route Redistribution
DHCP

Scope

5 routers, 4 LANs, 3 branch offices, 1 ISP transit hub

Future Improvements

Add ACLs to restrict inter-branch traffic to only what’s needed
Harden the management plane — restrict SSH/Telnet access to specific management hosts
Add a basic firewall rule set at the ISP boundary to simulate perimeter filtering
Migrate from Packet Tracer to GNS3/EVE-NG for closer-to-real IOS behavior

Lessons Learned

Protocol choice is a design decision, not a default. Picking static, OSPF, or RIP per segment based on the actual role of that segment taught me more than just deploying one protocol everywhere ever could.
Redistribution is where real networking skill shows up. Anyone can configure a single protocol from a guide — making two protocols coexist safely is where the actual engineering judgment lives.
Verification matters as much as configuration. A network that’s “configured” isn’t the same as a network that’s proven to work — testing convergence with real ping output made the difference between a checklist exercise and something I actually understood.

Project Status: ✅ Complete (routing/redistribution phase) — security hardening planned as next iteration GitHub:

Networking | Ahmed Portfolio