Michael J McCafferty wrote:
Well, I have seen things like this happen when supposedly "smart"
security devices are placed in line. I had a experience with a large
company that used Cisco IPS sensors. By default the IPS sensors tried
That could be...I have just uncovered some more interesting info. The
packet trace I provided before was of an SSL session and tethereal
apparently doesn't understand ssl sessions very well and emits a lot of
things that make the packet look like an error when it isn't. So I
switched to scp which seems to provide better packet traces.
I scp'd a 10M file from our phone system to 4 different locations and
captured the packet trace. The files are:
# From my personal colo'd box
from-colo-packets.txt
# From my home machine on Cox cablemodem
from-home-packets.txt
# From our New York office where we have VOIP audio quality problems
from-nyfw-packets.txt
# From our San Diego office where VOIP works great
from-csfw-packets.txt
[EMAIL PROTECTED] ~]$ for file in from-*; do echo $file; grep
"Retransmission" $file |wc -l; done
from-colo-packets.txt
1
from-csfw-packets.txt
604
from-home-packets.txt
86
from-nyfw-packets.txt
311
Twice as many packets retransmitted from the San Diego office which is
only two hops away on a private network?! Something really isn't adding
up here!
Ok, so I noticed a lot of duplicate ACK's also so let's see how many
there are:
[EMAIL PROTECTED] ~]$ for file in from-*; do echo $file; grep "Dup ACK" $file
|wc -l; done
from-colo-packets.txt
21
from-csfw-packets.txt
1596
from-home-packets.txt
167
from-nyfw-packets.txt
1169
There were some out of order packets also:
[EMAIL PROTECTED] ~]$ for file in from-*; do echo $file; grep "Out-Of-Order"
$file |wc -l; done
from-colo-packets.txt
17
from-csfw-packets.txt
1
from-home-packets.txt
1
from-nyfw-packets.txt
757
This doesn't really match up with the rest. Lots more out of order
packets on the New York connection. Hmm...
I see "Previous segment lost" also:
[EMAIL PROTECTED] ~]$ for file in from-*; do echo $file; grep "Previous
segment lost" $file |wc -l; done
from-colo-packets.txt
15
from-csfw-packets.txt
43
from-home-packets.txt
79
from-nyfw-packets.txt
958
Lots of TCP window updating going on also:
[EMAIL PROTECTED] ~]$ for file in from-*; do echo $file; grep "Window" $file
|wc -l; done
from-colo-packets.txt
0
from-csfw-packets.txt
194
from-home-packets.txt
2
from-nyfw-packets.txt
474
My colo connection and my cablemodem connection are both on potentially
significantly faster connections than the 3Mb links connecting NY and
CSFW (San Diego office). Doesn't TCP have a way to throttle the sender
so as not to flood out the link causing inefficiency? The NY and CSFW
routers are both identical hardware with as identical software
configurations as I can manage. They both run shorewall and wondershaper
to QoS our voice traffic. I have tried turning wondershaper off just in
case it was somehow messing with things in a bad way (although I have
used it before and had no problems) but did not see any change in behavior.
What does mtr (Matt's Traceroute) show from one host to the other ?
Nothing unusual...no packet loss and a reasonable number of hops.
Especially on the connection from CSFW to our pbx. 6ms ping and no
packet loss. Although if I run mtr while copying a file I do see 3%
packet loss. Hmm...604 packets retransmitted out of 14133 does come out
to be around 4%. I think I really need to start running packet traces on
actual SIP phone calls to see what is going on with the audio. SIP
packets are UDP, much smaller, and sent in 20ms intervals which could be
handled quite differently by the network.
--
Tracy R Reed http://ultraviolet.org
A: Because we read from top to bottom, left to right
Q: Why should I start my reply below the quoted text
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
