<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 8 août 2017 à 11:49, Moacir Ferreira <<a href="mailto:moacirferreira@hotmail.com" class="">moacirferreira@hotmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div id="divtagdefaultwrapper" dir="ltr" style="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=""><div style="margin-top: 0px; margin-bottom: 0px;" class="">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=""></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=""></body></html>