CCNA Switching and Network Access Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Identify the source interface or VLAN to monitor for traffic capture.

  Why this is correct

  Choosing the source is the foundational planning step before any SPAN configuration. The source can be a single physical port, a range of ports, or an entire VLAN, and you must also decide whether to capture ingress traffic, egress traffic, or both because a port's unidirectional traffic may reveal different issues. Selecting the wrong source or direction will result in a capture that misses the fault, so this step defines exactly which frames the SPAN session will clone and forward to the analyzer.

• ✓

  Configure a SPAN session to mirror traffic from the source to a destination port.

  Why this is correct

  SPAN is configured on the Cisco switch with commands such as 'monitor session 1 source interface GigabitEthernet0/1 both' followed by 'monitor session 1 destination interface GigabitEthernet0/2'. This creates a dedicated session that copies frames from the source to the destination on a per-session basis, but it does not remove the source's normal forwarding path. The configuration must include a session number, source, and destination, and you must be aware that a SPAN destination port cannot also be used for normal network traffic, so it becomes exclusively reserved for the analyzer.

• ✓

  Connect a packet capture device (e.g., laptop) to the SPAN destination port.

  Why this is correct

  The SPAN destination port is not a regular access or trunk port; it receives mirrored copies of the source traffic and forwards them only to the attached analyzer. A laptop or dedicated capture appliance must be physically connected to this port using a standard Ethernet cable, and the device's NIC must support promiscuous mode to see all frames. Because the destination port does not participate in normal switching, it will not send or receive user traffic, so it is safe to dedicate it solely to the packet capture device.

• ✓

  Start the packet capture software on the connected device.

  Why this is correct

  Running software like Wireshark or tcpdump on the connected device is where the mirrored frames are actually recorded and displayed. The capture interface must be selected explicitly, and features such as promiscuous mode and capture filters should be set before starting to avoid unnecessary disk usage and to focus on the protocol of interest. Starting the capture too late or selecting the wrong interface will result in missing the critical frames, even though the SPAN session is correctly delivering them to the device.

• ✓

  Initiate or reproduce the network issue you are troubleshooting.

  Why this is correct

  Reproducing the network issue while the capture is running generates the exact traffic that needs to be examined. For example, send continuous pings, transfer large files, or trigger the failing application so that the mirrored source sees the problematic frames. Without initiating traffic, the capture will only contain background broadcast or protocol chatter, which may not include the fault-specific packets required for diagnosis.

• ✓

  Stop the packet capture after sufficient traffic is collected.

  Why this is correct

  Stopping the capture after a reasonable amount of traffic is collected prevents the capture file from growing exponentially and makes analysis manageable. The stop action should be performed only after the issue has been reproduced and enough packets—including the exact problematic exchange—have been captured. If the capture is stopped too early, you may lose the key frames, and if it is left running indefinitely, the file may become too large for the analysis tool to process efficiently.

• ✓

  Examine captured frames for L2/L3 anomalies such as incorrect VLAN tags, MAC address mismatches, or ARP failures.

  Why this is correct

  Examining captured frames at Layers 2 and 3 is the final diagnostic step, where you look for anomalies such as frames with inconsistent VLAN tags, MAC address mismatches, unexpected ARP replies, or IP addressing errors. For example, an ARP request that goes unanswered can indicate a VLAN mismatch, while a frame with an unexpected source MAC may reveal a wiring or security issue. This analysis correlates the symptoms with the underlying network condition, turning raw captured frames into a concrete root-cause conclusion.

Go deeper

Related to this question