Question

Difficulty: Very hardTroubleshooting Routing, Default Gateways, and ACLs

A workstation at 10.20.1.50/2410.20.1.50/24 cannot access an internal application server at 172.16.50.10172.16.50.10. The administrator suspects a default gateway mismatch, a missing static route, or an Access Control List (ACL) dropping the traffic on the core Layer 3 switch. Place the following troubleshooting steps in the correct sequential order according to standard network troubleshooting methodology.

  1. 1Run `ping 10.20.1.1` and `traceroute 172.16.50.10` from the workstation to determine if packets reach the local default gateway.
  2. 2Review the core switch's `show ip access-lists` and `show ip route` outputs to hypothesize why traffic to 172.16.50.10172.16.50.10 is failing.
  3. 3Execute a targeted ping test from the gateway router CLI sourced from 10.20.1.110.20.1.1 toward 172.16.50.10172.16.50.10 to verify if the ACL on the ingress interface is dropping host packets.
  4. 4Modify the ingress ACL statement on the core switch to explicitly permit host traffic to 172.16.50.10172.16.50.10 and re-apply it to the interface.
  5. 5Confirm the workstation can successfully query 172.16.50.10172.16.50.10 over TCP port 443 and record the updated ACL entry in the network change log.

Answer

The correct sequence follows standard network troubleshooting methodology: 1) Run `ping` and `traceroute` from the workstation to isolate local vs. remote failure; 2) Review switch routing tables and ACL rules to establish a cause theory; 3) Test the theory using controlled CLI commands from the gateway; 4) Update the ingress ACL on the core switch; 5) Verify end-to-end host connectivity and update network documentation logs.
The proper troubleshooting sequence follows standard CompTIA methodology: gather initial host diagnostics (`ping`/`traceroute`), examine gateway configuration states to form a hypothesis, test the theory via targeted CLI tests, implement the corrective ACL statement, and verify end-to-end application functionality before documenting the outcome.

Step-by-Step Solution

1
Gather symptoms and isolate the layer/location of failure using host CLI diagnostic commands.
Determines whether the issue resides at the local NIC, default gateway interface, or upstream routing hop.
Troubleshooting must begin by identifying the problem scope before examining network infrastructure configurations.
2
Analyze gateway routing tables (`show ip route`) and interface ACL configurations (`show ip access-lists`).
Identifies potential misconfigurations such as implicit deny ACL entries or missing summary routes.
This establishes a plausible theory of probable cause based on empirical device configuration data.
3
Test the ACL hypothesis using diagnostic command simulations from the router CLI.
Confirms whether ingress packet filtering or dynamic routing table updates caused the drops.
The theory must be empirically tested and validated prior to executing changes on production equipment.
4
Apply the updated ACL permit entry to the appropriate switch VLAN interface.
Permits host traffic through the default gateway to the remote server subnet.
Implementing the solution resolves the verified root cause.
5
Verify application-layer connectivity from the client host and document the resolution.
Ensures full system functionality and maintains accurate operational change records.
Final phases require confirming complete service restoration and recording change management details.

Key Concept

CompTIA Network Troubleshooting Methodology applied to Default Gateways, Routing, and ACLs
Rate this question