HomeField notes
PACKETDOJO GUIDES

Automate a change you can verify.

Network automation begins with explicit intent, bounded changes, and repeatable validation.

Capture a baseline

Keep the original device configurations and define the traffic that must work before and after a change. Preserve a clear rollback artifact.

Separate rendering from deployment

Generate candidate configuration, inspect the diff, and run deterministic checks before applying it. Avoid mixing credentials or production inventory with training fixtures.

Verify behavior, not a text match

A configuration can contain the expected line while forwarding still fails. Compare reachability and protected flows after the proposed change. Python, Netmiko, and Ansible execution labs are planned; the current exercise focuses on configuration validation.

PUT THE IDEA TO WORK

The route to nowhere

Seattle office. The core has two routed branches and a cross-link before the common service handoff. The service at .10 is unreachable, but .200 in the same subnet and the secondary service still work. Investigate the two service networks from R1: 10.201.160.0/24 to 10.201.168.0/24 (TCP/443), and 10.201.161.0/24 to 10.201.169.0/24 (TCP/8443).

Network topology5 devices 6 links

The route to nowhere — network topologyR1: Client core. R2: North transit. R3: South transit. R4: Egress core. R5: Service gateway. R1 connects to R2. R1 connects to R3. R2 connects to R4. R3 connects to R4. R2 connects to R3. R4 connects to R5. Connections show physical links, not service health.R1 ↔ R2 · 10.201.176.0/30R1 ↔ R3 · 10.201.177.0/30R2 ↔ R4 · 10.201.178.0/30R3 ↔ R4 · 10.201.179.0/30R2 ↔ R3 · 10.201.180.0/30R4 ↔ R5 · 10.201.181.0/30R1Client coreR1 · Client coreR2North transitR2 · North transitR3South transitR3 · South transitR4Egress coreR4 · Egress coreR5ServicegatewayR5 · Service gateway
Physical links · Service health not shown

Free to practice. No account required.

Create an account to save your results and build your skill graph.