13

Consider the following: NAS with 10G interface connected to 10G interface on switch. Client computers connected to switch via gigabit Ethernet.

  • Will there be any gain in performance if MTU size is increased on NAS and switch port to which NAS is connected if the MTU size is not increased from the standard 1500 bytes on the client NICs?

  • Will this cause fragmentation problems?

  • How do devices "handle" mismatches in MTU for interfaces across a switched network?

Mike Pennington
  • 29,876
  • 11
  • 78
  • 152
sardean
  • 562
  • 2
  • 9
  • 18
  • what protocol are you using for SAN traffic? – Mike Pennington Oct 08 '13 at 07:43
  • 1
    Actually I think Path MTU Discovery (PMTUD) is fairly common on hosts these days, so it's likely the client will send an ICMP Fragmentation Needed (Type 3, Code 4) message containing its MTU, which should cause the host to reduce it's packet size. –  Oct 14 '13 at 20:19

4 Answers4

21

No performance gain will exist without everyone using larger packets. The point of jumbo frames is to pack more payload with the same overhead. The NAS's ability to send larger packets is meaningless if the clients don't as well.

There will be no "fragmentation" at all. Layer-2 (ethernet) has no means if indicating "fragmentation needed". This is figured out at Layer-3 (IP) by routers sending an ICMP message when it has to drop the packet because it won't fit on the next-hop interface. This cannot happen where there's no router -- on a flat, switched LAN. The jumbo packets sent from the NAS will be dropped by the client as an oversized frame -- or dropped by the switch for the same reason. [A 9k packet cannot be sent on a 1500B interface.]

Ricky
  • 31,438
  • 2
  • 43
  • 84
  • So, it will pretty much just cause endless problems, where the client or switch will drop a lot of the traffic from the SAN ? – nos Oct 08 '13 at 10:48
  • @Ricky - How might the repeated dropping of oversized packets manifest? Does the receiving interface have a way to "tell" the sender it can only take X size frames? Or does the sender see that the frame was never received by an upper layer protocol like TCP? – sardean Oct 08 '13 at 13:27
  • 1
    The packet is dropped and that's the end of it. (well, a counter ticks up, but a) no one checks it, and b) you won't know what exactly caused it.) You'll see it as TCP connections stalling as soon as a transfer begins, iSCSI links failing, etc. – Ricky Oct 08 '13 at 20:04
  • There are counters on most managed switches (ones with a telnet/SSH/web interface) that indicate categories of packets both successfully transmitted and those that are dropped. I have a Netgear GS108T that had that under one of the menus for the ports and can definitely say Ciscos (and their ilk) have those counters as well, which can be reset, then you test your connection, and will see the relevant dropped category counter increase. The name/category to look for is usually "oversize"/"oversized" or the like and you're looking for packet counters for a specific port in your device – Rook Nov 11 '20 at 19:50
5

Q: Will there be any gain in performance if MTU size is increased on NAS and switch port to which NAS is connected if the MTU size is not increased from the standard 1500 bytes on the client NICs?

Answer: No, because the the increased MTU size is not being utilized by the client. If you wanted to transport 100 people from point A to point B, you could use two busses or 25 sedans. If the road between A and B is made so that the busses can more easily move with no delays, and you still move them in sedans, you're not gaining anything.

Q: Will this cause fragmentation problems?

Answer: No, fragmentation happens in the opposite scenario when you send a large packet while the path does not support it and needs to chop it into supported sized packets.

Q: How do devices "handle" mismatches in MTU for interfaces across a switched network?

Answer: If the packet is smaller than the allowed packet size, it is passed with no issue. If the packet is larger than the allowed size, it is dropped.

slm
  • 397
  • 1
  • 5
  • 14
AdnanG
  • 353
  • 2
  • 10
  • 2
    This is not true. No fragmentation happens at layer 2. There is no means of negotiating MTU on an ethernet segment. If everything isn't setup the same, some nics (with the smaller MTU) will be dropping oversized frames. – Ricky Oct 08 '13 at 05:03
  • Have a look at https://supportforums.cisco.com/thread/20490 that explains what I mean. – AdnanG Oct 08 '13 at 06:01
  • I see, thanks for pointing that out. I am removing that part from the answer. – AdnanG Oct 08 '13 at 07:37
1

MTU of a tcp session is established on the initial TCY SYN connection. if you have mismatching MTU on the network, its not going to matter for your tcp application... layer2 or 3. UDP does not have the same concept so yes, for UDP you will start to fragment traffic which may/may not impact performance. It all depends on the traffic type, size, volume, and your hardware.

payam
  • 11
  • 1
0

Some stuff missed... First, there are no MTU negotiations. Second, when discussing TCP SYN packets, they are rarely ever going to exceed a link MTU frame size. In that reguard, there is PMTU responses when discussing layer 3 as well as TCP MSS which deliver a payload what the max size is. Im not saying anyone is incorrect here, but often MTU settings may go unnoticed because of such features.

Jason B Shrout
  • 101