Network Troubleshooting

486 questions

Question 321Question

A network administrator is troubleshooting remote administration access to an edge router (172.28.10.1172.28.10.1). Systems engineers on the management network (10.40.8.0/2410.40.8.0/24) report that ping requests to the router succeed, but SSH connections to port 22 time out. Upon inspecting the router interface's inbound Access Control List (ACL), the administrator reviews the following entries:

access-list 105 permit icmp 10.40.8.0 0.0.0.255 any
access-list 105 permit udp 10.40.8.0 0.0.0.255 host 172.28.10.1 eq 22
access-list 105 deny ip any any

Which of the following is the root cause preventing SSH access to the router?

Show answer & explanation

Answer: The ACL rule specifies UDP port 22 instead of TCP port 22, causing SSH traffic to match the deny rule.

Answer

The ACL rule specifies UDP port 22 instead of TCP port 22, causing incoming SSH packets to be dropped by the final deny statement.
SSH utilizes TCP as its transport protocol on port 22. The configured ACL rule permits UDP port 22, causing TCP SSH initiation packets to skip the permit statement and trigger the subsequent explicit deny rule.

Step-by-Step Solution

1
Analyze transport protocol requirements for SSH
SSH requires TCP port 22 for reliable stream-oriented communication.
Identifying the required Layer 4 protocol is essential for auditing firewalls and access lists.
2
Compare required protocol against ACL line 20
ACL line 20 permits 'udp' port 22 instead of 'tcp'.
Since SSH uses TCP, incoming TCP SYN packets for port 22 fail to match line 20.
3
Trace packet execution through the remainder of the ACL
Packets fall through to line 30 ('deny ip any any') and are dropped.
Traffic that does not match preceding permit entries is evaluated against subsequent deny rules.

Key Concept

ACL Transport Protocol Matching (TCP vs UDP)
Estimated Time:1m 30s
Question 322Question

A network engineer is responding to a critical datastore access failure across a virtualized server cluster immediately following scheduled network switch maintenance. Place the following troubleshooting steps in the correct chronological sequence according to the official CompTIA troubleshooting methodology.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence follows the official 6-step CompTIA Troubleshooting Methodology: 1. Identify the problem (gather hypervisor logs and interview admins) -> 2. Establish a theory of probable cause (hypothesize missing iSCSI VLAN) -> 3. Test the theory to determine cause (inspect switch running configuration) -> 4. Establish a plan of action and implement the solution (formulate change plan and apply fix) -> 5. Verify full system functionality and implement preventive measures (run I/O performance tests and configure logging) -> 6. Document findings, actions, and outcomes (log incident root cause and resolution in ticketing system).
The correct order strictly adheres to the standard 6-step CompTIA troubleshooting methodology: 1. Identify problem -> 2. Establish theory -> 3. Test theory -> 4. Plan of action & implement -> 5. Verify system functionality & preventive measures -> 6. Document findings.

Step-by-Step Solution

1
Identify the problem
Information is gathered from logs and host administrators to define the scope of the storage failure.
CompTIA methodology requires gathering information and identifying symptoms before forming assumptions.
2
Establish a theory of probable cause
A working theory is developed pointing to a missing iSCSI VLAN on the switch trunk port.
After defining symptoms, the technician considers potential causes, starting with the most probable.
3
Test the theory to determine the cause
The running configuration is checked to confirm if the iSCSI VLAN was dropped from the trunk.
The theory must be verified prior to making changes to the production network.
4
Establish a plan of action and implement the solution
A change plan is drafted and executed to restore the iSCSI VLAN to the trunk link.
Once the cause is confirmed, a plan of action is created to resolve the issue while minimizing risk.
5
Verify full system functionality and implement preventive measures
Datastore I/O benchmarks confirm storage recovery, and configuration logging is added to prevent future drops.
The solution must be validated across the entire system, followed by preventive steps against recurrence.
6
Document findings, actions, and outcomes
The ticketing system is updated with root cause details and updated procedure notes.
The final stage of the methodology requires documenting all steps for future reference and team knowledge.

Key Concept

CompTIA 6-Step Network Troubleshooting Methodology
Estimated Time:2m 0s
Question 323Question

A network engineer is troubleshooting several Layer 2 connectivity issues across enterprise switch stacks. Match each observed diagnostic log output or interface symptom on the left with its correct underlying root cause on the right.

Click a left item, then click its matching right item

Items

Interface log repeatedly records '%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/1 (10), with Switch-B GigabitEthernet0/1 (50)'.
Interface statistics on a 1 Gbps link show a rapidly incrementing counter for late collisions and FCS errors during high-throughput file transfers.
Console outputs '%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port GigabitEthernet0/12 with BPDU Guard enabled' and transitions port to err-disabled.
Trunk interface shows line protocol UP, but host traffic tagged with 802.1Q VLAN 40 fails to traverse the link while VLAN 10 traffic passes cleanly.

Matches

Show answer & explanation

Answer

Each diagnostic symptom matches its corresponding Layer 2 root cause: CDP native VLAN mismatch log corresponds to native VLAN misconfiguration; late collisions and FCS errors correspond to a duplex mismatch; BPDU Guard err-disable log corresponds to an unauthorized switch sending BPDUs on an access port; and single VLAN loss over an operational trunk corresponds to VLAN exclusion from the allowed trunk list.
Each diagnostic indicator directly maps to a distinct Layer 2 misconfiguration: CDP warning logs explicitly indicate native VLAN mismatches; late collision counters signify half-duplex/full-duplex operation mismatch; BPDU Guard shutdown indicates rogue switch detection on an access port; and single-VLAN failure on an active trunk points to allowed-list pruning.

Step-by-Step Solution

1
Analyze the CDP mismatch log message.
CDP explicitly identifies that local interface GigabitEthernet0/1 expects native VLAN 10 while Switch-B expects native VLAN 50.
Mismatched native VLANs prevent proper untagged frame processing and generate continuous CDP warnings.
2
Examine the late collisions and FCS error counters on the interface.
Late collisions indicate frames were transmitted while receiving data after 512 bit times (64 bytes), characteristic of half-duplex CSMA/CD operation conflicting with full-duplex.
When one end is set to full-duplex, it transmits regardless of incoming signals, causing the half-duplex end to experience late collisions.
3
Evaluate the BPDU Guard log and port state change.
BPDU Guard is designed to protect access ports configured with PortFast from unauthorized STP topology change messages.
Receiving a BPDU on a BPDU Guard-enabled port forces the switch to err-disable the port to prevent potential switching loops.
4
Diagnose selective VLAN loss across an active trunk link.
Since the link protocol is UP and VLAN 10 functions, trunk encapsulation and physical layer are operational, isolating the issue to VLAN 40 configuration.
A VLAN allowed-list restriction or VTP pruning specific to VLAN 40 blocks that single VLAN while permitting others.

Key Concept

Layer 2 Switching and Trunking Troubleshooting Diagnostics
Question 324Question

A network engineer is troubleshooting an issue where workstations on a branch office subnet (192.168.30.0/24192.168.30.0/24) cannot access an internal corporate web server (10.50.4.10010.50.4.100) over HTTPS or reach external websites. Local inter-VLAN traffic works normally.

The engineer inspects the workstation configuration and branch router logs:

Workstation Network Settings:
- IP Address: 192.168.30.45192.168.30.45
- Subnet Mask: 255.255.255.0255.255.255.0
- Default Gateway: 192.168.30.1192.168.30.1

Branch Router Routing Table (`show ip route` excerpt):
- C192.168.30.0/24C\quad 192.168.30.0/24 is directly connected, `GigabitEthernet0/0.30`
- S0.0.0.0/0S*\quad 0.0.0.0/0 [1/0] via 203.0.113.254203.0.113.254

Branch Router Outbound ACL (`show ip access-lists OUTBOUND_FILTER` excerpt):
- `10 permit udp 192.168.30.0 0.0.0.255 host 10.50.4.100 eq 443`
- `20 deny ip 192.168.30.0 0.0.0.255 10.50.0.0 0.0.255.255`

Which TWO factors are directly responsible for the observed connectivity failure? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: The router lacks a specific static or dynamic route targeting the internal 10.50.0.0/1610.50.0.0/16 network via the IPsec tunnel interface.; ACL line 10 specifies UDP instead of TCP for destination port 443, causing HTTPS web traffic to be blocked by the subsequent deny rule.

Answer

The connectivity failures are caused by a missing specific route for the internal 10.50.0.0/1610.50.0.0/16 network across the VPN tunnel, and a transport protocol mismatch in ACL line 10 specifying UDP instead of TCP for port 443.
The issue stems from two distinct misconfigurations. First, the router lacks a static or dynamic route for 10.50.0.0/1610.50.0.0/16 pointing to the VPN tunnel interface, causing internal corporate traffic to be forwarded to the public ISP gateway. Second, ACL line 10 incorrectly permits UDP port 443 instead of TCP port 443; HTTPS uses TCP, so web traffic falls through to line 20 and gets dropped by the explicit deny statement.

Step-by-Step Solution

1
Analyze the branch router routing table for destination network reachability.
The routing table only contains a directly connected route for 192.168.30.0/24192.168.30.0/24 and a default static route (0.0.0.0/00.0.0.0/0) pointing out the public Internet gateway (203.0.113.254203.0.113.254).
Traffic destined for the corporate network (10.50.4.10010.50.4.100) will incorrectly follow the default route out to the public internet rather than being directed into the IPsec VPN tunnel interface.
2
Inspect the Access Control List configuration for application protocol accuracy.
Line 10 permits UDP port 443 for traffic to 10.50.4.10010.50.4.100, but HTTPS utilizes TCP port 443.
Because HTTPS traffic uses TCP, it fails to match line 10 and is caught by line 20 (`deny ip 192.168.30.0 0.0.0.255 10.50.0.0 0.0.255.255`), dropping the packets.

Key Concept

Routing Table Lookups and Access Control List Protocol Matching
Estimated Time:2m 30s
Question 325Question

A network administrator is troubleshooting an issue where new Linux servers in VLAN 105 (192.168.105.0/24192.168.105.0/24) fail to acquire dynamic IP addresses from a central DHCP server (10.10.1.5010.10.1.50) located across a Layer 3 boundary. The router subinterface for VLAN 105 (`Gi0/0.105`) is configured with `ip helper-address 10.10.1.50`. However, packet captures show that client DHCP DISCOVER requests sent to 255.255.255.255255.255.255.255 are received on `Gi0/0.105`, but no unicast DHCP messages are ever transmitted from the router toward 10.10.1.5010.10.1.50, and client systems eventually assign themselves APIPA addresses. Upon reviewing the router interface configuration and DHCP server status, which TWO conditions would explain this behavior?

Select all that apply

Show answer & explanation

Answer: An inbound Access Control List (ACL) applied to interface `Gi0/0.105` explicitly blocks incoming UDP port 67 traffic, preventing the router relay process from intercepting client requests.; The central DHCP server lacks an active scope matching the gateway IP address (`giaddr`) of 192.168.105.1192.168.105.1 inserted by the relay agent.

Answer

The two conditions explaining the lease failure are that an inbound ACL on the subinterface is blocking incoming UDP port 67 broadcast traffic, and that the central DHCP server lacks an active scope corresponding to the relay agent's gateway IP address (giaddr).
DHCP relay agents must receive client broadcast traffic on UDP port 67 to process and encapsulate requests into unicast packets directed to the DHCP server. If an inbound Access Control List blocks UDP port 67 on the client subinterface, relaying fails immediately. Additionally, when relayed packets arrive at the DHCP server, the server inspects the `giaddr` field (set to the router's subinterface IP) to select an appropriate pool; if no matching scope exists for that subnet on the server, no lease offer can be generated.

Step-by-Step Solution

1
Analyze the DHCP Relay mechanism on Layer 3 interfaces.
DHCP clients send local broadcast packets (destination UDP 67). The router interface with `ip helper-address` must intercept these incoming broadcasts before relaying them as unicast UDP packets (destination 10.10.1.5010.10.1.50, UDP port 67).
If an inbound ACL filters UDP port 67 on the subinterface, the router drops the broadcast frame before it reaches the CPU/relay process.
2
Evaluate the relay agent packet fields and server scope matching.
The relay agent populates the `giaddr` field with its subinterface IP (192.168.105.1192.168.105.1). The DHCP server uses `giaddr` to select the appropriate scope.
If the central DHCP server does not have an active scope defined for 192.168.105.0/24192.168.105.0/24, it cannot assign an address, causing the DORA process to fail and clients to generate APIPA (169.254.x.x169.254.x.x) addresses.

Key Concept

DHCP Relay Operation, ACL Traffic Filtering, and GIADDR Scope Selection
Question 326Question

A network systems engineer is investigating severe network degradation on a newly deployed 90-meter Category 6A UTP link connecting an access switch to a server cluster. Server nodes on this link report intermittent link flapping, high frame loss, and an inability to obtain dynamic IP configurations from the centralized DHCP server. To conduct a comprehensive diagnosis of both physical layer integrity and transport protocol operations for this issue, which TWO of the following tools or capture filter configurations should the engineer utilize? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Attach a Time-Domain Reflectometer (TDR) to the UTP run to measure signal reflections and pinpoint the precise linear distance to any physical conductor breaks or impedance mismatches.; Configure a packet analyzer filter specifying `udp port 67 or udp port 68` to capture and inspect DHCPOFFER and DHCPACK transaction frames.

Answer

The network engineer should attach a Time-Domain Reflectometer (TDR) to locate physical cabling faults by distance, and set a packet analyzer filter for UDP ports 67 and 68 to inspect DHCP protocol traffic.
Using a Time-Domain Reflectometer (TDR) allows the administrator to send signals down the Category 6A cabling and calculate the distance to pin breaches or impedance disruptions. Additionally, setting a packet capture filter for UDP ports 67 and 68 captures the full DHCP DORA sequence, enabling analysis of lease negotiations.

Step-by-Step Solution

1
Evaluate the physical layer diagnostic requirement.
Identify that a Time-Domain Reflectometer (TDR) is required to pinpoint physical cable impairments such as impedance mismatches or breaks along copper runs.
Simple wiremap continuity testers only confirm pin-to-pin alignment and cannot measure distance to faults or high-frequency electrical characteristics.
2
Evaluate the upper-layer packet capture requirement for DHCP troubleshooting.
Identify that DHCP traffic uses UDP port 67 (server) and UDP port 68 (client).
DHCP is a connectionless protocol that uses UDP rather than TCP. Filtering for TCP port 67 or 68 would incorrectly filter out all legitimate DHCP packets.

Key Concept

Physical Cable Fault Localization and Packet Filter Construction
Question 327Question

A network administrator is troubleshooting connectivity issues for a workstation that cannot access a secure web portal (10.50.20.15:44310.50.20.15:443). The workstation is assigned an IP address of 192.168.5.85/24192.168.5.85/24 with a default gateway configured as 192.168.6.1192.168.6.1. A ping test from the workstation to its configured default gateway fails. Furthermore, inspection of the interface ACL on the intermediate router shows only the following rule: `permit tcp 192.168.5.0 0.0.0.255 host 10.50.20.15 eq 80`. Which TWO of the following configurations are causing the connection to fail? (Select TWO)

Select all that apply

Show answer & explanation

Answer: The host workstation's configured default gateway resides on a different IP subnet than the host address.; The Access Control List on the router lacks an explicit permit rule for TCP port 443 traffic, causing it to be dropped by implicit deny.

Answer

The connectivity failures are caused by the default gateway being configured on a different IP subnet than the host (192.168.6.1 vs 192.168.5.0/24) and the router ACL lacking an explicit permit statement for HTTPS traffic on TCP port 443.
The host is unable to reach its default gateway because 192.168.6.1192.168.6.1 falls outside the host's 192.168.5.0/24192.168.5.0/24 subnet. Additionally, even if routing succeeded, the secure web traffic targeting TCP port 443 is blocked by the router's ACL, which only permits TCP port 80 traffic before falling through to the implicit deny all rule.

Step-by-Step Solution

1
Analyze the local IP address and gateway subnet configuration.
Host IP 192.168.5.85/24192.168.5.85/24 belongs to subnet 192.168.5.0/24192.168.5.0/24 (range 192.168.5.1192.168.5.1192.168.5.254192.168.5.254). The gateway IP 192.168.6.1192.168.6.1 is in subnet 192.168.6.0/24192.168.6.0/24, creating a subnet mismatch.
A host cannot communicate off-subnet if its default gateway is configured outside its local subnet.
2
Examine the router ACL configuration against the target application requirement.
The target portal requires HTTPS (TCP 443), but the ACL only permits HTTP (TCP 80).
All traffic not explicitly allowed by ACL rules is blocked by the implicit deny rule at the end of the Access Control List.

Key Concept

Subnet alignment for default gateways and Access Control List port matching
Question 328Question

Match each physical layer network issue or diagnostic requirement with the most appropriate hardware testing tool.

Click a left item, then click its matching right item

Items

Locating the exact distance to a bend or break in a 2 km single-mode fiber optic link
Tracing an unlabelled Ethernet wall outlet back to its corresponding port on a patch panel
Verifying the operational integrity of a network interface card's transmit and receive circuitry
Identifying a split-pair condition and distance to an open fault on a Category 6 UTP cable run

Matches

Show answer & explanation

Answer

The diagnostic scenarios match their respective hardware tools as follows: Optical Time-Domain Reflectometer (OTDR) maps to long-distance fiber breaks; Tone Generator and Probe maps to tracing unlabelled cable runs; Loopback Plug maps to testing interface hardware circuitry; Time-Domain Reflectometer (TDR) maps to copper cable split pairs and open fault distance measurements.
Each tool is paired according to its specific function and physical medium: OTDR tests fiber optic reflections, Tone Generator/Probe traces copper cable pathways, Loopback Plugs test hardware interfaces, and TDR measures electrical reflections on copper twisted-pair cabling.

Step-by-Step Solution

1
Analyze the transmission medium and fault type for each diagnostic scenario.
Differentiate between optical fiber and twisted-pair copper requirements, and separate path tracing from interface diagnostics.
Selecting the correct hardware tester depends on whether the medium is copper or fiber optic and whether the objective is wire tracing, fault distance measurement, or port verification.
2
Match fiber optic reflective testing to OTDR.
Pair the 2 km single-mode fiber fault location task with the Optical Time-Domain Reflectometer (OTDR).
OTDR is specifically designed for optical cable reflection and distance-to-fault measurements.
3
Match signal induction tracing to tone generator and probe.
Pair tracing an unlabelled cable to its patch panel port with Tone Generator and Probe.
Tone generators induce an analog audio signal onto copper cabling that an inductive probe detects.
4
Match port loopback signal testing to loopback plug.
Pair NIC transmit/receive port testing with Loopback Plug.
Loopback plugs route TX back to RX to validate port hardware operational status.
5
Match electrical signal reflection and pinout testing to copper TDR.
Pair UTP split-pair and distance to open fault with Time-Domain Reflectometer (TDR).
TDR uses electrical pulse reflections to locate impedance changes and pinout errors on copper cables.

Key Concept

Selecting appropriate physical layer hardware tools based on medium, fault type, and testing objective.
Question 329Question

A network engineer is troubleshooting high frame error rates and link degradation on a 90-meter Category 6 twisted-pair cable drop connecting a core switch to a desktop client. A basic continuity wiremap tester indicates that all eight pins are correctly wired straight-through (1-to-1 through 8-to-8) with no open or short circuits. However, when the link autonegotiates to 1000BASE-T, the connection experiences severe Near-End Crosstalk (NEXT) and high packet loss. Which diagnostic tool should the engineer utilize to identify the physical cable fault causing this issue?

Show answer & explanation

Answer: Cable certifier / TDR with NEXT frequency testing capability to detect a split-pair error

Answer

Cable certifier / TDR with NEXT frequency testing capability to detect a split-pair error
The correct answer identifies that a cable certifier / advanced TDR capable of NEXT testing is required. A split pair occurs when individual conductors from different twisted pairs are accidentally swapped at termination points. Because DC continuity remains intact, simple continuity testers report the cable as correctly wired. However, mixing pairs breaks the balance of the differential signaling, leading to severe Near-End Crosstalk (NEXT) and packet corruption when operating at high frequencies like Gigabit Ethernet.

Step-by-Step Solution

1
Analyze the symptoms and test results provided in the scenario.
The cable shows 1-to-1 pin continuity on a simple wiremap tester, but suffers high Near-End Crosstalk (NEXT) and error rates under 1000BASE-T operations.
1000BASE-T uses all four twisted pairs simultaneously for bidirectional signaling, making it extremely sensitive to pair balance and electromagnetic interference.
2
Differentiate between simple continuity testing and signal quality certification.
A basic wiremap tester only confirms DC electrical continuity across corresponding pins on each connector; it does not measure high-frequency AC signal characteristics or proper pair pairing.
When conductors from two different pairs are mixed (e.g., tip of Pair 1 with ring of Pair 2), DC continuity is still maintained, but the twist geometry that cancels out electromagnetic interference is lost.
3
Select the appropriate hardware diagnostic tool for identifying split pairs and NEXT.
A cable certifier or advanced TDR measures crosstalk parameters across frequency spectrums and detects split pairs.
Only high-frequency cable certifiers evaluate parameter compliance (such as NEXT, FEXT, attenuation, and return loss) specified by TIA/EIA standards.

Key Concept

Identifying physical layer cable faults using cable certifiers vs basic wiremap testers
Estimated Time:2m 0s
Question 330Question

A network technician is troubleshooting severe latency and high frame retransmission rates on a 2.4 GHz wireless network within an office suite. Signal spectrum analysis reveals that three neighboring access points are broadcasting on channels 1, 2, and 3, resulting in significant adjacent-channel interference. Which of the following actions should the technician take to remediate these wireless signal issues? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Reconfigure the wireless access points to use a non-overlapping channel deployment pattern consisting of channels 1, 6, and 11.; Ensure 2.4 GHz channel width is configured to 20 MHz rather than 40 MHz channel bonding.

Answer

To resolve adjacent-channel interference in the 2.4 GHz band, the technician must reconfigure the access point channels to a non-overlapping scheme (channels 1, 6, and 11) and restrict radio channel widths to 20 MHz.
In the 2.4 GHz Wi-Fi spectrum, channels overlap significantly. Using adjacent channel assignments such as channels 1, 2, and 3 creates adjacent-channel interference (ACI), causing corrupt frames and high packet retransmission rates. Assigning non-overlapping channels (1, 6, and 11) eliminates ACI. Furthermore, maintaining a 20 MHz channel width avoids consuming excessive spectrum, preserving non-overlapping channel capacity.

Step-by-Step Solution

1
Analyze the radio frequency channel allocation.
Identified adjacent-channel interference caused by setting neighboring 2.4 GHz access points to channels 1, 2, and 3.
Channels 1, 2, and 3 overlap in frequency, causing uncoordinated signal degradation and high frame retransmissions.
2
Select non-overlapping channels for the 2.4 GHz band.
Reassign access points to channels 1, 6, and 11.
Channels 1, 6, and 11 have 25 MHz separation, providing the required spectral clearance to operate concurrently without inter-channel interference.
3
Verify channel width configurations across all access points.
Set channel width to standard 20 MHz.
Channel bonding (40 MHz) in the 2.4 GHz spectrum uses up most available frequencies and makes non-overlapping channel reuse virtually impossible.

Key Concept

2.4 GHz Non-Overlapping Channel Planning and Channel Width Optimization
Question 331Question

A network engineer is troubleshooting a newly connected point-of-sale terminal on VLAN 45 (10.45.10.0/2410.45.10.0/24) that cannot communicate with the accounting database. Executing `ip addr show eth0` on the terminal produces the following output:

text
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default
inet 169.254.112.85/16 brd 169.254.255.255 scope global eth0
valid_lft forever preferred_lft forever

Inspection of the default gateway router configuration for VLAN 45 displays the following settings:

text
interface GigabitEthernet0/0.45
encapsulation dot1Q 45
ip address 10.45.10.1 255.255.255.0
ip helper-address 10.100.20.14

A recent IP audit confirms that the active central enterprise DHCP server resides at address 10.100.20.1510.100.20.15. What is the primary root cause of the terminal failing to acquire a valid network IP address?

Show answer & explanation

Answer: The `ip helper-address` directive on the gateway router subinterface is misconfigured with an incorrect DHCP server IP address.

Answer

The `ip helper-address` statement on the gateway subinterface specifies 10.100.20.1410.100.20.14, which does not match the active central DHCP server IP address (10.100.20.1510.100.20.15).
When client devices display an address within the 169.254.0.0/16169.254.0.0/16 block (APIPA), it signifies that the host attempted a dynamic lease request but received no DHCP OFFER. Because the DHCP server sits on a different subnet (10.100.20.0/2410.100.20.0/24), the router's subinterface uses `ip helper-address` to forward broadcast requests via unicast. The configuration lists 10.100.20.1410.100.20.14 instead of the active server address 10.100.20.1510.100.20.15, causing all forwarded DHCP requests to be dropped by the network.

Step-by-Step Solution

1
Analyze client IP output snippet
The terminal displays IP address 169.254.112.85/16169.254.112.85/16, identifying an Automatic Private IP Addressing (APIPA) self-assigned address.
When a DHCP client fails to receive a DHCP DISCOVER response/OFFER, it defaults to APIPA.
2
Examine gateway relay settings
Interface `GigabitEthernet0/0.45` routes requests using `ip helper-address 10.100.20.14`.
DHCP broadcast messages generated on VLAN 45 must be converted into unicast packets destined for the DHCP server IP address specified in the helper directive.
3
Compare helper address against active server inventory
The configured helper IP (10.100.20.1410.100.20.14) is incorrect because the central DHCP server is hosted at 10.100.20.1510.100.20.15.
Forwarded unicast DHCP DISCOVER frames are sent to an inactive or non-DHCP endpoint, resulting in lost requests and client lease timeout.

Key Concept

DHCP Relay (IP Helper) Address Configuration and APIPA Diagnosis
Question 332Question

A network technician receives reports that internal workstations are intermittently directed to an external IP address when resolving the internal hostname `app.corp.local`. To investigate, the technician executes `nslookup app.corp.local 10.0.4.10` from a CLI interface and receives the following output:

Server: internal-dns.corp.local
Address: 10.0.4.10

Non-authoritative answer:
Name: app.corp.local
Address: 203.0.113.88

Based on this output, which of the following is the most accurate analysis of the issue?

Show answer & explanation

Answer: The local DNS server returned a cached response from an external recursive lookup rather than answering authoritatively from its local primary zone file.

Answer

The local DNS server returned a cached response from an external recursive lookup rather than answering authoritatively from its local primary zone file.
In DNS troubleshooting, a 'Non-authoritative answer' output from `nslookup` or `dig` signifies that the DNS server responding to the query does not maintain the authoritative zone file for the domain queried. Instead, the server obtained the record by querying external upstream servers recursively and cached the result. Returning an external IP address (`203.0.113.88`) for an internal domain under a non-authoritative banner indicates the server is resolving the domain via forwarders or cache rather than using a local primary domain zone.

Step-by-Step Solution

1
Analyze the CLI input command and target server IP.
The command `nslookup app.corp.local 10.0.4.10` directs the query specifically to the server at `10.0.4.10`.
Specifying the server IP overrides default host resolver settings to test a specific DNS server.
2
Examine the output header line 'Non-authoritative answer:'.
Identifies that `10.0.4.10` does not hold the primary or secondary authoritative zone file for `corp.local` for this record.
A non-authoritative answer occurs when a DNS server fulfills a request using cached data acquired from another DNS server rather than reading from its own authoritative zone database.
3
Synthesize the symptom with the returned IP address (`203.0.113.88`).
The server returned a cached external IP address instead of resolving `app.corp.local` internally.
This confirms that the local DNS server forwarded the query upstream or holds a polluted/stale cache entry rather than utilizing an authoritative local zone mapping.

Key Concept

Interpreting nslookup output headers and distinguishing authoritative zone responses from cached recursive lookup results.
Question 333Question

A network administrator is using a packet analyzer to troubleshoot an issue where client hosts on a remote subnet cannot obtain IP addresses automatically. The administrator suspects that DHCP relay messages are not reaching the centralized DHCP server. To verify if relayed bootstrap requests are arriving at the server's network interface card, which protocol and port criteria should the administrator filter for in the packet analyzer capture?

Show answer & explanation

Answer: UDP port 67

Answer

UDP port 67 is the correct filter criteria for inspecting incoming DHCP request and relay packets on the server interface.
DHCP uses UDP as its transport layer protocol. Centralized DHCP servers and relay agents send and receive requests on UDP port 67. To analyze incoming relay packets arriving at the server, filtering for UDP port 67 isolates the relevant BOOTREQUEST traffic.

Step-by-Step Solution

1
Identify the protocol transport model used by DHCP services
DHCP operates over User Datagram Protocol (UDP) for unacknowledged, low-latency transmission.
DHCP clients do not establish a TCP connection prior to obtaining an IP configuration.
2
Determine the specific port used by the server side of the DHCP communication
The server listens on destination UDP port 67 for incoming client requests and relay agent boot messages.
Port 67 receives requests (DHCPDISCOVER, DHCPREQUEST) and relayed BOOTREQUEST packets, while port 68 receives client responses (DHCPOFFER, DHCPACK).
3
Formulate the packet analyzer display filter
Filtering traffic for UDP destination port 67 isolates incoming DHCP relay traffic reaching the server.
This allows the technician to confirm whether the remote router successfully forwards relay packets to the server interface.

Key Concept

DHCP Protocol Operation and Packet Capture Filtering
Estimated Time:1m 30s
Question 334Question

A network administrator on a Linux workstation is troubleshooting an inability to reach a remote HTTPS service hosted at 10.20.30.50 on custom port 8443. Following a structured bottom-up OSI troubleshooting methodology, in what sequence should the administrator execute the following command-line diagnostics to systematically isolate the failure?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct diagnostic sequence begins with verifying host interface configuration (`ip addr show`), testing local gateway reachability (`ping -c 3 192.168.1.1`), isolating intermediate path routing (`traceroute -n 10.20.30.50`), and finally checking specific TCP port socket accessibility (`nc -zv 10.20.30.50 8443`).
Adhering to a bottom-up troubleshooting methodology requires starting with local host interface verification (`ip addr show`), followed by testing default gateway reachability (`ping`), isolating multi-hop routing paths (`traceroute`), and concluding with transport layer port testing (`nc`).

Step-by-Step Solution

1
Inspect local network interface configuration using `ip addr show`.
Confirms physical/data link connection state and validates local IPv4 address configuration.
Troubleshooting must begin at the local host level (Layers 1 and 2) to ensure the network interface is up and bound to an IP address.
2
Test ICMP echo communication to the default gateway with `ping -c 3 192.168.1.1`.
Verifies ARP resolution and local segment Layer 3 forwarding capability.
If local gateway ping fails, off-subnet routing is impossible, making upstream path tracing unnecessary until local connectivity is restored.
3
Perform path discovery to the target IP address using `traceroute -n 10.20.30.50`.
Identifies the specific hop or WAN interface where packet transit terminates.
Layer 3 path reachability must be confirmed end-to-end before probing specific transport layer application ports.
4
Probe destination transport port using netcat (`nc -zv 10.20.30.50 8443`).
Determines if TCP port 8443 accepts connection attempts or if packets are filtered by security devices.
Transport layer port socket testing is the final step once underlying Layer 3 routing and path reachability are confirmed.

Key Concept

Bottom-up CLI Network Troubleshooting Methodology
Estimated Time:2m 0s
Question 335Question

A network administrator is troubleshooting an issue where containerized API gateways fail to communicate with an internal microservice cluster across a virtual overlay network. The administrator established a theory that an overly restrictive container firewall policy was blocking traffic and verified this theory by temporarily allowing all traffic, which immediately restored connectivity. Which of the following actions should the administrator take in the immediate next phases of the CompTIA troubleshooting methodology? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Formulate a detailed plan of action to configure granular port rules while evaluating potential impact on overall application security.; Execute the planned firewall rule updates to permanently re-enable secure microservice communication.

Answer

The administrator should formulate a detailed plan of action while evaluating potential security impacts, and then execute the planned firewall rule updates.
According to the CompTIA troubleshooting methodology, once a technician tests a theory and confirms the root cause (Step 3), they must establish a plan of action to resolve the problem while identifying potential effects (Step 4), and then implement the solution (Step 5). Formulating a detailed plan of action with port rules and executing those planned updates correspond directly to these two sequential phases.

Step-by-Step Solution

1
Determine the completed step in the CompTIA troubleshooting methodology.
The administrator completed Step 3 (Test the theory to determine cause) by temporarily allowing traffic to confirm the hypothesis.
Identifying the current position in the sequence determines which steps logically follow.
2
Identify the immediate next steps in the official methodology sequence.
The next sequential steps are Step 4 (Establish a plan of action to resolve the problem and identify potential effects) and Step 5 (Implement the solution or escalate as necessary).
CompTIA guidelines require creating a plan and considering potential side effects before implementing a permanent resolution.
3
Match the scenario options to the required methodology steps.
Formulating a detailed plan considering security impact maps to Step 4, and executing the planned updates maps to Step 5.
System verification (Step 6) and documentation (Step 7) take place later in the methodology lifecycle.

Key Concept

CompTIA 7-Step Troubleshooting Methodology Sequence
Question 336Question

A network administrator is isolating connectivity failures on a newly commissioned twisted-pair workstation drop. The administrator needs to verify the physical layer integrity to pinpoint cable distance faults and analyze captured broadcast traffic to identify rogue DHCP server offers on the subnet. Which TWO tools or capabilities should the administrator utilize to achieve these objectives? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Time-Domain Reflectometer (TDR) to measure cable continuity and locate physical impedance breaks; Packet analyzer with a display filter targeting DHCP traffic (such as bootp or udp.port == 67)

Answer

The administrator should use a Time-Domain Reflectometer (TDR) for physical copper cable fault location and a packet analyzer with DHCP protocol display filters to identify rogue DHCP server traffic.
Using a Time-Domain Reflectometer (TDR) allows precise detection and distance measurement of physical copper cable defects, while a packet analyzer equipped with DHCP protocol filters enables capture and analysis of Layer 3/4 network traffic to identify unauthorized DHCP servers.

Step-by-Step Solution

1
Select the appropriate physical layer testing tool for copper media.
Identify that a Time-Domain Reflectometer (TDR) measures signal reflections to calculate cable length and locate distance to open or short circuits.
Physical layer cable testing requires specialized hardware capable of pinpointing signal degradation and wire breaks.
2
Select the appropriate protocol analysis tool for inspect network layer / application layer traffic.
Identify that a packet analyzer capturing traffic on UDP port 67/68 allows inspection of DHCP Offer packets.
Packet capture and protocol decoding are required to read upper-layer packet headers and trace rogue server IP/MAC addresses.

Key Concept

Utilizing TDR hardware for Layer 1 cable fault location and packet analyzers for protocol traffic inspection
Question 337Question

A network administrator is troubleshooting a DNS lookup issue on a Linux client. Standard hostname resolution over UDP functions normally for small queries, but operations requiring larger payloads fail. When testing the DNS server at IP address `172.16.10.5` using the TCP mode (`+vc` flag), the administrator observes the following output:

text
$ dig @172.16.10.5 app.corp.internal +vc
;; Connection to 172.16.10.5#53(172.16.10.5) for app.corp.internal failed: connection refused.

Which of the following is the most likely root cause of this failure?

Show answer & explanation

Answer: An intermediate network firewall or ACL is blocking traffic on TCP port 53.

Answer

An intermediate network firewall or ACL is blocking traffic on TCP port 53.
DNS relies on UDP port 53 for lightweight queries, but switches to TCP port 53 when responses exceed payload limits or when explicitly configured via tools like `dig +vc`. A 'connection refused' response when attempting to communicate over TCP indicates that network transport on TCP port 53 is being blocked by a security ACL or firewall filter.

Step-by-Step Solution

1
Analyze the utility command and flags used
The `dig` command specified `@172.16.10.5` with the `+vc` flag, forcing the request to establish a TCP connection on port 53 rather than standard UDP datagrams.
Understanding tool behavior identifies whether the failure occurs at the application service level or transport transport layer.
2
Evaluate the specific error message
The output returns 'connection refused' for port 53 under TCP mode.
This error indicates that TCP connection establishment (SYN/ACK) failed because traffic to TCP port 53 is explicitly denied or blocked by a firewall filter between the client and DNS server.
3
Correlate with DNS protocol operations
DNS uses UDP port 53 for standard queries under 512 bytes (or EDNS0 limits) and switches to TCP port 53 for truncated payloads or explicit TCP requests.
Blocking TCP port 53 prevents large DNS responses, zone transfers, and forced TCP fallbacks from succeeding.

Key Concept

DNS Protocol Transport Mechanism (TCP vs UDP Port 53)
Estimated Time:1m 30s
Question 338Question

Match each observed wireless network performance symptom to its corresponding Radio Frequency (RF) root cause or signal behavior.

Click a left item, then click its matching right item

Items

Elevated frame retry rates and low throughput despite a high Received Signal Strength Indicator (RSSI) near overlapping 2.4 GHz access points.
A severe drop in signal level (RSSI) immediately after passing through walls containing dense metallic shielding.
Corrupted frames and intermittent throughput drops caused by RF signals reflecting off hard surfaces and arriving at the receiver at slightly different times.
A mobile handheld scanner maintaining a connection to a distant access point with poor signal strength instead of switching to an adjacent access point with a stronger signal.

Matches

Show answer & explanation

Answer

1. High retry rate with strong RSSI maps to Adjacent Channel Interference (ACI). 2. Signal strength drop behind dense walls maps to Material Attenuation. 3. Reflected signals causing phase issues maps to Multipath Interference. 4. Mobile device failing to switch access points maps to Sticky Client Behavior.
Each symptom directly corresponds to a specific wireless RF issue: Adjacent Channel Interference causes high retransmissions under strong signal conditions due to channel overlap; Material Attenuation reduces signal strength across physical barriers; Multipath Interference results from RF signal reflections arriving out of phase; and Sticky Client Behavior occurs when client devices fail to roam to a closer access point.

Step-by-Step Solution

1
Analyze symptom 1 regarding high retries under strong signal conditions.
Identified Adjacent Channel Interference (ACI) because spectral overlap degrades Signal-to-Noise Ratio (SNR) without necessarily dropping raw RSSI.
Overlapping Wi-Fi channels corrupt frames during transmission.
2
Analyze symptom 2 regarding signal loss through metallic barriers.
Identified Material Attenuation because metallic and concrete obstacles absorb RF wave energy.
Physical obstacles reduce signal power measured in dBm.
3
Analyze symptom 3 regarding reflected signals arriving at different intervals.
Identified Multipath Interference, where multiple delayed copies of the signal cause phase cancellation.
RF reflections off conductive/dense surfaces create timing differences at the receiver antenna.
4
Analyze symptom 4 regarding roaming behavior failure.
Identified Sticky Client Behavior, where a station remains locked to a distant AP due to conservative roaming algorithms or power asymmetries.
Client driver roaming thresholds prevent timely reassociation.

Key Concept

Wireless Radio Frequency (RF) Signal Degradation and Roaming Issues
Question 339Question

A network administrator is troubleshooting an issue where a Windows client workstation fails to resolve internal hostnames. To isolate where name resolution fails within the OS lookup hierarchy, in what order does a standard Windows client attempt to resolve a target hostname? Arrange the following resolution mechanisms from first evaluated (top) to last evaluated (bottom).

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct evaluation sequence for Windows name resolution is: 1) Inspect local DNS cache and HOSTS file, 2) Send a unicast DNS query to the primary configured DNS server, 3) Transmit LLMNR requests on the local subnet, 4) Broadcast NetBIOS Name Service (NBT-NS) requests.
The Windows operating system follows a strict, deterministic sequence for host name resolution: local cache and HOSTS file lookup occurs first, followed by unicast queries to configured DNS servers, then local subnet multicast via LLMNR, and finally legacy NetBIOS (NBT-NS) broadcasts.

Step-by-Step Solution

1
Evaluate local host resources
The operating system checks memory (DNS resolver cache) and local configuration files (HOSTS) first to avoid unnecessary network traffic.
Local lookup requires zero network overhead and provides immediate response if a mapping exists.
2
Query configured network DNS servers
The OS queries the primary DNS server IP configured on the active network interface over port 53.
Centralized DNS resolution is the primary method for resolving domain hostnames across local networks and the internet.
3
Initiate local multicast fallback via LLMNR
If the DNS server is unreachable or responds with Name Error (NXDOMAIN), the client sends LLMNR multicast packets on UDP 5355.
LLMNR allows peer-to-peer name resolution on the local link without requiring a centralized DNS server.
4
Initiate legacy broadcast fallback via NBT-NS
If LLMNR produces no response, Windows defaults to NetBIOS Name Service broadcasts over UDP 137.
NBT-NS provides backward compatibility with legacy Windows networking environments.

Key Concept

Windows Client Name Resolution Order
Question 340Question

A network technician is troubleshooting a newly connected client workstation that cannot access local network resources or the internet. Executing `ipconfig /all` on the workstation yields the following output:

Ethernet adapter Ethernet0:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::d4a2:810f:3c21:7a9a%12
IPv4 Address. . . . . . . . . . . : 169.254.108.42
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :

Which of the following is the most likely cause of this workstation's IP configuration?

Show answer & explanation

Answer: The host was unable to obtain an IP lease from a DHCP server and self-assigned an Automatic Private IP Addressing (APIPA) address.

Answer

The host was unable to obtain an IP lease from a DHCP server and self-assigned an Automatic Private IP Addressing (APIPA) address.
An IPv4 address beginning with 169.254.x.x indicates Automatic Private IP Addressing (APIPA). Operating systems assign an APIPA address when configured as a DHCP client but fail to receive a response (DHCPACK) from a reachable DHCP server.

Step-by-Step Solution

1
Analyze the IP address output from the client workstation command prompt.
The IPv4 address is 169.254.108.42 with a subnet mask of 255.255.0.0.
Recognizing the address range helps identify how the host acquired its network settings.
2
Identify the standard protocol associated with the 169.254.0.0/16 address space.
The range 169.254.0.1 through 169.254.255.254 is reserved for Automatic Private IP Addressing (APIPA).
Client operating systems dynamically generate an APIPA address when DHCP DORA messages fail to produce a lease.
3
Deduce the primary root cause of the issue.
The workstation failed to contact a DHCP server, resulting in local link-local address generation.
Without a valid DHCP lease or static assignment, network layer routing beyond the immediate link is unviable.

Key Concept

Automatic Private IP Addressing (APIPA) Diagnosis
Estimated Time:1m 15s
PreviousPage 17 / 25Next