1

I've been asked to look into a packet loss problem a previous consultant identified at a client. They have two ADSLMax connections, one for data and the other dedicated to VoIP. The packet loss is causing problems for VoIP calls, but my first effort has been to run WinMTR over the data connection to give me a frame of reference before I test the VoIP line.

I've found the results interesting, though I am unsure how to interpret them. In both cases, 10.5.4.1 is a linux gateway, 10.5.4.254 is the ADSL router and 212.74.102.14 is the gateway at the ISP end. My first run produced:

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                                10.5.4.1 -   10 | 1215 | 1094 | -24901298 | 2353567 | 24901342 | 24901342 |
|                              10.5.4.254 -    0 | 2149 | 2149 | -24901307 | 222826 | 24899947 |    0 |
|                           212.74.102.14 -    0 | 2138 | 2138 | -24901309 | 1904058 | 24901369 |   30 |
|________________________________________________|______|______|______|______|______|______|

For my second run, I cut out the linux gateway by changing the gateway address to 10.5.4.254 (the data router):

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                              10.5.4.254 -    0 |  955 |  955 | -24896677 | 3722073 | 24896756 |    0 |
|                           212.74.102.14 -    0 |  821 |  821 | -24896534 | 2222737 | 24896284 | -297383 |
|________________________________________________|______|______|______|______|______|______|

I asked the consultant for his interpretation of the tests and he said:

The linux box just doesn't actually route internet traffic, it is the default route to make routing across VPNs easier but it does an ICMP redirect to the actual router for most traffic.

ICMP is not always representative of packet loss except for end-to-end where the both ends are under your control. Intermediate routers often throttle ICMP echo responses.

In essence he believes the packet loss is occurring on the ADSL line after it leaves our router, but his response to my question "What testing have you done to measure packet loss - is it just in the Asterisk logs or did you use a tool to measure it?" was:

I don't remember - it was several years ago.

My question is whether that is a helpful interpretation of the data or whether I have identified a potential issue that could be solved by fixing the gateway at our end.

Please note I am not trying to denigrate or cast aspersions on the consultant or his skills - much of the work he has done for this client has been unpaid (it is a charity). I'm just hoping to get an expert second opinion :-)

1 Answer 1

3

Basically, he is right on the properties of dropped ICMP packets, although it would be rather untypical to see dropouts on a local Linux machine - especially in the range of 10%. You should use another Linux host and run a ping -f 10.5.4.1 to check if there might be a local connectivity problem. If you see losses within the same magnitude, do an iperf run against this machine to see if it would affect other protocols (namely TCP and UDP) as well.

The WinMTR statistics indicate that the connection is fine - echo requests to 212.74.102.14 had 100% replies. If the VoIP data is passing the VPN through 10.5.4.1 and this very host has local connectivity problems for whatever reason, this would be the likely cause for your VoIP dropouts.

0

You must log in to answer this question.