On to the echo‑reply.
It's almost identical to the echo‑request we just examined. A few
obvious differences in the blue highlight reveal that the source and
destination IP addresses have been swapped, which makes sense as this
is a returning traffic flow.
The protocol remains ICMP, and this packet is identified as an echo‑reply.
Viewing the internal details, we find that the echo‑reply is a
different type of ICMP packet than the echo‑request.
The echo‑request was a type 8, and the echo‑reply is a type 0.
Because these packets are used for two opposing purposes, they
are completely different types.
The identifier value from the sender is copied in the reply back to the sender.
This allows the sender to pass this ICMP message to the
correct internal process for examination.
Remember, if you and I were both logged into that client and sending
pings at the same time to the same destination, the operating system
needs to keep track of which echo‑replies correspond to which
echo‑requests at a process level.
Not surprisingly,
the sequence numbers are also copied from echo‑requests to
echo‑replies on their way back to the sender.
This enables per‑packet mapping between echo‑requests and echo‑replies.
The client can account for every success and every failure. All in all,
ping operations and their packet analyses are pretty easy.
The real value of ping comes from its utility as a fault isolation tool.
I want to briefly review types and codes in the next clip, but right after that we will troubleshoot some live network issues