One of the most interesting things about learning networking is that many concepts seem abstract until you see them happening in real time.
For example, I had heard terms such as:
- ICMP
- Packets
- Requests
- Replies
- Network traffic
But they remained theoretical concepts until I opened Wireshark and watched them appear on my screen.
What started as a simple command:
ping github.com
turned into a useful lesson about how computers communicate across networks.
The Experiment
The setup was intentionally simple.
- Open Wireshark
- Select the active network interface
- Apply the filter:
icmp
- Open a terminal
- Run:
ping github.com
My goal was simple:
Observe what actually happens on the network when a ping command is executed.
Before Running Ping
Before running the command, Wireshark showed no ICMP traffic.
📸 Before Capture
Figure 1: Wireshark filtered by ICMP before running ping github.com.
This initially confused me.
I had applied the filter correctly, but nothing appeared.
Then I realized something important:
Wireshark only shows packets that actually exist.
Since no ICMP traffic was being generated, there was nothing to display.
Running the Command
The command used was:
ping github.com
Immediately, the terminal began showing responses similar to:
64 bytes from 20.xx.xx.xx:
icmp_seq=1 ttl=119 time=61 ms
At the same time, Wireshark started filling with packets.
After Running Ping
The moment the ping command started running, ICMP packets appeared in Wireshark.
📸 After Capture
Figure 2: ICMP Echo Requests and Echo Replies captured after running ping github.com.
This was the first time I could visually observe what the ping command was doing behind the scenes.
What Does ping Actually Do?
Many beginners—including myself—treat ping as a connectivity test.
We run:
ping github.com
and if responses appear, we assume everything is working.
While that is true, there is more happening underneath.
The ping utility uses a protocol called:
ICMP
which stands for:
Internet Control Message Protocol
ICMP is part of the TCP/IP networking stack and is primarily used for diagnostics and troubleshooting.
The Two Messages That Matter
When ping runs, two ICMP messages become important.
ICMP Echo Request
Sent from your computer.
It is essentially asking:
"Are you there?"
ICMP Echo Reply
Sent back by the destination host.
It is essentially saying:
"Yes, I'm here."
Together, these create the familiar request–response pattern.
What Wireshark Was Showing
Looking at the capture, I could see entries similar to:
Echo (ping) request
Echo (ping) reply
Echo (ping) request
Echo (ping) reply
Each request was followed by a corresponding reply.
This was not just theory anymore.
It was a live conversation occurring between my machine and GitHub's servers.
A Simple Conversation
The interaction can be visualized as:
My Laptop
↓
"Are you there?"
↓
github.com
github.com
↓
"Yes, I'm here."
↓
My Laptop
This exchange repeats continuously while the ping command runs.
Something Interesting I Noticed
In the capture, I could clearly see two IP addresses.
For example:
Source:
192.168.1.x
Destination:
20.x.x.x
and then immediately afterwards:
Source:
20.x.x.x
Destination:
192.168.1.x
The addresses had reversed.
That was the reply packet making its way back.
Seeing this happen visually helped me understand networking far better than simply reading definitions.
Looking Inside a Packet
Expanding a packet in Wireshark revealed multiple layers.
For example:
Ethernet Frame
↓
IPv4 Packet
↓
ICMP Message
This was an interesting moment because several concepts I had been studying separately suddenly appeared together.
Inside a single packet I could see:
- Source MAC Address
- Destination MAC Address
- Source IP Address
- Destination IP Address
- ICMP data
The OSI model was no longer just a diagram.
I was seeing it in action.
Why Both MAC and IP Addresses Appear
One question that had been bothering me earlier was:
Why do packets contain both MAC addresses and IP addresses?
Observing Wireshark helped answer that.
The packet needs:
IP Address
To determine where it should travel across networks.
MAC Address
To determine which device should receive it on the local network.
Both are required.
They simply operate at different layers.
Measuring Latency
One of the most useful outputs from ping is:
time=61 ms
This represents the round-trip time.
The measurement includes:
Request sent
↓
Destination receives it
↓
Reply generated
↓
Reply received
The reported time covers the entire journey.
This is why ping is often used to estimate network latency.
Why This Matters for DevOps
At first glance, ping appears to be a very simple command.
However, many real-world infrastructure problems eventually become questions such as:
- Is the server reachable?
- Is DNS resolving correctly?
- Is the network path functioning?
- Are packets being dropped?
Understanding what ping actually does provides a foundation for answering those questions.
Tools such as Wireshark simply make the invisible visible.
A Useful Mental Model
The way I currently think about it is:
ping command
↓
ICMP Echo Request
↓
Network
↓
Destination Host
↓
ICMP Echo Reply
↓
Back to Sender
Every successful ping is simply a completed request–reply conversation.
Final Thoughts
Before opening Wireshark, ping felt like a black box.
You ran the command.
A response appeared.
And that was the end of the story.
After watching the packets move across the network, the process became much easier to understand.
A simple command turned into a visible exchange of requests and replies.
And for the first time, concepts such as:
- ICMP
- Packet captures
- MAC addresses
- IP addresses
started feeling less like networking terminology and more like parts of a real conversation between machines.
Sometimes the best way to learn networking is not by reading about packets.
It is by watching them travel.
Top comments (0)