Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

IP SLA Responder Scalability ?


There are many documents explaining how well certain router platforms scale regarding IP SLA measurements depending on the number of IP SLA operation/probes are running. However, I couldn't find any information about the perfomance/CPU penalty a router will face as a IP SLA responder.

We would like to run hundreds of UDP jitter measurement (sourced from individual routers) toward a central  router (= responder). I'm looking for a table where the performance as a responder is given for different models (ISR G1, G2) or at least a rule of thumb.




  • WAN Routing and Switching
Everyone's tags (1)
Super Bronze

DisclaimerThe Author of this


The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.


I don't recall seeing any performance impact of the SLA responder, but it's not as intensive as SLA probe sourcing.

If you have PPS performance for software forwarding, you might be able to relate it somewhat to that for the amount of SLA traffic you intend the responder to handle.

If you looking for best accuracy, ideally you don't want to run the SLA responder on a production device.  If the responder's ingress interface gets busy enough, SLA timings can become inaccurate (due to the delay in the responder time stamping the ingress packet).

This widget could not be displayed.