Network Troubleshooting practice questions

Cable tester

Why wrong: Cable testers are used for wired cabling, not wireless signals.

Multimeter

Why wrong: Multimeters measure electrical properties like voltage and continuity, not RF signals.

Protocol analyzer

Why wrong: A protocol analyzer captures and decodes network traffic packets, but is less effective for physical RF signal issues.

netstat

Why wrong: Netstat displays active connections and listening ports, but does not trace the path to a remote host. It would not help identify where traffic is failing beyond the local gateway.

nslookup

Why wrong: Nslookup queries DNS servers to resolve hostnames to IP addresses. The user can already access local resources, but the problem is connectivity, not name resolution. If the issue were DNS, nslookup could help, but the scenario points to a routing problem.

arp

Why wrong: ARP resolves IP addresses to MAC addresses on the local network. Since the gateway is reachable, ARP is not the issue. ARP would not provide information about routing beyond the local subnet.

show vlan

Why wrong: 'show vlan' displays the VLAN database and which ports are in which VLANs, but it does not show which VLANs are allowed on a trunk interface.

show mac address-table

Why wrong: 'show mac address-table' displays MAC addresses learned on switch ports. It can help identify connectivity issues on specific VLANs but does not verify trunk configuration.

show ip route

Why wrong: 'show ip route' displays the router's routing table. While routing may be affected if the VLAN is not trunked, this command does not show trunking details.

tracert

Why wrong: tracert shows the route packets take to a destination, but since ping succeeded, the network path is functional, so this would not identify a DNS or application issue.

netstat

Why wrong: netstat displays current network connections and statistics, but it does not help diagnose name resolution or web server availability.

ipconfig

Why wrong: ipconfig shows network configuration on the local host, but since the user can access other internet sites, the local IP configuration is likely correct.

The DNS server is not responding

Why wrong: DNS failure would not cause an APIPA address; it would still get a valid IP from DHCP but fail name resolution.

The default gateway is misconfigured

Why wrong: A default gateway issue would affect off-subnet communication but not the IP address assignment; the device would still receive a valid DHCP IP.

There is a duplicate IP address on the network

Why wrong: A duplicate IP address would cause a conflict but not result in an APIPA address; the system would still have its configured IP.

B) DHCP lease time

Why wrong: Incorrect. If the DHCP lease expired, the user would likely lose all network connectivity, not just web browsing. Pinging the gateway would also fail.

C) Switch port speed and duplex settings

Why wrong: Incorrect. Speed/duplex mismatches usually cause complete or very frequent connectivity loss, not intermittent web browsing while pings succeed.

D) Firewall rules blocking ICMP

Why wrong: Incorrect. The fact that pings succeed indicates ICMP is not blocked. The firewall rules related to HTTP/HTTPS traffic could be an issue, but DNS is a more common cause of intermittent web failures.

B) Check the DNS resolution for the file server

Why wrong: Incorrect. The user can ping the gateway, so IP connectivity exists. If the user is pinging by IP, DNS is not involved. If by name, DNS failure would cause a different error.

C) Check the VPN encryption settings

Why wrong: Incorrect. Since the VPN tunnel is active and the user can ping the remote gateway, the encryption settings are likely correct for the tunnel. A mismatch would prevent any traffic through the tunnel.

D) Check the file server's antivirus software

Why wrong: Incorrect. Antivirus software on the file server could block certain traffic, but it would not cause a 'cannot connect' issue at the network level if routing is correct. It is less likely to be the first step.

show vlan brief

Why wrong: This command shows VLAN information but does not display trunk-specific allowed VLAN lists for each trunk interface.

show running-config interface

Why wrong: While this shows the configuration, it may not show the default allowed VLAN list if not explicitly configured; 'show interfaces trunk' is more direct.

show mac address-table

Why wrong: This command shows MAC address table entries, not trunk configuration.

The client's wireless adapter is faulty

Why wrong: If the adapter were faulty, the client likely would not associate successfully; it's not the most likely cause given association works.

The client's SSID is incorrect

Why wrong: If the SSID were incorrect, the client would not associate. Association is successful, so SSID is correct.

The AP's radio is operating on the wrong channel

Why wrong: Channel selection affects RF performance but does not prevent DHCP; association would still be possible on any channel.

B) DHCP server

Why wrong: The user already has an IP address (192.168.1.100), so the DHCP server is functioning. This is not the issue.

C) Router's firewall ACLs

Why wrong: While firewall ACLs could block internet traffic, the user can ping the gateway, so layer 3 connectivity exists. DNS is a more common cause and should be checked first.

D) Switch port VLAN assignment

Why wrong: If the VLAN were incorrect, the user would likely not have local connectivity. Since local resources are accessible, VLAN assignment is not the issue.

B) Incorrect default gateway

Why wrong: An incorrect gateway would prevent all outbound traffic, including IP-based access. Since IP access works, this is not the issue.

C) Duplicate IP address

Why wrong: A duplicate IP address would cause intermittent connectivity and possibly network errors, but it would not selectively affect name resolution.

D) Corrupted TCP/IP stack

Why wrong: A corrupted TCP/IP stack would likely cause issues with all network communication, including IP-based access.

Perform a traceroute to the external website to identify the point of failure.

Why wrong: Traceroute is useful for identifying path issues, but since external IPs are reachable (ping 8.8.8.8 works), the path is likely fine. The problem is with name resolution.

Check the Windows Firewall on the workstation to ensure it is not blocking outbound HTTP traffic.

Why wrong: If the firewall were blocking HTTP, the user would likely not be able to load any web pages, but the ability to ping external IPs suggests basic connectivity exists. The issue is specific to name resolution.

Renew the DHCP lease on the workstation.

Why wrong: The workstation already has a valid IP configuration and can reach internal and external IPs. Renewing the lease would not resolve a DNS-specific issue.

The default gateway is misconfigured.

Why wrong: A misconfigured gateway would likely prevent all external communication, including via IP address. Since the user can reach the website by IP, the gateway is working.

The web server's SSL certificate is expired.

Why wrong: An expired SSL certificate would cause a browser security warning but would not prevent accessing the site by IP address. Also, the issue is name resolution, not certificate validity.

The workstation's hosts file has an incorrect entry.

Why wrong: An incorrect hosts file entry could cause resolution failure, but it is less likely than a systemic DNS issue. The hosts file is checked before DNS, but the question states the user can access by IP, so a hosts entry for that domain would likely redirect to a different IP, not block access entirely.

Configure a static IP address on the workstation

Why wrong: While a static IP could resolve the issue temporarily, the root cause is likely DHCP, so statically assigning an IP bypasses the problem without fixing it. It is not the next step in standard troubleshooting.

Check the DNS server configuration on the workstation

Why wrong: DNS issues would not prevent the workstation from obtaining an IP address. APIPA is a link-local address assigned when DHCP fails, unrelated to DNS.

Replace the network cable

Why wrong: A faulty cable could cause connectivity issues but would not result in an APIPA address. APIPA assignment indicates the workstation attempted DHCP but received no response.

Faulty network cable

Why wrong: A faulty cable can cause errors, but the solid link LED indicates a physical connection. Duplex mismatch is a more common cause of CRC errors when the link is up.

Broadcast storm

Why wrong: A broadcast storm would cause high broadcast traffic on many ports, not necessarily CRC errors on a single port.

VLAN misconfiguration

Why wrong: VLAN misconfiguration typically causes connectivity issues (cannot reach resources) but does not directly result in CRC errors or runts.

The default gateway is misconfigured

Why wrong: A misconfigured default gateway would not cause an APIPA address; the client would still get a valid IP from DHCP.

The DNS server is down

Why wrong: A DNS issue would not affect IP address assignment; APIPA is unrelated to DNS.

The file server is offline

Why wrong: The file server being offline would not cause the client to have an APIPA address; the client would still have a valid IP.

IEEE 802.3

Why wrong: IEEE 802.3 defines Ethernet physical layer standards, but the specific wiring pinout is covered by TIA/EIA-568.

ISO 9001

Why wrong: ISO 9001 is a quality management standard, not a cabling specification.

RFC 1918

Why wrong: RFC 1918 defines private IP address ranges, not physical cabling standards.

The default gateway is misconfigured.

Why wrong: If the default gateway were misconfigured, the user would likely be unable to reach any external websites, not just one.

The DNS server is not resolving the domain name.

Why wrong: nslookup returned the correct IP, so DNS is working.

The subnet mask is incorrect.

Why wrong: An incorrect subnet mask would likely cause issues reaching all destinations, not just one.

The cable integrity with a tester

Why wrong: Since link lights are solid, the cable is likely functional at layer 1.

The DNS server settings

Why wrong: DNS is not involved in reaching the default gateway via IP.

The workstation's ARP cache

Why wrong: ARP cache issues would be a symptom, not a likely cause; the cache can be cleared, but the root cause is more likely a port configuration problem.

The DNS server is not responding

Why wrong: A DNS failure would not cause the workstation to obtain an APIPA address; the DHCP process would still complete successfully.

The subnet mask is incorrect

Why wrong: An incorrect subnet mask would be assigned by DHCP; the APIPA address indicates DHCP failure, not a misconfiguration.

The default gateway is down

Why wrong: A default gateway issue would not prevent DHCP lease acquisition; the workstation would still receive a proper IP address from DHCP.