[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ongoing problems with broken Path-MTU-discovery on servers at cvshom

From: Jason Williams
Subject: RE: ongoing problems with broken Path-MTU-discovery on servers at
Date: Mon, 27 Nov 2000 15:53:23 -0800

Hello All,

Thank you for your patience and once again we are sorry for the
inconvenience.  We are still looking into the filtering of ICMP error
messages.  We are going back and forth with as to where the
problem lies.  I will keep you posted as to the status of this problem and
will let you know once we find the defunct hardware or firewall.

Jason Williams
OpenAvenue, Inc.

-----Original Message-----
From: address@hidden [mailto:address@hidden Behalf Of
Greg A. Woods
Sent: Thursday, November 23, 2000 12:39 AM
To: Derek R. Price
Cc: CVS-II Discussion Mailing List
Subject: Re: ongoing problems with broken Path-MTU-discovery on servers

[ 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
> problem was being investigated but things are such that I am having
> 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
PING ( 1460 data bytes
36 bytes from ( frag needed and DF set.
Next MTU=0 for icmp_seq=0 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>

Info-cvs mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]