Bill Shanks wrote:
> That '1470' number you reference sounds very familiar.  We had a similar
> problem with large packet sizes several years ago and, no matter what we
> tried, packets larger than that size did not get passed across the network
> from the 3000.  We knowingly took the questionable approach of sending data
> a byte at a time, and the problem was solved.  I know it will increase
> traffic, and there is probably a better way, but no one has come up with
> anything better.

To transfer data from point A to point B, the effective MTU is the
smallest MTU of anything in the path.  When a packet longer than the
next link's MTU is detected, the intermediate device (e.g., a router)
will fragment the packet as mandated by the next link -- UNLESS the "do
not fragment" bit is set in the header.  If this is the case, the device
will send an ICMP Unreachable - "Packet too Big, DF requested", or in
more unix-ish terms ICMP_UNREACH_NEEDFRAG (ICMP type 3, code 4).  This
is intended to instruct the sender that the MTU is too large for this
path.  The interaction of the DF bit (Don't Fragment) and the ICMP 3/4
reply is collectively called Path MTU Discovery (PMTUD).

The first and most obvious problem is a "strict" firewall that blocks
ICMP altogether (can't even ping), or blocks ICMP unreachables
regardless of type (more common - as other types allow network discovery
and port mapping - depending on unreachable network, host, port,
administratively prohibited, etc).  If anything "eats" the ICMP 3/4
before it reaches the host, you're talking into a black hole, which
sounds like your example.

What you *expect* to be MTU and what the MTU *really* is can be
complicated by things along the way, such as 802.1q tagging, IPSec
tunnelling, or GRE encapsulation of a VPN tunnel.  All add overhead
bytes to the original packet.

If you have an overly-paranoid network admin between point A and B that
is snuffing the ICMP_UNREACH_NEEDFRAG, your only choice is to manually
back off your MTU until the link succeeds.  On the other hand, if YOU
are blocking inbound ICMP, you just shot yourself in the foot :-)

Jeff

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *