Now that we've learned how to discover the MTU along a routed path,
we should explore the packet too big ICMP unreachable.
Before we dive into the unreachable message itself,
it is worth exploring the large packet that generated
the unreachable in the first place.
After all, if you're troubleshooting a network in real life,
you'll want to stay focused on cause and effect.
These large packets are just regular ICMP echo‑requests,
but notice the difference in packet sizes.
The first ICMP echo‑request in the packet capture has a size
of 1400 bytes and is immediately followed by a valid and
equally sized ICMP echo‑reply.
The next ICMP echo‑request has a size of 1401 and is immediately followed
by an unreachable stating that fragmentation is needed.
What do you think the minimum MTU along the traffic path is?
Pause the video if you need a moment.
The MTU at the fragmentation point in the network is 1400
bytes since a packet of 1400 bytes works,
but 1401 does not.
There are two important pieces of information here.
We already saw the packet size of 1401 bytes,
which is the length field inside the packet.
The packet also has the Don't Fragment, or DF,
bit set instructing the router not to fragment the packet.
This is what generated the unreachable.
Let's explore this new unreachable in greater detail.
Like other ICMP unreachable messages we've explored so far,
the packet is sourced from the device that generated it,
which in this case is the Globomantics router.
The packet is destined to the sender who sent the
large packet in the first place.
None of this is new or surprising.
When we break open the packet, we see the familiar ICMP type and code constructs.
The type is 3, which specifies a generic destination unreachable message,
much like the port unreachable message we saw when learning
about traceroute in a previous module.
The code is 4,
specifying that this message specifically indicates a condition where
the Globomantics router needed to fragment the packet,
but could not because DF was set to 1.
The most useful piece of information is the actual MTU available.
Remember when I used the check engine light analogy as it
relates to automobiles in an earlier module?
It would be pretty obnoxious if this packet too big unreachable simply said,
yep, you have an MTU problem.
Okay, bye.
Fortunately for us,
it tells us what the MTU should be at a given point in the network,
allowing the sender's operating system to adjust its MTU accordingly.
When we enable debugging on our client and receive these packet
too big unreachables back from the router,
this MTU was clearly displayed to the console.
Like other unreachables,
it also encapsulates the original IP packet header so that the client
can marry up this unreachable to a specific IP packet.
Again, this isn't news to us as ICMP unreachables typically operate this way,
including those seen in traceroute.
The scourge of fragmentation is a very real and often is a
serious problem for networks large and small.
It's always important to know the MTU along the entire
network path between two endpoints.
We've discussed a bracketing method and a sweeping method.
A dynamic technique known as Path MTU Discovery,
or PMTUD, basically accomplishes what our manual tests did.
For IPv4 at least,
it relies on sending large packets with the DF bit set
and awaits packet too big unreachables.
The new packet too big unreachable is sent back from a
router where the outgoing MTU is less than the packet size
and the packet's DF bit is set.
This informs the sender what the proper MTU should
be at a given hop in the network.
This last point about security flows perfectly into the next module where
we wil discuss how to use basic firewalling techniques along with ICMP
messages to improve the security of our network.
This makes fragmentation‑based attacks less effective, which is good news for everyone.