Some operating systems have rudimentary automation features
to simplify MTU discovery using ping.
Let's see the ping sweeping technique in action on Cisco IOS.
Like the bracketing technique,
this does not require the packet too big unreachables.
It may not be supported on all operating systems,
but works very well on Cisco IOS.
It's also a technique I've personally used in production environments.
I want you to focus on how this solution solves the MTU discovery
problem and not the exact Cisco IOS commands I am typing.
To reiterate,
our goal is to discover the MTU from the Globomantics client to the
Wired Brain Coffee server across the network.
I've reduced the MTU between R1 and R2 to a value less than 1500.
I've also disabled ICMP unreachables for this demonstration so there is
no urge to cheat and simply enable ICMP debugging.
We begin by just typing ping ip without any other details.
Next, identify your paying destination of 10.2.5.5.
The repeat count should be 1.
The datagram size is irrelevant since we will later override it,
so just hit Enter.
Set the timeout to 1 second so that when the packets start failing,
the overall paying execution fails faster.
Enter y for yes to enter the extended commands menu.
Most of these have nothing to do with MTU discovery,
such as specifying the source address or type of
service or quality of service treatment.
However,
we must answer yes to setting the DF bit to ensure our
packets are not fragmented along the path.
The next three options are irrelevant, so I'll press Enter through them.
Here comes the important part.
Enter yes to the first sweep question.
For the starting point of the sweep,
enter a number that you feel confident will pass the MTU test without question.
Choose a nice even number, but then add one to it.
I will use 1301.
Don't worry, I promise I'll explain this.
For the sweep max size, use 1500 since that is our upperbound to test against.
Sweep interval of 1 is perfect, so just hit Enter, and off we go.
Each ICMP echo‑request sent is one byte larger than the one before it.
The first packet has a size of 1301, the second has a size of 1302, and so on.
This means that 200 total packets will be sent from 1301 to 1500.
Now do you see why we started at 1301 and not 1300?
It just makes the math so much easier.
At this point, we can see the failures starting to show up.
Looking like we had 192 out of 200 packets succeed.
That, my friends, is our answer.
We started at 1301 and sent 192 packets that succeeded.
That means we can simply add these two numbers,
then subtract one to properly count the first packet.
1301 plus 192 minus 1 yields 1492, which is the MTU I configured.
If you are paranoid like I am,
you can always do a quick sanity check using a
bracketing test within a tight range.
Try sending a packet at size 1492 with DF set.
Okay, that worked as expected.
I bet 1493 won't work with DF set though.
Go figure, 1493 fails because it's too big.
Notice there were no ICMP unreachables in use here,
and yet we were able to discover the MTU with one fancy ping command.
We then confirmed our findings using a few follow‑on basic ping tests.
Let me turn your attention back to the packet too big unreachable. In the next video, we will dissect this packet to learn more.