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 ttl=59 > time=34.8 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=6 ttl=59 > time=32.6 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=7 ttl=59 > time=33.1 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=8 ttl=59 > time=324 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=9 ttl=59 > time=836 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=10 ttl=59 > time=850 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=11 ttl=59 > time=321 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=12 ttl=59 > time=147 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=13 ttl=59 > time=115 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=14 ttl=59 > time=118 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=15 ttl=59 > time=107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=16 ttl=59 > time=107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=17 ttl=59 > time=272 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=18 ttl=59 > time=312 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=19 ttl=59 > time=102 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=20 ttl=59 > time=107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=21 ttl=59 > time=114 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=22 ttl=59 > time=89.8 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=23 ttl=59 > time=91.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=123 time=133 ms > 64 bytes from 193.219.184.7: icmp_seq=2 ttl=123 time=122 ms > 64 bytes from 193.219.184.7: icmp_seq=3 ttl=123 time=118 ms > 64 bytes from 193.219.184.7: icmp_seq=4 ttl=123 time=109 ms > 64 bytes from 193.219.184.7: icmp_seq=5 ttl=123 time=725 ms > 64 bytes from 193.219.184.7: icmp_seq=6 ttl=123 time=668 ms > 64 bytes from 193.219.184.7: icmp_seq=7 ttl=123 time=120 ms > 64 bytes from 193.219.184.7: icmp_seq=8 ttl=123 time=102 ms > 64 bytes from 193.219.184.7: icmp_seq=9 ttl=123 time=91.5 ms > 64 bytes from 193.219.184.7: icmp_seq=10 ttl=123 time=91.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@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
