LAB-NET-02 - Ping and Reachability

NET Networking and Communication

Ping and Reachability

Use ping to test reachability in a more structured way, separating local stack checks, gateway checks, and broader connectivity checks.

15 min BEGINNER LINUX Field-verified

Prerequisites

Lab LAB-NET-01 - Interfaces and IP Addresses

Success criteria

Use ping to test more than one layer of reachability.
Explain what ping does and does not prove.

Safety notes

Keep tests simple and bounded; use a small count instead of endless output when possible.

Part A: The Field Guide

ping is useful, but only when you are clear about what it is actually testing.

It is best treated as a reachability probe, not a total network verdict.

Key Limitation

A host or firewall may ignore ICMP ping even when the service you care about is healthy. So a failed ping is useful evidence, but not final proof by itself.

Part B: The Drill Deck

Terminal required: use short, bounded tests.

Exercise G1: Test loopback

Run ping -c 2 127.0.0.1
Confirm that the local stack responds
Explain why this still does not prove outside connectivity

Exercise G2: Test broader reachability

Run ping -c 2 8.8.8.8
Note whether packets return and what the latency roughly looks like
Explain how this differs from the loopback test

Exercise G3: Compare IP versus hostname

Run ping -c 1 8.8.8.8
Run ping -c 1 google.com
Explain why the second test depends on one extra layer

Exercise S1: Gateway reasoning

If you know your default gateway, test it with a short ping and explain why this sits between loopback testing and outside-internet testing in the troubleshooting order.

Exercise S2: Bound the command

Explain why ping -c 3 target is often better for a quick check than an endless ping session.

Mission M1: Write the three-step reachability ladder

Write a short sequence using ping that checks:

local loopback
local network path or gateway
outside reachability

If you can explain what each step proves, the lab is doing the right job.

Practice flow

Run the exercise carefully, then repeat the key steps once more in the same session without leaning on the instructions.

Open lesson Open Arena Back to Labs

Reflection

What became clearer once you treated ping as one layer check instead of the whole answer?
Which step in the reachability chain felt most useful to you first?

If not yet, repeat the lab once more without leaning on the instructions.

Move on when

Use ping with a small count and interpret the result without notes.
Explain why a failed ping does not always mean a service is down.

A lab counts when you can repeat it cleanly with much less help than the first time.

Practice review

After you finish, repeat this lab tomorrow with less reliance on the instructions.

Use spaced practice around day 1, day 2, day 5.
Try to predict the steps before you scroll.
Run the key commands or actions from memory first.
Use the lesson or Library only for the parts that still fail.

Lab context

Best for

Need structureSerious hands-on operatorStarting from zeroDeveloper expanding into systemsIT / support / sysadmin

Pathways

Career operator pathFoundations firstDeveloper to systems fluency

Practice fit

Beginner-safe Guided practice

This lab is designed to be attempted safely by newer learners if they stay inside the described sandbox or practice folder.

Expect tighter prompts and a more protected workflow while the skill is still forming.

Revisit the lesson

Module M28 - Network Model: How Networks Work Module M30 - Network Config: CLI Module M32 - Network Diagnostics

Topics

pingreachabilitylatencygatewayloopback

Reference support

Library ping Library reachability Library latency Library gateway

On this page