packet loss question

Thu Jul 7 20:14:57 UTC 2016

> On Jul 7, 2016, at 3:17 PM, Phillip Lynn <phillip.lynn at netwolves.com> wrote:
> 
> Hi all,
> 
>  I am writing because I do not understand what is happening.  I ran mtr against our email server and www.teco.comand below are the results.  I am not a network engineer so I am at a loss.  I think what I am seeing is maybe a hand off issue, between Frontier and Level3Miami2. If I am correct then what can I do?
> 
>  My system is running Centos 6.5 Linux.
> 
> Thanks,
> 
> Phillip
> 
> 
> 
> (! 1011)-> sudo mtr -r netwolves.securence.com
> HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>  1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10    3.2 2.0 1.0   4.3   1.2
>  3. 172.99.44.214                 0.0%    10    4.0 4.9 2.3   6.9   1.5
>  4. ae8---0.scr02.mias.fl.fronti  0.0%    10    9.3 9.1 7.5   9.8   1.0
>  5. ae1---0.cbr01.mias.fl.fronti  0.0%    10    8.9   9.1   7.6 9.7 0.7
>  6. lag-101.ear3.Miami2.Level3.n 80.0%    10    9.0   8.9   8.8 9.0 0.1
>  7. 10ge9-14.core1.mia1.he.net    0.0%    10   14.3 13.0 7.6  18.1   4.3
>  8. 10ge1-1.core1.atl1.he.net     0.0%    10   25.6  33.2 22.4  99.7  23.6
>  9. 10ge10-4.core1.chi1.he.net    0.0%    10   45.6  51.8 45.5  82.7  12.5
> 10. 100ge14-2.core1.msp1.he.net   0.0%    10   53.6  63.9 53.6 125.2  21.8
> 11. t4-2-usi-cr02-mpls-usinterne  0.0%    10   53.2  73.1 53.2 225.6  54.0
> 12. v102.usi-cr04-mtka.usinterne  0.0%    10   53.2  53.9 53.2  55.3   0.6
> 13. netwolves.securence.com       0.0%    10   53.4  53.9 53.4  55.4   0.7
> 
> (! 1014)-> sudo mtr -r www.teco.com
> HOST: xxxxx at netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>  1. 172.24.109.1                  0.0%    10    0.6 0.6 0.6   0.7   0.0
>  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%    10  104.8 81.4 1.1 113.2  43.2
>  3. 172.99.47.198                 0.0%    10  115.0 77.8 2.9 115.0  40.2
>  4. ae7---0.scr01.mias.fl.fronti  0.0%    10  111.1 80.2 8.5 113.5  41.3
>  5. ae0---0.cbr01.mias.fl.fronti  0.0%    10  105.9  82.2   7.6 115.4 33.8
>  6. lag-101.ear3.Miami2.Level3.n 70.0%    10  116.1  80.2   8.5 116.1 62.0
>  7. NTT-level3-80G.Miami.Level3.  0.0%    10  110.0 81.5 9.0 120.3  41.9
>  8. ae-3.r20.miamfl02.us.bb.gin.  0.0%    10  119.8  84.0 10.0 119.8  38.5
>  9. ae-4.r23.asbnva02.us.bb.gin. 10.0%    10  137.4 107.6 30.1 142.7  45.7
> 10. ae-2.r05.asbnva02.us.bb.gin.  0.0%    10  135.0 109.9 36.6 140.0  39.1
> 11. xe-0-9-0-8.r05.asbnva02.us.c  0.0%    10  147.5 125.6 49.4 165.5  41.1
> 12. 24.52.112.21                  0.0%    10  158.6 124.0 49.6 161.3  41.5
> 13. 24.52.112.42                  0.0%    10  151.0 127.7 52.2 159.0  41.2
> 14. ???                          100.0    10    0.0 0.0 0.0   0.0   0.0
> 
> --
> Phillip Lynn
> Software Engineer III
> NetWolves
> Phone:813-579-3214
> Fax:813-882-0209
> Email: phillip.lynn at netwolves.com
> www.netwolves.com
> 
Phillip,

The data for netwolves.securence.com shows 0% loss between HOST and netwolves.securence.com. This is most certainly good. The 80% Loss in line 4 simply indicates that that particular router was too busy to respond in a timely manner to an ECHO request because it was busy forwarding data traffic. There is no problem to solve for this connection.

The data for www.teco.com <http://www.teco.com/> has a couple of busy hops. However, for as far as the trace succeeds (24.52.112.42) there is no effective loss end to end.  The ??? response, similar to *** from traceroute, indicates that there is probably no route to the destination from that point. (Or there is a firewall blocking SNMP ECHO requests at that point.) Diagnosis may require contacting the operator of www.teco.com <http://www.teco.com/> to confirm the system is actually on line and operational. Contact information for tech.com is in whois.

Auxiliary information - traceroute data from a system in plymouth.mi.michigan.comcast.net <http://plymouth.mi.michigan.comcast.net/> shows similar results for both targets.

Are there other hosts difficult to reach?

James R. Cutler
James.cutler at consultant.com
PGP keys at http://pgp.mit.edu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160707/42235e8f/attachment.sig>