Why Can't the Host Route Traffic to the SSH Server?
Short answer
C The host does not have a route to the server.
Question
- 
Key Takeaways
Examines routing table interpretation to identify unreachable subnets, with test-takers often falling into the trap of blaming firewalls or daemons instead of checking basic IP routing.
This N10-008 practice question evaluates your ability to diagnose Layer 3 connectivity failures using command-line routing outputs. Community experts unanimously agree that the missing destination network in the host’s routing table prevents SSH communication.
Common mistake: Option A is frequently selected because SSH timeouts typically suggest firewall interference; however, the routing table explicitly shows no path to the server’s 10.10.10.0 subnet, ruling out application-layer blocks.
Expert Analysis
Why the Answer Is Correct
The host’s routing table contains only a default route and a direct route for 192.168.1.0/24, while the target server resides at 10.10.10.15. Without a matching route or a functional default gateway pointing toward that subnet, the host drops the packets immediately. As noted in the top-voted explanation, the absence of a 10.10.10.0 route directly explains the connection timeout.
Why the Other Options Are Wrong
A firewall block would typically allow ARP and initial TCP handshakes to proceed before dropping packets, which contradicts the routing table evidence. Plugging into a trunk port might cause VLAN mismatches but would not alter the host’s internal routing table. Similarly, a stopped SSH daemon would result in a connection refused error rather than a routing failure.
Community Comment Notes
Users highlighted that the default gateway shown is not on the same subnet as the server, reinforcing the routing gap. Multiple commenters confirmed that tracing the packet flow against the displayed routes quickly isolates Option C as the only logical conclusion. The overwhelming vote distribution reflects strong alignment with this Layer 3 troubleshooting approach.
Official Reference
These links open the official vendor documentation in a new tab.
Exam Strategy
Always verify Layer 3 reachability before investigating application-layer services. When presented with routing table outputs, cross-reference every destination IP against the listed networks and gateways to quickly eliminate distractors.
Community Votes
100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 3 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 3
-
72abe44 👍 3Although a gateway is listed, it is not on the 192.168.1. network
-
a87d6a4 👍 2 Answered CLooking at the second part of the image, the routing table on the host shows two routes: A default route pointing to 31.242.12.9 via interface eth0. A route for the 192.168.1.0 network via eth1. However, the server's IP (10.10.10.15) is in a different network, which does not appear in the host's routing table. As a result, the host has no route to reach the 10.10.10.0 network, meaning the traffic isn't being directed properly to the server. Thus, the host needs a route added for the 10.10.10.0 network to resolve this connectivity issue.
-
HENOKK 👍 1B. The server is plugged into a trunk port. This configuration could result in inconsistent behavior when accessing services on the server, particularly if the server is not VLAN-aware and cannot process the tagged traffic properly.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.