msaqib at gmail.com
Wed Mar 18 06:20:29 CDT 2009
I'm back! Thanks again to all those who replied. I am wondering how a
service provider might assess availability or reliability figures using
active measurements. Granted that one could set up traffic generators
between the two PoPs which will be connected to a customer's sites, and then
after a day of test traffic, I can look for downtimes and restoration times.
But a one day estimate is not a good estimate for what the service provider
is promising, which is usually "maximum of 10 hours downtime in an year", is
Thanks and best regards
On Fri, Mar 13, 2009 at 7:34 PM, Athanasios Douitsis <aduitsis at gmail.com>wrote:
> Anyone interested in setting up his own IP SLA probes by hand and then
> collect the measurements into a database, can use a Perl tool we developed
> at 2005:
> It's rather old (SAA got renamed into IPSLA in the meantime) and, in
> retrospect, the code is a little rough around the edges, but it's
> nevertheless usable.
> On Wed, Mar 11, 2009 at 10:20 PM, Andreas, Rich <
> Rich_Andreas at cable.comcast.com> wrote:
>> I have found that Cisco IPSLA is heavily used in the MSO/Service
>> Provider Space. Juniper has equivalent functionality via RPM.
>> -----Original Message-----
>> From: Saqib Ilyas [mailto:msaqib at gmail.com]
>> Sent: Saturday, March 07, 2009 6:12 AM
>> To: nanog at nanog.org
>> Subject: Re: Network SLA
>> I must thank everyone who has answered my queries. Just a couple more
>> short questions.
>> For instance, if one is using MRTG, and wants to check if we can meet
>> a 1 Mbps end-to-end throughput between a couple of customer sites, I
>> believe you would need to use some traffic generator tools, because
>> MRTG merely imports counters from routers and plots them. Is that
>> We've heard of the BRIX active measurement tool in replies to my
>> earlier email. Also, I've found Cisco IP SLA that also sends traffic
>> into the service provider network and measures performance. How many
>> people really use IP SLA feature?
>> Thanks and best regards
>> On Mon, Feb 23, 2009 at 1:19 PM, Zartash Uzmi <zartash at gmail.com> wrote:
>> > As I gather, there is a mix of answers, ranging from "building the
>> > according to requirements and HOPE for the best" to "use of arguably
>> > sophisticated tools and perhaps sharing the results with the legal
>> > department".
>> > I would be particularly interested in hearing the service providers'
>> > viewpoint on the following situation.
>> > Consider a service provider with MPLS deployed within its own network.
>> > (A) When the SP enters into a relation with the customer, does the SP
>> > establish new MPLS paths based on customer demands (this is perhaps
>> > to "building" based on requirements as pointed out by David)? If yes,
>> > between what sites/POPs? I assume the answer may be different
>> depending upon
>> > a single-site customer or a customer with multiple sites.
>> > (B) For entering into the relationship for providing X units of
>> > (to another site of same customer or to the Tier-1 backbone), does the
>> > use any wisdom (in addition to MRTG and the likes)? If so, what
>> > parameters are kept in mind?
>> > (C) How does the customer figure out that a promise for X units of
>> > is maintained by the SP? I believe customers may install some
>> > tools but is that really the case in practice?
>> > Thanks,
>> > Zartash
>> > On Fri, Feb 20, 2009 at 1:16 AM, Stefan <netfortius at gmail.com> wrote:
>> >> Saqib Ilyas wrote:
>> >>> Greetings
>> >>> I am curious to know about any tools/techniques that a service
>> >>> uses
>> >>> to assess an SLA before signing it. That is to say, how does an
>> >>> administrator know if he/she can meet what he is promising. Is it
>> based on
>> >>> experience? Are there commonly used tools for this?
>> >>> Thanks and best regards
>> >> Not necessarily as a direct answer (I am pretty sure there'll be
>> others on
>> >> this list giving details in the area of specific tools and
>> standards), but I
>> >> think this may be a question (especially considering your end result
>> >> concern: *signing the SLA!) equally applicable to your legal
>> department. In
>> >> the environment we live, nowadays, the SLA could (should?!? ...
>> >> unfortunately) be "refined" and (at the other end - i.e. receiving)
>> >> "interpreted" by the lawyers, with possibly equal effects (mostly
>> >> and as overall impact on the business) as the tools we (the technical
>> >> people) would be using to measure latency, uptime, bandwidth, jitter,
>> >> Stefan
>> Muhammad Saqib Ilyas
>> PhD Student, Computer Science and Engineering
>> Lahore University of Management Sciences
Muhammad Saqib Ilyas
PhD Student, Computer Science and Engineering
Lahore University of Management Sciences
More information about the NANOG