Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Stumper

  • From: Steve Gibbard
  • Date: Tue Jan 21 18:24:15 2003

On Tue, 21 Jan 2003, Mark J. Scheller wrote:

> The Linksys does have an MTU setting, and I've had my users try some lower
> settings to see if it made any differences.  One user set the MTU on the
> Linksys as low as 1200 with no noticeable improvement.

If you're using path MTU discovery (in other words, sending out packets
with the DF bit set), it works like this:  The host on each end of the
connection has an MTU configured in its TCP stack, so on initial
connection (generally with very small syn/ack packets), the packet size
gets negotiated and set to the lower of those two numbers.  If all the
router interfaces in between have an MTU equal or greater than the MTU
that gets negotiated between the hosts, packets will continue to flow at
that size without incident.  In general, when you're dealing with two
ethernet connected hosts with MTUs of 1500 bytes, and a bunch of routers
in between with MTUs of greater than 1500, this is what happens.  However,
if there's a network link in the path with an MTU smaller than the MTUs of
the two end devices, the large packets sent by the end devices won't be
able to pass through that link.  Instead, the router with the small MTU
link sends an ICMP response back to the sending host, requesting smaller
packets.  The sending host retries with progressively smaller packets
until arriving at a size that works.

Therefore, I think the scenario that people are describing here is this:
The user's computer is talking to the Linksys across a regular ethernet
with an MTU of 1500.  The host on your network probably also has an MTU of
1500.  The Linksys is talking to the DSL provider via PPPoE, and thus has
an MTU of 1492.  The connection starts out with an initial MTU of 1500 in
each direction, but 1500 byte packets can't pass through the 1492 byte MTU
of the connection between the Linksys and the DSL provider.  Therefore,
the devices on the two ends of that link would be sending back ICMP
messages requesting smaller packets.  If all ICMP were being blocked
somewhere, those ICMP messages wouldn't arrive, and the host that wasn't
receiving them would keep obliviously sending out 1500 byte packets until
the connection timed out.  But, if you were plugging the client computers
directly into the DSL line and running PPPoE on them, you'd have the 1492
byte MTU negotiated from the start and everything would work.  In this
scenario, decreasing the Linksys's MTU wouldn't help you, because the
problem would already be that the MTU on the Linksys was smaller than the
MTU on the end points.  Decreasing the MTU on the end points would help.
What would help even more would be fixing the ICMP filtering.

Now that I've said all that, this scenario doesn't really fit what you're
seeing.  You said your packet sniffer showed no packets coming across, but
TCP connections don't generally start out with 1500 byte packets.  In
general, when you see an path MTU discovery issue, you see the connection
being successfully opened, small packets (containing such small bits of
data as "GET /") flowing freely, and then the connection freezing when a
big burst of data gets sent for the first time.

Since that's not what you're seeing here, I'm more inclined to agree with
those who have suggested upgrading the Linksys's firmware.  I don't have
any experience with that -- The Linksys NAT box on my home network works
fine and I haven't had any reason to mess with it -- but it does seem like
a far more plausible explanation for what you're seeing.

-Steve

--------------------------------------------------------------------------------
Steve Gibbard				scg@gibbard.org	
+1 510 528-1263				http://www.gibbard.org/~scg






Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.