Introduction
Occasionally you may find that only specific services within your server respond slowly, or have intermittent connection problems, while other services usually behave without issue. This can lead to a frustrating situation where you cannot correctly diagnose the behavior due to discrepant behaviors.
In this article, we'll cover one tool for diagnosing these behaviors - MTR.
Procedure
If you do not already have MTR installed, it can be installed using the appropriate method from the below:
RHEL & CentOS variants:
yum install mtr
Ubuntu & Debian variants:
apt-get install mtr
Windows installation instructions, and the software itself, can be found here:
WinMTR
Once installed on your local system, the following can be used to run an MTR on a specific port, updating $PORT and $IPADDRESS as needed:
mtr -P $PORT -T $IPADDRESS -c 100 -w
Explaining the flags above:
- -P: Specify the port to check against
- -T: Specify TCP packets instead of ICMP Echo packets
- -n: Do not resolve hostnames from IPs
- -c: Specify the count to use
- -w: Wide report mode; This prevents trimming of addresses and provides a report after the task completes
The expected output would be similar to the following:
HOST: serverhost.name Loss% Snt Last Avg Best Wrst StDev
1.|-- 172.16.1.1 0.0% 100 0.5 0.5 0.4 0.7 0.0
2.|-- 10.2.32.1 0.0% 100 2.0 3.0 1.4 7.3 1.9
3.|-- 10.0.2.1 0.0% 100 0.8 0.8 0.7 1.2 0.0
4.|-- 1.2.0.0 0.0% 100 1.5 4.1 1.5 12.0 3.8
5.|-- 1.2.2.0 0.0% 100 1.1 1.2 1.1 1.3 0.0
6.|-- 1.2.2.1 0.0% 100 1946. 1419. 961.5 1946. 464.7
What to do with the information
You will undoubtedly, receive a lot of information from these tests. While the below is not an exhaustive list of possible outcomes, it serves as a glib overview of the most likely behaviors you will encounter.
If you see loss only in the middle of the route, it suggests a problem between your server and your local system. In cases like this, there is very little that can be done by you to resolve the behavior.
Suppose you see loss only near the start of the route. In that case, it suggests that your Internet Service provider(ISP) is filtering traffic over that port or that there is some issue in your local network equipment or its configurations causing the behavior. In this case, you would need to contact your ISP for assistance, as their security protocols cannot be modified from within your cPanel server.
If you see similar response times throughout the route and no loss anywhere in the route other than your server or the hop immediately prior to your server, it suggests that your server, or hosting provider, is filtering traffic of the type you are testing. In this case, the first step towards resolving the behavior would be to disable any security appliances or to whitelist all traffic destined for the noted port and then perform the tests again.
If the behavior continues after disabling your security appliances, please open a ticket with us to help you review the behavior further.