Walk ARP and ICMP across two routed subnets

Trace address resolution and an ICMP exchange from 10.0.1.0/24 through a router to 10.0.2.0/24.

Packet Pete, your practice guide

Packet Pete
Predict the reading, then compare it with the measurement.

Cisco Packet Tracer

Desktop lab

Trace address resolution and an ICMP exchange from 10.0.1.0/24 through a router to 10.0.2.0/24.

Tier 3 · Install required · Cisco account required

Version tested: Cisco Packet Tracer 9.0.1 on Ubuntu 22.04 (Apptainer/Xvfb); project saved and execution captured 2026-09-10. Date: 2026-09-10.

Install the tool; build from the steps. No file yet.

Download the Packet Tracer file

Need the app? Get Packet Tracer free from Cisco Networking Academy (free NetAcad login required).

Steps

Screens captured against Cisco Packet Tracer Cisco Packet Tracer 9.0.1 on Ubuntu 22.04 (Apptainer/Xvfb); project saved and execution captured 2026-09-10 on 2026-09-10; the tool may have moved on — the text steps are the contract.

  1. Step 1

    Do
    Open lab.pkt and inspect Sensor-PC, two LAN switches, Gateway-R1, and Cloud-PC.
    You will see
    PT displays 10.0.1.10/24 → 10.0.1.1/10.0.2.1 → 10.0.2.10/24.
    Why it matters
    The two subnet boundaries predict where a router must forward.

  2. Step 2

    Do
    From Sensor-PC, ping 10.0.2.10 twice so address resolution is complete.
    You will see
    The second run prints “Sent = 4, Received = 4, Lost = 0 (0% loss)”.
    Why it matters
    The successful baseline checks both forward and return routes.

  3. Step 3

    Do
    Clear Sensor-PC’s ARP table, enter Simulation mode, and start the ping.
    You will see
    The Simulation event list starts at 0.000 and a green PDU waits at Sensor-PC.
    Why it matters
    A cold cache exposes the link-layer lookup that a warm ping can hide.

  4. Step 4

    Do
    Step the ARP exchange through LAN1-SW and Gateway-R1.
    You will see
    The event list visibly records Sensor-PC, LAN1-SW, Gateway-R1, and LAN1-SW on the return leg.
    Why it matters
    The host resolves the gateway MAC, not the remote host MAC.

  5. Step 5

    Do
    Continue through Gateway-R1 and inspect the routed ping reply at Sensor-PC.
    You will see
    Each routed reply visibly returns with TTL=127, one lower than the host default of 128.
    Why it matters
    TTL changes at the forwarding boundary and makes the routed hop observable.

  6. Step 6

    Do
    Open PDU Information at Gateway-R1 during the ARP exchange.
    You will see
    The OSI Model shows distinct inbound and outbound Ethernet II headers and rewrites the destination from FF:FF:FF:FF:FF:FF to 00D0.9794.010C.
    Why it matters
    The IP destination remains end to end while Ethernet source and destination are rewritten per link.

  7. Step 7

    Do
    Step through LAN2-SW to Cloud-PC and continue through the reply.
    You will see
    The final command output remains 4 sent, 4 received, and 0 lost.
    Why it matters
    The completed return path is the evidence needed for bidirectional reachability.

Chapter checks

These questions refer to the chapter’s examples. Use the return links to review their answers.

  1. A sensor link has enough nominal bandwidth for the average payload calculation, but users still see delayed readings during shift changes. What should be checked next?

    Return to the chapter’s knowledge check

  2. Why can a shared wireless IoT channel fail even when the average payload bandwidth is below the nominal link rate?

    Return to the chapter’s knowledge check

Return to Network Collisions and Bandwidth · Browse Labs