A hospital campus runs UDP jitter IP SLA tests from a core router toward clinic gateways. For accurate two-way measurements that need a far-end participant, which role relationship is required?
Select an answer to reveal the explanation.
Short Explanation
Jitter tests that need a real conversation partner use a source that sends the probes and a responder that answers on the far end—like a catcher for the pitcher’s test throws.
Full Explanation
The hospital campus runs UDP jitter IP SLA tests from a core router toward clinic gateways. For accurate two-way measurements that need a far-end participant, the required role relationship is an IP SLA source initiating the operation and an IP SLA responder enabled on the far-end device. The source generates timed UDP probes; the responder participates so one-way or round-trip delay/jitter components can be measured meaningfully rather than guessing far-end behavior from a silent host.
Only a NetFlow exporter on the clinic with no IP SLA components fails by concept—NetFlow exports flow records and does not fulfill the responder role for UDP jitter. A SPAN destination port on the source router that reflects probes to itself does not create a far-end measurement participant. A RESTCONF client that disables CEF before each jitter sample invents a harmful, unrelated step; CEF disablement is not part of IP SLA jitter methodology.
Exam caveat: know which IP SLA operations need a responder (commonly UDP jitter and some advanced tests) versus simpler ICMP echo that may not. Responder enablement is a deliberate far-end configuration, not automatic because NetFlow or SPAN exists.
Operational check across the hospital campus: enable the IP SLA responder on clinic gateways, start UDP jitter from the core source, verify both devices show the operation active, and compare measured jitter against clinical voice/video expectations before trusting the results for WAN changes.