Re: [LARTC] Random ping jumps

["R. Steve McKown" <rsmckown@yahoo.com>]

On Thursday 08 January 2004 01:01 pm, Artūras Šlajus wrote:
> Map is at http://h2o.pieva.net/net.png

Ah, nice.

> > I'm also unclear about the pings that you've tried.  After you've shown
> > the network map, perhaps you can identify the two machines (and
> > interfaces) involved in each of the different ping tests you've
> > performed.
>
> The machine is totaly random.

What happens if you ping from the linux box to the linux box's default 
gateway?  If the problem doesn't exhibit in this test nor in any test between 
machines in your LAN, the problem is probably your providers: the DSL modem 
or something 'downstream' from it.  You should consider doing tests #2 and #3 
anyway as support for your position when you call your ISP to open a trouble 
ticket.

If the latency problem does exhibit pinging from the linux box to the default 
gateway, you haven't learned much yet.  Continue testing by removing 
variables, attempting to isolate the smallest 'configuration' that exhibits 
the problem.  The variables are: computers, hubs/switches, cables, and the 
like.  Here's some suggestions for testing:

1. plug the linux router directly into the DSL modem and ping from the router 
to the default gateway.  If the problem goes away, it's something in the 
hardware and cables that were 'bypassed' in this test.  You can continue this 
strategy to test into your network.  Read my security note below.

2. plug a PC, configured as the linux router's eth0:1 interface (with proper 
default gateway) and ping from the pc to the default gateway.  If the problem 
goes away, its probably the linux router (hardware or software).

3. If #1 and #2 don't cause it to go away, be sure you used a different cable 
in tests #1 and #2.  If the problem still doesn't go away, it's an issue for 
your network provider.

* security note *

Running both your LAN and the internet provider subnets on the same ethernet 
network puts you at a much greater security risk.  You should seriously 
consider installing a third network interface into your linux box and moving 
eth0:1's ip info to eth2.  Then plug the DSL modem into eth2 with a 
cross-over cable with no computers attached.

I'm guessing your thirty users using Windows.  If they have windows network 
enabled, they are all generating broadcast traffic.  That traffic will most 
likely be crossing the DSL modem (since it is bridging).  Aside from security 
implications, the local traffic that does get bridged is tying up your DSL 
bandwidth.  It seems unlikely that 30 PC's could saturate your 128kbps 
uplink, but I'm no expert on windows networking.  128kbps is not a huge pipe, 
so perhaps it's possible.  If so, the solution to your security problem is 
also the solution to the latency variability issue.  If this is the case, 
both tests #2 and #3 will not show the variability, since your local LAN is 
effectively removed from the test.

Hope this helps,
Steve

> x11@rasnet:~$ traceroute fortas.ktu.lt
> traceroute to fortas.ktu.lt (193.219.160.131), 30 hops max, 38 byte packets
>    1  adsl-213-190-40-129.takas.lt (213.190.40.129)  26.269 ms  23.333 ms 
> 25.156 ms 2  fe22-acc0-tai.kns.telecom.lt (212.59.7.233)  63.079 ms  33.146
> ms  26.117 ms 3  telecom-gw.is.lt (193.219.13.99)  35.978 ms  26.476 ms 
> 103.138 ms 4  litnet-gw.is.lt (193.219.13.98)  22.715 ms  24.531 ms 
> 209.984 ms 5  cat6506-p2-1.kttc.litnet.lt (193.219.62.125)  52.826 ms 
> 98.040 ms  81.609 ms 6  ktu-lan.litnet.lt (193.219.61.252)  38.696 ms 
> 182.582 ms  241.836 ms 7  fortas.ktu.lt (193.219.160.131)  215.523 ms 
> 126.815 ms  29.217 ms
>
> x11@rasnet:~$ traceroute cs.mes.lt
> traceroute to cs.mes.lt (193.219.67.253), 30 hops max, 38 byte packets
>    1  adsl-213-190-40-129.takas.lt (213.190.40.129)  748.174 ms  66.331 ms 
> 135.586 ms 2  fe22-acc0-tai.kns.telecom.lt (212.59.7.233)  21.645 ms 
> 21.588 ms  24.597 ms 3  telecom-gw.is.lt (193.219.13.99)  30.584 ms  31.065
> ms  29.612 ms 4  litnet-gw.is.lt (193.219.13.98)  24.602 ms  143.212 ms 
> 143.096 ms 5  cat6506-p2-1.kttc.litnet.lt (193.219.62.125)  292.196 ms 
> 163.870 ms  84.549 ms 6  ktu-lan.litnet.lt (193.219.61.252)  84.982 ms 
> 54.801 ms  69.143 ms 7  diz.ktu.lt (193.219.67.253)  33.831 ms  29.877 ms 
> 30.005 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=5 ttlY
> time4.8 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=6 ttlY
> time2.6 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=7 ttlY
> time3.1 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=8 ttlY
> time24 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=9 ttlY
> timeƒ6 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq\x10 ttlY
> time…0 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq\x11 ttlY
> time21 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq\x12 ttlY
> time\x147 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq\x13 ttlY
> time\x115 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq\x14 ttlY
> time\x118 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq\x15 ttlY
> time\x107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq\x16 ttlY
> time\x107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq\x17 ttlY
> time'2 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq\x18 ttlY
> time12 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq\x19 ttlY
> time\x102 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq  ttlY
> time\x107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq! ttlY
> time\x114 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq" ttlY
> time‰.8 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq# ttlY
> time‘.2 ms
>
> x11@rasnet:~$ traceroute cs.bbd.lt
> traceroute to cs.bbd.lt (193.219.184.7), 30 hops max, 38 byte packets
>    1  adsl-213-190-40-129.takas.lt (213.190.40.129)  23.803 ms  24.813 ms 
> 56.163 ms 2  fe22-acc0-tai.kns.telecom.lt (212.59.7.233)  171.425 ms 
> 21.174 ms  24.321 ms 3  telecom-gw.is.lt (193.219.13.99)  27.882 ms  30.782
> ms  26.219 ms 4  litnet-gw.is.lt (193.219.13.98)  22.842 ms  23.025 ms 
> 24.079 ms 5  cat6506-p2-1.kttc.litnet.lt (193.219.62.125)  24.201 ms 
> 25.130 ms  27.256 ms 6  ktu-lan.litnet.lt (193.219.61.252)  26.811 ms 
> 27.362 ms  27.785 ms 7  193.219.184.7 (193.219.184.7)  27.928 ms  29.185 ms
>  28.067 ms x11@rasnet:~$ ping cs.bbd.lt
> PING cs.bbd.lt (193.219.184.7) 56(84) bytes of data.
> 64 bytes from 193.219.184.7: icmp_seq=1 ttl\x123 time\x133 ms
> 64 bytes from 193.219.184.7: icmp_seq=2 ttl\x123 time\x122 ms
> 64 bytes from 193.219.184.7: icmp_seq=3 ttl\x123 time\x118 ms
> 64 bytes from 193.219.184.7: icmp_seq=4 ttl\x123 time\x109 ms
> 64 bytes from 193.219.184.7: icmp_seq=5 ttl\x123 timer5 ms
> 64 bytes from 193.219.184.7: icmp_seq=6 ttl\x123 timef8 ms
> 64 bytes from 193.219.184.7: icmp_seq=7 ttl\x123 time\x120 ms
> 64 bytes from 193.219.184.7: icmp_seq=8 ttl\x123 time\x102 ms
> 64 bytes from 193.219.184.7: icmp_seq=9 ttl\x123 time‘.5 ms
> 64 bytes from 193.219.184.7: icmp_seq\x10 ttl\x123 time‘.7 ms
>
> > I had a similar problem recently.  Interestingly, it
> > turned out to be bad hardware.
>
> Another person told me that bad hw could be reason. But it works for
> LAN perfectly.
>
>   >  Moved the boot media to an identically
> >
> > configured machine and the problem went away.  Returned the boot media to
> > the original machine and the problem returned.
>
> Sad, but i can't do that :(
>
> My /etc/network/interfaces:
> auto eth0
> iface eth0 inet static
>           address 192.168.0.1
>           netmask 255.255.255.0
>
> autho eth0:1
> iface eth0:1 inet static
>           address 81.7.84.36
>           netmask 255.0.0.0
>           gateway 81.7.84.1
>           mtu 1492
>
> I hadn't set mtu before. After setting it ping times decreased. (afterall
> it's dsl). Also, what exatcly net/ipv4/tcp_low_latency = 1 in sysctl do?

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/