This blog post shows how you can configure your Orion IP SLA Manager module to verify whether or not your Communication / Internet Service Providers (CSP/ISP) delivers what they “promised” to you.

 

If you have a formal Service Level Agreement with them, it’s likely their commitment to you is about availability of the connectivity, but also packet latency and packet loss across the site to site connection (typical commitment from CSPs), and throughput (typical commitment from ISPs) of their access.

 

Well, if you don’t have a formal agreement (SLA), I think the info below is still a very good best practice and can be used as a solid basis for informal discussions with your CSP about their quality of service, also whether you should think about buying faster throughput from them… It can also provide great data to help you improve the design of your network in general and your WAN in particular, regardless of any I/CSP relationship you may have or not.

 

So, whatever your situation and objective is, let’s look in details at these 3 metrics.

 

Committed Throughput

 

Cisco’s IP SLA does not natively give information on the throughput experienced by the operations, as they perform their packet generation tasks (therefore Solarwind’s IP SLA Manager module does not either).

 

But there is an easy way to work this around (manually) and get this precious information about the throughput that your SP connection effectively delivers.

 

In order to achieve this, just create an IP SLA “FTP” Operation that will periodically perform an FTP GET between any FTP server and an IP SLA-capable router. Orion IP SLA manager will give you a chart similar to this one, showing the time it took to perform the file transfer. Great but this is not the Throughput information you are looking for.

 

image

 

All you have to do to get the Throughput, is apply this simple formula manually:

 

Throughput = File Size (Bytes) x 8 / Transfer time (Sec)

 

Let’s do the math on this actual example. The spike in the middle of the chart shows that for 1 hour, the transfer time of this 337KBytes file was around 4000 ms (with a spike up to 10,000 ms).

 

Throughput = 337,000 x 8 / 4 = 674,000 bps = 674Kbps… for a connection sold as a 1Mbps…

 

For 1 hour, I did not get my share! And look at 8am when the business day starts…

 

If this happened too frequently, I would certainly pick-up the phone and call my I/CSP…Especially if I hear my users complaining about slow response time at the same time…

 

Of course, you don’t want to blame your I/CSP too rapidly and you should make sure that you select a Router which is as close as possible to the connection to your SP. And chose an FTP server which is as fast and consistent as possible (hopefully dedicated to this task), to eliminate any component that would be responsible for this and not be under your I/CSP’s responsibility.

 

To achieve this, you can either deploy an FTP server dedicated to this, or ask your SP whether they can provide one in their domain, or pick one like I did (Cisco page) and hit it from several locations:

 
      
  • If all locations experience the same spike simultaneously, the problem is likely in the FTP server. Ignore this.
  •    
  • If only one location experiences the spike, the problem is likely in your SP’s access.
 

Here is how, in a few snapshots, you can create this FTP operation with IP SLA Manager:

 
      
  • IP SLA Manager / IP SLA Manager Settings / Add New Operation / Create New Operation / Check FTP operation type:
 

image

 
      
  • Select the Cisco IP SLA–capable router that will perform periodically the FTP GET
  •    
  • Specify the target of the FTP GET operation that will be performed periodically
 

image

 
      
  • Select a frequency for this FTP GET. Don’t be to aggressive. I personally use for the frequency, at least 5 x the time it typically takes to perform the transfer, so you don’t create an operation that is constantly transferring files and actually kills your WAN. Unless this is what you are trying to do. If it is, we have something much better for you: The Wan Killer tool from the Engineer’s Toolset! But this is a separate discussion…
  •    
  • Tons of good things here:     
    - Thresholds that will allow you to create alerts when the transfer time reflects a throughput which is lower than what your I/CSP commits to. This is real time SLA verification!      
    - Also the VRF tagging asks for this transfer to be done in a particular VPN tunnel.      
    - And the TOS tagging will classify your FTP transfer in the proper Class of Service, that you are buying from your SP. In this case, create a separate operation for each Class of Service (ToS) and see if there is a real difference between this Best Effort and this Mission Critical COS that you are paying premium for…
 

image

 
      
  •     
    Once you have created this FTP operation, wait a few minutes for the first measurements to be done and you will see an FTP operation on your IP SLA Summary view:
      
 

image

 
      
  •     
    Drill down to see the chart showed at the beginning of this section.
      
 

Packet Latency

 

All Orion IP SLA Manager users commonly use their module to monitor Latency on a near real time basis and be alerted about bad latency, but not all use the historical reporting capabilities of Orion to turn this into an SLA verification tool.

 

On this example, you can see that during May, the committed monthly average of 10ms for packet latency is not met.    

image  

To create this view, this is what you have to do:

 
      
  • Use the Report Writer to create the report, starting from an existing IP SLA report, configure the proper fields and tweak the time period (e.g. 3 months). I did not show all tabs below:
 

image

 
      
  •     
    Once the report is created, all you have to do is add it to an IP SLA View by clicking on the “Customize Page” and add a Resource of this type:
      
 

image

 
      
  •     
    Then Submit in order to get there:
      
 

image

 
      
  • And hit Done. You are now back to the View you started from and you can select the report that you have previously created, from this resource (hit Click Here):
 

image

 
      
  •     
    At this point, you should see your 3 months historical report on the View, as showed at the beginning of this section.
      
 

Packet Loss

 

The same historical report can be done with Packet Loss, using the same technique.

 

And what if you are a ISP or a CSP?

 

Then, this blog can help you leverage Orion IP SLA Manager to show your customers that you DO DELIVER!

 

Orion supports account limitation and can be used to push these reports to your end-customers in a safe and secure way, and deliver a simple but effective customer-facing Service Level Reporting portal!