CCNP Practice Question: Is troubleshooting a performance issue on a Cisco…

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 a flow record that matches the specific application using NBAR or an ACL, and apply a flow monitor with a sampler rate to reduce CPU impact.

  Why this is correct

  This is correct because Flexible NetFlow permits a flow record that matches only the target application via NBAR (e.g., using an application match in a flow record) or an ACL in a flow monitor. Adding a sampler rate—for instance, sampling 1 out of every N packets—reduces the number of packets that must be inspected and cached, lowering CPU utilization and export bandwidth while still providing statistically accurate application-level visibility. This confines resource consumption to the specific traffic of interest rather than processing every flow on the switch.

• ✗

  Enable NetFlow on all interfaces and export all flows to the collector, then filter at the collector.

  Why it's wrong here

  Enabling NetFlow on all interfaces and exporting every flow creates a flow cache entry for each unique flow, requiring CPU-intensive lookups and timer maintenance for every packet. The switch must process and export all flows, which can saturate the CPU and exacerbate the very performance problem being diagnosed. Filtering at the collector occurs after the switch has already incurred the cost of exporting all flows, so it does nothing to alleviate the switch-side resource drain.

• ✗

  Use SNMP to poll interface counters and calculate the bandwidth used by the application.

  Why it's wrong here

  SNMP polling retrieves interface MIB counters (e.g., ifHCInOctets, ifHCOutOctets) that aggregate all traffic on an interface into a single total, providing no visibility into which application generated the traffic. It cannot distinguish between HTTP, video, or database flows, and calculating bandwidth from counter deltas yields only a coarse sum, not per-application usage. Moreover, frequent SNMP polling adds management traffic and still does not identify the application causing the issue.

• ✗

  Configure port mirroring (SPAN) to send all traffic to an external probe for analysis.

  Why it's wrong here

  SPAN copies packets of interest to a probe, but without a granular filter—or with a broad filter—it replicates all traffic to the SPAN destination, requiring the switching engine to duplicate every frame and consume extra CPU and bandwidth. This added overhead can further degrade switch performance, and the external probe must do all the analysis, which is not a native flow-based monitoring method. It also doesn't provide flow-level statistics unless the probe reassembles and correlates, making it inefficient for ongoing application bandwidth monitoring.