Will using jumbo frames help VBR 12 performance?

It will improve performance, but not much.

I don't think that you will see a significat effect. I did not in the one environment I have tried it.

Nope...doesn't hurt 🙂

My experience with Frames is that a mismatch is not good, resulting in fragmentation and re-transmissions. 

Scenario 1: all frames set to standard MTU end-to-end the data path including NIC, all switch ports, and storage array, and beware that different switches have different MTUs - performance OK.

Scenario 2: all frames set to Jumbo Frames end-to-end the data path including NIC, all switch ports, and storage array - performance should definitely improve for sequential IO pattern.

Scenario 3: Frame mismatch - likely to be worse that Scenario 1.

Jumboframes are awesome.  Performance may be negligible, but can’t hurt if done right.  If you attempt to use Jumboframes but don’t have that set at every hop end to end, you’re likely to end up with packet fragmentation which is going to negatively affect your performance.  One way to test is to ping with a set packet size and disallow fragmentation to validate that packets larger than 1500 bytes are allowed.

Windows: ping 192.168.10.1 -l 1500 –f

Linux: ping -s 1500 -M do 192.168.10.1

Cisco (IOS): ping 192.168.10.1 size 1500 df-bit

For instance, if you try to ping with a larger packet that 1500 with jumboframes disabled somewhere along the path, you’ll see something like this.  In my case, when creating this capture, I forgot when using a 9000 byte packet the -f switch and was took me a moment to figure out that my pings were successful because the packet was being fragmented - exactly what we are aiming to avoid.  (DOH!)

C:\Users\user>ping 10.2.2.10 -l 1400 -f

Pinging 10.2.2.10 with 1400 bytes of data:

Reply from 10.2.2.10: bytes=1400 time=1ms TTL=128

Reply from 10.2.2.10: bytes=1400 time=1ms TTL=128

Reply from 10.2.2.10: bytes=1400 time=1ms TTL=128

Reply from 10.2.2.10: bytes=1400 time=1ms TTL=128

Ping statistics for 10.2.2.10:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 1ms, Maximum = 1ms, Average = 1ms

C:\Users\user>ping 10.2.2.10 -l 9000 -f

Pinging 10.2.2.10 with 9000 bytes of data:

Packet needs to be fragmented but DF set.

Packet needs to be fragmented but DF set.

Packet needs to be fragmented but DF set.

Packet needs to be fragmented but DF set.

@dloseke - Great post.

I have had to use many of those commands before where my expected result wasn’t correct. Now everything on the “infrastructure” side uses jumbo frames but it’s always good to run a check every once in a while.   

The only caution I’d have to using it for Veeam, is the proxy servers. Repos are easy, and changing it on the Proxies is easy however, depending on your backup method things can change. 

• Is it using the VMware management port? Was that configured?
• are you doing file level restores direct to servers?
• Is your proxy a VM/physical? 
• Is your mount server using jumbo frames? 
• Is your workstation using jumbo frames? 

It’s so easy to miss something, but almost everything should support it these days.

When I have a dedicated purpose, like SAN replication it’s easy to configure both sides.

Interesting comment, do you have any Veeam Doc as source? Or just a feedback from the field or lab?

Thanks for sharing @Moustafa_Hindawi , it’s general network best practices as discussed in this topic.