The Importance of MTU

With Sun Ray Server 3, we started supporting remote/broadband/WAN type deployments.  Emphasis on supporting because we've both known about and helped some customers do this for a very long time.  (Funny that the last link was to MTU and this about MTU)  We also introduced some changes to the firmware and server side code (even in the 2.0 version) that allowed for things like NAT, furthering the deployment possiblities.  One thing however that they Sun Ray does not do is fragmentation reassembly.  There are some good reasons for this as some WAN links drop fragremented packets, but mostly it's just a resource/feature issue.  But we do offer a work-around by allowing you to set the MTU on the Sun Ray itself which tells the Sun Ray protocol to throttle back on the MTU.  More on that later.

Bear with me as I step in over my head (with a little help from my friends)

One thing to consider in doing remote deployments is the Maximum Transmission Unit, which is the largest packet/datagram that can be sent over a network   In a perfect world, the MTU for ethernet is 1500.  In most WAN environments, things are far from perfect.  Due to different types of links, network gear, security features, etc, an MTU of 1500 over a WAN (and sometimes a LAN) connection is a pipe dream.  So some smart people invented PMTU Discovery, which is mechanism for a client and server to determine an agreed upon MTU.  Then some paranoid people decided to it's best to block ICMP packets across WAN routers, firewalls, etc, which basically renders PMTU-D useless.

Having the wrong MTU size is the cause for most of the frustration someone deals with in remote Sun Ray scenarios.  "Slow redraws", "jaggy", "black pixels", and "unuseable" are just some of the terms I've heard that all go away when we discover the correct MTU.   My MTU journey all started with my own dissatisfaction with my Sun Ray @ Home experience.  People were raving about it and I was just not seeing it.  MTU was checked and it was "correct" for the Cisco VPN gear (1366).  

So how can one find the correct MTU.  First you need a ping program that supports the do not fragment flag.  Not sure if this counts as irony, but the only one I've found is from Microsoft (AFAIK Solaris lacks the ability to allow for a "do not fragment switch" in a ping packet).  Booting up Window XP, please stand by.

OK.  I'm back.  Wait, I lied.  Even though I can log in, not all services are started yet.  Running to grab a soda.  BRB.

So what we want to do now is to ping through to the other side to find out the largest packet size you can get through.  Here I decided to just ping my ISP's DNS server using the MTU that my Sun Ray @ Home is configured to use.

C:\\Documents and Settings\\Craig>ping -l 1366 -f

Pinging with 1366 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.

Doh!  Santa Clara, we have a problem.  In this case 1366 is too large and I've found the 1256 is the largest size I can put through.  It's something in the WiFi setup that's doing this.  And guess what, my Sun Ray @ Home is going through the WiFi gear before it goes out to the internet.

C:\\Documents and Settings\\Craig>ping -l 1256 -f
Pinging with 1256 bytes of data:

Reply from bytes=1256 time=13ms TTL=59
Reply from bytes=1256 time=18ms TTL=59
Reply from bytes=1256 time=16ms TTL=59

Once you find your magic MTU value add 28 to it and set option 26 on the DHCP server supplying the Sun Ray it's information, power cycle the Sun Ray and you are all set.  You can also set this in the GUI firmware.


Post a Comment:
Comments are closed for this entry.

My name is Craig Bender aka ThinGuy. I'm a Principal Software Developer for Oracle's Virtual Desktop Engineering group.

I architect and evangelize the use of Oracle's Desktop technology including Sun Ray, Secure Global Desktop, and Oracle VDI.


« February 2016