Sweet--talking about a great source of information in networking! :-)
Laura, please allow me to respond inline:
> If you can capture on both sides of the firewall with two time synced
WS
> systems then you can merge the trace files and note the delay at the
> firewall.
[Small, James] That sounds like a great idea but I'm a little unclear on
how to do it. So, if I have two XP computers synced to the same ntp
server (with the built-in SNTP Windows client) and start the captures at
close to the same time, would I then be able to use mergecap to
successfully merge them in order?
If so, I believe that's something I can do remotely and perhaps take
another stab at this problem.
> 10% is really high - now it may be that there is packet loss somewhere
> upstream (closer to the HTTP server) and it's not your firewall's
fault at
[Small, James] The problem definitely exists without the firewall.
However, I'm not letting myself off the hook as the firewall measurably
exacerbates the issue.
One off the wall idea - the site had two T1's (3.0 Mbps) multiplexed via
PPP before. The problems seem to start close to around when they added
a third T1 (again via PPP) for a total of approx 4.5Mbps. Is there any
chance that this could cause issues - seems to be a pretty standard
provider setup...
> all. When we a high number of lost packets (which, during the file
> download
> will cause duplicate ACKs from the client and retransmissions from the
> server) we'll run ping potter or ping path to identify where packet
loss
> may
> be occurring - you're kind of comparing apples to oranges, however and
may
> find your itty bitty pings go flying through while larger packets are
> dropped. We have noted a router upstream from us that is dropping
packets
> through this process, however.
>
> Do you only find the packet loss when the firewall is in place? Have
you
> tried jacking in outside the firewall to perform the same download?
What
> latency times are you seeing? If your duplicate ACK count gets really
high
> (not just up to DUPE ACK #2 or so), then you may look into latency
issues
> as
> well.
[Small, James] There is packet loss/issues with or without the firewall
- the firewall just seems to exacerbate it for some reason.
When I connect directly to the router (outside of the firewall) I get
measurably better performance but I still have somewhat erratic
performance and have never been able to get the advertised bandwidth on
the connection - even at night with 0 traffic.
I did setup PRTG to do pings every 10 seconds (32 bytes) to the ISPs
edge router and the first hop router in Chicago (believe at the Chicago
NAP).
The ISP edge router (12 hops from site) varies between 10-100+ ms for
latency. I notice that when the performance becomes erratic, the ping
latency times spike.
The Chicago router (15 hops from site) varies between 15-130+ ms with
occasional drops.
One more thing I didn't mention - the problems are mainly between 7-3
when they have their peak load. However, they are usually not getting
to more then 70% of their theoretical bandwidth capacity so I'm not sure
that it's necessarily a bandwidth problem. When you look at an SNMP
graph of their bandwidth usage, it doesn't seem like the are maxing out
much and when they do it's very short lived.
Ping plotter looks very slick - I just set it up. It appears to give
much more detail than other ping/tracert programs I've used. I'll be
interested to see what it shows me next week.
Any other thoughts?
Thanks,
--Jim