I'm not sure, but if you run tcpdump* on the solaris box and connect to the netapp with both set to 9194, and you don't see any ICMP type 3 code 4 traffic, you're probably OK. You should also be able to see the actual packet lengths in ethereal, iirc.
-Nick
* output it to a file and open it in ethereal/wireshark.
On Fri, 2008-03-07 at 14:04 -0800, Sto Rage© wrote:
Thanks for the reply. Now my next question is does NetApp support a MTU size of 9194? It looks easier for me to change the NetApp end (just 1 cluser) instead of asking the Solaris admin to change on 18+ hosts. All the documents I have seen from NetApp seems to only suggest using 9000 as the default, where as all the SUN documents suggest 9194 as their default. Thanks once again -G
On Thu, Mar 6, 2008 at 11:26 PM, Nicholas Bernstein nick@nicholasbernstein.com wrote:
On 3/5/08 9:05 PM, "Sto Rage(c)" netbacker@gmail.com wrote:
Quick question to all the networking gurus on this list. Is there a performance impact if the filer and the clients have different MTU sizes defined. Also is there a way to check this. Our filers all have jumbo frame MTU set to 9000, but for some reason our solaris admin chose to set them on his side to 9194. ifstat on the filer interfaces don't show any errors/discards or retransmits. Example:
Yes, there's definitely a performance impact. Essentially, if one packet's 9100 and one's 9000, you've got 100 that's going to have to be split back into another packet. Your filer will give a response saying "MTU size is too big", please break it into chunks. I'm not sure if this only happens once / session, or per-packet, but if it happens per-packet it's a lot of extra overhead. Even if it's not, that extra 100 needs to go into a new packet, so you're getting overhead of splitting it into chunks and then overhead of re-assembling it on the destination.
Essentially... Yes. :) you want them all to match.
-- Nicholas Bernstein http://nicholasbernstein.com