Determining your MTU, and why you should care.

When we talk about networking, sometimes we’ll talk about Maximum Transmission Unit (MTU) packet sizing.  I briefly referred to MTUs in the SSL errors, and how to diagnose them post.

Why should you care?  Well if you want a fast internet connection, you should.

Think of the MTU as a 4 pint jug.  Your 4 pint jug can ever only hold 4 pints.  But say you are trying to fill it from an 8 pint (gallon) bucket.  You need two jugs.  This, in networking, we call packet fragmentation.  Packet fragmentation was the root cause of the issue in the SSL errors post.

Packet fragmentation is bad.  To stretch the bucket example, you’d need to make two trips as your 4 pint is too small.  It’s faster to make one trip.

So how do you set the maximum MTU for your network connection?
(Note: if you are running Windows Vista or Windows 7, you should not need to.  But if you want/need to, there is a handy guide here.)

Well there are two ways to adjust your MTU.

The hard way – MTU Ping Test

We do a series of ping tests using the ping command like this:
ping www.google.com -f -l xxxx,
where Continue reading

SSL errors, and how to diagnose them.

Frankly, I don’t know, but here’s what I learnt.

It started with a customer reporting a problem

When we press the publish button on the website, we get a 403 error.

A co-worker of mine picked up the call.  After trying many different things, he asks our Network team for help.

If it works on a standard Windows PC, we’re not interested in even having a look.

“What next?”, asked my colleague.

Never, ever volunteer; but the words sprang from my mouth,

“Perhaps I can be of assistance.”

SSL Malformed Packet Some network tracing was done, and the problem was SSL related.  An SSL error was being thrown.  The application server was throwing a SSL Malformed Packet back at us.

As SSL traffic is encrypted, you can’t tell much more than that, unless you turn off encryption.  Not going to happen on a production system.

My first guess at the solution was wrong.  An schannel.dll update didn’t fix the problem.  I spent a bit of time analysing what the JavaScript code was doing as well.  Couldn’t find any issues with it.

So what else do we see in the network trace?  Ah… we’re getting packet fragmentation.

Hmmm.

Told my colleague to look at the PMTU Discovery setting and to turn it on, to eliminate the packet fragmentation.  That was wrong too, as it was already on.
But turning it OFF fixed the issue.

So what are the important “take-aways”?

  • Sometimes your first, second, and even third guess, can be wrong.
  • Sometimes you need to cut your losses with an issue, but in this particular case, we did not get to that stage.
    IMHO, I thought we were close.
  • Know what is “normal” behaviour, and what is “abnormal” behaviour.  Spot the difference.
    In this case, we had two network traces; a working one, and one which captured the problem.

Update 4th Oct 2009: Eric Law’s MSDN Blog post is worth a read: Internet Explorer Cannot Download https://something
Update 6th Dec 2009: Deb Shinder’s article is worth a read: SSL Acceleration and Offloading: What Are the Security Implications?
Update 17th Dec 2009:
I had to revisit SSL sniffing in Internet Explorer has issues with session cookies, fancy that.

Bookmark and Share