On 18/01/12 14:44, Nick Rout wrote:
On Wed, Jan 18, 2012 at 2:37 PM, Derek Smithies
<[email protected]> wrote:
Hi,
I have a linux box in a data centre, somewhere in the US..
This box runs a program which talks voip (lots of udp packets, a few tcp
packets)
with other boxes.
Being performance conscious, things like packet loss are monitored, and
there are packets being dropped.
An identical box, with the same settings for firewall etc, with the same
program, but in a totally different place,
reports no loss.
ok. run
ping -q -A -c 200 4.2.2.2
and the loss rate may be anything from 0 to 8% (on some runs it is perfect,
on others it is bad)
the data centre network operators claim it is not them, and that their
centre is fine. I don't know if the
data centre is running traffic shapers, bandwidth throttling, or what..
iptables -L reports no drop rules.
Conclusion: it is not the firewall settings that is dropping packets.
Don't think it is hardware, but I did remember hearing something about full
& half duplex
However, one can use the command:
mii-tool eth0
eth0: 10 Mbit, full duplex, link ok
(ethtool appears to be the newer tool, but ethtool fails on operations
I found a tool on the network called shaperprobe, that (apparently) works
out if there is any traffic shaping going on.
This tool reports no shaping..
Is it the hardware on the box? I don't think so. - it is a new box. Is it my
software - no - ping reports similar answers.
is the box heavily loaded - no. the load average is 0.00
Question:
is there a software tool to analyse network traffic and work out where the
packets are being lost (tcptrace?) and
say why they are being lost?
There is a tool, which you probably know, called traceroute, does it help?
Hi,
I have used traceroute - you are right - I should have mentioned it in
my letter.
With traceroute, I found the ip address of the closest box.
eth0 Link encap:Ethernet HWaddr 00:30:18:A9:53:26
inet addr:104.82.220.175 Bcast:104.82.220.191
Mask:255.255.255.192
inet6 addr: fe80::230:18ff:ffff:6666/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:832709 errors:0 dropped:0 overruns:0 frame:0
TX packets:1027152 errors:44 dropped:0 overruns:0 carrier:63
collisions:2303 txqueuelen:1000
RX bytes:246227064 (234.8 MiB) TX bytes:752975481 (718.0 MiB)
Interrupt:185 Base address:0x2000
You see that this box has an ip address of 104.82.220.175 (ip addresses
changed for here)
When doing traceroute, the next hop is at 104.82.220.130
ping -c 2000 -q -A 104.82.220.130
gives a loss rate also - so the loss is happening real close to my box.
Somehow - there is a loss mechanism to 164.82.220.130. Thus my question,
what tool is there
to find out what the cause of the loss is? I mean, I could do (and most
guides suggest this)
trial and error:
replace the box, scream for help, replace the cable, replace the
switch at the centre,
use a new data centre etc,
but they are slow to implement. Each option takes a day or so.. tedious.
there was a suggestion to use tools such as mtr, cacti etc, but all
these tools tell me there is a loss.
I know that already - ping told me that. Why the loss - and then I can
do the one change and fix it.
Packet loss is a weird thing - I have just gone back to that box, and it
is now reporting a much lower
packets loss - in the order of 0.05% - which is very acceptable.
Thus the question on analysis - is there a way to look at the loss, even
over a period of time, and
determine where the loss is happening?
Cheers,
Derek.
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
--
Derek J Smithies Ph.D.
Christchurch,
New Zealand
-- "How did you make it work??" "the usual, got everything right"
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
