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 correct? 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 wrote: > As I gather, there is a mix of answers, ranging from "building the resources > 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 similar > 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 bandwidth > (to another site of same customer or to the Tier-1 backbone), does the SP > use any wisdom (in addition to MRTG and the likes)? If so, what scientific > parameters are kept in mind? > > (C) How does the customer figure out that a promise for X units of bandwidth > is maintained by the SP? I believe customers may install some measuring > tools but is that really the case in practice? > > Thanks, > Zartash > > On Fri, Feb 20, 2009 at 1:16 AM, Stefan wrote: > >> Saqib Ilyas wrote: >> >>> Greetings >>> I am curious to know about any tools/techniques that a service provider >>> 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 financial >> and as overall impact on the business) as the tools we (the technical >> people) would be using to measure latency, uptime, bandwidth, jitter, etc... >> >> Stefan >> >> > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences
Re: Network SLA
Saqib, On 07.03.2009, at 12:12, Saqib Ilyas wrote: 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 correct? Yes, if you want to do a test bandwidth, iperf should probably be your first stop. 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? I know a lot of people that use IPSLA. Remember, that you set it up between two routers or higher-end switches and it constantly tests that connection. However, IPSLA is the wrong tool for a one-off test of whether you can push a Mbps from site A to site B, because you need to saturate the link to do that test. IPSLA is great for monitoring things like jitter. HTH, Chris Thanks and best regards On Mon, Feb 23, 2009 at 1:19 PM, Zartash Uzmi wrote: As I gather, there is a mix of answers, ranging from "building the resources 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 similar 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 bandwidth (to another site of same customer or to the Tier-1 backbone), does the SP use any wisdom (in addition to MRTG and the likes)? If so, what scientific parameters are kept in mind? (C) How does the customer figure out that a promise for X units of bandwidth is maintained by the SP? I believe customers may install some measuring tools but is that really the case in practice? Thanks, Zartash On Fri, Feb 20, 2009 at 1:16 AM, Stefan wrote: Saqib Ilyas wrote: Greetings I am curious to know about any tools/techniques that a service provider 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 financial and as overall impact on the business) as the tools we (the technical people) would be using to measure latency, uptime, bandwidth, jitter, etc... Stefan -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences
Re: Network SLA
On Sat, Mar 07, 2009 at 12:26:45PM +0100, Chris Meidinger wrote: > Saqib, > > On 07.03.2009, at 12:12, Saqib Ilyas wrote: > > >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 > >correct? > > Yes, if you want to do a test bandwidth, iperf should probably be your > first stop. Or for more sophisticated matricies of spot-checks, BWCTL (http://www.nanog.org/meetings/nanog43/presentations/Boote_tools_N43.pdf) > >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? > > I know a lot of people that use IPSLA. Remember, that you set it up > between two routers or higher-end switches and it constantly tests > that connection. However, IPSLA is the wrong tool for a one-off test > of whether you can push a Mbps from site A to site B, because you need > to saturate the link to do that test. IPSLA is great for monitoring > things like jitter. While Birx is awesome and a cisco-heavy site certainly should use rtr/ipsla in their mix, don't underestimate the value of a lightweight system built on smokeping (http://oss.oetiker.ch/smokeping/). Choose the right set of tools for your budget and environment. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
level3 out of san francisco
Anyone else having level3 issues out of san Francisco ? -carlos
