Hello,
Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
accept a larger incomming packet.
kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max
1294)
I don't think it worked this way in the past.
Won't this affect pmtud?
man page for ifconfig says mtu l
Sten Daniel Soersdal wrote:
Stephen Clark wrote:
Hello,
Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
accept a larger incomming packet.
kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max
1294)
That is what to be expected.
Incoming interf
Stephen Clark wrote:
Hello,
Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
accept a larger incomming packet.
kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max
1294)
That is what to be expected.
Incoming interface must have mtu set to the same mtu
In response to Stephen Clark <[EMAIL PROTECTED]>:
> Sten Daniel Soersdal wrote:
>
> >Stephen Clark wrote:
> >
> >
> >>Hello,
> >>
> >>Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
> >>accept a larger incomming packet.
> >>
> >>kernel: rl0: discard oversize frame (ether typ
Bill Moran wrote:
In response to Stephen Clark <[EMAIL PROTECTED]>:
Sten Daniel Soersdal wrote:
Stephen Clark wrote:
Hello,
Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
accept a larger incomming packet.
kernel: rl0: discard oversize frame (ether typ
In response to Stephen Clark <[EMAIL PROTECTED]>:
> Bill Moran wrote:
>
> >In response to Stephen Clark <[EMAIL PROTECTED]>:
> >
> >>Sten Daniel Soersdal wrote:
> >>
> >>>Stephen Clark wrote:
> >>>
> Hello,
>
> Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
> >>
Bill Moran wrote:
In response to Stephen Clark <[EMAIL PROTECTED]>:
Bill Moran wrote:
In response to Stephen Clark <[EMAIL PROTECTED]>:
Sten Daniel Soersdal wrote:
Stephen Clark wrote:
Hello,
Did something change in 6.2? If my mtu size on rl0 is 1280
Bill Moran wrote:
ractices are
still evolving.
Let's flip the question around a bit: why would you _want_ the TCP stack
to accept frames larger than the stated MTU?
Because mtu is mTu not mRu.
The interface should theoretically always accept any packet up to
the maximum practical size..
As t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill Moran <[EMAIL PROTECTED]> wrote:
>
> Let's flip the question around a bit: why would you _want_ the TCP
> stack to accept frames larger than the stated MTU?
If I receive a 64K frame and the TCP checksum checks out, and the
sequence numbers match
In response to David DeSimone <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Bill Moran <[EMAIL PROTECTED]> wrote:
> >
> > Let's flip the question around a bit: why would you _want_ the TCP
> > stack to accept frames larger than the stated MTU?
>
> If I receive a 64K
On Jul 13, 2007, at 12:27 PM, Bill Moran wrote:
I agree with others that MTU means "limit what I transmit". It
does not
mean "limit what someone else can transmit to me."
Interesting viewpoint. I disagree with it, but I can't quote any
standard
or otherwise to support my view. You didn'
Chuck Swiger wrote:
On Jul 13, 2007, at 12:27 PM, Bill Moran wrote:
I agree with others that MTU means "limit what I transmit". It
does not
mean "limit what someone else can transmit to me."
Interesting viewpoint. I disagree with it, but I can't quote any
standard
or otherwise
On Jul 13, 2007, at 1:24 PM, Stephen Clark wrote:
Designers of gateways should be prepared for the fact that
successful
gateways will be copied and used in other situation and
installations. Gateways must be prepared to accept datagrams as
large as can be sent in the maximum packe
Stephen Clark wrote:
Chuck Swiger wrote:
On Jul 13, 2007, at 12:27 PM, Bill Moran wrote:
I agree with others that MTU means "limit what I transmit". It
does not
mean "limit what someone else can transmit to me."
Interesting viewpoint. I disagree with it, but I can't quote any
sta
> Bill Moran wrote:
> ractices are
> > still evolving.
> >
> > Let's flip the question around a bit: why would you _want_ the TCP stack
> > to accept frames larger than the stated MTU?
> >
> Because mtu is mTu not mRu.
I must agree. There is no strong requirement that MTU == MRU, although
the
Mike Karels wrote:
I'd be happy to see the change undone as well. I (well, our test
group) found this change in a similar way, and it didn't agree with
our previous usage.
In -CURRENT my changes to the ethernet input path maintain the use of
ETHER_MAX_FRAME() however the check is folded un
> In -CURRENT my changes to the ethernet input path maintain the use of
> ETHER_MAX_FRAME() however the check is folded under #ifdef DIAGNOSTIC. I
> don't recall adding this conditional or touching it so it seems to be
> something which was already thereo radded by someone else.
It has been the
Stephen Clark wrote:
Sten Daniel Soersdal wrote:
Stephen Clark wrote:
Hello,
Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
accept a larger incomming packet.
kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514
> max
1294)
That is what to be exp
Sten Daniel Soersdal wrote:
Stephen Clark wrote:
Sten Daniel Soersdal wrote:
Stephen Clark wrote:
Hello,
Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
accept a larger incomming packet.
kernel: rl0: discard oversize frame (ether type 800 flags 3 len 15
Mike Karels wrote:
In -CURRENT my changes to the ethernet input path maintain the use of
ETHER_MAX_FRAME() however the check is folded under #ifdef DIAGNOSTIC. I
don't recall adding this conditional or touching it so it seems to be
something which was already thereo radded by someone else.
It
On Fri, 13 Jul 2007, Mike Karels wrote:
The ability to receive packets larger than mtu was not accidental. This
should be fixed, if it is, as is suggested, a deliberate change.
I'd be happy to see the change undone as well. I (well, our test group)
found this change in a similar way, and it
> A related change that should probably be discussed if we want to think more
> about asymmetry in maximum transmission unit is this one:
>
>revision 1.98
>date: 2006/06/26 17:54:53; author: andre; state: Exp; lines: +2 -0
>In syncache_respond() do n
Sten Daniel Soersdal wrote this message on Sat, Jul 14, 2007 at 15:41 +0200:
> You are trying to lower the mtu on the wrong end.
> As i said, all hosts on the same L2 needs to share the same mtu.
> The router that forwarded you that packet is obviously not using the
> same mtu (otherwise it would
Stephen Clark wrote:
Sten Daniel Soersdal wrote:
Stephen Clark wrote:
Sten Daniel Soersdal wrote:
Stephen Clark wrote:
Hello,
Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
accept a larger incomming packet.
kernel: rl0: discard oversize frame (ether type
Wes Peters wrote:
On 7/16/07, Sten Daniel Soersdal <[EMAIL PROTECTED]> wrote:
I guess it wouldn't hurt for the operating system to accept larger
frames, as long as only the correctly sized frames are transmitted.
There are alot of people, including myself, that assume a host can't
receive a
On 7/16/07, Sten Daniel Soersdal <[EMAIL PROTECTED]> wrote:
I guess it wouldn't hurt for the operating system to accept larger
frames, as long as only the correctly sized frames are transmitted.
There are alot of people, including myself, that assume a host can't
receive a frame that is larger
Mike Karels wrote:
A related change that should probably be discussed if we want to think more
about asymmetry in maximum transmission unit is this one:
revision 1.98
date: 2006/06/26 17:54:53; author: andre; state: Exp; lines: +2 -0
In syncache
Stephen Clark wrote:
Mike Karels wrote:
A related change that should probably be discussed if we want to
think more about asymmetry in maximum transmission unit is this one:
revision 1.98
date: 2006/06/26 17:54:53; author: andre; state: Exp; lines:
> There are also things to consider such as if a GigE card is connected to
> a GigE device (switch/card etc) and the card supports jumbo frames
> should the MRU be set to the max jumbo receive size for the card? This
> could cause confusion when people plug jumbo capable devices in with
> hardw
Mike Karels wrote:
There are also things to consider such as if a GigE card is connected to
a GigE device (switch/card etc) and the card supports jumbo frames
should the MRU be set to the max jumbo receive size for the card? This
could cause confusion when people plug jumbo capable devices in w
> Mike Karels wrote:
> >> There are also things to consider such as if a GigE card is connected to
> >> a GigE device (switch/card etc) and the card supports jumbo frames
> >> should the MRU be set to the max jumbo receive size for the card? This
> >> could cause confusion when people plug jumbo
Stephen Clark wrote:
So was any decision reached on this issue - will FreeBSD changed to
accept a packet on an
interface that is larger than the mtu on that interface?
If possible, I'd like to see the ability to enforce interface MTU for
received packets preserved in a sysctl if it is re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eli Dart <[EMAIL PROTECTED]> wrote:
>
> If possible, I'd like to see the ability to enforce interface MTU for
> received packets preserved in a sysctl if it is removed for the
> default config...
I'm curious, why do you want this feature?
- --
David
Eli Dart wrote:
Stephen Clark wrote:
So was any decision reached on this issue - will FreeBSD changed to
accept a packet on an
interface that is larger than the mtu on that interface?
If possible, I'd like to see the ability to enforce interface MTU for
received packets preserved in a s
see below...
Julian Elischer wrote:
Eli Dart wrote:
Stephen Clark wrote:
So was any decision reached on this issue - will FreeBSD changed
to accept a packet on an interface that is larger than the mtu on
that interface?
If possible, I'd like to see the ability to enforce interface MTU
f
Eli Dart wrote:
see below...
Julian Elischer wrote:
Eli Dart wrote:
Stephen Clark wrote:
So was any decision reached on this issue - will FreeBSD changed
to accept a packet on an interface that is larger than the mtu on
that interface?
If possible, I'd like to see the ability to enforc
Julian Elischer wrote:
Eli Dart wrote:
see below...
Julian Elischer wrote:
Eli Dart wrote:
Stephen Clark wrote:
So was any decision reached on this issue - will FreeBSD changed
to accept a packet on an interface that is larger than the mtu on
that interface?
If possible, I'd like to s
Here's one example where MTU!=MRU would be useful.
Think of asymmetric bandwith-limited ADSL links. Lower MTU would allow
lower TX latency for high priority packets when upstream is saturated,
yet large MRU on the downstream would be great for downloads.
Right now with 6.2 one has to trade off l
Artem Belevich wrote:
Here's one example where MTU!=MRU would be useful.
Think of asymmetric bandwith-limited ADSL links. Lower MTU would allow
lower TX latency for high priority packets when upstream is saturated,
yet large MRU on the downstream would be great for downloads.
Right now with 6.2
Eli Dart wrote:
The networks that are apparently working fine are most likely
misconfigured, IMHO.
Others have made a case for permitting an interface to accept as large a
packet as it can, regardless of configured MTU. That's fine for theory.
My operational experience leads me to a diffe
Eli Dart wrote:
see below...
Julian Elischer wrote:
Eli Dart wrote:
Stephen Clark wrote:
So was any decision reached on this issue - will FreeBSD changed
to accept a packet on an interface that is larger than the mtu on
that interface?
If possible, I'd like to see t
Artyom Viklenko wrote:
Artem Belevich wrote:
Here's one example where MTU!=MRU would be useful.
Think of asymmetric bandwith-limited ADSL links. Lower MTU would allow
lower TX latency for high priority packets when upstream is saturated,
yet large MRU on the downstream would be great for do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eli Dart <[EMAIL PROTECTED]> wrote:
>
> The networks that are apparently working fine are most likely
> misconfigured, IMHO.
>
> Others have made a case for permitting an interface to accept as large
> a packet as it can, regardless of configured MTU.
> Any two hosts, connected to single Layer2 network MUST use
> same MTU. Any other cases lead to hard-to-solve problems.
I'd have to disagree. In fact, I'd say that any two hosts on the
same L2 network must use the same MRU. In particular, if a host
choses to use a lower MTU, if that also lowers
Stephen Clark wrote:
Artyom Viklenko wrote:
Artem Belevich wrote:
Here's one example where MTU!=MRU would be useful.
Think of asymmetric bandwith-limited ADSL links. Lower MTU would allow
lower TX latency for high priority packets when upstream is saturated,
yet large MRU on the downstream
Mike Karels wrote:
Any two hosts, connected to single Layer2 network MUST use
same MTU. Any other cases lead to hard-to-solve problems.
I'd have to disagree. In fact, I'd say that any two hosts on the
same L2 network must use the same MRU. In particular, if a host
choses to use a lower MTU, i
46 matches
Mail list logo
