[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ongoing problems with broken Path-MTU-discovery on servers at cvsho
Greg A. Woods
Re: ongoing problems with broken Path-MTU-discovery on servers at cvshome.org/OpenAvenue.com
Thu, 23 Nov 2000 03:39:10 -0500 (EST)
[ On Wednesday, November 22, 2000 at 16:00:06 (-0500), Derek R. Price wrote: ]
> Subject: Re: ongoing problems with broken Path-MTU-discovery on servers at
> I really have nothing to do with the networks, so I can't do much, but
> I keep forwarding you descriptions of the problem to our internal network
> people. I thought something was being done last week or at least that this
> problem was being investigated but things are such that I am having trouble
> getting work out of the OA folks as well. Last week I was told that they
> had isolated the issue to AboveNet and would be checking with them again
> but apparently nothing has been done. I'll try and follow up and let you
> know if I learn anything else. Sorry for the inconvenience.
Thanks very much for your reply and your efforts Derek!
It's been rather frustrating on this end since even though I can collect
tcpdumps from my upstream router that clearly show things are working
properly on my end, I've haven't heard whether anyone's even been close
to seeing where the problem is at your end, never mind from anyone who
wants to try a live test and compare packet traces.
Meanwhile with at least two claims coming to me from AboveNet folks
stating that they don't ever filter anything I'm still stuck with the
problem and no solution in sight.
Since we know exactly what the problem is it really shouldn't be that
hard to spot since anyone doing the testing need only send large enough
packets (even ICMP echo-request packets will do) from one of the servers
in question (or some immediate LAN peer) to any one of my machines, with
the 'DF' bit set in those packet, and then look for ICMP "needs-frag"
replies coming back in return from my upstream router.
You don't even need to do packet captures if you can do pings like this
from every segment between those servers and your gateway to AboveNet:
$ /sbin/ping -c 1 -D -s 1460 most.weird.com
PING most.weird.com (188.8.131.52): 1460 data bytes
36 bytes from walnut.planix.com (184.108.40.206): frag needed and DF set. Next
MTU=0 for icmp_seq=0
----most.weird.com PING Statistics----
3 packets transmitted, 0 packets received, 100.0% packet loss
(Note that the "Next MTU=0" above is a lie -- I think it's a bug in that
version of ping. My next-hop MTU is 1280, for a GIF tunnel.)
Just to re-iterate: all of my traffic goes through my GIF tunnel except
for some of my web browsing (which goes via my provider's web proxy,
outside of the GIF). I have very vew problems with very few sites and
it almost always turns out to be an over zealous firewall on the remote
side, but sometimes it's a broken networking device such as was alluded
to in an earlier thread about this on info-cvs (eg. a load balancer that
doesn't implement ICMP properly).
Greg A. Woods
+1 416 218-0098 VE3TCP <address@hidden> <robohack!woods>
Planix, Inc. <address@hidden>; Secrets of the Weird <address@hidden>