Cisco CCNP 350-401 ENCOR Flexible NetFlow, SPAN/RSPAN/ERSPAN, and IP SLA Practice Test 2

 

Topic 14 Practice Test 2 covers Flexible NetFlow, SPAN/RSPAN/ERSPAN, and IP SLA for Cisco 350-401 ENCOR. For broader exam preparation, review the Cisco 350-401 ENCOR Exam Dumps. Every option includes focused technical reasoning explaining both the Cisco enterprise networking concept and its fit to the scenario.

Question 1

Servers in VLAN 120 exchange large amounts of traffic without crossing an SVI. The team needs flow visibility for that bridged traffic. Which Flexible NetFlow capability should be used? Choose ONE.

1. Layer 3 Flexible NetFlow
2. Layer 2 Flexible NetFlow
3. IP SLA ICMP echo
4. SPAN destination interface

Correct Answer(s)

 

B

Rationale

1. Layer 3 Flexible NetFlow observes routed traffic; purely switched traffic within the same VLAN is outside that routed-flow view. Mismatch for Layer 3 Flexible NetFlow: the design must collect flow data for traffic switched within a VLAN rather than only routed traffic. Layer 2 Flexible NetFlow remains the required control for this case.
2. Layer 2 Flexible NetFlow can observe bridged traffic using fields such as MAC addresses and VLAN identifiers. The decisive goal is to collect flow data for traffic switched within a VLAN rather than only routed traffic; Layer 2 Flexible NetFlow supplies that behavior.
3. An ICMP echo operation actively measures basic IP reachability and round-trip response time to a target. The evidence calls for a way to collect flow data for traffic switched within a VLAN rather than only routed traffic; IP SLA ICMP echo does not supply it. This cannot replace the Layer 2 Flexible NetFlow function required here.
4. The SPAN destination is the analyzer-facing port to which the switch sends replicated packets from the configured source. The required outcome is to collect flow data for traffic switched within a VLAN rather than only routed traffic; SPAN destination interface addresses another function. The scenario still depends on Layer 2 Flexible NetFlow for the requested result.

 

Question 2

An engineer tries to apply two IPv4 input flow monitors to the same physical interface and direction so each can analyze the same traffic. The platform rejects the second monitor. What design should replace it? Choose ONE.

1. duplicate unrelated exporters
2. RSPAN remote-span VLAN
3. second same-type input monitor
4. one monitor per traffic type and direction

Correct Answer(s)

 

D

Rationale

1. Adding exporters changes destinations for exported records; it does not solve a same-traffic-type monitor attachment restriction. The required outcome is to avoid two same-type monitors on one interface and direction while still defining the required analysis; duplicate unrelated exporters addresses another function. That leaves one monitor per traffic type and direction as the mechanism that must be addressed.
2. RSPAN carries mirrored frames between switches over a specially designated remote-span VLAN in the Layer 2 domain. Avoid two same-type monitors on one interface and direction while still defining the required analysis is the controlling need; RSPAN remote-span VLAN operates elsewhere in the workflow. The relevant dependency is one monitor per traffic type and direction, so this change misses it.
3. A second monitor of the same traffic type in the same interface direction conflicts with the platform restriction rather than extending coverage. Mismatch for second same-type input monitor: the design must avoid two same-type monitors on one interface and direction while still defining the required analysis. The case is governed by one monitor per traffic type and direction, not this adjacent feature.
4. Catalyst IOS XE does not allow multiple flow monitors of the same traffic type on the same interface and direction, so one monitor must cover that need. The decisive goal is to avoid two same-type monitors on one interface and direction while still defining the required analysis; one monitor per traffic type and direction supplies that behavior.

 

Question 3

A router performs NAT and Flexible NetFlow on the same interface. The analyst expects ordinary records to contain a second set of translated addresses, but they do not. Which behavior matches the cited platform? Choose ONE.

1. actual flow details without a separate translated tuple
2. SPAN both direction
3. translated NAT tuple as a general FNF field
4. NetFlow version 9 export

Correct Answer(s)

 

A

Rationale

1. With FNF and NAT together, the platform normally exports the actual flow details rather than separate translated tuple details, aside from documented ALG behavior. The decisive goal is to understand that ordinary export reports actual flow details rather than general translated tuple details; actual flow details without a separate translated tuple supplies that behavior.
2. A both-direction SPAN source mirrors ingress and egress traffic and is useful when the analysis needs both sides. The evidence calls for a way to understand that ordinary export reports actual flow details rather than general translated tuple details; SPAN both direction does not supply it. The symptom remains until the actual flow details without a separate translated tuple behavior is present.
3. Flexible NetFlow on the cited Catalyst platform normally exports the actual flow details rather than a separate translated NAT tuple for ordinary traffic. This case is about interpreting that documented behavior, so expecting a general translated tuple is the wrong model. The collector should be evaluated against the actual flow fields the device exports.
4. NetFlow v9 is template-based flow export, but it is not interchangeable with a collector explicitly requiring IPFIX. Understand that ordinary export reports actual flow details rather than general translated tuple details is the controlling need; NetFlow version 9 export operates elsewhere in the workflow. The scenario’s missing function is actual flow details without a separate translated tuple, so this is insufficient.

 

Question 4

An outbound ACL drops a class of traffic, and no egress Flexible NetFlow records appear for those denied packets. What explains the observation? Choose ONE.

1. increase the active timeout
2. create another flow record
3. egress ACL permits the packet to reach the FNF learn path
4. collector dashboard

Correct Answer(s)

 

C

Rationale

1. Changing an active timeout affects export timing for long-lived flows; it does not make an ACL-denied packet reach the FNF learning path. Packets denied before the fnf learn path cannot create egress flow records is the controlling need; increase the active timeout operates elsewhere in the workflow. The actual control point is egress ACL permits the packet to reach the FNF learn path, which this choice bypasses.
2. A record defines key and nonkey fields, but merely creating another record does not cause an existing monitor to export its cache. Mismatch for create another flow record: the design must packets denied before the FNF learn path cannot create egress flow records. This can coexist with egress ACL permits the packet to reach the FNF learn path, but it cannot substitute for it.
3. On egress, a packet denied before the FNF learn or mirror path does not create a flow record, so policy order matters. The decisive goal is to packets denied before the FNF learn path cannot create egress flow records; egress ACL permits the packet to reach the FNF learn path supplies that behavior.
4. The collector dashboard can prove receipt and parsing, but it cannot by itself establish whether the source device learned flows. The evidence calls for a way to packets denied before the FNF learn path cannot create egress flow records; collector dashboard does not supply it. That would leave the egress ACL permits the packet to reach the FNF learn path dependency unresolved in this design.

 

Question 5

Several monitors use identical cache size and inactive-timeout settings on ports handled by the same forwarding slice. Which statement best reflects Catalyst Flexible NetFlow resource behavior? Choose ONE.

1. second same-type input monitor
2. SPAN source VLAN
3. shared NetFlow profile parameters
4. duplicate unrelated exporters

Correct Answer(s)

 

C

Rationale

1. A second monitor of the same traffic type in the same interface direction conflicts with the platform restriction rather than extending coverage. The evidence calls for a way to understand that identical monitor parameters can map to a shared NetFlow profile; second same-type input monitor does not supply it. The needed result comes from shared NetFlow profile parameters, not from this mechanism.
2. A VLAN source mirrors traffic associated with the selected VLAN, which is useful when endpoints can move among several access ports. The required outcome is to understand that identical monitor parameters can map to a shared NetFlow profile; SPAN source VLAN addresses another function. This option targets another layer while shared NetFlow profile parameters controls the outcome.
3. Monitors with the same cache-size and timeout parameters can share the same underlying NetFlow profile on ports in the same ASIC/slice context. shared NetFlow profile parameters is appropriate here because operations must understand that identical monitor parameters can map to a shared NetFlow profile.
4. Adding exporters changes destinations for exported records; it does not solve a same-traffic-type monitor attachment restriction. Mismatch for duplicate unrelated exporters: the design must understand that identical monitor parameters can map to a shared NetFlow profile. shared NetFlow profile parameters directly governs the condition that this choice cannot satisfy.

 

Question 6

A flow monitor is building local cache entries, and an exporter object points to the correct collector, but no export datagrams leave the device. The exporter exists but is not referenced by the monitor. What should be corrected? Choose ONE.

1. associate the exporter with the monitor
2. input flow monitor attachment
3. create another flow record
4. show flow monitor cache

Correct Answer(s)

 

A

Rationale

1. A defined exporter must be referenced by the flow monitor if the learned cache entries are expected to be exported remotely. associate the exporter with the monitor fits because the design must ensure the active monitor references the exporter that sends its records remotely.
2. Applying a monitor in the input direction classifies traffic as it enters the selected interface. Here the task is to ensure the active monitor references the exporter that sends its records remotely, not to use input flow monitor attachment for its normal role. The evidence instead points to associate the exporter with the monitor at this control point.
3. A record defines key and nonkey fields, but merely creating another record does not cause an existing monitor to export its cache. The evidence calls for a way to ensure the active monitor references the exporter that sends its records remotely; create another flow record does not supply it. This cannot replace the associate the exporter with the monitor function required here.
4. The monitor cache display confirms whether the device is actually learning and retaining flow entries locally. The required outcome is to ensure the active monitor references the exporter that sends its records remotely; show flow monitor cache addresses another function. The scenario still depends on associate the exporter with the monitor for the requested result.

 

Question 7

A monitored EtherChannel loses one member. Shortly afterward the collector briefly sees extra flow entries while traffic moves to remaining links, but forwarding remains healthy. What is the best interpretation? Choose ONE.

1. delete the port-channel
2. member-port flow monitor attachment
3. translated NAT tuple as a general FNF field
4. wait for the inactive timeout after a port-channel member failure

Correct Answer(s)

 

D

Rationale

1. Removing the logical bundle would disrupt forwarding and is not the normal response to temporary NetFlow cache duplication after member movement. The required outcome is to recognize stale entries can coexist briefly after member movement until inactive aging completes; delete the port-channel addresses another function. That leaves wait for the inactive timeout after a port-channel member failure as the mechanism that must be addressed.
2. Attaching FNF directly to an EtherChannel member is not the supported method on the cited Catalyst IOS XE platform. Recognize stale entries can coexist briefly after member movement until inactive aging completes is the controlling need; member-port flow monitor attachment operates elsewhere in the workflow. The relevant dependency is wait for the inactive timeout after a port-channel member failure, so this change misses it.
3. Expecting a general translated tuple from FNF is incorrect on the cited platform; NAT translation data is not exported that way for ordinary flows. Mismatch for translated NAT tuple as a general FNF field: the design must recognize stale entries can coexist briefly after member movement until inactive aging completes. The case is governed by wait for the inactive timeout after a port-channel member failure, not this adjacent feature.
4. When a monitored port-channel loses a member, flows can temporarily appear duplicated as traffic moves while old inactive entries age out. The decisive goal is to recognize stale entries can coexist briefly after member movement until inactive aging completes; wait for the inactive timeout after a port-channel member failure supplies that behavior.

 

Question 8

A team wants a second IPv4 input monitor on the same interface solely to add different counters. Which action stays within the platform restriction while preserving one traffic-type monitor per direction? Choose ONE.

1. duplicate unrelated exporters
2. modify the existing same-type monitor
3. member-port flow monitor attachment
4. second same-type input monitor

Correct Answer(s)

 

B

Rationale

1. Adding exporters changes destinations for exported records; it does not solve a same-traffic-type monitor attachment restriction. Here the task is to modify or redesign the existing monitor rather than attach a second monitor of the same traffic type, not to use duplicate unrelated exporters for its normal role. modify the existing same-type monitor is still necessary to satisfy the stated constraint.
2. Reworking the existing monitor lets one same-traffic-type monitor carry the needed record and cache behavior for that interface direction. For this case, modify or redesign the existing monitor rather than attach a second monitor of the same traffic type is the constraint that modify the existing same-type monitor satisfies.
3. Attaching FNF directly to an EtherChannel member is not the supported method on the cited Catalyst IOS XE platform. The required outcome is to modify or redesign the existing monitor rather than attach a second monitor of the same traffic type; member-port flow monitor attachment addresses another function. This option does not perform the modify the existing same-type monitor role required here.
4. A second monitor of the same traffic type in the same interface direction conflicts with the platform restriction rather than extending coverage. Modify or redesign the existing monitor rather than attach a second monitor of the same traffic type is the controlling need; second same-type input monitor operates elsewhere in the workflow. The scenario’s missing function is modify the existing same-type monitor, so this is insufficient.

 

Question 9

A local SPAN session currently mirrors both ingress and egress. The packet analyzer must now show only responses leaving the monitored server port. What source direction should be configured? Choose ONE.

1. SPAN transmit (tx) direction
2. RSPAN remote-span VLAN
3. SPAN receive (rx) direction
4. SPAN both direction

Correct Answer(s)

 

A

Rationale

1. A tx SPAN source copies frames transmitted from the monitored source and excludes ingress-only traffic. SPAN transmit (tx) direction is appropriate here because operations must capture only frames transmitted from the monitored source interface.
2. RSPAN carries mirrored frames between switches over a specially designated remote-span VLAN in the Layer 2 domain. Mismatch for RSPAN remote-span VLAN: the design must capture only frames transmitted from the monitored source interface. This can coexist with SPAN transmit (tx) direction, but it cannot substitute for it.
3. An rx SPAN source copies frames received on the monitored source and excludes egress-only traffic. Here the task is to capture only frames transmitted from the monitored source interface, not to use SPAN receive (rx) direction for its normal role. The requirement maps to SPAN transmit (tx) direction; this option serves another purpose.
4. A both-direction SPAN source mirrors ingress and egress traffic and is useful when the analysis needs both sides. The evidence calls for a way to capture only frames transmitted from the monitored source interface; SPAN both direction does not supply it. That would leave the SPAN transmit (tx) direction dependency unresolved in this design.

 

Question 10

A workstation under investigation moves from Gi1/0/5 to Gi1/0/17 while remaining in VLAN 44. The capture must follow its VLAN traffic without changing the source port each time. What should the session use? Choose ONE.

1. SPAN source physical port
2. SPAN destination interface
3. ERSPAN source session
4. SPAN source VLAN

Correct Answer(s)

 

D

Rationale

1. A physical-port source follows one interface; it is useful for a fixed link but misses traffic after an endpoint moves elsewhere. The evidence calls for a way to mirror the VLAN rather than a single physical attachment point; SPAN source physical port does not supply it. The needed result comes from SPAN source VLAN, not from this mechanism.
2. The SPAN destination is the analyzer-facing port to which the switch sends replicated packets from the configured source. The required outcome is to mirror the VLAN rather than a single physical attachment point; SPAN destination interface addresses another function. This option targets another layer while SPAN source VLAN controls the outcome.
3. An ERSPAN source encapsulates mirrored traffic for transport to a remote ERSPAN destination across routed IP connectivity. Mirror the vlan rather than a single physical attachment point is the controlling need; ERSPAN source session operates elsewhere in the workflow. The scenario calls for SPAN source VLAN; changing this feature would not help.
4. A VLAN source mirrors traffic associated with the selected VLAN, which is useful when endpoints can move among several access ports. SPAN source VLAN fits because the design must mirror the VLAN rather than a single physical attachment point.

 

Question 11

An RSPAN source and destination session are configured on separate switches, but the transport VLAN was created as an ordinary VLAN. What missing configuration should be fixed? Choose ONE.

1. make the ERSPAN IDs identical
2. SPAN receive (rx) direction
3. mark the VLAN as remote-span
4. enable IP routing on the analyzer

Correct Answer(s)

 

C

Rationale

1. The ERSPAN identifier must match between the source and destination session so the receiver associates encapsulated traffic with the intended session. Mismatch for make the ERSPAN IDs identical: the design must designate the transport VLAN for RSPAN rather than leaving it as an ordinary client VLAN. mark the VLAN as remote-span remains the required control for this case.
2. An rx SPAN source copies frames received on the monitored source and excludes egress-only traffic. Here the task is to designate the transport VLAN for RSPAN rather than leaving it as an ordinary client VLAN, not to use SPAN receive (rx) direction for its normal role. The evidence instead points to mark the VLAN as remote-span at this control point.
3. The VLAN that transports RSPAN copies must be designated as a remote-span VLAN so switches treat it as the RSPAN transport. For this case, designate the transport VLAN for RSPAN rather than leaving it as an ordinary client VLAN is the constraint that mark the VLAN as remote-span satisfies.
4. An analyzer host does not fix a missing RSPAN remote-span VLAN designation in the switched transport path. The required outcome is to designate the transport VLAN for RSPAN rather than leaving it as an ordinary client VLAN; enable IP routing on the analyzer addresses another function. The scenario still depends on mark the VLAN as remote-span for the requested result.

 

Question 12

The source and analyzer are separated by a routed WAN, and extending an RSPAN VLAN is not permitted. Which technology should replace RSPAN? Choose ONE.

1. SPAN source physical port
2. ERSPAN instead of RSPAN
3. extend the RSPAN VLAN through routers
4. single local SPAN session

Correct Answer(s)

 

B

Rationale

1. A physical-port source follows one interface; it is useful for a fixed link but misses traffic after an endpoint moves elsewhere. The required outcome is to use IP-routed encapsulation when no end-to-end Layer 2 RSPAN transport exists; SPAN source physical port addresses another function. That leaves ERSPAN instead of RSPAN as the mechanism that must be addressed.
2. ERSPAN encapsulates mirrored traffic for routed IP transport, so it is appropriate when the path between source and analyzer crosses Layer 3 boundaries. ERSPAN instead of RSPAN is appropriate here because operations must use IP-routed encapsulation when no end-to-end Layer 2 RSPAN transport exists.
3. RSPAN depends on Layer 2 carriage of the remote-span VLAN; routers do not transparently extend that VLAN as the mirror transport. Mismatch for extend the RSPAN VLAN through routers: the design must use IP-routed encapsulation when no end-to-end Layer 2 RSPAN transport exists. The case is governed by ERSPAN instead of RSPAN, not this adjacent feature.
4. Local SPAN copies traffic to a destination on the same switch and does not create the remote transport needed across switches. Here the task is to use IP-routed encapsulation when no end-to-end Layer 2 RSPAN transport exists, not to use single local SPAN session for its normal role. This would not supply the ERSPAN instead of RSPAN behavior the design needs.

 

Question 13

An ERSPAN configuration uses Loopback10 as the origin IP. A ping to the destination succeeds from another interface, but ERSPAN packets never arrive. What is the most relevant reachability test? Choose ONE.

1. test only from an unrelated management interface
2. verify routed reachability from the configured ERSPAN origin IP
3. matching RSPAN VLAN only
4. show flow monitor cache

Correct Answer(s)

 

B

Rationale

1. A successful ping sourced from a different interface can hide a routing or VRF problem affecting the configured ERSPAN origin address. Here the task is to validate routing using the exact source address configured for ERSPAN encapsulation, not to use test only from an unrelated management interface for its normal role. verify routed reachability from the configured ERSPAN origin IP is still necessary to satisfy the stated constraint.
2. Testing the destination from the exact origin address validates the routed path the ERSPAN GRE traffic is expected to use. For this case, validate routing using the exact source address configured for ERSPAN encapsulation is the constraint that verify routed reachability from the configured ERSPAN origin IP satisfies.
3. An RSPAN VLAN can transport Layer 2 mirrored traffic, but it does not establish the routed GRE-based path used by ERSPAN. The required outcome is to validate routing using the exact source address configured for ERSPAN encapsulation; matching RSPAN VLAN only addresses another function. This option does not perform the verify routed reachability from the configured ERSPAN origin IP role required here.
4. The monitor cache display confirms whether the device is actually learning and retaining flow entries locally. Validate routing using the exact source address configured for erspan encapsulation is the controlling need; show flow monitor cache operates elsewhere in the workflow. The scenario’s missing function is verify routed reachability from the configured ERSPAN origin IP, so this is insufficient.

 

Question 14

The ERSPAN source uses ID 37 while the destination session expects ID 52. IP reachability between origin and destination is good. What should be corrected? Choose ONE.

1. make the ERSPAN IDs identical
2. mark the VLAN as remote-span
3. SPAN transmit (tx) direction
4. use different ERSPAN IDs to avoid collision

Correct Answer(s)

 

A

Rationale

1. The ERSPAN identifier must match between the source and destination session so the receiver associates encapsulated traffic with the intended session. make the ERSPAN IDs identical is appropriate here because operations must match the ERSPAN ID on both endpoints so the receiver associates the incoming stream correctly.
2. The VLAN that transports RSPAN copies must be designated as a remote-span VLAN so switches treat it as the RSPAN transport. Mismatch for mark the VLAN as remote-span: the design must match the ERSPAN ID on both endpoints so the receiver associates the incoming stream correctly. This can coexist with make the ERSPAN IDs identical, but it cannot substitute for it.
3. A tx SPAN source copies frames transmitted from the monitored source and excludes ingress-only traffic. Here the task is to match the ERSPAN ID on both endpoints so the receiver associates the incoming stream correctly, not to use SPAN transmit (tx) direction for its normal role. The requirement maps to make the ERSPAN IDs identical; this option serves another purpose.
4. Different identifiers on the two ends prevent the destination from matching the arriving ERSPAN stream to the intended session. The evidence calls for a way to match the ERSPAN ID on both endpoints so the receiver associates the incoming stream correctly; use different ERSPAN IDs to avoid collision does not supply it. That would leave the make the ERSPAN IDs identical dependency unresolved in this design.

 

Question 15

A SPAN session is configured but the analyzer is silent. Before examining platform registers, which operational check should confirm the session type, source, destination, and direction? Choose ONE.

1. IP SLA schedule
2. show ip route
3. show flow monitor cache
4. show monitor session all

Correct Answer(s)

 

D

Rationale

1. The schedule activates an already-defined IP SLA operation and controls when and how long it runs. The evidence calls for a way to validate the software session state and configured mirror endpoints before hardware-level investigation; IP SLA schedule does not supply it. The needed result comes from show monitor session all, not from this mechanism.
2. The routing table is important for ERSPAN reachability, but it does not verify the SPAN session source, destination, or direction itself. The required outcome is to validate the software session state and configured mirror endpoints before hardware-level investigation; show ip route addresses another function. This option targets another layer while show monitor session all controls the outcome.
3. The monitor cache display confirms whether the device is actually learning and retaining flow entries locally. Validate the software session state and configured mirror endpoints before hardware-level investigation is the controlling need; show flow monitor cache operates elsewhere in the workflow. The scenario calls for show monitor session all; changing this feature would not help.
4. This command exposes the configured SPAN session type, source, destination, direction, and operational status before deeper hardware troubleshooting. show monitor session all fits because the design must validate the software session state and configured mirror endpoints before hardware-level investigation.

 

Question 16

A technician plugs a normal user into the configured SPAN destination and expects that port to behave like a regular access uplink. Why is that expectation wrong? Choose ONE.

1. configure the analyzer port as a normal access uplink
2. SPAN source interface
3. SPAN destination normally has ingress forwarding disabled
4. RSPAN remote-span VLAN

Correct Answer(s)

 

C

Rationale

1. Treating the analyzer-facing SPAN destination as an ordinary production uplink conflicts with its monitoring role and can create misleading expectations. Mismatch for configure the analyzer port as a normal access uplink: the design must recognize a SPAN destination is dedicated to receiving replicated traffic rather than ordinary endpoint forwarding. SPAN destination normally has ingress forwarding disabled remains the required control for this case.
2. A SPAN source interface identifies the production port whose traffic is copied; it is not the analyzer egress port. Here the task is to recognize a SPAN destination is dedicated to receiving replicated traffic rather than ordinary endpoint forwarding, not to use SPAN source interface for its normal role. The evidence instead points to SPAN destination normally has ingress forwarding disabled at this control point.
3. A SPAN destination is primarily an analyzer-facing replication port; normal ingress forwarding is disabled by default in the verified configuration. For this case, recognize a SPAN destination is dedicated to receiving replicated traffic rather than ordinary endpoint forwarding is the constraint that SPAN destination normally has ingress forwarding disabled satisfies.
4. RSPAN carries mirrored frames between switches over a specially designated remote-span VLAN in the Layer 2 domain. The required outcome is to recognize a SPAN destination is dedicated to receiving replicated traffic rather than ordinary endpoint forwarding; RSPAN remote-span VLAN addresses another function. The scenario still depends on SPAN destination normally has ingress forwarding disabled for the requested result.

 

Question 17

An IP SLA operation appears in the running configuration, but `show ip sla statistics` never accumulates results and no start time was configured. What should the engineer add? Choose ONE.

1. schedule the existing IP SLA operation
2. object tracking tied to IP SLA
3. active timeout
4. recreate the operation under a new number

Correct Answer(s)

 

A

Rationale

1. An IP SLA probe that is defined but not scheduled will not generate measurements; scheduling starts the operation. The scenario needs to activate the existing IP SLA operation instead of replacing a valid probe definition, which is exactly where schedule the existing IP SLA operation applies.
2. A track object can consume IP SLA reachability state so routing or gateway behavior changes when the measured path fails. Activate the existing ip sla operation instead of replacing a valid probe definition is the controlling need; object tracking tied to IP SLA operates elsewhere in the workflow. The relevant dependency is schedule the existing IP SLA operation, so this change misses it.
3. The active timeout expires and exports long-lived flows periodically even while packets continue to arrive. Mismatch for active timeout: the design must activate the existing IP SLA operation instead of replacing a valid probe definition. The case is governed by schedule the existing IP SLA operation, not this adjacent feature.
4. Changing the operation identifier is unnecessary when the existing probe definition is valid but simply has not been scheduled. Here the task is to activate the existing IP SLA operation instead of replacing a valid probe definition, not to use recreate the operation under a new number for its normal role. This would not supply the schedule the existing IP SLA operation behavior the design needs.

 

Question 18

The team needs voice-like active measurements with accurate jitter and loss between two Cisco devices. Which destination-side feature best supports the UDP jitter test? Choose ONE.

1. show monitor session all
2. rely only on ordinary ICMP replies
3. IP SLA ICMP echo only
4. configure an IP SLA responder for UDP jitter

Correct Answer(s)

 

D

Rationale

1. This command exposes the configured SPAN session type, source, destination, direction, and operational status before deeper hardware troubleshooting. Here the task is to use the IP SLA responder for timed UDP probe processing rather than ordinary ping behavior, not to use show monitor session all for its normal role. configure an IP SLA responder for UDP jitter is still necessary to satisfy the stated constraint.
2. ICMP reachability can prove the target responds, but it does not provide the UDP jitter measurement behavior required for voice-like path analysis. The evidence calls for a way to use the IP SLA responder for timed UDP probe processing rather than ordinary ping behavior; rely only on ordinary ICMP replies does not supply it. The symptom remains until the configure an IP SLA responder for UDP jitter behavior is present.
3. ICMP echo can show Layer 3 reachability even when the required TCP listener is unavailable, so it cannot prove service-port availability. The required outcome is to use the IP SLA responder for timed UDP probe processing rather than ordinary ping behavior; IP SLA ICMP echo only addresses another function. This option does not perform the configure an IP SLA responder for UDP jitter role required here.
4. A Cisco IP SLA responder at the far end supports accurate UDP jitter measurements and timestamp handling for the synthetic test flow. configure an IP SLA responder for UDP jitter is appropriate here because operations must use the IP SLA responder for timed UDP probe processing rather than ordinary ping behavior.

 

Question 19

A server responds to ping, but users cannot open TCP port 443. The router should actively test the service listener itself. Which IP SLA operation is most appropriate? Choose ONE.

1. IP SLA ICMP echo only
2. IP SLA TCP connect
3. IP SLA DNS operation
4. IP SLA UDP jitter

Correct Answer(s)

 

B

Rationale

1. ICMP echo can show Layer 3 reachability even when the required TCP listener is unavailable, so it cannot prove service-port availability. Verify tcp connection establishment to the required service rather than only host reachability is the controlling need; IP SLA ICMP echo only operates elsewhere in the workflow. The actual control point is IP SLA TCP connect, which this choice bypasses.
2. A TCP connect operation tests whether a specific TCP service can complete a connection, making it more application-specific than an ICMP ping. IP SLA TCP connect fits because the design must verify TCP connection establishment to the required service rather than only host reachability.
3. A DNS IP SLA operation actively measures name-resolution behavior against the configured DNS service rather than merely testing host reachability. Here the task is to verify TCP connection establishment to the required service rather than only host reachability, not to use IP SLA DNS operation for its normal role. The requirement maps to IP SLA TCP connect; this option serves another purpose.
4. A UDP jitter operation generates timed UDP probes to measure delay variation, loss, and latency characteristics relevant to real-time traffic. The evidence calls for a way to verify TCP connection establishment to the required service rather than only host reachability; IP SLA UDP jitter does not supply it. That would leave the IP SLA TCP connect dependency unresolved in this design.

 

Question 20

Clients can reach the DNS server IP address but intermittently fail to resolve names. The network team wants an active synthetic check of the DNS transaction. Which IP SLA operation fits? Choose ONE.

1. IP SLA ICMP echo only
2. IP SLA TCP connect
3. IP SLA DNS operation
4. IP SLA UDP echo

Correct Answer(s)

 

C

Rationale

1. ICMP echo can show Layer 3 reachability even when the required TCP listener is unavailable, so it cannot prove service-port availability. The evidence calls for a way to exercise name resolution itself rather than merely proving IP or generic transport reachability; IP SLA ICMP echo only does not supply it. The needed result comes from IP SLA DNS operation, not from this mechanism.
2. A TCP connect operation tests whether a specific TCP service can complete a connection, making it more application-specific than an ICMP ping. The required outcome is to exercise name resolution itself rather than merely proving IP or generic transport reachability; IP SLA TCP connect addresses another function. This option targets another layer while IP SLA DNS operation controls the outcome.
3. A DNS IP SLA operation actively measures name-resolution behavior against the configured DNS service rather than merely testing host reachability. IP SLA DNS operation is appropriate here because operations must exercise name resolution itself rather than merely proving IP or generic transport reachability.
4. UDP echo tests a UDP endpoint response, but it does not exercise the DNS query/response transaction required to validate resolution service. Mismatch for IP SLA UDP echo: the design must exercise name resolution itself rather than merely proving IP or generic transport reachability. IP SLA DNS operation directly governs the condition that this choice cannot satisfy.

• < Cisco CCNP 350-401 ENCOR Flexible NetFlow, SPAN/RSPAN/ERSPAN, and IP SLA Practice Test 1
• Cisco CCNP 350-401 ENCOR Catalyst Center Workflows, NETCONF, and RESTCONF Practice Test 1 >