Dave Huang <khym%azeotrope.org@localhost> writes: (Separately from the points addressed hear, I should point out that I agree with everything Dennis has said.) > How does the OS know what the MTU of the next-hop network is? By > adding a static route, I'm declaring what I want the next hop's > outgoing interface to be. It seems reasonable that I should also be > able to use it to declare what the MTU is, if the default MTU assumed > by the system based on the interface type is incorrect for whatever > reason. That's layering on a kludge to fix a bug. An interface has a configured MTU, which can be changed if it's wrong. But an MTU and the implicit MRU are really a property of link (v6 term). > It doesn't seem like NetBSD uses it as a PMTU cache--at least I've > never seen "netstat -r" show any routes added due to PMTU discovery. I have seen such entries. They are rare now, as DSL has faded, and most links handle 1500. And almost all v6 links handle 1280. You could provoke them by hooking up two machines with a configured (interface) MTU of 576 across an ethernet serving as a gateway to another link, and then operate normally from the far side. > I was just experimenting with route MTUs when I came across this > problem; I don't have any real need or use for them, so I wouldn't > personally be affected either way. That said, I do think it makes > sense for the route MTU to be a way to administratively set the "MTU > of the next-hop network" for a certain route. Which is what NetBSD The MTU is fundamentally a property of the link (next hop), not of paths (where an MTU is dynamic, and the min of the links). There is a way to configure MTU for the network, although it is rarely appropriate to change it. > already does-- packets being forwarded through the router that are > larger than the route MTU do get fragmented if DF is not set. This > would also match the Linux behavior, and I think the FreeBSD behavior > too. I haven't actually tried on FreeBSD, but there's a comment in > their ip_input.c:ip_forward() that says, "Try to cache the route MTU > from ip_output so we can consider it for the ICMP_UNREACH_NEEDFRAG > "Next-Hop MTU" field described in RFC1191." followed by > mtu = ro.ro_rt->rt_rmx.rmx_mtu; > > Later, when the ICMP needs frag is sent, the MTU sent back is the > minimum of the interface MTU and the route MTU. It still seems overly inventive to be using "route MTUs" which are really PMTU-D cache entries.
Attachment:
pgprQK08GyrpR.pgp
Description: PGP signature