Troubleshooting Network Connectivity – Step by Step

1. The Troubleshooting Mindset and Framework

Effective network troubleshooting is a disciplined, methodical process — not random command-typing. The best engineers follow a structured approach that works from the bottom of the OSI model upward, eliminating layers one at a time until the problem is isolated. This prevents the common mistake of jumping straight to complex configurations when the problem is a disconnected cable or a wrong subnet mask.

1.1 Troubleshooting Approaches

Approach Direction When to Use Pros / Cons
Bottom-Up Layer 1 (Physical) → Layer 7 (Application) New installations; unknown problems; when physical issues are suspected Systematic; never skips a layer. Slower if the problem is clearly at a higher layer.
Top-Down Layer 7 (Application) → Layer 1 (Physical) Application-specific issues; when physical layer is known good Efficient for app problems; risks missing lower-layer issues contributing to the fault
Divide and Conquer Start in the middle (e.g., Layer 3) and work up or down based on result Most experienced engineers; when you have a hypothesis Fastest when the hypothesis is correct; efficient for experienced troubleshooters
Follow the Path Trace the traffic path hop by hop from source to destination Routing problems; intermittent connectivity; slow path performance Excellent for routing and path issues; requires access to intermediate devices
Compare Working vs Broken Compare a working similar path or device against the broken one When a known-good baseline exists Very fast when a comparison is available; depends on having a reference

1.2 The Six-Step Connectivity Troubleshooting Workflow

This page follows the bottom-up approach which is the standard CCNA exam methodology. Each step isolates one possible cause. See Troubleshooting Methodology and OSI Model for the broader framework.

Step Layer Question Being Answered Key Commands
1 Layer 1 — Physical Is the cable connected and the interface physically up? show interfaces, LED status, cable check
2 Layer 2 — Data Link Is the interface in the correct VLAN? Is the link protocol up? show interfaces, show vlan, show mac address-table
3 Layer 3 — Network (Local) Does the host have a valid IP address, mask, and gateway? ipconfig, ip addr, show ip interface brief
4 Layer 3 — Gateway Reachability Can the host reach its default gateway? ping <gateway-IP>
5 Layer 3 — Routing Does the router have a route to the destination? Is the return path intact? show ip route, traceroute
6 Layer 3–7 — ACLs, NAT & Application Is traffic being blocked by an ACL, mis-NATted, or is the application itself failing? show ip access-lists, show ip nat translations, telnet/curl

Related pages: Troubleshooting Methodology | OSI Model | OSI Layer Functions | Ping Command | Traceroute Command | show ip interface brief | show ip route | show interfaces | ACL Overview | debug ip packet | ipconfig / ifconfig | End-to-End Troubleshooting Lab

2. Step 1 – Check the Physical Link (Layer 1)

Every connectivity problem starts with the physical layer. A loose cable, a disabled port, or a duplex mismatch can cause complete connectivity failure or intermittent packet loss that mimics higher-layer problems. Always verify Layer 1 before investigating anything else.

2.1 Physical Checks

Check What to Look For Tool / Method
Cable connection Cable firmly seated in both ports — not partially unplugged Visual inspection; reseat the cable
Link LED Green = link active; amber = link fault or STP blocking; no LED = no physical link Physical inspection of switch/router port LED
Wrong cable type Straight-through vs crossover (less relevant with Auto-MDIX on modern switches) Cable tester; visual inspection (T568A vs T568B)
SFP / transceiver SFP module properly seated; correct wavelength for the fibre type (singlemode vs multimode) Visual; show interfaces transceiver
Fibre Tx and Rx fibres not swapped; clean connectors; bend radius not exceeded Optical power meter; loopback test

2.2 Cisco IOS – Interface Status Commands

! The most important first command for any interface problem
Router# show interfaces GigabitEthernet0/0

! Quick overview of all interfaces — status and protocol
Router# show ip interface brief

! Check for physical errors (CRC, input errors, giants, runts)
Router# show interfaces GigabitEthernet0/0 counters errors

See show interfaces for a full annotation of every error counter.

2.3 Interpreting Interface Status

Status / Protocol Meaning Likely Cause
up / up Physical link and data-link both active — interface is healthy Normal operation
up / down Physical signal present but Layer 2 protocol failed to come up Keepalive mismatch; encapsulation mismatch; WAN clocking issue; mismatched duplex
down / down No physical signal — Layer 1 failure Cable unplugged or broken; remote port shut down; bad NIC or SFP; wrong cable type
administratively down / down Interface has been manually shut down with the shutdown command Intentional disable — run no shutdown to re-enable
up / up with high error counters Physical link active but data is corrupted Duplex mismatch; bad cable; marginal SFP; excessive cable length; EMI interference

2.4 Duplex and Speed Mismatch

A duplex mismatch between two connected devices is a classic Layer 1/2 problem. One end is full-duplex and the other is half-duplex — the half-duplex end uses CSMA/CD and detects "collisions" that are actually legitimate frames from the full-duplex end. Symptoms: very high late collisions and input errors on show interfaces. 

! Check current speed and duplex settings
Router# show interfaces GigabitEthernet0/0 | include duplex|speed

! Fix: manually set speed and duplex (matching both ends)
Router(config)# interface GigabitEthernet0/0
Router(config-if)# duplex full
Router(config-if)# speed 1000
Router(config-if)# no shutdown

3. Step 2 – Check Layer 2 (Data Link / VLAN)

Once physical connectivity is confirmed, verify that Layer 2 is working correctly. The most common Layer 2 issues in enterprise networks are VLAN misconfiguration, trunk port problems, and STP blocking an expected path.

Layer 2 Check Command What to Verify
Port VLAN assignment show vlan brief Confirm the access port is assigned to the correct VLAN. A port in the wrong VLAN cannot communicate with other hosts in the intended VLAN.
Trunk port status show interfaces trunk Confirm the trunk is active; the expected VLANs are in the "VLANs allowed and active in management domain" section; native VLAN matches on both ends
MAC address table show mac address-table Verify the host's MAC address is learned on the correct port and in the correct VLAN
STP port state show spanning-tree vlan <id> Confirm the expected port is in Forwarding state, not Blocking. An unexpected block causes connectivity loss for hosts in that VLAN.
CDP / LLDP neighbours show cdp neighbors detail Confirms which device is connected to which port and reveals VLAN and interface information from the peer

4. Step 3 – Check IP Configuration (Layer 3, Local)

Once physical and Layer 2 connectivity are confirmed, verify the host's IP configuration. Incorrect IP address, wrong subnet mask, or missing default gateway are the most common causes of connectivity loss that have nothing to do with the network infrastructure.

4.1 IP Configuration Checks

Check Command (Windows) Command (Linux) Command (Cisco IOS)
View IP address ipconfig /all ip addr show show ip interface brief
View routing table / gateway route print ip route show show ip route
View ARP cache arp -a arp -n show arp
Flush DNS cache ipconfig /flushdns systemd-resolve --flush-caches N/A (router DNS: clear ip dns cache)
Release / renew DHCP ipconfig /release then ipconfig /renew dhclient -r eth0 then dhclient eth0 release dhcp (on router acting as client)

4.2 Common IP Configuration Errors

Error Symptom Fix
APIPA address (169.254.x.x) Host assigned a 169.254.x.x address — DHCP request failed. Cannot communicate with any other subnet. Check DHCP server availability and reachability; check DHCP relay (ip helper-address) on the router; verify DHCP scope has available addresses
Wrong subnet mask Host can ping some devices but not others; hosts in the same physical VLAN appear to be on different subnets to the host Correct the subnet mask to match the intended prefix; hosts with mismatched masks may try to send local traffic to the default gateway instead
Duplicate IP address Intermittent connectivity; other host affected; ARP table shows conflicting MAC addresses for the IP Check ARP table; use arp -a to find which MAC is mapped to the IP; assign a unique address
Missing or wrong default gateway Local subnet works; cannot reach any remote subnet or internet Verify gateway IP is correct and on the same subnet as the host; can ping local hosts but not remote ones
Host in wrong subnet Host IP is not in the correct network — cannot communicate with peers even on the same switch Verify the host's IP is within the intended subnet range; check DHCP scope boundaries

4.3 Cisco IOS Interface IP Verification

! Verify interface IP addresses and status
Router# show ip interface brief

! Full interface details including IP, mask, helpers
Router# show ip interface GigabitEthernet0/0

! Verify DHCP bindings on the router acting as DHCP server
Router# show ip dhcp binding

! Check DHCP pool configuration
Router# show ip dhcp pool

5. Step 4 – Test Gateway Reachability (Layer 3)

Once IP configuration is verified, test whether the host can reach its default gateway. This tests the entire local-segment path: the host NIC, the switch, and the router's ingress interface. If the gateway ping fails, the problem is local — between the host and the router.

5.1 The Layered Ping Test

The strategic ping sequence isolates where reachability fails:

Ping Target What a Success Proves What a Failure Indicates
127.0.0.1 (loopback) TCP/IP stack on the host is functional Host TCP/IP stack is broken — reinstall network driver or TCP/IP stack
Own IP address (e.g., 192.168.1.10) NIC and IP binding are working correctly on the host IP address not properly bound to the NIC
Default gateway IP (e.g., 192.168.1.1) Layer 1, 2, and local Layer 3 are all working; ARP resolved the gateway MAC Physical link problem, VLAN mismatch, wrong gateway IP, or gateway interface is down
Remote host in another subnet (e.g., 10.0.0.1) Routing is working — gateway is forwarding packets to the remote network Routing problem, ACL blocking traffic, NAT issue, or remote host down
DNS name (e.g., google.com) DNS resolution is working; full internet connectivity confirmed DNS server unreachable, misconfigured DNS, or DNS server itself down

5.2 Ping from a Cisco Router

! Standard ping (uses router's own IP as source)
Router# ping 192.168.1.10

! Extended ping — specify source interface or IP (for path verification)
Router# ping 10.0.0.5 source GigabitEthernet0/1

! Ping with repeat count and size
Router# ping 10.0.0.5 repeat 100 size 1500

! Check if ping succeeds from router but fails from host direction
Router# ping 192.168.1.10 source 10.0.0.1

See Ping Command for the complete guide to all ping options and output interpretation.

5.3 Interpreting Ping Output

Symbol Meaning Likely Cause
! (exclamation) Success — ICMP Echo Reply received Connectivity confirmed for this hop/destination
. (period) Timeout — no reply within the timeout period Destination unreachable; packet dropped by ACL or firewall; return path broken; ICMP blocked
U Destination Unreachable — ICMP type 3 received from an intermediate router No route to destination; ACL generating unreachable message; destination host is down
N Network Unreachable No route to the network in the routing table
H Host Unreachable Router has a route to the network but cannot reach the specific host (ARP failure, host down)
A Administratively Prohibited — ICMP type 3 code 13 Packet was denied by an ACL; check show ip access-lists for incrementing deny counters
? Unknown packet type Unusual response — check for routing loop or misconfigured tunnels

6. Step 5 – Check the Routing Table (Layer 3)

If the gateway is reachable but the destination is not, the problem is likely in the routing table — either on the near-end router, an intermediate router, or the far-end router. Use traceroute to identify exactly where the path breaks.

6.1 Routing Table Checks

! View the complete routing table
Router# show ip route

! Look for a specific destination prefix
Router# show ip route 10.0.2.0

! Verify which route will be used for a specific destination IP
Router# show ip route 10.0.2.55

! Check if a default route exists (0.0.0.0/0)
Router# show ip route | include 0.0.0.0

See show ip route for full output annotation and route code meanings.

6.2 Routing Table Key Codes

Code Route Source Default Admin Distance
C Connected — directly attached network 0
L Local — host route for the router's own interface IP 0
S Static route (manually configured) 1
D EIGRP 90 (internal) / 170 (external)
O OSPF 110
R RIP 120
B BGP 20 (eBGP) / 200 (iBGP)
* Candidate default route (best match for 0.0.0.0/0) —

6.3 Using Traceroute to Locate the Break

traceroute (Cisco) / tracert (Windows) sends packets with incrementing TTL values to map every hop in the path. The last hop that responds before timeouts begin is the router nearest the problem. 

! Cisco IOS traceroute
Router# traceroute 10.0.2.5

! Extended traceroute — specify source
Router# traceroute 10.0.2.5 source GigabitEthernet0/0

! Windows
C:\> tracert 10.0.2.5

! Linux
$ traceroute 10.0.2.5
$ tracepath 10.0.2.5      ! Alternative — no root required

6.4 Interpreting Traceroute Output

Output Pattern Meaning Next Action
All hops respond with IP addresses and RTTs Full path to destination is routable Problem is at application layer — check Step 6
Hops respond up to hop N, then * * * (timeouts) Router at hop N is the last to respond — the next router is not returning packets Check routing table on the router at hop N; check for ACL blocking ICMP TTL-exceeded messages
First hop times out immediately (* * *) Default gateway is unreachable from this source Return to Step 4 — gateway reachability problem
Loop — same IP addresses repeating Routing loop — two routers are forwarding to each other Check routing tables on both routers; look for conflicting static routes and dynamic protocol redistribution
Destination reached but RTT is very high Path is working but suboptimal — possible hair-pinning via a distant hub Check routing policy; verify expected path is used; check for suboptimal static routes

See Traceroute Command for the complete guide including extended traceroute options.

6.5 Common Routing Problems

Problem Symptom Diagnosis Command
Missing route Ping returns U (Unreachable) or . (timeout) show ip route <dest> — no matching entry found
Wrong next-hop Traceroute goes to unexpected destination; intermittent reachability show ip route <dest> — verify next-hop IP is reachable and correct
Routing loop Traceroute shows the same hops cycling; ping has very high RTT or returns TTL exceeded show ip route on multiple routers — find where two routers are pointing at each other
Asymmetric routing Ping succeeds but TCP sessions fail; stateful firewall drops return traffic from unexpected interface traceroute in both directions — compare forward and return paths
Missing return route Extended ping from router succeeds when sourced from one interface but not another ping <dest> source <int> — try different source IPs; check remote router has a return route

7. Step 6 – Check ACLs and NAT

If routing is correct but traffic is still blocked, an Access Control List (ACL) or a NAT misconfiguration is the most likely cause. ACLs are a common source of connectivity problems because they can block traffic silently — the packet is dropped without any ICMP response to the sender by default.

7.1 ACL Troubleshooting

! View all configured ACLs with match counters
Router# show ip access-lists

! View ACLs applied to a specific interface and direction
Router# show ip interface GigabitEthernet0/0 | include access list

! Show running config ACL section only
Router# show running-config | section access-list

See ACL Overview and Applying ACLs for direction and placement guidance, and show running-config to inspect the full ACL configuration.

7.2 ACL Troubleshooting Checklist

Check What to Look For Command
ACL applied to wrong interface or direction Standard ACL should be closest to destination; extended ACL closest to source; check inbound vs outbound direction show ip interface <int> — look for "Inbound access list" and "Outbound access list" fields
Deny counter incrementing A deny entry with an increasing match count indicates traffic is being dropped by this rule show ip access-lists — look for non-zero match counts next to deny statements
Implicit deny at end of ACL Every ACL ends with an implicit deny any that has no counter — traffic not matching any permit rule is silently dropped Review the ACL entries — if the destination traffic's permit rule is missing, it hits the implicit deny
Wildcard mask error ACL matches too much or too little traffic due to incorrect wildcard mask Manually calculate which hosts the ACE matches: bits where wildcard = 1 are ignored; bits where wildcard = 0 must match exactly
ACL blocks ICMP (ping) Ping fails but TCP applications work; or ICMP permitted but TCP blocked Check ACL for explicit ICMP permit/deny lines; remember ping result does not always reflect TCP reachability

7.3 NAT Troubleshooting

! View active NAT translations
Router# show ip nat translations

! View NAT statistics — hits, misses, expired entries
Router# show ip nat statistics

! Clear NAT translation table (forces re-translation)
Router# clear ip nat translation *

! Debug NAT in real time (use with caution)
Router# debug ip nat

See NAT Overview for the full NAT configuration reference.

NAT Problem Symptom Check
NAT ACL too narrow Some hosts reach the internet; others cannot — only certain source IPs are being NATted show ip nat translations — verify which source IPs have translation entries; check the NAT inside source ACL
inside / outside not set on interfaces All traffic bypasses NAT — hosts use private IPs on the internet show ip interface <int> | include NAT — verify "ip nat inside" and "ip nat outside" applied to correct interfaces
Static NAT conflict Traffic for the static NAT destination goes to wrong host show ip nat translations — check static entries; verify inside global IP is correct

8. Step 7 – Application Layer Checks (Layer 7)

If pinging the destination succeeds but the application still does not work, the problem has moved to Layer 7. Ping only tests ICMP reachability — a host can be pingable while its HTTP, DNS, or SSH service is down or blocked on a specific port.

8.1 Testing Specific Application Ports

! Test TCP port reachability from a Cisco IOS router (Telnet to a specific port)
Router# telnet 10.0.0.5 80       ! Test HTTP (port 80)
Router# telnet 10.0.0.5 443      ! Test HTTPS
Router# telnet 10.0.0.5 22       ! Test SSH

! From Windows — test TCP port with PowerShell
PS> Test-NetConnection -ComputerName 10.0.0.5 -Port 80
PS> Test-NetConnection -ComputerName 10.0.0.5 -Port 443

! From Linux — test TCP port
$ nc -zv 10.0.0.5 80
$ nc -zv 10.0.0.5 443 22
$ curl -v http://10.0.0.5      ! Full HTTP request test

! Test DNS resolution
$ nslookup google.com 8.8.8.8
$ dig @8.8.8.8 google.com

8.2 Application Layer Problem Checklist

Problem Symptom Diagnosis
Service not running Ping succeeds; TCP connection to the port fails (connection refused) Log into the server; verify the service is running (netstat -an or ss -tlnp on Linux; Services manager on Windows)
Firewall on the server Port reachable from the server itself but not remotely Check host-based firewall rules (iptables -L on Linux; Windows Firewall rules)
DNS resolution failure IP address ping succeeds; DNS name resolution fails nslookup <name> — check which DNS server is being queried; verify DNS server is reachable and has the correct record
Application misconfiguration Service is running and port is open; application returns errors Check application logs; verify server-side configuration (listen address, SSL certificate, database connectivity)
MTU / fragmentation Small pings succeed; large transfers fail; SSH connects but hangs after authentication ping 10.0.0.5 size 1500 df-bit — if large ping fails but small succeeds, MTU path discovery is broken; check for "ip tcp adjust-mss" on routers

9. Advanced Diagnostic Commands

When the standard troubleshooting steps do not reveal the problem, the following advanced tools provide deeper insight. Use debug commands with caution in production environments — they can consume significant CPU on busy routers.

Command Platform Purpose & Notes
debug ip packet Cisco IOS Shows every IP packet processed by the router CPU — including packets being forwarded, dropped, and generated locally. Use with an ACL to limit output: debug ip packet detail 101 where ACL 101 matches only the interesting traffic. Use carefully — extremely verbose on busy routers.
debug ip icmp Cisco IOS Shows ICMP messages sent and received — useful for understanding exactly what is happening with ping failures (unreachable messages, redirects)
debug ip routing Cisco IOS Real-time routing table changes — shows when routes are installed and removed; useful for flapping routes
show ip traffic Cisco IOS Global IP traffic statistics — total packets routed, fragmented, dropped, ICMP breakdown by type; good for spotting unexpected traffic patterns
show logging Cisco IOS Router syslog buffer — look for interface up/down events, OSPF neighbour changes, and ACL log messages that coincide with the problem timeframe
show processes cpu Cisco IOS CPU utilisation — if CPU is high (>70%), the router may be dropping packets due to overload; look for unusual processes consuming CPU
netstat -an Windows / Linux Shows all active TCP/UDP connections and listening ports on the host — confirms whether a service is listening on the expected port
tcpdump Linux Packet capture on a Linux host or router — captures traffic in real time for analysis with Wireshark: tcpdump -i eth0 host 10.0.0.5 -w capture.pcap
wireshark Windows / Linux GUI packet analyser — open PCAP files captured by tcpdump or a SPAN port; filter by IP, protocol, or port; follow TCP streams to inspect application handshakes

10. Complete Troubleshooting Scenario

Scenario: A user reports they cannot access a web server at 10.0.2.10 from their PC at 192.168.1.50. The web server is on a different subnet connected through two routers. See also End-to-End Troubleshooting Lab for a full hands-on version of this scenario.

Step Action Result Conclusion
1 Check physical connection and interface LED on the switch port LED is green; show interfaces Gi0/1 shows up/up Layer 1 and 2 OK — continue
2 ipconfig /all on the user's PC IP: 192.168.1.50/24, Gateway: 192.168.1.1, DNS: 8.8.8.8 IP config looks correct — continue
3 ping 192.168.1.1 (default gateway) 5/5 replies — success Local segment OK; gateway reachable — continue
4 ping 10.0.2.10 (web server) 0/5 replies — all timeouts (.....) Problem is beyond the gateway — could be routing, ACL, or server
5 traceroute 10.0.2.10 Hop 1: 192.168.1.1 (OK), Hop 2: 172.16.0.2 (OK), Hop 3: * * * (timeout) Router at hop 2 (172.16.0.2) is forwarding but hop 3 does not respond — check router at 172.16.0.2
6 Log into router at 172.16.0.2; run show ip route 10.0.2.10 No route to 10.0.2.0/24 — route is missing Root cause found — missing route to the server's subnet on the intermediate router
7 Add static route: ip route 10.0.2.0 255.255.255.0 172.16.0.3 ping 10.0.2.10 from the PC — 5/5 replies Problem resolved — restored routing; verify why the dynamic routing protocol did not advertise the route

11. Troubleshooting Quick-Reference Summary

Step Layer Key Command(s) What You Are Checking
1 Physical (L1) show interfaces, show ip int brief up/up status; error counters; duplex/speed
2 Data Link (L2) show vlan brief, show interfaces trunk, show spanning-tree VLAN assignment; trunk allowed VLANs; STP port state
3 Network — local (L3) ipconfig /all, ip addr, show ip int brief IP address; subnet mask; default gateway
4 Gateway reachability ping <gateway> ARP resolution; local segment connectivity
5 Routing (L3) show ip route, traceroute Route existence; correct next-hop; return path
6 ACL / NAT (L3–4) show ip access-lists, show ip nat translations Deny counters; ACL direction; NAT inside/outside
7 Application (L7) telnet <ip> <port>, Test-NetConnection, nc -zv, nslookup Port reachability; service running; DNS resolution

Test Your Knowledge – Connectivity Troubleshooting Quiz

1. A Cisco router interface shows "GigabitEthernet0/0 is administratively down, line protocol is down." What is the cause and fix?

Correct answer is B. "Administratively down" is the specific status that means the interface has been deliberately disabled with the shutdown command — it is not a hardware failure. The fix is always interface <int> then no shutdown. Contrast with "down / down" (no physical signal — hardware or cable issue) and "up / down" (physical link present but Layer 2 protocol failed). An IP address is not required for the line status to be up. See show interfaces for the full status interpretation guide.

2. A user's PC has the IP address 169.254.45.20. What does this indicate, and what is the first thing to check?

Correct answer is C. A 169.254.x.x address is an APIPA (Automatic Private IP Addressing) address — Windows and other OSes assign this when a DHCP request fails after several attempts (typically 4 retries over ~60 seconds). The PC is not broken; it simply did not receive a DHCP response. Check: (1) Is the DHCP server running? (2) Is there a relay agent (ip helper-address) on the gateway router if the server is on a different subnet? (3) Has the DHCP pool run out of addresses (show ip dhcp pool)? (4) Is the client in the correct VLAN?

3. You ping a destination and receive A symbols in the Cisco IOS ping output (e.g., A.A.A.A.A). What does this mean?

Correct answer is D. The A symbol in Cisco ping output means the router received an ICMP Destination Unreachable type 3, code 13 — "Communication Administratively Prohibited." This ICMP message is generated when an ACL with ip unreachables enabled denies the packet. The immediate next step is show ip access-lists on every router in the path to find which ACL has incrementing deny counters for the source/destination combination you are testing. Also check the direction (inbound vs outbound) of the ACL on the blocking interface. See Applying ACLs.

4. A user can ping their default gateway but cannot reach any remote subnet. What is the correct next step in the bottom-up troubleshooting workflow?

Correct answer is A. The systematic bottom-up approach requires following the workflow in order. Layer 1 (physical), Layer 2 (VLAN), and the local Layer 3 segment (gateway reachability via ping) have all been confirmed OK. The next layer is routing — can the router forward packets beyond the local subnet? Traceroute maps every hop and identifies exactly where the path ends; then show ip route on that router reveals whether a route to the destination exists and what the next hop is. Skipping straight to application (option D) or reloading equipment (option B) before routing is verified violates the methodology.

5. A network engineer is troubleshooting a route. show ip route 10.0.5.10 returns "% Network not in table" on Router-A. What does this mean and what should be checked next?

Correct answer is C. "% Network not in table" from show ip route means the router has no matching route for that destination — not even a default route (0.0.0.0/0) that would catch any packet. Any packet destined for 10.0.5.x arriving at this router will be dropped with an ICMP "Network Unreachable" sent back to the source. The next checks: (1) Does a default route exist? (show ip route | include 0.0.0.0); (2) Is the routing protocol supposed to be advertising this prefix? (show ip ospf database or similar); (3) Was a static route configured and accidentally removed?

6. Traffic between two hosts fails. show ip access-lists shows an ACL with a permit statement for the source subnet but the deny counter for the last implicit deny is incrementing. What does this tell you?

Correct answer is B. Every ACL ends with an invisible implicit deny ip any any that catches all traffic not matched by any earlier permit or explicit deny statement. If the implicit deny counter is incrementing, it means actual traffic is reaching the end of the ACL without matching any permit rule. Possible causes: (1) The permit statement has the wrong source/destination subnet; (2) The ACL is applied in the wrong direction (inbound vs outbound) — traffic arrives from the direction the permit was not written for; (3) A more specific deny entry earlier in the ACL is consuming the packets before the permit can match; (4) The permit is for TCP but the traffic is UDP or ICMP. See Applying ACLs.

7. A PC can ping the web server at 10.0.2.10 successfully (5/5 replies) but cannot load the web page in a browser. What layer of the OSI model should be investigated next?

Correct answer is A. A successful ping proves that Layers 1, 2, and 3 are all functioning — the IP reachability path is intact. ICMP ping does not test TCP port availability or application service status. The failure is at Layer 7: the HTTP/HTTPS service may be down, the firewall may be blocking TCP port 80/443, or a host-based firewall on the server is interfering. Test with telnet 10.0.2.10 80 from the router or nc -zv 10.0.2.10 80 from a Linux host to verify whether the TCP port is open and responding.

8. An ACL applied to a router's outbound interface is blocking all traffic even though the permit entries look correct. The engineer notices the ACL was applied as ip access-group 101 out. The ACL contains: 10 permit tcp 192.168.1.0 0.0.0.255 any eq 80. Traffic from 192.168.1.5 to the internet on port 80 is blocked. What is the most likely mistake?

Correct answer is D. This is the classic ACL placement and direction problem. The permit statement permit tcp 192.168.1.0 0.0.0.255 any eq 80 is syntactically correct. However, an outbound ACL on the WAN interface checks packets as they leave the WAN interface — at that point, the source IP is still 192.168.1.x (before NAT) only if NAT has not yet been applied, or it is a NATted public IP. The permit checks the pre-NAT source (192.168.1.0/24) which should match. However, the ACL only permits port 80. If port 443 (HTTPS) or port 53 (DNS) traffic is also needed and no permit exists for them, they hit the implicit deny. The best practice for extended ACLs is to place them inbound on the source interface (close to source) — and to ensure all required ports are permitted. See ACL Overview and Applying ACLs.

9. Traceroute to 10.0.2.10 shows hops 1 and 2 responding normally, then hops 3 and 4 show the same IP address repeating indefinitely. What is happening?

Correct answer is C. Seeing the same one or two IP addresses alternating repeatedly in traceroute output is the classic signature of a routing loop. Router A has a route to the destination pointing to Router B; Router B has a route pointing back to Router A — packets bounce between them until TTL expires. To fix: log into both routers at hops 3 and 4, run show ip route <dest> on each, and find the conflicting routes. Common causes: two static routes pointing at each other, or incorrect redistribution between routing protocols.

10. A network engineer runs ping 10.0.2.10 size 1500 df-bit from a Cisco router and it fails, but ping 10.0.2.10 (default 100-byte size) succeeds. What is the problem and how is it fixed?

Correct answer is B. This is a classic PMTUD (Path MTU Discovery) black hole symptom — small pings work, large pings with DF (Don't Fragment) bit set fail. It means a link in the path has an MTU smaller than 1500 bytes (common with tunnels like GRE, PPPoE, or MPLS) but the router generating the "Fragmentation Needed" ICMP message (type 3, code 4) is being blocked by a firewall or ACL. TCP sessions exhibit this as connecting but hanging after the handshake (SSH connects but hangs; HTTPS partial loads). Fix: ip tcp adjust-mss 1452 on the WAN interface clamps the TCP MSS in SYN packets, preventing hosts from sending full 1500-byte segments; or allow ICMP type 3 code 4 through firewalls. Use Wireshark to capture and confirm the ICMP unreachable type.

← Back to Home