Can we use ICMP ping to help discover the MTU?
We sure can.
Let's start with a method I like to call ping bracketing.
Before we jump into this demo,
think back to the past demo of using ICMP ping to isolate faults.
We started at the edges of the network,
then slowly and methodically worked our way into the
center until we found the fault.
We can also discover the MTU of our path between two
endpoints using similar logic, but applied differently.
Rather than varying the location in the network for ping targeting,
we can vary the size of the ping packets we send into the network.
Imagine looking for a last name in a phone book.
You open the book to a random page and then make rough over or
underestimates until you reach the name you're trying to find.
Despite a phone book having thousands of pages,
it typically only takes 8 to 10 searches to find the name in question.
Let's apply this logic to MTU testing.
I've reduced the MTU on the link between R1 and R2
to a value less than 1500 bytes.
I won't spill the beans and tell you exactly what value though.
Starting at 1500 for testing is usually a good idea because it's
the default MTU for most Layer 3 protocols.
In order to speed up testing,
I'm only going to send one packet at a time by using repeat
1 and remember to enable the DF bit too.
Okay, no good.
Clearly, the MTU is less than 1500.
Let's guess 1350 now.
I like to operate in a 100 to 200‑byte range when using this technique,
so settling on 150 for this demonstration works fine.
No need to overthink it.
It worked, but what comes next?
Resist the urge to randomly guess.
Follow a binary search algorithm instead.
You don't have to be surgically precise,
but just keep splitting the value in half and making decisions at each point.
150 divided by 2 is 75, so let's try 1425, the midpoint between 1350 and 1500.
This fails, so let's scale back 37 more to 1388,
the midpoint between 1350 and 1425.
This succeeds, so adding 18 to 1388 yields 1406.
This fails.
Clearly, we are zeroing in on the actual MTU,
which is between 1388 and 1405 at this point.
Let's subtract 9 and test 1398.
Okay, that worked.
Adding 4 yields 1402, taking us ever closer to finding the answer.
This fails.
Subtracting 2 yields 1400.
Let's test that.
Okay, 1400 succeeds.
At this point, we know 1400 works and 1402 doesn't.
Let's quickly test 1401 to finish our testing.
It fails, which proves 1400 is the MTU.
Now that we've done it the hard way, I'll show you the super easy way.
I'll enable ICMP unreachables in the network so that the new packet too big
message is sent back rather than the ping timing out.
Then I'll turn on ICMP debugging and send a 1500‑byte packet again,
being sure to set the DF bit.
The packet too big unreachable message carries the available MTU in its payload,
making it easily accessible to the client operating system.
You might be asking,
why did you waste 3 minutes of my life on this time‑consuming
bracketing technique when there is an easier way?
The answer will become apparent in the ICMP security section,
but in short, not all devices send ICMP unreachables.
And even when they do, unreachables that are sent may get filtered by firewalls.
A number of issues could prevent the packet too big
unreachables from functioning correctly.
I want you all to remember this: This bracketing technique always
works on any operating system in any environment.
Even if the devices along the way don't send unreachables,
you'd simply get no reply from your pings.
Having supported customers with high security production
networks where unreachables are often disabled, this technique is very handy for network operators and is a perfect last resort.