[c-nsp] IP SLA Scalability

[Ben Steele]

On Thu, Oct 21, 2010 at 4:52 PM, Mikael Abrahamsson <swmike at swm.pp.se>wrote:

> On Thu, 21 Oct 2010, Ben Steele wrote:
>
>  Has anyone ran a rather large amount of SLA probes from a router who can
>> comment on the cpu performance characteristics on how it scaled for your
>> particular platform?
>>
>
> You should really contact your account team to get a comment from them.
> I've spoken to the product manager for IP SLA and I was quite surprised by
> some comments I got regarding the functionality and the thinking/handling of
> it within Cisco.
>
>  Yes good advice and I plan to talk to an SE about it soon, but nothing
quite like hearing people's real world experiences with it, like yourself :)


>
>  Specifically looking to see if its feasible to expect a router to be able
>> to
>> go upwards of 500+ simultaneous monitors(looking at a total of about
>> 10-15k
>> pps of udp-jitter probes in total).
>>
>
> I'd say Cisco doesn't have a product that has been designed to scale this
> far and is supposed to work for prolonged sustained testing like I guess you
> want to do. They consider 300 second of 50pps testing "extremely long" and
> if single high jitter packet in that "long" test occurs, the opinion seems
> to be that fixes for that is on a best-effort work priority. It's not
> something they really test on all platforms and all code.


Not entirely sure what you mean here, the udp-jitter probe has a
computational delay timestamp put into it by the responder to account for
any cpu delays in the processing, however, how well that works in a
generally non pre-emptive environment like IOS with a high number of
monitors is yet to be seen(well, by me anyway.)


>
>
>  Before anyone says that I should look at another vendor/solution, this is
>> already being done in the background. I am purely after what a Cisco router
>> can offer in this regards, i've never come across more than about 20 sla
>> probes on a router before so am interested to hear the results.
>>
>
> If you're doing this in an MPLS VPN scenario, you might want to make sure
> you test your code so it has timestamping for arrival time for packets even
> if they are labeled. I ran into this on a 7301 5 years ago, took 14 months
> for that TAC case to complete with the answer that "timestamping wasn't done
> in labeled packets" and as a result, any cpu spike would cause jitter in the
> measurements. Converting the router to IP only (putting it behind a MPLS PE
> router) "solved" the problem.
>

Not MPLS VPN, but end-to-end LSP tunnel so still label switched either way,
I would have expect the ip sla process to only be exposed to the IP layer
before/after necessary imposition/disposition had occurred.

Appreciate your feedback.

Ben


>
> --
> Mikael Abrahamsson    email: swmike at swm.pp.se
>