personally, I would detect the speed (Macs do that) and set to 1500
for 10/100 and 9K for 1000 (and 10000). It might be of value to try
sending a jumbogram to a neighbor, perhaps in the context of an ARP/
ND request (send a 9K packet containing an ARP request or ND
solicitation and see if you get a response) before doing so.
On Jul 31, 2007, at 8:47 PM, John Heffner wrote:
Fred Baker wrote:
On Jul 28, 2007, at 2:05 AM, John Heffner wrote:
The difficult problem is the router's behavior. If a subnet is
running a mixed MTU, it's not clear what that router's interface
MTU to that subnet should be. It would be nice for it to forward
the largest packets that it can support; however, to be compliant
with the spec it must generate ICMP PTB messages for any packets
that are too large to be delivered.
here's an interesting gotcha. Macs run a 1000/100/10 Ethernet
interface and run a 1500 byte MTU/MRU regardless. The router can
correctly observe that it is 1 GBPS and send the jumbogram, the
switch can support the jumbogram, and have the Mac not accept the
packet.
Hence, there are variations of this that are beyond the router's
knowledge.
Exactly.
I would suggest that the router respond with the ICMP when the
packet is too big for the configured interface MTU and not try to
predict the end system's or the switch's behavior. 4821 encourages
the sender to use the largest segment size that it can verify
delivery of. Leave that to the end system.
The question then is how to configure the router's MTU. The only
safe way that won't break 1122/1981 for an Ethernet interface would
be to set it to 1500 bytes. But then it won't forward larger
packets so jumbo-capable devices don't get the benefit of jumbo
frames beyond their local subnet. Setting the router MTU larger
will allow 4821 probing to work for jumbo-capable hosts, but then
you risk breaking connectivity to hosts on your subnet with smaller
MTUs, from outside hosts/protocols with larger MTUs that rely on
classical PMTUD (and aren't protected by the TCP MSS option).
-John
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
