Network Troubleshooting practice questions

tracert

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: This option is incorrect because 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 wrong: 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.

Verify the default gateway configuration

Why wrong: Since the user can reach the server by IP address, the default gateway is working; the issue is name resolution, not routing.

Renew the DHCP lease

Why wrong: Renewing the DHCP lease would reassign IP configuration but would not directly affect DNS resolution if the workstation already has correct DNS server addresses.

Disable the Windows Firewall

Why wrong: Firewall rules at the client could block DNS traffic, but since other users can resolve the name and the client can reach the DNS server, this is less likely than a local DNS cache issue.

The destination server is powered off.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: Port security can operate in restrict or shutdown mode; the default shutdown mode disables the port entirely.

Check the DNS server configuration.

Why wrong: The workstation does not have a valid IP address, so DNS is not yet a factor. The issue is with IP address assignment.

Replace the network cable between the wall jack and the workstation.

Why wrong: The link light is green, indicating a good physical connection. Cable replacement is unlikely to resolve the issue.

Verify the default gateway setting on the workstation.

Why wrong: The default gateway cannot be reached because the workstation does not have a valid IP address. The root cause is the missing DHCP lease.

Incorrect DNS server configuration on the workstation

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Session layer (Layer 5)

Why wrong: 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 wrong: 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 wrong: 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.

Incorrect encryption settings

Why wrong: Incorrect encryption would prevent clients from associating or authenticating, not cause intermittent slow performance.

Incorrect SSID configured

Why wrong: An incorrect SSID would prevent clients from seeing the network at all.

Low antenna gain on the access points

Why wrong: The survey indicated adequate signal strength, so antenna gain is not the issue.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 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: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 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: 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 wrong: 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 wrong: 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.