Network Troubleshooting practice questions

tracert

Why it fails: tracert (or traceroute on Linux/macOS) maps the network path by displaying the sequence of routers (hops) that packets traverse to reach a destination. Since the user can successfully ping the internal web server, it confirms that basic network connectivity exists and the route to the server is functional. Therefore, tracert would not provide useful diagnostic information for a problem that occurs after network reachability is established, such as a name resolution failure or an application-layer issue.

netstat

Why it fails: netstat is a command-line utility that displays active network connections, routing tables, interface statistics, and open ports on the local machine. While it can show if a web server is listening on port 80 or 443, it only becomes relevant after a connection attempt has been initiated and potentially failed at the transport layer or higher. It does not assist in diagnosing why a hostname ('intranet') cannot be translated into an IP address in the first place, which is the preceding step to establishing a connection.

ipconfig

Why it fails: ipconfig (or ifconfig/ip addr on Linux) displays the current TCP/IP network configuration of the local host, including IP address, subnet mask, default gateway, and DNS server addresses. While checking local DNS server configuration is part of troubleshooting, the fact that the user can access other internet sites successfully implies that the client's fundamental IP configuration, including its DNS server settings, is generally correct and functional for external lookups. Thus, ipconfig alone would not directly diagnose why a specific internal hostname fails to resolve.

The default gateway is misconfigured.

Why it fails: A misconfigured default gateway would prevent the user's device from sending any traffic to destinations outside its local subnet. Since the default gateway is the first hop for all external communications, its incorrect setting would render the user unable to access any internet resources, including all websites, email servers, and cloud services. The problem specifically states an inability to reach a specific website, implying that other external connectivity is likely functional, thus ruling out a default gateway misconfiguration.

The DNS server is not resolving the domain name.

Why it fails: The problem statement implies that DNS resolution is successful. If `nslookup` or a similar tool returns the correct IP address for the website's domain name, it confirms that the DNS server is functioning properly and has successfully translated the human-readable domain into a machine-readable IP address. Without successful DNS resolution, the user's device would not even know which IP address to attempt to contact, leading to a "host not found" error rather than an inability to reach the site at a known IP.

The subnet mask is incorrect.

Why it fails: An incorrect subnet mask would fundamentally disrupt the device's ability to determine whether a destination IP address is on the local network segment or requires routing through a gateway. Such a misconfiguration would typically lead to widespread network connectivity issues, preventing the user from reaching most, if not all, external resources and potentially even other local devices. The problem describes an isolated issue with a single website, making a global network configuration error like an incorrect subnet mask highly unlikely.

Check the DNS server configuration on the network

Why it fails: DNS server configuration would affect all users on the subnet, not just one.

Check the website's DNS records

Why it fails: The website's DNS records would affect all users globally, not just one client.

Check the user's browser proxy settings

Why it fails: Proxy settings could affect access but typically wouldn't allow access by IP while blocking by domain name, and other users would likely be affected if proxy is the issue.

The destination server is powered off.

Why it fails: If the destination server is powered off, the traceroute would successfully traverse all intermediate routers until it reaches the final router responsible for the server's local subnet. At this point, the last router would attempt to resolve the server's MAC address via ARP or directly forward the packet to the server's IP. Since the server is unresponsive, the last router would not receive a reply, causing the traceroute to time out at that *final* hop, not at an intermediate router further upstream in the network path.

The router is blocking ICMP echo requests.

Why it fails: If an intermediate router is configured to block ICMP echo requests or ICMP Time Exceeded messages, it would simply not respond to the traceroute probes. While this would cause the traceroute to display asterisks or 'Request timed out' for that specific hop, the router would still typically decrement the packet's Time-to-Live (TTL) and attempt to forward the packet to the next hop, assuming its routing table permits. Therefore, the traceroute would likely continue to attempt to discover subsequent hops, which might also show timeouts, rather than completely hanging at that single router without any further progress.

There is a routing loop.

Why it fails: A routing loop would cause packets to be continuously forwarded between two or more routers, never reaching their intended destination. In a traceroute output, this scenario would typically manifest as a repetitive sequence of router IP addresses appearing in the trace, or a very long series of hops until the packet's Time-to-Live (TTL) value eventually expires. The traceroute would not simply stop and time out at a single intermediate router; instead, it would show many hops, often repeating, before ultimately displaying 'Request timed out' messages after the TTL is exhausted.

The phone will work but the computer will not

Why it fails: Port security blocks all traffic from the second MAC, but the switch will typically disable the entire port, not just the computer's traffic.

Both devices will work because the phone uses a different MAC

Why it fails: The phone and computer have two unique MAC addresses, exceeding the limit, so a violation occurs.

The switch will allow only the first learned MAC and block the second

Why it fails: Port security can operate in restrict or shutdown mode; the default shutdown mode disables the port entirely.

Incorrect DNS server configuration on the workstation

Why it fails: An incorrect DNS server configuration primarily impacts name resolution, which is the process of translating human-readable domain names into IP addresses. When a user attempts to ping a specific IP address, like 8.8.8.8, the DNS service is entirely bypassed because the destination address is already provided in numerical format. Therefore, a misconfigured DNS server would not prevent direct IP-level connectivity or the ability to ping an external IP address, making it an unlikely cause for this specific troubleshooting scenario.

Incorrect subnet mask on the workstation

Why it fails: An incorrect subnet mask on the workstation would fundamentally alter how it determines whether a destination IP address resides on the local network or a remote network. If the subnet mask were misconfigured, the workstation might incorrectly attempt to send local traffic through the gateway or remote traffic directly. However, the ability to successfully ping both internal hosts and the default gateway confirms that the workstation correctly identifies its local network segment and can communicate within it, ruling out a subnet mask error as the cause for external internet access failure.

Malware on the workstation is blocking ICMP traffic

Why it fails: If malware on the workstation were actively blocking ICMP traffic, the user would typically experience failures when attempting to ping any destination, regardless of whether it's internal or external. The successful pings to internal hosts and the default gateway demonstrate that the workstation's ICMP functionality is operational and not being obstructed locally. Therefore, the issue preventing external pings to 8.8.8.8 is not due to local malware interfering with the ICMP protocol on the workstation itself.

Incorrect VLAN assignment

Why it fails: An incorrect VLAN assignment means the workstation's network interface is configured for a virtual LAN that does not correspond to its intended IP subnet or the network segment it needs to access. This typically results in a complete and consistent lack of logical connectivity to the desired resources, as traffic is either dropped or routed to an unintended broadcast domain. While the physical link light would usually be solid green, indicating Layer 1 connectivity, the issue would not manifest as intermittent connectivity with a slow blinking LED.

Bad cable

Why it fails: A physically damaged or improperly terminated network cable typically results in a complete loss of link, meaning no link light at all, or an extremely unstable link with a very high rate of physical layer errors. While some marginal cables might cause intermittent issues, they rarely present specifically with a slow blinking link light; instead, the connection would likely drop entirely or show a solid but error-prone state. Given that the cable was already checked, this option is less probable for the described symptoms.

Spanning Tree blocking

Why it fails: When a switch port is in a Spanning Tree Protocol (STP) blocking state, it is intentionally preventing data traffic from passing through to avoid network loops. In this operational mode, the port's link light typically remains solid green, indicating physical layer connectivity is established, but no user data frames are forwarded. This state is a deliberate and consistent loop prevention mechanism, meaning it would not cause intermittent connectivity with a slow blinking LED, as the port is either forwarding or consistently blocking.

The default gateway is down.

Why it fails: If the default gateway were down, the user would not be able to ping any external IP addresses. The fact that pinging 8.8.8.8 works rules this out.

The corporate firewall is blocking UDP port 53.

Why it fails: A firewall block on UDP port 53 would cause DNS failures consistently, not intermittently. The user would never be able to resolve domain names.

The user's machine has a corrupted DNS cache.

Why it fails: A corrupted DNS cache typically causes failures for specific cached entries, but the issue is described as intermittent and affects all domain names. Flushing the cache might resolve it, but the intermittent nature points more to server load.

Session layer (Layer 5)

Why it fails: The Session layer (Layer 5) is tasked with establishing, managing, and terminating communication sessions between applications. While it handles dialogue control and synchronization, HTTP is a stateless protocol that primarily manages its own 'sessions' (e.g., through cookies or application-level state) at the Application layer. Given that lower-layer communication is functional, a direct failure at the Session layer itself is a less likely culprit compared to issues within the specific web application or service operating at Layer 7.

Transport layer (Layer 4)

Why it fails: Since the firewall allows HTTP traffic, a Transport layer block is unlikely. If it were a port issue, ping would still work, but the symptom would be consistent with a firewall block. However, the most likely cause is the Application layer.

Network layer (Layer 3)

Why it fails: The Network layer (Layer 3) is responsible for logical addressing (IP addresses) and routing packets across different networks. A successful `ping` command, which uses ICMP at Layer 3, confirms that IP connectivity exists between the client and the server. This indicates that IP addresses are correctly configured, and routers are forwarding packets appropriately, thereby ruling out a Network layer issue as the primary cause of the web page access problem.

The router's WAN interface is configured with the wrong subnet mask

Why it fails: If the router's WAN interface were configured with an incorrect subnet mask, it would fundamentally impair the router's ability to communicate with devices on its directly connected WAN segment. This misconfiguration would likely prevent the router from even establishing basic Layer 3 connectivity, meaning it would be unable to successfully ping the ISP gateway at 192.0.2.1. The ability to ping the gateway rules out a basic interface IP or subnet mask misconfiguration as the root cause.

NAT is not configured on the router

Why it fails: While Network Address Translation (NAT) is essential for allowing multiple private IP addresses to share a single public IP for internet access, its absence is not the immediate problem indicated by the symptoms. The fact that the router can ping the ISP gateway but has an incorrect default route next-hop points to a fundamental routing issue. The router isn't even correctly attempting to forward traffic to the internet; it's sending it to the wrong place before NAT would even come into play for address translation.

A firewall on the router is blocking outbound traffic

Why it fails: A firewall on the router blocking outbound traffic is unlikely to be the primary issue in this scenario. If a firewall were actively blocking all outbound traffic, the router would typically fail to ping the ISP's gateway (192.0.2.1) in the first place. Since the router can successfully reach the ISP gateway, the problem lies further down the forwarding path, specifically with how the router is instructed to handle traffic destined for networks beyond its immediate next-hop.

The router is configured with an ACL that blocks traffic from VLAN 10 to VLAN 20

Why it fails: An Access Control List (ACL) on the router could indeed filter traffic between VLANs if inter-VLAN routing is otherwise correctly configured. However, an ACL only processes packets that the router *intends* to forward. If the router lacks a route to the destination VLAN 20 subnet entirely, packets from VLAN 10 would be dropped before any ACL could even evaluate them for blocking.

The switch port connecting the user to the network is configured with port security limiting MAC addresses

Why it fails: Port security limits the number of MAC addresses allowed on a switch port. If enabled and exceeded, it would typically disable the port or drop frames from unauthorized MAC addresses, preventing all network access for the user, not just inter-VLAN communication. Since the user can communicate within their own VLAN, port security is not the root cause of the specific inter-VLAN issue.

The file server has a firewall blocking ICMP ping requests

Why it fails: A firewall on the file server could block specific types of traffic, such as ICMP ping requests or the particular file sharing protocol. However, the user's report of 'cannot access' typically implies a complete inability to establish any connection, not just a failed ping. If only ping was blocked, other services might still be accessible, which contradicts the general nature of the problem described, suggesting a more fundamental network layer issue.

802.3ab: Gigabit Ethernet standard using fiber optic cabling.

Why it fails: This statement is incorrect because IEEE 802.3ab specifically defines 1000BASE-T, which is the standard for Gigabit Ethernet over unshielded twisted pair (UTP) copper cabling. It utilizes all four pairs of wires within a Cat5e or higher cable to achieve 1 Gbps speeds over distances up to 100 meters. Fiber optic cabling for Gigabit Ethernet is defined by other standards, such as 802.3z, not 802.3ab.

802.3z: Gigabit Ethernet standard using twisted pair cabling.

Why it fails: This statement is incorrect because IEEE 802.3z defines the 1000BASE-X family of standards, which are specifically designed for Gigabit Ethernet over fiber optic cabling. This includes specifications like 1000BASE-SX for multimode fiber and 1000BASE-LX for single-mode or multimode fiber, supporting various distances. Twisted pair cabling for Gigabit Ethernet is instead defined by the 802.3ab standard (1000BASE-T), making this option's description inaccurate.

Cable tester

Why it fails: A cable tester is specifically designed to verify the integrity and proper termination of physical wired network cables, such as Ethernet or fiber optic. It checks for continuity, shorts, opens, and correct wiring schemes (e.g., T568A/B). Since the problem describes intermittent connectivity on a laptop that moves between floors, implying a wireless connection, a cable tester would be completely irrelevant as it provides no insight into radio frequency (RF) signal quality or interference.

Multimeter

Why it fails: A multimeter is an electrical testing device used to measure fundamental electrical properties such as voltage (AC/DC), current (amperage), and resistance (ohms), and can also test for continuity. While essential for diagnosing power supply issues or checking electrical circuits, it is not designed to detect, measure, or analyze radio frequency (RF) signals. Consequently, a multimeter would offer no diagnostic value for troubleshooting intermittent wireless connectivity problems related to signal strength or interference.

Protocol analyzer

Why it fails: A protocol analyzer, also known as a packet sniffer, operates at higher layers of the OSI model, capturing and decoding network traffic to inspect headers and payloads. While useful for diagnosing logical network issues like misconfigurations, dropped packets due to software errors, or application performance problems, it cannot directly visualize or measure the physical radio frequency (RF) environment. Therefore, it would not effectively identify the root cause of intermittent connectivity stemming from RF interference or weak signal strength.

netstat

Why it fails: Netstat (network statistics) is a command-line utility that displays various network information on the local host, including active connections, listening ports, routing tables, and interface statistics. While useful for examining the local machine's network state or verifying local routing table entries, `netstat` does not trace the path packets take across multiple network hops to a remote destination. It cannot identify intermediate routers or pinpoint where traffic is being dropped or failing to forward beyond the local gateway, making it unsuitable for diagnosing external routing problems.

nslookup

Why it fails: 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 it fails: The Address Resolution Protocol (ARP) is a Layer 2 protocol used to resolve IP addresses to MAC addresses exclusively within a local broadcast domain or subnet. Since the user can access local resources, their device is successfully performing ARP resolution for the local gateway. ARP provides no visibility into network paths or routing beyond the immediate local segment, making it ineffective for diagnosing internet connectivity issues that occur past the local router.

show vlan

Why it fails: The `show vlan` command displays the local VLAN database on the switch, outlining which access ports are assigned to specific VLANs and the overall status of each VLAN. While it confirms the existence of a VLAN and its local port memberships, it does not provide any information about the configuration of trunk links between switches, nor does it indicate which VLANs are permitted to traverse those trunks. Therefore, it cannot identify if a VLAN is blocked from passing between switches.

show mac address-table

Why it fails: The `show mac address-table` command reveals the MAC addresses learned by the switch, indicating which MACs are reachable via specific ports and VLANs. While a lack of learned MAC addresses for affected users might suggest a connectivity problem, this command primarily reflects the *result* of traffic flow, not the underlying configuration issue preventing that flow. It does not provide details about trunk link configuration or the allowed VLANs, which is the likely culprit after a switch replacement.

show ip route

Why it fails: The `show ip route` command displays the IP routing table, which is primarily relevant for Layer 3 communication between different IP subnets or VLANs. Since the problem describes users in the *same* VLAN experiencing issues, their communication within that VLAN is a Layer 2 function. While a trunking issue could indirectly impact inter-VLAN routing by preventing a VLAN's Switched Virtual Interface (SVI) from being reachable, this command provides no information about the Layer 2 trunk configuration itself, making it unsuitable for diagnosing a direct trunking problem.

The DNS server is not responding

Why it fails: A non-responsive DNS server prevents a device from resolving human-readable hostnames into numerical IP addresses, which is crucial for accessing websites or network shares by name. Despite this, a DNS failure does not interfere with the DHCP process itself; the client would still successfully obtain a valid IP address, subnet mask, and default gateway. The device would retain its network connectivity and could still access resources directly by their IP addresses, just not by their names.

The default gateway is misconfigured

Why it fails: A misconfigured default gateway primarily impacts a device's ability to route traffic to destinations outside its local subnet, such as the internet or other VLANs. However, the default gateway setting does not influence the process of obtaining an IP address from a DHCP server. The device would still successfully acquire a valid IP configuration, allowing it to communicate with other devices on its local segment, even if it cannot reach external networks.

There is a duplicate IP address on the network

Why it fails: A duplicate IP address on the network leads to an IP conflict, where two devices attempt to use the same unique identifier, causing intermittent connectivity issues and error messages for one or both systems. While disruptive, an IP conflict does not trigger the assignment of an APIPA address; the system would continue to attempt using its configured, albeit conflicting, IP address. APIPA is specifically a fallback mechanism for when a DHCP server cannot be reached to provide *any* IP configuration.

B) DHCP lease time

Why it fails: An expired DHCP lease, if not successfully renewed, would typically cause the client to lose its assigned IP address, subnet mask, and gateway information. This fundamental loss of network configuration would result in a complete inability to communicate on the network, preventing even basic connectivity like pinging the local gateway. Therefore, it would manifest as a total network outage rather than just intermittent web browsing.

C) Switch port speed and duplex settings

Why it fails: Firewall rules specifically blocking ICMP traffic would prevent successful ping responses, which contradicts the scenario where underlying IP connectivity is implied to be functional. While a firewall could certainly block HTTP/HTTPS traffic, the success of ping operations indicates that the network path is open at the ICMP level. Intermittent web browsing points to a higher-layer service issue rather than a blanket block on a specific protocol like ICMP.

D) Firewall rules blocking ICMP

Why it fails: A mismatch in speed or duplex settings between a network interface card and a switch port typically results in severe network performance degradation, high collision rates, or a complete loss of link connectivity. This would manifest as extremely slow or entirely non-functional network access for all traffic types, not just intermittent web browsing while basic IP-level pings remain successful. Such a physical layer issue would impact all network communications consistently.

B) Check the DNS resolution for the file server

Why it fails: Checking DNS resolution for the file server is incorrect because the user can ping the remote gateway, confirming basic IP-level connectivity through the VPN. If the user is attempting to connect to the file server using its IP address, DNS is not involved in the process. Even if connecting by hostname, a DNS failure would typically manifest as a 'host not found' error, whereas a 'cannot connect' message often points to a deeper network layer problem like routing after successful name resolution.

C) Check the VPN encryption settings

Why it fails: Checking VPN encryption settings is incorrect because the user can successfully ping the remote gateway, indicating the VPN tunnel is established and operational at a fundamental level. Mismatched encryption algorithms, authentication methods, or pre-shared keys would typically prevent the tunnel from forming or passing any traffic whatsoever. Since basic connectivity through the tunnel exists, the issue is likely not with the VPN's foundational security parameters.

D) Check the file server's antivirus software

Why it fails: 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 it fails: The `show vlan brief` command displays a summary of all configured VLANs on the switch, including their names and the access ports assigned to them. While useful for verifying VLAN existence and port assignments, it does not provide any information about trunk link configurations, such as which VLANs are allowed or disallowed on a specific trunk interface. Therefore, it cannot directly diagnose why a particular VLAN might not be communicating across a trunk.

show running-config interface

Why it fails: The `show running-config interface <interface-id>` command displays the specific configuration commands applied to a particular interface from the active running configuration. While it would show explicitly configured `switchport trunk allowed vlan` statements, it might not reveal the *effective* allowed VLAN list if no explicit configuration exists (which defaults to all VLANs). More importantly, it doesn't show the dynamic operational status, such as whether the trunk has actually formed or if there are negotiation issues, making `show interfaces trunk` a more complete diagnostic tool.

show mac address-table

Why it fails: The `show mac address-table` command displays the switch's MAC address table, which maps MAC addresses to specific interfaces and VLANs. This table is crucial for understanding how the switch forwards frames to known destinations. However, it provides no information about the configuration or operational status of trunk links or the VLANs allowed to traverse them, making it irrelevant for diagnosing issues related to VLAN communication across inter-switch trunks.

The client's wireless adapter is faulty

Why it fails: A faulty wireless adapter on the client would typically manifest as an inability to detect wireless networks, failure to associate with any AP, or persistent disconnections. Given that the client successfully associates with the AP, the core functionality of the adapter to establish a physical and data link layer connection is confirmed to be operational. While a very specific, subtle fault *could* theoretically interfere with DHCP traffic, it is far less probable than a network configuration issue when the primary association process functions correctly.

The client's SSID is incorrect

Why it fails: If the client's SSID were incorrect, the initial association process with the Access Point (AP) would fail entirely. The SSID (Service Set Identifier) acts as the network name, and a client must precisely match the AP's broadcast SSID to initiate the authentication and link-layer connection. Since the question explicitly states the client *can* associate, this indicates the SSID is correctly configured on the client, making this option an invalid cause for a DHCP failure.

The AP's radio is operating on the wrong channel

Why it fails: The AP's radio operating on a 'wrong' channel primarily impacts the quality and reliability of the wireless connection, not the fundamental ability to associate or process network protocols like DHCP. While an overly congested or non-standard channel might lead to poor signal strength, high latency, or dropped packets, it does not inherently prevent a client from establishing an initial association with the AP. Once associated, the client can still attempt DHCP, even if the channel performance is suboptimal, meaning this is not the direct cause of a DHCP failure.