better MTU support...

[John-Mark Gurney]

Andre Oppermann wrote this message on Thu, Sep 09, 2004 at 19:05 +0200:
> John-Mark Gurney wrote:
> > 
> > In a recent experiment w/ Jumbo frames, I found out that sending ip
> > frames completely ignores the MTU set on host routes.  This makes it
> > difficult (or next to impossible) to support a network that has both
> > regular and jumbo frames on it as you can't restrict some hosts to the
> > smaller frames.
> 
> What you should do instead is to set the MTU on the interface to 9018
> or so and then have a default route with MTU 1500 for everything else.
> Now you can specify larger MTUs for hosts that support it.
> 
> Otherwise you are opening a can of worms...

Actually, this will still be broken, since host routes on the local
segment will be cloned from the link/net route, and ip will still try
to use the if mtu...  which is set to 9018...

TCP works fine, the problem is using UDP in a mixed environment...

> > I now have a patch to ip_output that makes it obay the MTU set on the
> > route instead of that of the interface.
> 
> Your patch corrects a problem in ip_output where a smaller MTU on an
> rtentry was ignored but that is only for the non-TCP cases.  When you
> open a TCP session the MTU will be honored (see tcp_subr.c:tcp_maxmtu).
> If not it would be a bug.

TCP works fine, the problem is with icmp and udp and other types..
duplicating the MTU logic in each would seem excesive...

> Could you try your large MTU setup again using the procedure I desribed
> above?

Turns out that my hub can't do jumbo frames.. so I can't completely
test it beyound the simulation of 1000 being the normal MTU, and 1500
being "jumbo"...

> That should solve your immediate problem.

As I said, I'm pretty sure this would still break other hosts, since
the issue I'm talking about doesn't touch the default route...

> For the general 'bug' in ip_output that it doesn't honour a smaller MTU
> on a route I'd like to do a more throughout fix.  Routes should be
> created with MTU 0 if the MTU is not different from the if_mtu.  Only
> in those cases where you want to have a lower MTU you set it.  For cloned
> routes the MTU would be cloned from the parent.  This range of changes is
> more intrusive.  On top of that comes the new ARP code which will have a
> MTU field as well.  This one is supposed to store different MTUs for mixed
> MTU L2 networks.  How to transport the MTU information is a separate
> discussion.
> 
> If the fix above works for you I'd like to do the real fix later (< end
> of year) and not change the current behaviour in ip_output at the moment.

Sorry, I can't test it.. :( I stupidly assumed that all gige equipment
supported jumbo frames...  it was never a high priority, but as gige
stuff is cheap, this is going to become more of an issue, and wanted
to preemptively fix it..

Esspecially how cool 5.3-R is from a networking perspective.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."