Network Troubleshooting Methodology Questions

Focused approach to diagnosing network connectivity, performance, and reliability issues. Includes defining symptoms and scope, checking physical connectivity, verifying interface and link status, examining addressing and routing, investigating firewall and access control rules, performing path checks and packet captures, interpreting flow data and latency metrics, forming and testing hypotheses systematically, and escalating as needed. Familiarity with common network diagnostic tools and techniques, approaches to intermittent and performance degradation issues, and layer by layer reasoning are expected.

EasyTechnical

58 practiced

Describe the minimum steps and capture settings you would use to perform a packet capture that is useful for troubleshooting a connectivity issue. Cover capture location (host vs tap vs SPAN), interface selection, capture filters, snaplen, buffering, and legal/privacy considerations when capturing production traffic.

Sample Answer

**Approach — minimum useful steps**

1. Capture location- Prefer a passive network TAP or dedicated packet broker for complete, non-intrusive visibility.- Use SPAN/mirror as fallback (beware of dropped packets, truncated packets, lack of VLAN tags).- Host capture when troubleshooting a single endpoint (lo/eth0) — shows stack-level issues.

2. Interface selection- Choose the interface carrying the traffic (core link, VLAN SVI, or host NIC). On hosts, capture the physical NIC and any virtual interfaces (docker, vlan).

3. Capture filters (BPF)- Limit scope to relevant IPs/ports to reduce volume. Example:

bash

# Capture only traffic between host A and B on TCP port 443
tcpdump -i eth0 host 10.0.0.5 and host 10.0.0.8 and tcp port 443 -w capture.pcap

4. Snaplen- Set snaplen to capture full packets when troubleshooting application-layer issues:

bash

# full capture
tcpdump -s 0 -w capture.pcap

- For header-only capture, use 128–256 bytes to protect payloads and reduce size.

5. Buffering and file rotation- Use ring buffers to avoid losing data and control disk usage:

bash

# rotate 10 files of 100MB each
tcpdump -i eth0 -s 0 -C 100 -W 10 -w capture-%03d.pcap <filter>

- Increase capture buffer (Linux) with:

bash

# increase kernel buffer for tcpdump
sudo sysctl -w net.core.rmem_max=33554432

6. Legal / privacy considerations- Get authorization before capturing production traffic.- Minimize sensitive data: use filters, header-only snaps, or anonymization tools.- Secure PCAPs (encrypt at rest, limit access, redact when sharing).- Log purpose, owner, retention period; comply with policies/regulations (GDPR, HIPAA).

Outcome: capture from the proper location with tight BPF, appropriate snaplen, and ring buffers, while observing legal/privacy controls to produce a small, actionable PCAP for troubleshooting.

MediumTechnical

78 practiced

A set of hosts on VLAN 10 can no longer reach hosts on VLAN 20 after a recent change. Describe how you would troubleshoot VLAN or trunking misconfigurations on switches. Include commands and checks such as show vlan, show interfaces trunk, show mac address-table, show lldp/cdp neighbors, and how to detect native VLAN mismatches or dot1q tagging issues.

Sample Answer

**Approach (goal):** Verify VLAN presence, trunk status, L2 reachability, and tagging consistency end-to-end.

**Step 1 — Verify VLANs on each switch**- Check VLAN exists and is active:

bash

show vlan brief

Look for VLAN 10 and 20 and their SVI/interface assignments.

**Step 2 — Check trunk status and allowed VLANs**

bash

show interfaces trunk

Confirm trunk ports between switches are in trunking mode, carry VLANs 10/20, and note native VLAN.

**Step 3 — Validate MAC learning & forwarding**

bash

show mac address-table dynamic vlan 10
show mac address-table dynamic vlan 20

Ensure MACs of hosts appear on expected access ports and on uplink trunk interface.

**Step 4 — Check neighbor info for topology**

bash

show lldp neighbors detail
show cdp neighbors detail

Verify connected device, remote port, and remote native VLAN info.

**Step 5 — Detect native VLAN mismatch / dot1q issues**- Native VLAN mismatch: native VLAN differs on two ends — causes untagged frames to be placed in wrong VLAN. Compare native VLAN reported in `show interfaces trunk` on both ends.- Dot1q tagging issue: if native VLAN set to something other than management (e.g., 1) or if switchport trunk encapsulation mismatches (on older devices), frames may be dropped.

**Step 6 — Troubleshooting actions**- If native mismatch: align native VLANs or explicitly tag native via `switchport trunk native vlan X` consistently.- If VLAN missing on trunk: add via `switchport trunk allowed vlan add 10,20`.- If MACs missing: check access port config (`show run interface GigabitX`) for correct `switchport access vlan 10/20`, spanning-tree blocking, or port-security.- Use captures on trunk with `monitor session` or SPAN and verify 802.1Q tags.

**Outcome & verification**- After fixes, re-run `show interfaces trunk`, `show vlan brief`, `show mac address-table` and ping across VLANs. Document root cause (native mismatch, missing allowed VLAN, wrong access VLAN, or STP blocking) and remediation.

MediumTechnical

72 practiced

You need to analyze flow data (NetFlow/sFlow) to find the root cause of repeated short TCP sessions from many hosts to a single destination port. Describe a methodology to pivot from flow summaries to packet-level evidence, identify whether this is a legitimate microservice pattern, scheduled job, or malicious scanning, and recommend automated alerts to catch similar anomalies earlier.

Sample Answer

**Methodology overview**

1. **Clarify scope & gather flow summaries**- Query NetFlow/sFlow for destination port, time window, and metrics: src ip, dst ip, src/dst ports, protocol, packet count, byte count, start/end times, flow duration.- Tools: nfdump, Elastic/ELK, Kentik, or vendor flows.

2. **Pivot from flows to packet-level**- From flows, extract top offending dst IP and top source IPs and timestamps.- Generate a targeted capture: apply BPF filter like

text

host <dst_ip> and port <dst_port> and (src net <source_subnet1> or src net <source_subnet2>)

- Capture short window around peak with tcpdump/pcap-ng or pull archived PCAPs; use tshark to reconstruct 3-way handshake, RST/FIN patterns, payload, TLS fingerprints.

3. **Triage: microservice vs scheduled job vs scanning**- Microservice pattern: repeated short sessions from a small set of service IPs, consistent inter-arrival, predictable ports, successful application-layer handshakes, meaningful payloads or TLS ClientHello with expected SNI.- Scheduled job: bursts aligned to cron-ish intervals, consistent source set, identical session sizes and timing, likely internal origin and known automation hostnames.- Malicious scanning: many unique source IPs, varying ports/flags, many SYN without completing handshake, odd TTLs or geo-distribution, short flows with no payload, high source entropy.

4. **Evidence checklist (packet-level)**- TCP flags (SYN-only vs SYN/ACK/ACK)- Flow duration and packet counts- Payload presence, protocol negotiation (HTTP, TLS SNI)- Source diversity and ASN/geolocation- Timing periodicity (use autocorrelation)

5. **Automated alerts**- Alert when dst port receives > X short-duration (<Y sec) sessions from > N distinct sources within T minutes.- Alert on high source entropy or rapid growth in unique sources to a dst IP.- Alert on SYN ratio threshold: (SYN packets without ACKs) / total TCP attempts > Z.- Auto-whitelist known legitimate source-dst pairs (microservices, batch jobs) with exception lifecycle.- Integrate into SIEM with playbooks: trigger pcap capture, reverse DNS enrichment, ASN lookup, and notify Slack/pager with remediation steps.

6. **Follow-up**- If legitimate, document and whitelist; if malicious, block via ACL/NSG, throttle, and initiate incident response with captured PCAPs and flow evidence.

This approach moves from aggregate signals to concrete packet evidence, provides decision criteria to classify cause, and creates actionable automated detection to catch repeats early.

MediumTechnical

74 practiced

Your network sees sudden large traffic spikes. Use a structured approach to determine whether this is a legitimate traffic surge, a misconfiguration, or a DDoS attack. Describe what flow, packet, and device telemetry you collect, thresholding/baselining techniques, and initial containment options to prevent collateral damage while preserving evidence for investigation.

MediumTechnical

60 practiced

Asymmetric routing causes a specific client to fail to reach a service. Explain how you would detect asymmetric routing and detail corrective actions (routing policy change, reverse path filtering, NAT adjustments, or policy-based routing). Include commands or checks you would run on routers and firewalls to prove asymmetry.

Sample Answer

**Detection — hypothesis & quick tests**- I suspect replies take a different path. Confirm with bi-directional traceroutes and packet captures on both ends.- From client and service: run traceroute/tcpdump; on a router near service run capture to see incoming SYN vs outgoing SYN/ACK path.

Commands to prove asymmetry:- Client -> service traceroute:

bash

traceroute -n <service-ip>

- Service -> client traceroute:

bash

traceroute -n <client-ip>

- Capture on router/firewall ingress/egress:

bash

tcpdump -i eth0 host <client> and host <service> -w asym.pcap

- On Cisco IOS routers:

bash

show ip route <client-ip>
show ip cef <client-ip>
show access-lists
show ip nat translations
debug ip packet detail  (use carefully)

- On ASA/FTD:

bash

show conn detail | include <client-ip>
show xlate | include <service-ip>
show route

- On Juniper:

bash

show route <client-ip>
show security flow session source-prefix <client-ip>
monitor traffic interface <if> matching "host <client> and host <service>"

Look for traceroute hop differences, captures showing SYN arrives on one device but SYN/ACK exits via another upstream, or NAT/state entries missing on return path (firewall drops).

**Root causes & corrective actions**- Routing policy change: adjust IGP/BGP to ensure symmetric paths (prefer same next-hop for both directions), change route-maps or BGP local-preference/AS-path prepend to equalize.- Reverse Path Filtering (RPF): if strict RPF enabled and legitimate return path differs, either set RPF to loose mode or add static/exception routes. - Cisco IOS: disable or change

bash

no ip verify unicast reverse-path
ip verify unicast reverse-path interface Gig0/0 rx (or use loose)

- NAT adjustments: ensure NAT is applied on the path where return traffic traverses (or centralize NAT). If firewall does DNAT, ensure return path traverses same device or use asymmetric NAT helpers. - On ASA, ensure xlate is created for session; if not, force symmetric routing or configure Transparent NAT/Policy NAT.- Policy-Based Routing (PBR): on the device that is incorrectly routing return traffic, create PBR to steer traffic back through the firewall/NAT or original next-hop. - Example IOS PBR:

bash

route-map RETURN_PATH permit 10
 match ip address CLIENTS
 set ip next-hop <expected-next-hop>
interface Gig0/1
 ip policy route-map RETURN_PATH

**Verification after fix**- Repeat bi-directional traceroutes and tcpdumps; confirm SYN/SYN-ACK traverse same sequence of devices and firewall NAT/state is present (show conn/xlate).- Monitor for drops and review logs (ACL drops, RPF denies).

**Trade-offs / cautions**- Disabling strict RPF reduces spoof protection; prefer targeted exceptions or loose mode.- PBR adds complexity and must be monitored for scale; prefer fixing routing with IGP/BGP where possible.- NAT centralization may introduce throughput limits—check device capacity.

This approach demonstrates detection, evidence collection, targeted fixes (routing, RPF, NAT, PBR) and verification steps appropriate for a Network Engineer.

Unlock Full Question Bank

Get access to hundreds of Network Troubleshooting Methodology interview questions and detailed answers.

Join thousands of developers preparing for their dream job.