Cisco SLA data access via SNMP?

Wed Nov 15 21:57:36 UTC 2006

 Ray,

   Do you have an example of accessing the SLA data via SNMP? I've just 
got interested in those things, I've found the OIDs required, but its 
all a bit of a maze ... I could really use some jitter information in a 
couple of places right about now ...

                                                Neal

Ray Burkholder wrote:
> If you have Cisco routers on either end, use the built in SLA capability.
> It will give you ongoing abilty to trace latency, loss, jitter.  It won't
> tell you bandwidth, but will give you a set of metrics for traffic quality.
> Do a full mesh between all your edge devices and it might help track where
> in the middle your issues reside.  The SLA tools are pretty standard to
> Cisco devices and so should give you an edge in getting people to listen to
> you.
>
>   
>> -----Original Message-----
>> From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On 
>> Behalf Of J. Oquendo
>> Sent: Wednesday, November 15, 2006 16:20
>> To: Kuechel, Mark
>> Cc: nanog at merit.edu
>> Subject: Re: Network Connectivity... Dealing with Providers
>>
>>
>> Kuechel, Mark wrote:
>>     
>>> Sounds like you are trouble shooting a VoIP issue several networks 
>>> removed from the actual user. First step is to get into 
>>>       
>> their network 
>>     
>>> via telnet and start from there. Is this a jitter issue on 
>>>       
>> some or all 
>>     
>>> calls? Has the customer done a traffic study on their own 
>>>       
>> LAN to see 
>>     
>>> if there is not some sort of congestion there? Pings from 
>>>       
>> afar are not 
>>     
>>> used to trouble shoot issues in depth: Lots of posting on this. Has 
>>> the clients Bandwidth utilization been looked at to their provider? 
>>> Give us more.
>>>
>>>       
>> Pings and traceroutes weren't the only tests I've done. Here 
>> is my capacity when dealing with this client:
>>
>> When something happens and I need to do some VoIP related 
>> stuff (extension changes, etc), I mainly log in via SSH from 
>> one of four points, a DSL connection CTTEL, Level3, GBLX, and 
>> Verio. When my lab's CTTel DSL connection fails I jump on a 
>> DS3 (GBLX), when that fails, I jump on to a machine in Texas 
>> and most of the times one of them is going to let me in. Now, 
>> I have had failures from two points to all points at sporadic 
>> times. So I do the obvious traceroutes, pings, etc.. Now a 
>> provider can be quick to tell me "check your line" but come 
>> on now... 4 different lines are failing to connect here. 
>> (This doesn't include the fact that if I can't get in... What 
>> makes you think voice data is getting in?)
>>
>> So, for my testing, I'm doing a functional (its fugly) test 
>> from all four locations to my client, and from my client to 
>> all four. My data is going to be a collection of ping tests, 
>> traceroute test (tcptraceroute), bing test, etc.... I was 
>> hoping to get feedback on other tools... I have Radarping as 
>> well but don't feel like using it. I want to be able to leave 
>> something running 24x7 until Friday. I'd like for it to be 
>> opensource so the provider doesn't cry "your network voodoo 
>> tools don't count!". I want to be able to go back and say 
>> "Listen these tools are industry standard tools from CAIDA 
>> (or elsewhere), and they're used by engineers all across the 
>> board. I've done a fair test and its obviously coming from 
>> your network.."
>>
>> So to answer your bandwidth question, bandwidth (according to 
>> the provider) is under 50% capacity with "sporadic spikes" as 
>> their engineers have seen while on the phone with them. 
>> Sporadic means nothing to me. I have a 63% packet loss which 
>> means even if I was equipped with an OC768, the bandwidth 
>> means nothing if the packets aren't going through. "Here's 
>> your Lamborghini Murcielago Sir. It does 200mph. Although 
>> from time to time you'll only do 126mph..." Traffic 
>> internally, I've put on QoS maps, but with or without them 
>> same errors occur. It's not an issue of echoes, its more of 
>> calls to specific DID's dropping, not going through, caller 
>> can hear - receiver can't. All the while some lines work, 
>> others don't. Couple this with my Nagios test going bonkers - 
>> I configured Nagios to monitor from my client to Google, 
>> Yahoo, MSN and I can see loss from here to the outside world 
>> so it's twofold. Short of my client running me over with his 
>> FX45, I'm even running out of patience with my client's provider.
>>
>>
>> --
>> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>> J. Oquendo
>> echo @infiltrated|sed 's/^/sil/g;s/$/.net/g'
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743
>>
>> "How a man plays the game shows something of his character - 
>> how he loses shows all" - Mr. Luckey 
>>
>> --
>> Scanned for viruses and dangerous content at 
>> http://www.oneunified.net and is believed to be clean.
>>
>>
>>     
>
>
>   