Iljitsch van Beijnum wrote:
On 23-jul-2007, at 18:46, Iljitsch van Beijnum wrote:
After the feedback this afternoon I read RFC 4821, which is about
discovering the path MTU by probing rather than depending on ICMP
messages.
[...]
This means that it would be possible for hosts implementing this
mechanism to simply set the maximum MTU search size to their local
non-standard MTU and everything will work.
However, for this to work reliably, it's necessary that a host only
sends large packets if it actually supports RFC 4821. What could happen
if that host A1 on subnet A where RFC 4821 in combination with a
variable MTU is used by systems supporting jumboframes communicates with
host B2 on subnet B where RFC 4821 isn't used, but the administrator has
set a larger than 1500 byte MTU on all nodes on the subnet (the way
jumboframes are done traditionally). If host B2 then sends a packet that
is too large for the switch that host A1 connects to, the router on
subnet A keeps sending packets that are too large into the layer 2
network and host B2 never recovers from the lack of reachability.
For hosts communicating on a mixed-MTU switched network, it should be
safe for hosts implementing 4821 to increase their interface MTU beyond
that network's configured MTU. (Assuming nothing bad happens to the
network gear by sending oversized frames -- as you mentioned, this has
potential to cause some problems on very old ethernet gear.) Hosts
implementing 4821 that have a jumbo-clean path between them will
automatically take advantage of this, while still communicating with
non-4821 hosts using the standard MTU.
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. (Note, I assume here that MTU==MRU in all cases.) Since the
router does not know the MTU of each host on the subnet, the only
compliant thing for it to do is to use the smallest possible (e.g.,
standard) MTU for that network. I believe what you are describing above
is the failure mode if the router interface is configured with an MTU
higher than the standard MTU. Hosts sending from outside the router
using 4821 will work fine, but any host outside the router with a larger
MTU (that may be valid on its own network), and still relying on
classical 1122/1982 pmtud, will break.
In my mind, the question of what the router should do is the most
important in any discussion of mixed-MTU subnets. In order to generate
the correct ICMP PTB messages, a route with a large-MTU interface on a
mixed-MTU subnet would need to know the individual MTUs of each host on
that subnet. Neighbor discovery seems like the place you'd want to do
this. However, I think this is a tricky problem, and I'm not sure your
proposal solves it in full. (Think this over and tell me if I'm wrong
-- I'm not sure I understand your "The MTU detection message"s fully.)
There was some talk a while back about doing jumbo ARP or jumbo DHCP to
allow routers to discover the MTU of their neighbors. Does anyone have
pointers on this? At least one Cisco router has error counters for
jumbo ARP/DHCP (google jumbo arp). I've been kicking around some ideas
in this space but none of them are fully baked, possibly not even
half-baked. ;)
One thing to note is that if you imagine a world where the vast majority
of hosts with large MTUs use 4821, it may be operationally acceptable to
deliberately break classical pmtud by not generating ICMP PTB messages.
This may not be totally far-fetched, since classical pmtud is so
fragile in practice that large MTUs are currently quite rare. This is
an imperfect solution, but with some luck it may be just good enough.
-John
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
