[LARTC] Random ping jumps
R. Steve McKown
rsmckown@yahoo.com
Thu, 8 Jan 2004 19:43:48 -0700
On Thursday 08 January 2004 01:01 pm, Art=C5=ABras =C5=A0lajus 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=20
gateway? If the problem doesn't exhibit in this test nor in any test betwe=
en=20
machines in your LAN, the problem is probably your providers: the DSL modem=
=20
or something 'downstream' from it. You should consider doing tests #2 and =
#3=20
anyway as support for your position when you call your ISP to open a troubl=
e=20
ticket.
If the latency problem does exhibit pinging from the linux box to the defau=
lt=20
gateway, you haven't learned much yet. Continue testing by removing=20
variables, attempting to isolate the smallest 'configuration' that exhibits=
=20
the problem. The variables are: computers, hubs/switches, cables, and the=
=20
like. Here's some suggestions for testing:
1. plug the linux router directly into the DSL modem and ping from the rout=
er=20
to the default gateway. If the problem goes away, it's something in the=20
hardware and cables that were 'bypassed' in this test. You can continue th=
is=20
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 prope=
r=20
default gateway) and ping from the pc to the default gateway. If the probl=
em=20
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 cab=
le=20
in tests #1 and #2. If the problem still doesn't go away, it's an issue fo=
r=20
your network provider.
* security note *
Running both your LAN and the internet provider subnets on the same etherne=
t=20
network puts you at a much greater security risk. You should seriously=20
consider installing a third network interface into your linux box and movin=
g=20
eth0:1's ip info to eth2. Then plug the DSL modem into eth2 with a=20
cross-over cable with no computers attached.
I'm guessing your thirty users using Windows. If they have windows network=
=20
enabled, they are all generating broadcast traffic. That traffic will most=
=20
likely be crossing the DSL modem (since it is bridging). Aside from securi=
ty=20
implications, the local traffic that does get bridged is tying up your DSL=
=20
bandwidth. It seems unlikely that 30 PC's could saturate your 128kbps=20
uplink, but I'm no expert on windows networking. 128kbps is not a huge pip=
e,=20
so perhaps it's possible. If so, the solution to your security problem is=
=20
also the solution to the latency variability issue. If this is the case,=20
both tests #2 and #3 will not show the variability, since your local LAN is=
=20
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 packe=
ts
> 1 adsl-213-190-40-129.takas.lt (213.190.40.129) 26.269 ms 23.333 ms=
=20
> 25.156 ms 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 63.079 ms 33.1=
46
> ms 26.117 ms 3 telecom-gw.is.lt (193.219.13.99) 35.978 ms 26.476 ms=20
> 103.138 ms 4 litnet-gw.is.lt (193.219.13.98) 22.715 ms 24.531 ms=20
> 209.984 ms 5 cat6506-p2-1.kttc.litnet.lt (193.219.62.125) 52.826 ms=20
> 98.040 ms 81.609 ms 6 ktu-lan.litnet.lt (193.219.61.252) 38.696 ms=20
> 182.582 ms 241.836 ms 7 fortas.ktu.lt (193.219.160.131) 215.523 ms=20
> 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 m=
s=20
> 135.586 ms 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 21.645 ms=20
> 21.588 ms 24.597 ms 3 telecom-gw.is.lt (193.219.13.99) 30.584 ms 31.0=
65
> ms 29.612 ms 4 litnet-gw.is.lt (193.219.13.98) 24.602 ms 143.212 ms=20
> 143.096 ms 5 cat6506-p2-1.kttc.litnet.lt (193.219.62.125) 292.196 ms=20
> 163.870 ms 84.549 ms 6 ktu-lan.litnet.lt (193.219.61.252) 84.982 ms=20
> 54.801 ms 69.143 ms 7 diz.ktu.lt (193.219.67.253) 33.831 ms 29.877 ms=
=20
> 30.005 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D5 ttl=3D59
> time=3D34.8 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D6 tt=
l=3D59
> time=3D32.6 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D7 tt=
l=3D59
> time=3D33.1 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D8 tt=
l=3D59
> time=3D324 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D9 ttl=
=3D59
> time=3D836 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D10 tt=
l=3D59
> time=3D850 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D11 tt=
l=3D59
> time=3D321 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D12 tt=
l=3D59
> time=3D147 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D13 tt=
l=3D59
> time=3D115 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D14 tt=
l=3D59
> time=3D118 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D15 tt=
l=3D59
> time=3D107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D16 tt=
l=3D59
> time=3D107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D17 tt=
l=3D59
> time=3D272 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D18 tt=
l=3D59
> time=3D312 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D19 tt=
l=3D59
> time=3D102 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D20 tt=
l=3D59
> time=3D107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D21 tt=
l=3D59
> time=3D114 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D22 tt=
l=3D59
> time=3D89.8 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=3D23 t=
tl=3D59
> time=3D91.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=
=20
> 56.163 ms 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 171.425 ms=20
> 21.174 ms 24.321 ms 3 telecom-gw.is.lt (193.219.13.99) 27.882 ms 30.7=
82
> ms 26.219 ms 4 litnet-gw.is.lt (193.219.13.98) 22.842 ms 23.025 ms=20
> 24.079 ms 5 cat6506-p2-1.kttc.litnet.lt (193.219.62.125) 24.201 ms=20
> 25.130 ms 27.256 ms 6 ktu-lan.litnet.lt (193.219.61.252) 26.811 ms=20
> 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=3D1 ttl=3D123 time=3D133 ms
> 64 bytes from 193.219.184.7: icmp_seq=3D2 ttl=3D123 time=3D122 ms
> 64 bytes from 193.219.184.7: icmp_seq=3D3 ttl=3D123 time=3D118 ms
> 64 bytes from 193.219.184.7: icmp_seq=3D4 ttl=3D123 time=3D109 ms
> 64 bytes from 193.219.184.7: icmp_seq=3D5 ttl=3D123 time=3D725 ms
> 64 bytes from 193.219.184.7: icmp_seq=3D6 ttl=3D123 time=3D668 ms
> 64 bytes from 193.219.184.7: icmp_seq=3D7 ttl=3D123 time=3D120 ms
> 64 bytes from 193.219.184.7: icmp_seq=3D8 ttl=3D123 time=3D102 ms
> 64 bytes from 193.219.184.7: icmp_seq=3D9 ttl=3D123 time=3D91.5 ms
> 64 bytes from 193.219.184.7: icmp_seq=3D10 ttl=3D123 time=3D91.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 =3D 1 in sysctl do?