Similar to another thread on the list today, I'm troubleshooting a problem
for a customer on Comcast business fiber.
Downloading a file from one of our web servers is very slow (~15KByte/sec).
mtr looks clean in both directions. I added an IP address on the same
server from a different class C on our network, and downloads form this new
IP are fast (2MByte/sec).
Tracerouting from server to client is the same using both source IPs. But,
one IP consistently has the very slow speeds that the other does not.
Changing our outbound path between different upstreams does not make a
difference.
It certainly feels like Comcast is throttling one of our IP ranges. Could
someone at Comcast please contact me off-list for details?
Thanks,
Mark
Replying off-list as requested.
John
That's possible, but while a traceroute can help shed some light on certain performance problems, this doesn't seem like one where a traceroute will help very much. The slow traceroute hops are more likely due to other factors (ICMP rate limiting / control plane policing / etc), rather than a direct indicator of Comcast shaping / throttling your traffic.
As others have indicated, doing a packet capture of a transfer session that shows the behavior you noted is likely to be a lot more telling than a traceroute.
jms
I recently hit a similar problem, tracked it down to a brain-dead firewall
owner that had configured the gear to change the TCP WSCALE header option to
NOPs. Hilarity ensues when the sender thinks the window is 389 bytes rather
than 389<<10 bytes.
Yes, you *would* think that sort of tomfoolery went out with the last century,
but it's amazing how long people will re-invent bad ideas....