15 Nov
2006
15 Nov
'06
5:08 p.m.
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@merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of nealr > Sent: Wednesday, November 15, 2006 17:58 > To: nanog@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@merit.edu [mailto:owner-nanog@merit.edu] > On Behalf > >> Of J. Oquendo > >> Sent: Wednesday, November 15, 2006 16:20 > >> To: Kuechel, Mark > >> Cc: nanog@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.