Network Diagnostic Tools and Commands Questions

Practical knowledge of common network tools: ping (ICMP echo requests), traceroute (path tracing), ipconfig/ifconfig (IP configuration viewing), nslookup/dig (DNS queries), netstat (connection statistics), arp (address resolution protocol), and packet analysis tools like Wireshark. Know what each tool does, what output to expect, and how to interpret results.

HardTechnical

76 practiced

Traffic is encrypted with TLS, but connections are failing. Explain how you can use packet traces (Wireshark/tcpdump) to diagnose TLS handshake issues without decrypting payloads: identifying ClientHello, ServerHello, SNI, cipher suite negotiation, certificate issues, alerts, and handshake timeouts. Provide Wireshark filters to surface relevant handshake messages and explain what each observable symptom implies.

Sample Answer

**Approach (what to look for & why)**

When TLS connections fail but traffic is encrypted, packet traces still expose the handshake metadata you need: ClientHello/ServerHello messages, SNI, cipher list, chosen cipher, certificate chain exchange, TLS Alerts, and timing. Use these to map where the handshake breaks (client, network middlebox, server).

**Useful Wireshark/tcpdump filters**

- Show all TLS handshake packets:

display

tls.handshake

- ClientHello packets:

display

tls.handshake.type == 1

- ServerHello:

display

tls.handshake.type == 2

- TLS Alerts:

display

tls.record.content_type == 21

- Certificates:

display

tls.handshake.type == 11

- SNI in ClientHello:

display

tls.handshake.extension.type == 0

- TCP retransmits / handshake timeouts:

display

tcp.analysis.retransmission or tcp.analysis.retransmission.fast or tcp.analysis.ack_rtt

**What to inspect and what symptoms mean**

- Missing ClientHello: client didn’t send — app/config issue or network blocking outbound.- ClientHello seen, no ServerHello: server not responding, server-side firewall, server crash, or middlebox dropping; check TCP-level (SYN/ACK) and retransmits.- SNI present but server returns certificate for different name: virtual-host mismatch or misconfigured TLS termination.- No SNI (older client): server may reject if virtual hosting required.- Cipher suites present but ServerHello selects none / sends alert: server does not support client algorithms — configure compatible ciphers or enable TLS versions.- Certificate packet present but server sends fatal alert immediately after: certificate validation failure on server or client (e.g., wrong CA, expired) or middlebox inspecting and dropping.- TLS Alert with description (e.g., handshake_failure, certificate_unknown): use alert.description in Wireshark to map cause.- Large RTTs / retransmits before handshake: network/MTU issues, path MTU, or packet loss causing timeouts.

**Practical steps**

- Correlate timestamps: identify where timeouts/retransmits occur.- Capture both sides if possible to compare perspectives.- If SNI/cipher mismatch suspected, reproduce with s_client to confirm server behavior.- Check middleboxes (TLS proxies) by looking for unexpected RST/FIN or duplicated ClientHello.

This workflow lets a network engineer pinpoint whether failures are network-level, configuration/cipher mismatch, certificate problems, or interception, without decrypting TLS.

MediumTechnical

84 practiced

Write a short Python solution outline or shell pipeline that reads a pcap file and counts TCP SYN packets per source IP. Specify that the answer must use Python and must avoid loading the whole pcap into memory (streaming). Describe which libraries or tools you would use and show brief example commands or code snippets.

Sample Answer

**Approach (short)** Stream packets—never load whole pcap. Use tshark for fast CLI one-liners or Python with Scapy/pyshark in streaming mode. Count TCP packets with SYN set (optionally SYN and not ACK for initial handshakes) grouped by source IP.

**Tools**- tshark (Wireshark CLI) — fast, low-memory- Scapy PcapReader — streaming in Python- pyshark.FileCapture with keep_packets=False — streaming wrapper around tshark

**Shell one-liner (tshark)**

bash

tshark -r capture.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==0" -T fields -e ip.src \
  | sort | uniq -c | sort -nr

**Python streaming (Scapy)**

python

from scapy.utils import PcapReader
from collections import Counter

counts = Counter()
with PcapReader("capture.pcap") as pcap:
    for pkt in pcap:
        if pkt.haslayer("TCP"):
            tcp = pkt["TCP"]
            if tcp.flags & 0x02 and not (tcp.flags & 0x10):  # SYN and not ACK
                ip = pkt["IP"].src
                counts[ip] += 1

for ip, c in counts.most_common():
    print(ip, c)

**Notes / Trade-offs**- tshark is fastest for large files; Scapy is flexible for additional logic.- For IPv6 use ip.src / ipv6.src fields accordingly.- If pkts unlabeled or fragmented, add checks. Use multiprocessing if you need parallel parsing across split files.

HardTechnical

76 practiced

You suspect DNS tunneling or exfiltration over DNS. Describe specific methods using dig, nslookup, tcpdump, and Wireshark to detect DNS tunneling patterns: look for long query names, unusual character entropy, many unique subdomains per domain, TXT or NULL record abuses, and high query rates to a single resolver. Provide commands and filters you would use to extract suspicious queries and suggest remediation and long-term monitoring strategies.

Sample Answer

**Approach (what I look for)** I look for long/random-looking query names and labels, many unique subdomains for one domain, TXT/NULL record usage, and high query rates to one resolver. I use dig/nslookup for spot checks, tcpdump/tshark/Wireshark for captures and forensic filtering, plus scripts to count uniques and compute length/entropy.

Dig / nslookup (spot checks)- Check TXT/NULL records and raw query:

bash

dig @1.2.3.4 suspicious.example.com TXT +norecurse
dig @1.2.3.4 suspicious.example.com NULL +norecurse
nslookup -type=txt suspicious.example.com 1.2.3.4

Live capture with tcpdump / tshark- Capture DNS traffic for host or subnet:

bash

sudo tcpdump -i eth0 -s 0 -w dns.pcap port 53 and udp

- Quick live summary of high-rate query IPs:

bash

sudo tcpdump -n -l port 53 | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -nr | head

- Use tshark to extract queries and answer types:

bash

tshark -r dns.pcap -Y "dns.qry.name" -T fields -e frame.time -e ip.src -e dns.qry.name -e dns.count.answers -e dns.resp.type > dns-queries.csv

Wireshark / tshark display filters (forensics)- Long query names (label length > 40) — Wireshark filter:

dns.qry.name matches "[a-z0-9]{40,}\."

- TXT/NULL or unusual types:

dns.qry.type == 16 || dns.qry.type == 10

- Many unique subdomains per domain (tshark):

bash

tshark -r dns.pcap -Y "dns.qry.name contains \"example.com\"" -T fields -e dns.qry.name | sort | uniq -c | sort -nr | head

Detect entropy / randomness- Basic length and character-entropy heuristic (quick awk/perl):

bash

tshark -r dns.pcap -Y "dns.qry.name" -T fields -e dns.qry.name | \
awk -F. '{print $(NF-2)"."$(NF-1)"."$NF, length($0), $0 }' | \
while read host len fqdn; do entropy=$(echo -n "$fqdn" | perl -ne '@c=split(//,$_); $H=0; foreach $x (keys %h){$h{$x}++} foreach $x (keys %h){$p=$h{$x}/@c;$H-=$p*log($p)/log(2)} print $H }'; echo "$entropy $len $fqdn"; done

(Use this or a small Python script to flag entropy > ~3.5 for domain labels.)

High query rates to a single resolver- Count queries per second from clients:

bash

tshark -r dns.pcap -T fields -e frame.time_epoch -e ip.src | \
awk '{t=int($1);print t,$2}' | uniq -c | sort -nr | head

Remediation & short-term actions- Block or sinkhole suspicious authoritative domains at recursive resolvers or firewall (reject NXDOMAIN or respond with internal IP).- Rate-limit/blackhole client generating excessive queries.- Force DNS over authenticated channels (DoT/DoH) where practical and log.- Disable NULL record support at resolvers and inspect TXT responses.

Long-term monitoring & detection- Instrument recursive resolvers to log query name lengths, counts per domain, unique subdomain counts, query types, and entropy score; alert on thresholds (e.g., >1000 unique subdomains/hr or avg label entropy > 3.5).- Integrate DNS logs into SIEM/ELK and create dashboards: top queried domains, unique subdomain growth, TXT/NULL usage, top clients by DNS rate.- Deploy passive DNS collectors and periodic reverse lookups to detect new suspicious authoritative servers.- Use DNS RPZ (response policy zones) for blocking known tunnels and feed threat intel.- Regularly review resolver configs, enable logging with minimal performance impact, and run red-team DNS tunneling tests to validate detection.

Why this works- Tunnels use many high-entropy subdomains, long labels, or text-bearing RR types and high query volume — the commands above extract those signatures for triage, capture, and automated detection.

MediumTechnical

86 practiced

On a Linux server experiencing high network wait, describe how you would use ss/netstat combined with lsof and /proc to find the process with the highest concurrent outgoing TCP connections and determine whether those sockets are in SYN_SENT or ESTABLISHED state. Provide exact commands you would run and how to interpret the outputs.

Sample Answer

**Approach (brief)** Use ss/netstat to list TCP sockets and states, aggregate by inode, map inodes to PIDs via /proc and lsof to find which process holds the most outgoing connections and whether they're SYN_SENT or ESTABLISHED.

**Commands & rationale**

1) Count outgoing TCP sockets per inode (shows state + remote addr)

bash

ss -tnp | awk 'NR>1 { state=$1; peer=$5; inode=""; if ($0 ~ /ino:/) { match($0,/ino:([0-9]+)/,a); inode=a[1] } print state, inode, peer }'

Look for lines with inode numbers and states (SYN-SENT or ESTAB).

2) Identify top inodes by count (concurrent connections)

bash

ss -tnp | awk 'NR>1 { if ($0 ~ /ino:/) { match($0,/ino:([0-9]+)/,a); inode=a[1]; g[$1","inode]++ } } END{ for(k in g) print g[k], k }' | sort -rn | head

Output: "count STATE,INODE". The highest count pinpoints candidate inode(s).

3) Map inode -> PID using /proc (find processes holding that socket)

bash

inode=1234567   # replace with inode found
for pid in $(ls /proc | grep -E '^[0-9]+$'); do
  ls -l /proc/$pid/fd 2>/dev/null | grep "socket:\\[$inode\\]" && echo "PID $pid"
done

Or faster with lsof:

bash

lsof -nP -iTCP -sTCP:ESTABLISHED | grep 1234567
lsof -nP | grep "socket:[$inode]"

4) Confirm state from /proc/net/tcp (hex fields)

bash

grep 1234567 /proc/net/tcp
# fields: sl local_address rem_address st inode

State codes: 01=ESTABLISHED, 02=SYN_SENT. Example:

text

sl: ... st: 02  -> SYN_SENT

**How to interpret** - ss output shows human-readable state; aggregation gives the process owning many outgoing sockets. - lsof or /proc mapping confirms PID and command. - /proc/net/tcp provides canonical state code if ss ambiguous. If many SYN_SENTs, suspect connection attempts/backlog or remote unreachable; many ESTABLISHED indicates heavy legitimate connections from that process. Take remediation (rate-limit, investigate destination, restart, firewall).

MediumTechnical

90 practiced

A traceroute output contains hops labeled with 'mpls' and several hops do not respond to ICMP, plus you see widely varying RTTs. Explain how MPLS and ECMP can affect traceroute output, why some hops might be invisible, and how to use TCP-based traceroute or Paris-traceroute to more reliably map a path through load-balanced devices.

Sample Answer

**Short answer / overview**MPLS and ECMP both make classic ICMP/UDP traceroute results unreliable. MPLS inserts label stacks (often shown as "mpls" in output) and can hide or change where TTL-expired ICMP messages originate. ECMP (hash-based load‑balancing) can send successive probes down different physical paths, producing missing hops and wildly varying RTTs.

**Why MPLS affects traceroute**- MPLS forwards by label; intermediate LSRs may not generate TTL‑expired ICMPs the way pure IP routers do. Some devices perform penultimate‑hop popping so the ICMP comes from a different router.- RFC4950 shows MPLS label info when devices include it; otherwise you just see "mpls" or label stacks, not a clear per-hop IP.

**Why ECMP and load‑balancers create noise**- ECMP hashes on flow 5‑tuple; standard traceroute varies source/dest UDP/ICMP ports per probe, so probes take different ECMP paths. Result: different sets of hops and RTTs, asymmetric return paths, and some probes never elicit replies.- Stateful firewalls/load‑balancers may drop unexpected ICMP/UDP probes.

**Why hops are invisible**- Devices can drop TTL‑exceeded messages (ACLs, rate limiting).- MPLS devices may not send ICMP until label popped; intermediary LSRs are effectively invisible.- Asymmetric return paths can mean replies are filtered or lost.

**How to get more reliable path maps**- Use Paris‑traceroute to keep packet header fields constant so all probes follow the same ECMP hash: - Example: paris-traceroute -n target (or with -T for TCP)- Use TCP-based traceroute (or tcptraceroute) toward a port likely allowed (80/443) so probes traverse stateful firewalls/load‑balancers like real user traffic: - Example: traceroute -T -p 443 target OR tcptraceroute target 443- Combine both: paris-traceroute --tcp -p 443 target to maintain flow identity and use TCP.- Use different destination ports and methods to see alternate behavior; correlate with BGP/ASN hops and MPLS label stacks to interpret hidden segments.

**Practical troubleshooting steps**- Run paris-traceroute (TCP) and classic traceroute (ICMP/UDP) and compare.- Check for RFC4950 MPLS labels in output; correlate with provider MPLS PE/LSR hop addresses.- Capture packets (tcpdump) to see where probes actually go and which replies are sent/filtered.- If provider-owned hop invisible, contact provider with timestamps and packet captures.

This approach yields consistent path mapping through ECMP and load‑balanced devices and helps interpret MPLS-labeled hops.

Unlock Full Question Bank

Get access to hundreds of Network Diagnostic Tools and Commands interview questions and detailed answers.

Join thousands of developers preparing for their dream job.