2:23 p.m.
--Apple-Mail=_7EF4733A-7CCD-4EDB-83B5-111DEFD694DB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
Le 8 ao=FBt 2017 =E0 11:49, Moacir Ferreira =
<moacirferreira(a)hotmail.com> a =E9crit :
=20
This is by far more complex. A good NIC will have an offload engine =
(LSO - Large
Segment Offload) and, if so, the NIC driver will report a =
MTU of 64K to the IP stack. The IP stack will then send data to the NIC =
as if the MTU were 64K and the NIC will fragment it to the size of the =
"declared" MTU on the interface so PMTUD will not be efficient in such =
scenario. If all this takes place in the server, then you get no =
problem. But if a standard router is configured to support 9K jumbo =
frame in one interface (i.e.: LAN connection) and 1500 in another (i.e.: =
WAN connection) then the router will be responsible for the =
fragmentation.
That's happen only if the bit don't fragment is not set, otherwise =
router are not allowed to do that and send back a "packet to big" ICMP, =
it's called path mtu discovery. To my knowledge, it's usually set, and =
even mandatory on IPv6.
--Apple-Mail=_7EF4733A-7CCD-4EDB-83B5-111DEFD694DB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=iso-8859-1
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html =
charset=3Diso-8859-1"></head><body style=3D"word-wrap: break-word;
=
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote
type=3D"cite" class=3D""><div =
class=3D"">Le 8 ao=FBt 2017 =E0 11:49, Moacir Ferreira <<a =
href=3D"mailto:moacirferreira@hotmail.com" =
class=3D"">moacirferreira(a)hotmail.com</a>&gt; a =E9crit
:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div
=
id=3D"divtagdefaultwrapper" dir=3D"ltr" style=3D"font-style:
normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; font-size: 12pt; font-family: Calibri, =
Helvetica, sans-serif;" class=3D""><div style=3D"margin-top:
0px; =
margin-bottom: 0px;" class=3D"">This is by far more complex. A good NIC
=
will have an offload engine (LSO - Large Segment Offload) and, if so, =
the NIC driver will report a MTU of 64K to the IP stack. The IP stack =
will then send data to the NIC as if the MTU were 64K and the NIC will =
fragment it to the size of the "declared" MTU on the interface so PMTUD =
will not be efficient in such scenario. If all this takes place in the =
server, then you get no problem. But if a standard router is configured =
to support 9K jumbo frame in one interface (i.e.: LAN connection) and =
1500 in another (i.e.: WAN connection) then the router will be =
responsible for the
fragmentation.</div></div></div></blockquote><br =
class=3D""></div><div>That's happen only if the bit don't
fragment is =
not set, otherwise router are not allowed to do that and send back a =
"packet to big" ICMP, it's called path mtu discovery. To my knowledge, =
it's usually set, and even mandatory on IPv6.</div><br =
class=3D""></body></html>=
--Apple-Mail=_7EF4733A-7CCD-4EDB-83B5-111DEFD694DB--