Troubleshooting MTU & ICMP Issues

Where do you draw the line between troubleshooting and optimization?

I believe the difference is related to your threshold of pain. In other words, how long are you (or your clients) willing to put up with an issue before you start investigating? I can't count the number of times I have overheard a complaint and investigated, only to find out there was a legitimate technical issue that needed to be addressed.

The saying, "if it ain't broke, don't fix it" does not apply to the networking, medical, or automotive fields. In the past 10 years, troubleshooting has changed from "break and fix" to "slow and ignored." Break and fix has a more straightforward approach and goal. Find the device that failed, fix it and test it to make sure it is back up. Performance issues can get more time consuming since variables such as the client's configuration, location, network, server and other components may contribute to an overall performance issue.

This video deals with an issue that I run into often, but is typically overlooked because it doesn't cause an obvious outage. These issues typically rear their ugly heads when you are in the middle of something important, like upgrading your network or migrating to the cloud, so you should find out how your applications behave in advance.

Here I show you how to use ICMP to look into slow performance related to packet size. I also take a few moments to cover relative sequence numbers and some other Wireshark messages along the way.

One of the key points to take away from this example is that the problem did eventually resolve itself, only with the help of ICMP. In many cases, if you have a low latency network, the impact will be minimal. But circumstances can vary for different clients.

Keep that in mind some cloud providers, routers or firewalls are configured to block all ICMP packets, which will result in the same problem. And IPv6 would make this behave differently yet.