CCNA Network Troubleshooting Questions — Page 2 of 2

MCQeasy

A user reports that they cannot access the internet. The network technician checks the workstation's IP configuration and finds the IP address 169.254.15.77. What does this address indicate?

A.The workstation has a static IP address configured.

B.The DHCP server is unreachable.

C.The DNS server is down.

D.The default gateway is misconfigured.

AnswerB

When a workstation is configured for dynamic IP addressing (DHCP) but cannot locate or communicate with a DHCP server, it resorts to Automatic Private IP Addressing (APIPA). This process assigns an IP address from the 169.254.0.0/16 range. Since APIPA addresses are non-routable and intended only for local link communication, the workstation cannot obtain a valid network configuration, including a default gateway, thus preventing internet access.

Why this answer

The IP address 169.254.15.77 falls within the Automatic Private IP Addressing (APIPA) range (169.254.0.0/16, per RFC 3927). This address is automatically assigned by the operating system when a DHCP client fails to receive a lease from a DHCP server, indicating that the DHCP server is unreachable or not responding.

Exam trap

The trap here is that candidates often confuse APIPA with a DNS failure or gateway issue, but APIPA specifically indicates a DHCP lease failure, not a problem with higher-layer services like DNS or routing.

Why the other options are wrong

A 169.254.x.x address is an Automatic Private IP Addressing (APIPA) address, assigned when a DHCP server is unreachable. A static IP address would be manually configured and not fall in this range.

The IP address 169.254.15.77 is an Automatic Private IP Addressing (APIPA) address, which indicates that the workstation failed to obtain an IP from a DHCP server. DNS server issues do not cause APIPA addresses; they affect name resolution after IP configuration.

A 169.254.x.x address is an Automatic Private IP Addressing (APIPA) address, assigned when DHCP fails. A misconfigured default gateway would not cause the workstation to self-assign an APIPA address; it would still receive a valid DHCP lease but lack connectivity.

Practice this question →

MCQeasy

A network technician sees that the link light on a switch port is not lit, even though the cable is connected to an active device. The port has been tested with a known good cable. Which of the following should the technician do next?

A.Replace the switch

B.Check if the port is administratively disabled

C.Check the VLAN configuration

D.Check the speed/duplex settings

AnswerB

When a switch port is administratively disabled, it is intentionally taken offline by a network administrator. This state prevents the port from establishing a physical link, resulting in no link light illumination, regardless of whether a cable is connected or a device is attached. Verifying the port's operational status using CLI commands like 'show interface <interface_id> status' is the crucial first step, and if found disabled, the 'no shutdown' command can reactivate it.

Why this answer

When a link light is off despite a known good cable and an active device, the most likely cause is that the switch port is administratively disabled (shutdown). This is a common Layer 1/2 issue where the interface is configured with the 'shutdown' command, preventing the port from negotiating a link. Checking the interface status with 'show interfaces status' or 'show interfaces [interface]' will confirm if the port is in an 'administratively down' state.

Exam trap

The trap here is that candidates often jump to VLAN or hardware failure (replace the switch) because they forget that an administratively down port is a common Layer 1 misconfiguration that completely prevents link establishment, even with a good cable and active device.

Why the other options are wrong

Replacing the switch is an extreme and premature action; the issue is likely isolated to a single port, and the switch itself is probably functional. The technician should first check for administrative disablement before considering hardware replacement.

The link light not lit indicates a Layer 1 or Layer 2 connectivity issue, not a VLAN mismatch. VLAN configuration problems typically allow the link to come up but prevent traffic forwarding, so checking VLAN config is premature before verifying basic port status.

Speed/duplex mismatches typically cause packet errors or slow performance, not a completely unlit link light. The link light not being lit indicates a Layer 1 issue (no electrical signal), which is not resolved by checking speed/duplex settings.

Practice this question →

MCQmedium

A user reports that they cannot access a web server by its URL but can access it by IP address. A technician checks the DNS server and finds it is reachable. What is the most likely cause?

A.Incorrect default gateway

B.DNS resolution failure for that specific record

C.Firewall blocking port 80

D.IP conflict on the user's workstation

AnswerB

If a user can successfully access a web server using its IP address but fails when attempting to use its URL (e.g., www.example.com), it strongly indicates a problem with Domain Name System (DNS) resolution. This scenario confirms that network connectivity to the server exists and that the server itself is operational and listening on the correct port. The specific failure to resolve the URL means the DNS server either lacks the necessary A record for that hostname or is unable to provide it to the client, preventing the client from learning the server's IP address from its human-readable name.

Why this answer

The user can access the web server by IP address but not by URL, which indicates that the name-to-IP resolution is failing. Since the DNS server is reachable, the issue is not with network connectivity to the DNS server but rather with the specific DNS record for that web server. This is a classic DNS resolution failure for that specific record, often due to a missing or incorrect A or AAAA record.

Exam trap

The trap here is that candidates often assume a reachable DNS server means DNS is fully functional, but the question specifically tests the distinction between server reachability and record availability.

Why the other options are wrong

An incorrect default gateway would prevent access to any external IP address, but the user can access the web server by IP, indicating routing is functional. The issue is specific to URL access, pointing to DNS, not gateway.

The user can access the web server by IP address, which indicates that port 80 is not blocked. A firewall blocking port 80 would prevent access by both URL and IP.

An IP conflict would cause intermittent connectivity or complete loss of network access, not a specific inability to resolve a URL while IP access works. The user can reach the server by IP, ruling out IP conflict.

Practice this question →

MCQhard

A network technician is troubleshooting a connectivity issue between two switches. The technician suspects a duplex mismatch on the link between them. Which of the following commands would best confirm this suspicion?

A.show cdp neighbors

B.show mac address-table

C.show interfaces

D.show interface counters errors

AnswerC

The show interfaces command displays detailed information about each interface, including duplex and speed settings. By comparing the duplex configuration on both ends of the link, the technician can confirm if one side is set to full-duplex and the other to half-duplex, which is a duplex mismatch.

Why this answer

The correct answer is show interfaces. This command displays the duplex and speed settings for each interface, allowing the technician to compare both ends of the link. A duplex mismatch occurs when one side is set to full-duplex and the other to half-duplex, leading to performance issues and errors.

The other commands do not directly show duplex settings, making them less effective for confirming a duplex mismatch.

Exam trap

The trap here is assuming that show interface counters errors will directly indicate a duplex mismatch, when it only shows symptoms like late collisions, not the duplex configuration itself.

Practice this question →

MCQmedium

A user reports that they can access the company's internal web server by IP address (10.10.10.100) but cannot access it by its hostname (intranet.company.com). The user's workstation is configured with the correct internal DNS server address. Which of the following should the technician do FIRST?

A.Check the DNS server's A record for intranet.company.com

B.Review the firewall rules on the server

C.Run ipconfig /flushdns on the workstation

D.Verify the default gateway configuration

AnswerA

The ability to access the server by its IP address confirms network connectivity and the server's operational status. However, the inability to reach it by its hostname, intranet.company.com, directly points to a name resolution issue. An A (Address) record on the DNS server maps a hostname to its corresponding IPv4 address. If this specific A record is missing, incorrect, or misconfigured on the internal DNS server, clients will fail to resolve the hostname to the correct IP, even if the server is otherwise accessible.

Why this answer

The user can reach the server by IP but not by hostname, which indicates a DNS resolution problem. Since the workstation is configured with the correct internal DNS server, the most likely cause is a missing or incorrect A record for intranet.company.com on that DNS server. Checking the A record is the logical first step before other troubleshooting.

Exam trap

The N10-009 exam often tests the distinction between connectivity issues (firewall, routing) and name resolution issues; the trap here is that candidates might jump to flushing the DNS cache (Option C) without verifying the authoritative DNS record first.

Why the other options are wrong

The user can already access the server by IP, so connectivity and firewall rules are not the issue. The problem is specifically with hostname resolution, not network access.

The user can access the server by IP but not by hostname, indicating a DNS resolution issue. Flushing the DNS cache would not fix a missing or incorrect A record on the DNS server.

The user can access the internal web server by IP but not by hostname, indicating a DNS resolution issue, not a routing problem. The default gateway is only relevant for reaching external networks, not for internal hostname resolution.

Practice this question →

MCQmedium

A network administrator is troubleshooting communication between two switches connected via a trunk port. The trunk link is up/up, but devices in VLAN 20 cannot communicate across the trunk. The administrator has verified that both switches have VLAN 20 created and that the access ports are configured correctly. Which command should the administrator run on each switch to verify the trunk's allowed VLAN list?

A.show vlan brief

B.show interfaces trunk

C.show running-config interface

D.show mac address-table

AnswerB

This command is the most effective for troubleshooting VLAN communication issues over a trunk link because it provides a comprehensive overview of the trunk's operational status. It explicitly lists the allowed VLANs on the trunk interface, the native VLAN, and the trunking encapsulation type (e.g., 802.1Q). By checking the "Vlans allowed on trunk" output, an administrator can quickly determine if the specific VLAN experiencing communication problems (e.g., VLAN 20) is permitted to traverse the link.

Why this answer

The 'show interfaces trunk' command displays the trunking status, including the allowed VLAN list on the trunk port. Since the trunk link is up/up but VLAN 20 traffic fails, the most likely cause is that VLAN 20 is not included in the allowed VLAN list on one or both switches. This command directly shows which VLANs are permitted, pruned, or active on the trunk.

Exam trap

The N10-009 exam often tests the distinction between 'show vlan brief' (which shows VLAN existence and access port assignments) and 'show interfaces trunk' (which shows trunk-specific VLAN permissions), leading candidates to mistakenly check VLAN existence instead of trunk VLAN filtering.

Why the other options are wrong

The 'show vlan brief' command displays VLAN membership and ports assigned to each VLAN, but it does not show the allowed VLAN list on a trunk port. The trunk's allowed VLAN list is specifically shown by 'show interfaces trunk'.

The 'show running-config interface' command displays the current configuration of an interface, including VLAN assignments and trunk settings, but it does not show the dynamically learned allowed VLAN list or the operational trunk status. For verifying the trunk's allowed VLAN list, 'show interfaces trunk' is needed.

The 'show mac address-table' command displays MAC address entries learned by the switch, not the allowed VLAN list on a trunk port. It does not provide information about which VLANs are permitted on the trunk link.

Practice this question →

MCQmedium

Users in VLAN 10 cannot obtain IP addresses from a DHCP server located in VLAN 20. The router has an ip helper-address configured on VLAN 10 interface pointing to the DHCP server. Users can ping the DHCP server IP from the router. However, users are receiving APIPA addresses. What is the most likely cause?

A.The DHCP server is not reachable from the router

B.The DHCP server scope does not include the VLAN 10 subnet

C.The router's ip helper-address is configured incorrectly

D.The switch ports are not configured for VLAN 10

AnswerB

A DHCP server scope defines the range of IP addresses and associated configuration parameters (like subnet mask, default gateway, and DNS servers) that the server can lease to clients within a specific subnet. If the DHCP server receives a DHCP Discover request from a client in VLAN 10 but lacks a configured scope for the VLAN 10 subnet, it will be unable to generate a valid DHCP Offer. Consequently, clients in VLAN 10 will not receive an IP address, even if the initial broadcast request successfully reaches the server via an IP helper address.

Why this answer

The DHCP server must have a scope configured for the subnet of the requesting clients (VLAN 10) to assign IP addresses from that range. Since users receive APIPA addresses (169.254.x.x), the DHCP discovery process is failing, which typically occurs when the server receives the request via the ip helper-address but has no matching scope for VLAN 10. The router's ability to ping the server confirms Layer 3 reachability, isolating the issue to the server's scope configuration.

Exam trap

The N10-009 exam often tests the misconception that a successful ping from the router to the DHCP server guarantees DHCP functionality, but the trap here is that the ip helper-address only relays the request; the server must still have a scope for the client's subnet to assign an address.

Why the other options are wrong

The router can ping the DHCP server, so the server is reachable. The issue is that users get APIPA addresses, indicating DHCP requests are not reaching the server or replies are not returning, but reachability is confirmed.

The router can ping the DHCP server, indicating the ip helper-address is correctly configured and reachable. The issue is that the DHCP server's scope lacks a subnet for VLAN 10, not the helper-address configuration.

The question states users can ping the DHCP server from the router, indicating connectivity. Switch port misconfiguration for VLAN 10 would prevent all communication, but users can still obtain APIPA addresses, meaning they are on VLAN 10 but DHCP fails. The issue is at the DHCP server scope, not switch ports.

Practice this question →

MCQeasy

A user reports that they cannot access any network resources. The technician runs 'ipconfig' on the workstation and sees that the IP address is 169.254.23.45 with a subnet mask of 255.255.0.0. What is the most likely cause of this issue?

A.The workstation's network cable is unplugged.

B.The DNS server is not responding.

C.The DHCP server is unreachable or not functioning.

D.The workstation has been assigned a static IP address in the wrong subnet.

AnswerC

When a DHCP client fails to receive an IP address lease from a DHCP server after multiple attempts, it automatically assigns itself an APIPA address. This self-configuration occurs within the 169.254.0.0/16 range, indicating that the DHCP server is either offline, unreachable due to network connectivity issues, or misconfigured. The presence of an APIPA address is a strong diagnostic indicator of a DHCP service failure, as the client cannot obtain a valid, routable IP address.

Why this answer

The IP address 169.254.23.45 with a subnet mask of 255.255.0.0 is an Automatic Private IP Addressing (APIPA) address, which is assigned by the operating system when a DHCP discovery attempt fails. This indicates that the workstation was unable to contact a DHCP server to obtain a valid IP configuration, making an unreachable or non-functioning DHCP server the most likely cause.

Exam trap

The trap here is that candidates often confuse APIPA with a physical connectivity issue, but APIPA specifically indicates that the DHCP process failed, not necessarily that the cable is unplugged.

Why the other options are wrong

An unplugged network cable would result in no IP address or a disconnected status, not an Automatic Private IP Addressing (APIPA) address like 169.254.23.45. APIPA addresses are assigned when DHCP fails, but the link is still active.

The IP address 169.254.23.45 is an Automatic Private IP Addressing (APIPA) address, which indicates that the workstation failed to obtain an IP from a DHCP server. DNS issues do not cause APIPA addresses; they would result in name resolution failures but the workstation would still have a valid IP.

A static IP in the wrong subnet would typically result in a different IP address (not an APIPA 169.254.x.x address) and would not cause the workstation to self-assign an APIPA address. The 169.254.23.45 address indicates DHCP failure, not a static misconfiguration.

Practice this question →

MCQmedium

Users in a small office can access external websites normally, but they cannot reach the internal company wiki server at 192.168.10.25. A technician can successfully ping the server's IP address from a user's workstation. The DNS resolution for the wiki's hostname (wiki.company.local) returns the correct IP. The company's firewall permits HTTP traffic to the server. What is the most likely cause of the issue?

A.The web server service is not running or is listening on a different port

B.The default gateway on the server is misconfigured

C.The user's workstation has a duplicate IP address

D.The DNS cache on the workstation is poisoned

AnswerA

This is the correct answer because a successful ping only verifies basic IP-level connectivity (Layer 3) to the server. If the web server application (e.g., Apache, Nginx, IIS) is not actively running, or if it's configured to listen on a non-standard TCP port (e.g., not 80 for HTTP or 443 for HTTPS) without the client specifying it, the client's browser cannot complete the TCP three-way handshake required to establish a connection to the web service. Consequently, even with network reachability, the application-layer service remains inaccessible, resulting in a connection refused or timeout error for web requests.

Why this answer

Since the technician can successfully ping the server's IP address from the user's workstation, Layer 3 connectivity is confirmed, ruling out routing or gateway issues. DNS resolution returns the correct IP, so name resolution is not the problem. The firewall permits HTTP traffic, so access control is not blocking the connection.

The most likely cause is that the web server service (e.g., Apache, IIS) is not running or is listening on a non-standard port (e.g., 8080 instead of 80), preventing the HTTP request from reaching the service even though the host is reachable.

Exam trap

The trap here is that candidates assume a successful ping implies full application-layer connectivity, but ping uses ICMP (Layer 3) while HTTP uses TCP (Layer 4), so a working ping does not guarantee that the web service is running or reachable on the correct port.

Why the other options are wrong

The default gateway on the server is misconfigured would prevent the server from reaching external networks, but here users can access external websites normally and can ping the server's IP, indicating the server is reachable. The issue is that users cannot reach the wiki server's web service, which is a higher-layer problem.

DNS cache poisoning would cause incorrect IP resolution, but the question states that DNS returns the correct IP and ping to the server succeeds, so the issue is not DNS-related.

Practice this question →

MCQmedium

A technician is troubleshooting a loss of network connectivity for a single workstation. The workstation has a valid IP address but cannot ping its default gateway. The link lights on both the workstation and the switch are solid. Which of the following should the technician check NEXT?

A.The cable integrity with a tester

B.The switch port configuration, such as VLAN assignment

C.The DNS server settings

D.The workstation's ARP cache

AnswerB

A misconfigured VLAN assignment on the switch port is a common cause of network connectivity loss for a single device, even when physical link lights are solid. If the port is placed in an incorrect VLAN, the workstation will be isolated from its intended network segment and unable to communicate with its default gateway or other devices on its subnet. This Layer 2 misconfiguration effectively prevents IP communication despite a healthy Layer 1 connection.

Why this answer

The workstation has a valid IP address and solid link lights, indicating Layer 1 (physical) and Layer 3 (IP configuration) are functional. The inability to ping the default gateway points to a Layer 2 issue, such as the switch port being in the wrong VLAN or having a misconfigured access/trunk setting. Checking the switch port configuration is the logical next step because VLAN mismatches prevent frames from reaching the gateway's subnet.

Exam trap

The N10-009 exam often tests the misconception that solid link lights guarantee full Layer 2 connectivity, when in fact they only indicate carrier detect and electrical synchronization, not correct VLAN membership or spanning-tree port state.

Why the other options are wrong

The link lights are solid, indicating physical connectivity is present, so cable integrity is not the next logical step. The issue is likely at Layer 2 (switch port configuration) since the workstation has a valid IP but cannot reach the gateway.

DNS server settings affect name resolution, not IP-level connectivity to a gateway. Since the workstation has a valid IP but cannot ping the gateway, the issue is at Layer 2 or Layer 3, not DNS.

The workstation has a valid IP address and link lights are solid, indicating Layer 1 and Layer 3 configuration are likely correct. The inability to ping the gateway despite a valid IP suggests a Layer 2 issue, such as VLAN mismatch, not an ARP cache problem.

Practice this question →

MCQeasy

A user reports that they cannot access the internet. The technician tests connectivity: pinging the default gateway succeeds, but pinging a public IP address like 8.8.8.8 fails. Firewall logs show outbound ICMP to 8.8.8.8 is permitted. What is the most likely cause?

A.Incorrect DNS configuration on the workstation

B.Missing default route on the router

C.Duplicate IP address on the local network

D.Proxy server configuration is required

AnswerB

When a router receives a packet for a destination not on its directly connected networks or within its specific routing table entries, it consults its default route. If this route (often 0.0.0.0/0) is absent, the router has no "gateway of last resort" and will drop all traffic intended for external networks, such as the internet. This directly prevents any device behind that router from accessing resources outside the local network, including public IP addresses.

Why this answer

The user can ping the default gateway (local connectivity) but cannot ping a public IP like 8.8.8.8. This indicates that the workstation has a valid route to its local subnet, but the router lacks a default route (0.0.0.0/0) to forward traffic to the internet. Firewall logs confirm outbound ICMP is permitted, so the issue is at Layer 3 routing, not filtering.

Exam trap

CompTIA often tests the distinction between local connectivity (gateway reachable) and internet connectivity (default route missing), trapping candidates who assume DNS or firewall issues when the symptom is a successful ping to the gateway but failure to external IPs.

Why the other options are wrong

Incorrect DNS configuration would prevent name resolution but not direct IP pings; the user can ping the gateway (IP) but not a public IP, so the issue is routing, not DNS.

A duplicate IP address would cause intermittent connectivity or address conflict errors, but here pinging the default gateway succeeds, indicating the workstation has valid IP communication locally. The failure is specifically to external IPs, which points to a routing issue, not a duplicate address.

The issue is that pinging a public IP (8.8.8.8) fails while the default gateway is reachable, indicating a routing problem beyond the local network. Proxy server configuration affects application-layer traffic, not ICMP to a public IP, and the firewall permits outbound ICMP, so a proxy is not the cause.

Practice this question →

MCQhard

A network administrator configures a router-on-a-stick to route traffic between VLAN 10 and VLAN 20. Users in each VLAN can communicate within their own VLAN but cannot reach devices in the other VLAN. The router has subinterfaces configured, and the switch port connected to the router is configured as an access port in VLAN 1. What is the most likely cause of the inter-VLAN connectivity failure?

A.The router's subinterfaces are not configured with IP addresses.

B.The switch port connected to the router is not configured as a trunk.

C.The VLANs are not created on the switch.

D.The router's default route is missing.

AnswerB

This is the most likely cause. A trunk port is required to carry frames from multiple VLANs to the router for inter-VLAN routing. An access port only carries a single VLAN, preventing the router from receiving traffic from other VLANs.

Why this answer

The router-on-a-stick design requires the switch port connecting to the router to be configured as a trunk port. This allows the switch to forward frames from multiple VLANs (VLAN 10 and VLAN 20) to the router's subinterfaces, each tagged with the appropriate 802.1Q VLAN ID. When the port is set as an access port in VLAN 1, it only accepts untagged frames from VLAN 1, so the router's subinterfaces for VLAN 10 and VLAN 20 never receive traffic, breaking inter-VLAN routing.

Exam trap

CompTIA often tests the misconception that a router-on-a-stick only needs subinterfaces with IP addresses, leading candidates to overlook the critical requirement that the switch port must be a trunk to carry multiple VLAN tags.

Why the other options are wrong

The router's subinterfaces are configured, so they likely have IP addresses. The issue is the switch port is an access port in VLAN 1, preventing tagged traffic from VLANs 10 and 20 from reaching the router.

The question states that users within each VLAN can communicate, which means the VLANs are already created on the switch. The issue is inter-VLAN routing, which fails because the switch port to the router is an access port in VLAN 1, not a trunk carrying both VLANs.

The router's default route is used for reaching networks not directly connected, not for inter-VLAN routing. Since the router has subinterfaces for VLAN 10 and 20, it can route between them directly without a default route. The issue is that the switch port is an access port, preventing VLAN-tagged traffic from reaching the router.

Practice this question →

MCQmedium

A user reports that they cannot access any network resources. The technician checks the IP configuration and sees that the workstation has an IP address of 169.254.1.5. What is the most likely cause?

A.The DNS server is down

B.The DHCP server is unavailable

C.The default gateway is incorrect

D.The subnet mask is mismatched

AnswerB

A 169.254.x.x address is an APIPA self-assignment, which Windows applies when its DHCP DISCOVER broadcasts receive no offer. The workstation therefore lacks a valid lease, default gateway and DNS servers, so no network resources are reachable. This directly satisfies the stem's symptom of total loss of access caused by an unreachable DHCP server.

Why this answer

The IP address 169.254.1.5 is an Automatic Private IP Addressing (APIPA) address (169.254.0.0/16 range), which Windows assigns when a DHCP client fails to receive a lease from a DHCP server. Since the workstation cannot obtain a valid IP configuration, it cannot communicate with any network resources, confirming that the DHCP server is unavailable.

Exam trap

The trap here is that candidates may confuse APIPA with a static IP misconfiguration or assume a DNS issue, but the 169.254.x.x address is a definitive indicator of DHCP failure, not a gateway or subnet problem.

Why the other options are wrong

The IP address 169.254.1.5 is an Automatic Private IP Addressing (APIPA) address, which indicates that the workstation failed to obtain an IP from a DHCP server. A down DNS server would not cause the workstation to self-assign an APIPA address; it would still receive a valid IP via DHCP.

The workstation has an APIPA address (169.254.x.x), which indicates DHCP failure, not an incorrect default gateway. An incorrect default gateway would still allow local network access but not external routing, and the IP would be valid from DHCP or static.

A mismatched subnet mask would not cause the workstation to obtain an APIPA address (169.254.x.x); it would instead cause connectivity issues within the subnet while the IP address would still be assigned via DHCP or static configuration.

Practice this question →

MCQmedium

Users in a branch office report intermittent connectivity to the corporate data center. A technician runs a continuous ping from a workstation to the data center server and observes packet loss after the third hop. Which command should the technician run next to identify the specific router causing the issue?

A.ping -n 1000 server_ip

B.tracert server_ip

C.nslookup server_ip

D.ipconfig /all

AnswerB

The `tracert` command is the most effective tool for diagnosing intermittent connectivity issues along a network path because it maps the route a packet takes to its destination. By sending a series of ICMP echo requests with incrementally increasing Time To Live (TTL) values, `tracert` elicits ICMP "Time Exceeded" messages from each router along the path, revealing each hop. This detailed output, including round-trip times and potential packet loss at each hop, allows a technician to precisely identify the specific router or network segment causing the intermittent problem.

Why this answer

The technician has already identified packet loss after the third hop using a continuous ping. The next logical step is to use `tracert` (or `traceroute` on Linux) to map the path and pinpoint which router (hop) is dropping packets. This command sends ICMP echo requests with incrementing TTL values, forcing each router along the path to reply with a Time Exceeded message, thereby revealing the specific hop where loss occurs.

Exam trap

The trap here is that candidates often jump to running a longer ping (option A) to confirm loss, but the question already states loss is observed; the correct next step is to isolate the failing hop using `tracert`, not to gather more loss statistics.

Why the other options are wrong

The question asks to identify the specific router causing packet loss after the third hop. Ping only tests end-to-end connectivity and does not show the path or which hop is failing.

nslookup is used for DNS resolution, not for tracing the network path or identifying packet loss at specific hops. It cannot show where packet loss occurs along the route.

The ipconfig /all command displays local network configuration details (IP address, MAC, DNS, etc.) but does not perform any path tracing or connectivity testing to remote hosts, so it cannot identify which router is causing packet loss.

Practice this question →

MCQhard

A network engineer is troubleshooting intermittent packet loss on a 10 km single-mode fiber link between two buildings. The link lights are on, but the interface shows a high number of CRC errors. The engineer has cleaned the fiber connectors and replaced the patch cables. What should the engineer check NEXT?

A.Check the transmit/receive optical power levels

B.Check the duplex settings on both ends

C.Verify the cable length is within specifications

D.Adjust the Spanning Tree Protocol priority

AnswerA

Intermittent packet loss on fiber links, especially over distance, often points to physical layer issues. Checking transmit (Tx) and receive (Rx) optical power levels with an optical power meter is crucial. If Rx power is too low (below receiver sensitivity) or too high (saturating the receiver), it can lead to bit errors, which manifest as CRC errors and subsequent packet retransmissions or drops, causing intermittent loss. This verifies the optical link budget and ensures signal integrity.

Why this answer

CRC errors on a single-mode fiber link typically indicate physical-layer issues such as excessive attenuation or dispersion. Since cleaning connectors and replacing patch cables did not resolve the problem, the next logical step is to measure the optical power levels at both the transmitter and receiver using an optical power meter. This will confirm whether the received signal is within the acceptable range (e.g., -3 dBm to -20 dBm for 10GBASE-LR) and identify if a damaged transceiver or a splice loss is causing the errors.

Exam trap

The trap here is that candidates often jump to duplex mismatch or cable length issues because those are common in copper troubleshooting, but on long-haul single-mode fiber, optical power levels are the primary suspect when CRC errors persist after cleaning and patching.

Why the other options are wrong

CRC errors on a fiber link with link lights on typically indicate signal degradation or physical layer issues, not duplex mismatches, which usually cause frame check sequence errors or late collisions on copper links, not on single-mode fiber.

The question states the link is 10 km, which is within the typical range for single-mode fiber (up to 40 km or more). CRC errors are more likely due to signal degradation or dirty connectors, not cable length.

Practice this question →

MCQmedium

A technician is troubleshooting an intermittent connectivity issue between two switches connected by a fiber optic cable. The link status shows up/down flapping. The technician checks the optical power levels and finds they are within acceptable range. Which of the following is the most likely cause?

A.Dirty fiber connectors

B.Duplex mismatch

C.Speed mismatch

D.VLAN mismatch

AnswerA

Contamination on fiber end faces, such as dust or oil, can cause significant and intermittent signal degradation. These microscopic particles can partially block or scatter the light signal, leading to increased attenuation or back reflection that disrupts communication. The intermittent nature arises because the contamination might shift, vibrate, or only partially obscure the core, causing periods of good signal followed by periods of poor or lost signal, resulting in link flaps. Even if average power readings appear acceptable, the transient nature of the obstruction can cause connectivity to drop.

Why this answer

Intermittent link flapping with acceptable optical power levels strongly indicates a physical-layer issue that is not related to signal strength. Dirty fiber connectors cause intermittent signal degradation due to scattering and absorption of light, leading to CRC errors and link flaps even when average power appears normal. Cleaning the connectors is the standard first step in such scenarios.

Exam trap

The trap here is that candidates see 'acceptable optical power levels' and assume the physical layer is fine, overlooking that intermittent physical contamination can cause flapping without dropping the average power below threshold.

Why the other options are wrong

Duplex mismatch typically causes constant errors or complete link failure, not intermittent flapping. The symptoms here (up/down flapping with acceptable optical power) point to a physical layer issue like dirty connectors, not a duplex configuration problem.

Speed mismatch typically causes a link to not come up at all or to flap continuously, but the question states optical power levels are within range, and the issue is intermittent. Speed mismatch would usually be constant, not intermittent, and is less common on fiber links with auto-negotiation.

A VLAN mismatch would cause connectivity issues but typically results in a stable link state (up/up) with no communication, not intermittent flapping of the link status. The link flapping indicates a physical layer problem, not a layer 2 configuration issue.

Practice this question →

MCQhard

Users in a remote office are experiencing slow file transfers to the data center. The network technician runs a traceroute and discovers high latency on a specific hop. The technician pings that hop and gets replies with varying latency. The technician also checks the interface error counters on the router at that hop and finds no errors. What is the most likely cause?

A.Duplex mismatch

B.Incorrect MTU

C.Route flapping

D.CPU overload on the router

AnswerD

When a router's CPU is overloaded, it struggles to process packets efficiently, leading to increased queue depths for incoming traffic. This results in significant packet processing delays and variable latency, directly impacting file transfer speeds without necessarily generating interface errors like discards or input errors. The router simply cannot keep up with the forwarding, routing table lookups, and other management plane tasks.

Why this answer

High latency with varying values (jitter) combined with clean interface error counters points to a router that is overwhelmed by processing demands. When a router's CPU is overloaded, it queues packets for processing, introducing variable delays even though the physical layer shows no errors. This matches the symptom of a specific hop showing latency spikes without CRC or framing errors.

Exam trap

The trap here is that candidates see 'no errors' on the interface and assume the problem must be at a higher layer, but CompTIA often tests that CPU overload can cause latency without any interface errors, misleading those who think clean counters always mean a healthy router.

Why the other options are wrong

Duplex mismatch typically causes CRC errors and frame check sequence failures, which would appear in interface error counters. Since the technician checked and found no errors, duplex mismatch is unlikely.

Incorrect MTU typically causes packet fragmentation or drops, not varying latency with no interface errors. The symptoms of high and varying latency without errors point to CPU overload, not MTU issues.

Route flapping typically causes intermittent connectivity and routing table instability, not consistently high latency with varying ping responses and no interface errors.

Practice this question →

MCQmedium

A technician is troubleshooting a wireless network that experiences intermittent disconnections. A spectrum analysis shows channel utilization consistently above 80% on the 2.4 GHz band. Which of the following is the most likely cause?

A.Too many access points are configured on the same or overlapping channels

B.Access point output power is too high

C.Microwave ovens are interfering with the wireless signal

D.Client devices have weak signal strength

AnswerA

When multiple access points operate on the same or overlapping Wi-Fi channels within close proximity, they create co-channel interference. This forces devices to contend more frequently for airtime, leading to increased retransmissions and a higher perceived channel utilization. The result is reduced effective throughput and intermittent connectivity issues for clients as they struggle to communicate reliably amidst the signal collisions.

Why this answer

A is correct because consistently high channel utilization above 80% on the 2.4 GHz band indicates co-channel or adjacent-channel interference, typically caused by too many access points (APs) operating on the same or overlapping channels (e.g., channels 1, 6, and 11 are non-overlapping in 802.11b/g/n). This leads to excessive contention, increased retransmissions, and intermittent disconnections as stations wait for clear channel access via CSMA/CA.

Exam trap

The trap here is that candidates often attribute high channel utilization solely to non-Wi-Fi interference (like microwaves) or power settings, but the exam expects you to recognize that persistent >80% utilization in the 2.4 GHz band is almost always due to overlapping APs on the same or adjacent channels, not transient interference sources.

Why the other options are wrong

High output power can cause co-channel interference and cell overlap, but the question states channel utilization is above 80%, which points to congestion from too many APs on the same or overlapping channels, not power levels.

Intermittent disconnections with high channel utilization are more likely caused by co-channel interference from too many access points on the same or overlapping channels, not by microwave ovens, which typically cause non-Wi-Fi interference that is constant rather than intermittent.

Weak signal strength causes low throughput or disconnections at the client, but the question states channel utilization is consistently above 80% on the 2.4 GHz band, indicating congestion from many devices or access points, not weak signal.

Practice this question →

MCQhard

Users in a remote branch office report that they cannot access the company's cloud-based applications. The network administrator notices that the edge router's WAN interface is up but the branch's default route points to a next-hop IP that is unreachable. The administrator can ping the ISP's gateway IP from the router. What is the most likely cause?

A.The routing protocol is not redistributing the default route

B.The static default route has an incorrect next-hop IP

C.The WAN interface is administratively down

D.The firewall is blocking traffic to the cloud

AnswerB

If the next-hop IP in the static route is incorrect or the interface is down, traffic cannot be forwarded even though the WAN interface is up and the ISP gateway is reachable via another path.

Why this answer

The scenario describes a static default route configured with a next-hop IP that is unreachable. The WAN interface is up and the ISP gateway is reachable (as confirmed by the ping), but the router cannot forward traffic to the cloud because the static route points to an incorrect next-hop address. This is a classic static route misconfiguration where the next-hop IP does not match the ISP gateway or is not in the directly connected subnet.

Exam trap

CompTIA often tests the distinction between a WAN interface being up and the default route's next-hop being reachable; candidates mistakenly assume that if the interface is up and the ISP gateway is pingable, the default route must be correct, but the next-hop IP configured in the static route could be a different, unreachable address.

Why the other options are wrong

The question states that the default route points to an unreachable next-hop IP, and the administrator can ping the ISP's gateway. This indicates a static route misconfiguration, not a redistribution issue. Redistribution would only matter if a dynamic routing protocol were involved, but the problem is with a static default route.

The WAN interface is up (as stated), so it is not administratively down. An administratively down interface would show as 'down' or 'disabled', not 'up'.

The firewall blocking traffic to the cloud would not cause the router to have an unreachable next-hop IP for the default route; it would instead prevent traffic from passing through the firewall, but the router would still have a valid route.

Practice this question →

MCQmedium

A user reports that they can access the internet but cannot access the company's internal web application at https://intranet.company.local. The technician can ping the server's IP address (192.168.10.50) successfully from the user's workstation. However, when the technician runs 'nslookup intranet.company.local', it returns 'Non-existent domain'. What is the most likely cause?

A.The web server is not running on port 443.

B.The client's DNS server does not have a record for the internal domain.

C.A firewall is blocking traffic to the internal web server.

D.The hostname is misspelled in the browser.

AnswerB

This is the correct answer because an 'NXDOMAIN' (Non-existent domain) response from `nslookup` explicitly indicates that the DNS server queried could not find a corresponding A or CNAME record for the internal hostname. Since external internet access works, the client's DNS server is functional for public lookups but lacks the necessary zone information or conditional forwarders to resolve internal company domain names, preventing any connection attempts to internal resources.

Why this answer

The user can access the internet and ping the server's IP address, which confirms Layer 3 connectivity and that the web server is reachable. However, 'nslookup intranet.company.local' returns 'Non-existent domain', indicating that the DNS server used by the client does not have an A or CNAME record for that internal hostname. Since the browser relies on DNS resolution to translate the FQDN to an IP address, the failure to resolve the name prevents the web application from loading, even though the server itself is online and reachable.

Exam trap

CompTIA often tests the distinction between connectivity (ping) and name resolution (nslookup), trapping candidates who assume that successful ping to an IP means the web application should work, ignoring that DNS failure prevents the browser from even initiating the HTTP request.

Why the other options are wrong

The user can access the internet but not the internal web app, and nslookup returns 'Non-existent domain', indicating a DNS resolution failure. The web server being down on port 443 would not cause a DNS lookup to fail; it would cause a connection timeout or refusal after successful resolution.

The technician can ping the server's IP address successfully, indicating that network connectivity and firewall rules are not blocking traffic to the server. The issue is DNS resolution, not firewall filtering.

The user can access the internet and ping the server IP, but nslookup returns 'Non-existent domain', indicating a DNS resolution failure, not a browser misspelling. A misspelling would still result in a DNS query, not a 'Non-existent domain' error.

Practice this question →