On Thu, Mar 15, 2007 at 12:03:02PM -0700, Steven Kurylo wrote:
> >Ok, but given any of those scenarios, is a 2.6.x Linux system's path MTU
> >discovery smart enough to figure out what's going on and correct? Or
> >will it just send data out to get mangled and not detect it?
>
> If the switch is dropping the packet, then it will be treated like any
> packet loss. In the case of TCP, the packet will be resent, and of
> course dropped again.
>
> If the packet was mangled, the ethernet frame would be thrown away for
> failing the crc.
>
> You really need a switch which supports path discovery.
In general, I haven't seen or read much discussion on PMTU discovery at the
link layer. My gut feel is that it would be something proprietary if it
did exist.
Traditional PMTU works at the network layer (IP) where datagrams cross link
boundaries. The RFC that describes doing PMTU discovery basically says try
sending smaller datagrams until they start getting through. That algorithm
works on the assumption that datagrams just don't make it through from the
point of view of IP. Ethernet could drop them on the link (at the switch)
or could forward a truncated frame which will fail the CRC. Either way, IP
never sees it. If an intermediate router sees it, it may want to fragment
however the "Don't Fragment" bit of IP will prevent that, causing an error
and an ICMP error response.
A hack solution to deal with MTU discovery on a link might be to write a
script to run on startup.
Here's some pseudo-code
for (mtu = max_mtu; mtu > 0; mtu - mtu_decrement) {
set interface_mtu = mtu
if ping gateway then {break;}
Basicaly start with the max MTU and keep decrementing until a ping reply
comes back.
Received on Thu Mar 15 13:38:44 2007
This archive was generated by hypermail 2.1.8 : Thu Mar 15 2007 - 13:38:50 CST