Switching and Network Access →mediumDrag & DropObjective-mapped

CCNA Switching and Network Access Practice Question

Drag and drop the following steps into the correct order to capture and analyze traffic on IOS-XE using the embedded packet capture feature, and in Wireshark to isolate a Layer 2 or Layer 3 fault.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

⚠ Common exam trap

A common trap is confusing the order of steps, especially applying the filter before defining the interface or starting the capture before applying the filter. Remember that the interface must be defined first, then the filter, then start, then stop, then export.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Define the capture interface, apply a filter, start capture, stop capture, export for analysis in Wireshark.

First define the capture interface, then apply a filter, start capture, stop it, and finally export for analysis in Wireshark.

Answer analysis

Option-by-option breakdown

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

✓
Define the capture interface, apply a filter, start capture, stop capture, export for analysis in Wireshark.
Why this is correct
This is the correct sequence for using embedded packet capture on IOS-XE. First, you define the interface to capture traffic. Then you apply a filter to narrow down the traffic of interest. After starting the capture, you let it run until you have enough data, then stop it. Finally, you export the captured data for analysis in Wireshark to isolate Layer 2 or Layer 3 faults.
✗
Apply a filter, define the capture interface, start capture, export for analysis, stop capture.
Why it's wrong here
This order is incorrect because you must define the capture interface before applying a filter; the filter is applied to the interface. Also, you must stop the capture before exporting the data; exporting while capturing may result in incomplete data.
✗
Define the capture interface, start capture, apply a filter, stop capture, export for analysis.
Why it's wrong here
In IOS-XE embedded packet capture, the capture filter is configured as part of the capture definition and is tied to the capture interface. Once the capture is started, the filter for an active capture cannot be changed; you would need to stop, modify, and restart. Starting without a filter will indiscriminately fill the circular buffer with all traffic, potentially evicting the frames you actually need to analyze for a Layer 2/3 fault.
✗
Apply a filter, start capture, define the capture interface, stop capture, export for analysis.
Why it's wrong here
A capture filter cannot be meaningfully applied before the capture interface exists because the filter's scope is the traffic entering or leaving that interface. In IOS-XE, the interface is a mandatory parameter of the monitor capture command; without it, there is no capture point to associate with the filter. Attempting to start a capture before defining the interface will fail or silently capture nothing, making the subsequent export and analysis impossible.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The 200-301 exam frequently reuses these exact scenarios with slightly different constraints.

✓Define the capture interface, apply a filter, start capture, stop capture, export for analysis in Wireshark.Correct answer▾

Why this is correct

This is the correct sequence for using embedded packet capture on IOS-XE. First, you define the interface to capture traffic. Then you apply a filter to narrow down the traffic of interest. After starting the capture, you let it run until you have enough data, then stop it. Finally, you export the captured data for analysis in Wireshark to isolate Layer 2 or Layer 3 faults.

✗Apply a filter, define the capture interface, start capture, export for analysis, stop capture.Wrong answer — click to see why▾

Why this is wrong here

The specific factual error is that the filter cannot be applied before the interface is defined, and exporting should occur after stopping the capture.

Why candidates choose this

Candidates might think that applying a filter first is logical to limit traffic before defining the interface, but the IOS-XE CLI requires the interface to be specified first.

✗Define the capture interface, start capture, apply a filter, stop capture, export for analysis.Wrong answer — click to see why▾

Why this is wrong here

The specific factual error is that the filter must be configured before the capture starts; applying it after starting would not affect the already captured data.

Why candidates choose this

Candidates might think that you can start capturing first and then apply a filter to the ongoing capture, but IOS-XE does not support dynamic filter application during an active capture.

✗Apply a filter, start capture, define the capture interface, stop capture, export for analysis.Wrong answer — click to see why▾

Why this is wrong here

The specific factual error is that the capture interface must be defined first; otherwise, the device does not know where to capture traffic.

Why candidates choose this

Candidates might think that applying a filter first is a good practice to reduce traffic, but the interface definition is a prerequisite for any capture operation.

Analysis generated from the official 200-301blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Visual reference

Go deeper

CCNA Switching and Network Access Practice Question

Why each option matters

Option-by-option breakdown

Why each answer is right or wrong

Related to this question