Cisco SLA data access via SNMP?

Ray Burkholder ray at oneunified.net
Wed Nov 15 22:08:42 UTC 2006


 I've been using Cricket along with GenDevConfig_2_0 from
http://www.acktomic.com/cricket/cricket-genRtrConfig.htm to collect and plot
cisco SAL status.  I have had to make some changes to their scripts to
accept some of Cisco's recent changes.  I can get the changes posted in the
next day or two.

> -----Original Message-----
> From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On 
> Behalf Of nealr
> Sent: Wednesday, November 15, 2006 17:58
> To: nanog at merit.edu
> Subject: Cisco SLA data access via SNMP?
> 
> 
> 
>  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.
> >>
> >>
> >>     
> >
> >
> >   
> 
> 
> --
> Scanned for viruses and dangerous content at 
> http://www.oneunified.net and is believed to be clean.
> 
> 


-- 
Scanned for viruses and dangerous content at 
http://www.oneunified.net and is believed to be clean.




More information about the NANOG mailing list