Why Can't the Host Route Traffic to the SSH Server?
A network technician is troubleshooting an issue that involves connecting to a server via SSH. The server has one network interface that does not support subinterfaces. The technician runs a command on the server and receives the following output: On the host, the technician runs another command and receives the following: Which of the following best explains the issue? -
- 
Community Votes
100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
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.
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.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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
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.