Le 8 ao=FBt 2017 =E0 11:49, Moacir Ferreira = <moacirferreira@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 =
--Apple-Mail=_7EF4733A-7CCD-4EDB-83B5-111DEFD694DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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@hotmail.com</a>> 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--