nanog mailing list archives

RE: Network Connectivity... Dealing with Providers


From: "Ray Burkholder" <ray () oneunified net>
Date: Wed, 15 Nov 2006 17:05:18 -0400


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.


Current thread: