Hands-on Labs
Theory sticks better with practice. This chapter walks through essential command-line tools and exercises. Commands are shown for Linux; Windows equivalents are noted where they differ.
ping — test reachability and RTT
$ ping -c 4 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=117 time=12.3 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=11.9 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=12.1 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=12.4 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss rtt min/avg/max/stddev = 11.9/12.2/12.4/0.2 ms
The ttl=117 means the packet had a starting TTL of 128 and crossed 11 hops. -c 4 sends 4 packets (Linux). On Windows use ping -n 4 8.8.8.8.
traceroute — discover the path
$ traceroute -n 8.8.8.8 # Linux (-n skips reverse DNS) # Windows: tracert -d 8.8.8.8 1 192.168.1.1 1.2 ms 1.0 ms 1.1 ms ← default gateway 2 10.0.0.1 5.3 ms 5.1 ms 5.2 ms ← ISP router 3 * * * ← router not responding to ICMP 4 142.250.68.14 10.8 ms 10.7 ms 10.8 ms 5 8.8.8.8 12.2 ms 12.1 ms 12.3 ms
* * * means that hop did not return an ICMP Time Exceeded message — common for routers configured to silently drop ICMP. The path may still work fine.
ip addr / ipconfig — interface information
# Linux
$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
inet 192.168.1.100/24 brd 192.168.1.255 scope global eth0
# Windows
> ipconfig /all
Ethernet adapter Ethernet:
Physical Address. . . : AA-BB-CC-DD-EE-FF
IPv4 Address. . . . . : 192.168.1.100
Subnet Mask . . . . . : 255.255.255.0
Default Gateway . . . : 192.168.1.1
DNS Servers . . . . . : 8.8.8.8
ip route — routing table
# Linux $ ip route show default via 192.168.1.1 dev eth0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100 # Windows > route print Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.100 25 192.168.1.0 255.255.255.0 On-link 192.168.1.100 281
ss / netstat — socket statistics
# Linux: ss (modern replacement for netstat) $ ss -tunapl # -t TCP -u UDP -n numeric -a all -p process -l listening # Show listening TCP ports: $ ss -tlnp State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 0.0.0.0:22 0.0.0.0:* LISTEN 0 511 0.0.0.0:80 0.0.0.0:* LISTEN 0 511 0.0.0.0:443 0.0.0.0:* # Windows > netstat -ano | findstr LISTENING
dig / nslookup — DNS queries
# Query A record: $ dig A www.example.com ;; ANSWER SECTION: www.example.com. 3594 IN A 93.184.216.34 # Query MX records: $ dig MX example.com example.com. 3600 IN MX 0 . # Query against specific nameserver: $ dig @8.8.8.8 A www.example.com # Reverse lookup: $ dig -x 93.184.216.34 # Windows nslookup equivalent: > nslookup www.example.com 8.8.8.8
curl -v — HTTP/HTTPS inspection
$ curl -v https://example.com * Trying 93.184.216.34:443... * Connected to example.com (93.184.216.34) port 443 * TLSv1.3, TLS handshake, Client hello (1): * TLSv1.3, TLS handshake, Server hello (2): * TLSv1.3, TLS handshake, Finished (20): > GET / HTTP/2 > Host: example.com > User-Agent: curl/8.4.0 < HTTP/2 200 < content-type: text/html; charset=UTF-8 < content-length: 1256
nc (netcat) — TCP/UDP Swiss army knife
# Test if a TCP port is open: $ nc -zv 93.184.216.34 443 Connection to 93.184.216.34 443 port [tcp/https] succeeded! # Simple TCP server on port 9000: $ nc -l 9000 # Connect to that server from another terminal: $ nc 127.0.0.1 9000 Hello! ← typed, sent to the server
tcpdump — capture packets
# Capture all traffic on eth0: $ sudo tcpdump -i eth0 # Capture only TCP SYN packets (start of connections): $ sudo tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn) != 0' # Capture HTTP traffic on port 80: $ sudo tcpdump -i eth0 -A port 80 # Save to file for Wireshark: $ sudo tcpdump -i eth0 -w capture.pcap
Wireshark display filters
tcp.flags.syn == 1 # All SYN packets tcp.flags.syn == 1 && tcp.flags.ack == 0 # Only SYN (not SYN-ACK) ip.addr == 93.184.216.34 # Traffic to/from a specific IP dns # All DNS traffic http # All HTTP traffic tls.handshake.type == 1 # ClientHello TLS messages
Practice exercises
Exercise 1: Subnet calculation
Calculate the network address, broadcast, subnet mask, and number of usable hosts for 192.168.10.0/26.
Show solution
Prefix length : /26 Host bits : 32 - 26 = 6 Total addresses: 2^6 = 64 Subnet mask : 255.255.255.192 (binary: …11000000) Network address: 192.168.10.0 Broadcast : 192.168.10.63 First host : 192.168.10.1 Last host : 192.168.10.62 Usable hosts : 62
Exercise 2: Identify the TCP handshake from a packet log
Given these three Wireshark entries, identify which is SYN, SYN-ACK, and ACK, and explain the sequence numbers:
No. Time Src Dst Info 1 0.000 192.168.1.10 93.184.216.34 TCP 54321→443 [SYN] Seq=0 2 0.012 93.184.216.34 192.168.1.10 TCP 443→54321 [SYN, ACK] Seq=0 Ack=1 3 0.012 192.168.1.10 93.184.216.34 TCP 54321→443 [ACK] Seq=1 Ack=1
Show solution
Packet 1 is the SYN (client's ISN = 0 in relative terms). Packet 2 is the SYN-ACK: the server sets Ack=1 (expecting byte 1 from client) and its own ISN=0. Packet 3 is the ACK: client sets Seq=1, Ack=1 (expecting byte 1 from server). Wireshark uses relative sequence numbers starting at 0 for readability; real ISNs are random large integers.
Exercise 3: Routing decision
A host with IP 10.0.1.5 has this routing table. Where does a packet destined for 10.0.2.10 go?
Destination Gateway Interface 0.0.0.0/0 10.0.1.1 eth0 10.0.1.0/24 — eth0 (directly connected) 10.0.2.0/24 10.0.1.254 eth0
Show solution
10.0.2.10 matches both 10.0.2.0/24 (prefix length 24) and 0.0.0.0/0 (prefix length 0). The longest prefix match rule selects 10.0.2.0/24 — the packet is forwarded to gateway 10.0.1.254.
Exercise 4: tcpdump filter
Write a tcpdump filter to capture only DNS queries (not responses) from your machine.
Show solution
sudo tcpdump -i eth0 'udp dst port 53' # Explanation: DNS uses UDP port 53 by default. # Queries go TO port 53 (dst port 53). # Responses come FROM port 53 (src port 53). # For TCP DNS (large responses / zone transfers): tcp port 53
Exercise 5: End-to-End HTTP Latency & TCP Congestion Calculation
A client fetches an HTML page (negligible size) and 1 large image of size 30 KB (30,000 bytes, or 20 TCP segments at MSS = 1,500 bytes) over persistent HTTP without pipelining. Given RTT = 50 ms, initial cwnd = 1 MSS, and ssthresh = 16 MSS (with zero packet loss), how many RTTs are required for (a) the TCP handshake, (b) the HTML request/response, and (c) transferring the 20-segment image during Slow Start / Congestion Avoidance? What is the total elapsed time?
Show solution
(a) TCP 3-way handshake:
• 1 RTT (Client SYN → Server SYN-ACK → Client ACK with GET).
(b) Base HTML request + response:
• 1 RTT (Server transmits HTML; client receives and parses it).
(c) Transferring the 20-segment image during TCP Slow Start:
• Round 1: cwnd = 1 MSS → sends 1 segment (19 left). cwnd grows to 2 MSS. [1 RTT]
• Round 2: cwnd = 2 MSS → sends 2 segments (17 left). cwnd grows to 4 MSS. [1 RTT]
• Round 3: cwnd = 4 MSS → sends 4 segments (13 left). cwnd grows to 8 MSS. [1 RTT]
• Round 4: cwnd = 8 MSS → sends 8 segments (5 left). cwnd grows to 16 MSS. [1 RTT]
• Round 5: cwnd = 16 MSS (reaches ssthresh) → sends remaining 5 segments. [1 RTT]
Total image transfer rounds = 5 RTTs.
Total elapsed time:
Total RTTs = 1 (TCP) + 1 (HTML) + 5 (Image) = 7 RTTs.
Total time = 7 × 50 ms = 350 ms (0.35 s).