Network Connection Problem Troubleshooting

If you believe that your server is experiencing a slow network connection, you should first consider and check the following:

• Is there anything on your server that may be causing this issue; e.g. a client on your device sending high volumes of traffic?

• Is your server trying to send or receive an abnormally large amount of data?

• Is your server’s connection speed and duplex settings configured correctly? Your server’s connection to our switch should always be set to full duplex and the speed setting should always match what our switch port is set to.

If you have considered and checked the above, and believe that none of these factors could be causing the slow network issue, then we would suggest hard power-cycling your machine to see if this fixes the issue. Please be aware that there is always a chance of data-loss when power-cycling a server, so we can only advise you to power-cycle your machine and the decision to do so must be your own.

If you have considered all the above, attempted to reboot the server, and this has not resolved the issue, please raise a support ticket with the following information and answers to the following questions, so that we can effectively troubleshoot this problem for you:

• Are you experiencing any complete outages or just high latency/delay to your service?

• When did you start to notice the interruption to the service?

• Is the interruption still ongoing? If not, when did it end?

• Can you please supply an MTR of 1000 cycles to your hosted server from your remote machine (forward direction)?

• Can you please supply an MTR of 1000 cycles to your remote machine from your hosted server (reverse direction)?

• Please confirm the public address you are using at the remote location; and also the IP address of the affected service hosted with us?

• Can you please confirm the geographical location you are trying to reach the server from?

• Have you have tried to re-boot your server?

• Can you please confirm the speed and duplex settings of this server?

Once you get in touch with the above information, our team will be able to look into this issue for you as soon as possible. If you have any further questions, please get in touch and we will be happy to help.

If you believe that your server is experiencing packet loss, you should first consider and check the following:

• Is there anything on your server that may be causing this issue?

• Is your server trying to send or receive an abnormally large amount of data / packets? If so, can I resolve this?

• Is your server’s connection speed and duplex settings configured correctly? Your server’s connection(s) to our switch should always be set to full duplex and the speed setting should always match what our switch port is set to.

If you have considered and checked the above, and believe that none of these factors could be causing the slow network issue, then we would suggest hard power-cycling your machine to see if this fixes the issue. Please be aware that there is always a chance of data-loss when power-cycling a server, so we can only advise you to power-cycle your machine and the decision to do so must be your own.

If you have considered all the above, attempted to reboot the server, and this has not resolved the issue, please raise a support ticket with the following information and answers to the following questions, so that we can effectively troubleshoot this problem:

• Are you experiencing a complete outage or high latency/delay to your service?

• When did you start to notice the interruption to service?

• Is the interruption still ongoing? If not, when did it end?

• Can you confirm the speed/duplex setting for the interface with the issue?

• Can you supply an MTR of 1000 cycles to your hosted server from your remote machine (forward direction)?

• Can you supply an MTR of 1000 cycles to your remote machine from your hosted server (reverse direction)?

• Please confirm the public address you are using at the remote location; and also the IP address of the affected service hosted with us.

• Have you have tried to re-boot your server?

• Can you please confirm the speed and duplex settings of this server?

Once you get in touch with the above information, our team will be able to look into this issue for you as soon as possible. If you have any further questions, please get in touch and we will be happy to help.

If you have a problem accessing a device hosted with us from one location, but not another, before you get in touch you should consider the following:

• Could this be caused by a software problem on my external device? Does some software need updating?

• Is there a firewall rule on my hosted device or within my infrastructure that could be blocking this access?

If you have considered the above, but cannot find a resolution, please raise a support ticket with the following information:

• The device, IP address / Subnet that cannot be reached.

• The public IP address of the device that cannot reach the device in our DC.

• The geographical location of the device that cannot reach the device in our DC.

• Is this problem with more than one IP/Subnet and/or device, or just the one?

• The OS of the device that cannot be reached (please include the version).

• Is there any firewall rules that could be blocking the access to this device?

• The following Trace Routes:

  • A MTR of 1000 cycles to your hosted server from your remote machine (forward direction).

  • A MTR of 1000 cycles to your remote machine from your hosted server (reverse direction).

• The network configuration of the problem device (IP, subnet mask, default gateway, speed and duplex settings).

Once you get in touch with the above information, our team will be able to look into this issue for you as soon as possible. If you have any further questions, please get in touch and we will be happy to help.

If you have a routing issue with devices hosted with us, before you get in touch you should consider the following:

• Is there a firewall rule on one of my hosted devices that could be blocking this access?

• Are both servers accessible, online and reachable externally?

If you have considered the above, but cannot find a resolution, please raise a support ticket with the following information:

• The IP address / Subnet that cannot be reached.

• The IP address / Subnet that you are trying to reach it from.

• Is this problem with more than one IP addresses/Subnets and/or device, or just the one?

• Can you reach both devices externally?

• The OS of the devices (please include the version).

• If there any Firewall rules that could be blocking the access to this device?

• Can you please supply bi-directional MTRs of 1000 cycles (from device A to device B; then from device B to device A).

• The network configuration of the problem devices (IP, Subnet Mask, Default Gateway, Speed and Duplex settings).

Once you get in touch with the above information, our team will be able to look into this issue for you as soon as possible. If you have any further questions, please get in touch and we will be happy to help.

MTR, or My Traceroute, is a free network diagnostic tool, designed to combine the functionality of traceroute and ping monitoring programs. A MTR works by sending around one packet per second from the host device to the destination device, while probing the routers along the route path and checking how many packets were lost between each hop.

The results of an MTR will show the host each packet passes through, how many packets have been sent, the percentage of packets lost between hops and the details surrounding the results of Pings on each host. MTRs are often used when there is suspected packet loss between two devices, or a routing issue, to determine if and where any issue may reside. If you suspect either of these two issues are occurring on a device hosted with us, we will require you to run an MTR to help diagnose where the issue is.

Please see our FAQ section for information on how to run MTRs. If you have any more questions about MTRs, please look through our FAQ section, or raise a support ticket and we will be happy to help.

To run a MTR from a CentOS device, you first need to install the MTR package provided by Linux. If you have not installed MTR on your CentOS device before, run the following install commands:

Command 1
Command Description	Issue the following command to start the install of MTR
Command	yum install mtr
Image of Command being Run
Image of a Successful Result of Command
Command 2
Command Description	Press Y then enter to confirm you wish to install the MTR package
Command	y
Image of Command being Run
Image of a Successful Result of Command

Once you have installed the MTR package, you can now issue a command to begin the MTR.

When issuing the below command, you will need to enter the IP address of the destination device. What the destination device is depends on what problem you are experiencing and trying to diagnose. If you are experiencing packet loss or if there is a routing issue between two devices, you will need enter the IP address of the other device. In my example, I am running a MTR from one of my servers to another, as I believe that there may be packet loss between the two servers.

Command 3
Command Description	Issue the following command to start the MTR, running a trace the destination IP address.
Command	mtr [insert destination IP address]
Image of Command being Run
Image of a Successful Result of Command

The MTR will now start running and it should send roughly one packet per second. You can see how many packets have been sent from the host you are running the MTR on in the top row, in-line with the host’s IP, under the sent column. You must now leave the MTR running.

Once the MTR has sent 1000 packets, you can use the results to identify where the issue lies. We require at least 1000 packets to be sent, so the results are accurate.

If you are checking for packet loss, you can use the Loss% column to identify the percentage of packets lost within this hop, and you can use the Host column in line with the Loss% column to identify where the packet loss began. If you are checking for a routing issue, you can use the Host column to identify the path the route has taken.

Once the MTR has sent 1000 packets, you should copy the entire MTR table and paste it into a text document. If you do identify an issue, you will need these results later. To copy the table from a putty window, you simply need highlight the whole table. You can see an example of a copied table below.

		Packets		Pings
	Host	Loss%	Snt	Last	Avg	Best	Wrst	St	Dev
1	□8.□29.□50.□□	0.00%	1100	0.5	0.6	0.5	0.8	0
2	e1-46.lea302.1ue.dc5.as20860.net	0.00%	1100	0.6	0.6	0.5	0.7	0
	e1-45.lea302.1ue.dc5.as20860.net
3	e3-21.bor2.dc5.as20860.net	0.00%	1100	0.7	0.7	0.7	0.9	0
4	po2-30.net1.north.dc5.as20860.net	0.00%	1100	0.4	0.3	0.3	0.4	0
5	□7.□17.□11.□□	0.00%	1100	1.2	1.4	0.9	2.4	0.3
6	□3.□42.□28.□□	0.00%	1100	0.3	0.4	0.3	0.5	0

Once you have finished running the MTR on this device and copied the table, press Q to stop the MTR.

You should now run the MTR on the destination device, to the device you just ran the MTR on above, then copy the table (reverse direction). If you do discover any issues that lie within our network, please supply both MTRs in a support ticket with the details of the problem you are experiencing, and our team will investigate this issue.

If you have any more questions about MTRs, please look through our FAQ section, or raise a support ticket and we will be happy to help.

To run a MTR from an Ubuntu device, you first need to install the MTR package provided by Linux. If you have not installed MTR on your Ubuntu device before, run the following install commands:

Command 1
Command Description	Issue the following command to update the list of available packages.
Command	apt-get update -y
Image of Command being Run
Image of a Successful Result of Command
Command 2
Command Description	Issue the following command to start the install of MTR
Command	apt install mtr
Image of Command being Run
Image of a Successful Result of Command	As you can see in my example above, the MTR package has been replaced by the updated version MTR-Tiny package.

Once you have installed the MTR package, you can now issue a command to begin the MTR.

When issuing the below command, you will need to enter the IP address of the destination device. What the destination device is depends on what problem you are experiencing and trying to diagnose. If you are experiencing packet loss or if there is a routing issue between two devices, you will need enter the IP address of the other device. In my example, I am running a MTR from one of my servers to another, as I believe that there may be packet loss between the two servers.

Command 3
Command Description	Issue the following command to start the MTR, running a trace the destination IP address.
Command	mtr [insert destination IP address]
Image of Command being Run
Image of a Successful Result of Command

The MTR will now start and it should send roughly one packet per second. You can see how many packets have been sent from the host you are running the MTR on in the top row, in-line with the host’s IP, under the sent column.

Once the MTR has sent 1000 packets, you can use the results to identify where the issue lies. We require at least 1000 packets to be sent to make sure that the results are accurate.

If you are checking for packet loss, you can use the Loss% column to identify the percentage of packets lost within this hop, and you can use the Host column in line with the Loss% column to identify where the packet loss began. If you are checking for a routing issue, you can use the Host column to identify the path the route has taken.

Once the MTR has sent 1000 packets, you should copy the entire MTR table and paste it into a text document. If you do identify an issue, you will need these results later. To copy the table from a putty window, you simply need highlight the whole table. You can see an example of a copied table below.

		Packets		Pings
	Host	Loss%	Snt	Last	Avg	Best	Wrst	St	Dev
1	□8.□29.□50.□□	0.00%	1100	0.5	0.6	0.5	0.8	0
2	e1-46.lea302.1ue.dc5.as20860.net	0.00%	1100	0.6	0.6	0.5	0.7	0
	e1-45.lea302.1ue.dc5.as20860.net
3	e3-21.bor2.dc5.as20860.net	0.00%	1100	0.7	0.7	0.7	0.9	0
4	po2-30.net1.north.dc5.as20860.net	0.00%	1100	0.4	0.3	0.3	0.4	0
5	□7.□17.□11.□□	0.00%	1100	1.2	1.4	0.9	2.4	0.3
6	□3.□42.□28.□□	0.00%	1100	0.3	0.4	0.3	0.5	0

Once you have finished running the MTR on this device and copied the table, press Q to stop the MTR.

You should now run the MTR on the destination device, to the device you just ran the MTR on above, then copy the table (reverse direction). If you do discover any issues that lie within our network, please supply both MTRs in a support ticket and our team will investigate this issue.

If you have any more questions about MTRs, please look through our FAQ section, or raise a support ticket and we will be happy to help.

To run a MTR from a Debian device, you first need to install the MTR package provided by Linux. If you have not installed MTR on your Debian device before, run the following install commands:

Command 1
Command Description	Issue the following command to update the list of available packages.
Command	apt-get update
Image of Command being Run
Image of a Successful Result of Command
Command 2
Command Description	Run the following command to install the MTR package.
Command	apt-get install mtr
Image of Command being Run
Image of a Successful Result of Command
Command 3
Command Description	Press Y and then enter to confirm you want to download the software.
Command	y
Image of Command being Run
Image of a Successful Result of Command

Once you have installed the MTR package, you can now issue a command to begin the MTR.

When issuing the below command, you will need to enter the IP address of the destination device. What the destination device is depends on what problem you are experiencing and trying to diagnose. If you are experiencing packet loss or if there is a routing issue between two devices, you will need enter the IP address of the other device. In my example, I am running a MTR from one of my servers to another, as I believe that there may be packet loss between the two servers.

Command 4
Command Description	Issue the following command to start the MTR, running a trace the destination IP address.
Command	mtr [insert destination IP address]
Image of Command being Run
Image of a Successful Result of Command

The MTR will now have started and it should send roughly one packet per second. You can see how many packets have been sent from the host you are running the MTR on in the top row, in-line with the host’s IP, under the sent column.

Once the MTR has sent 1000 packets, you can use the results to identify where the issue lies. We require at least 1000 packets to be sent to make sure the results are accurate.

If you are checking for packet loss, you can use the Loss% column to identify the percentage of packets lost within this hop, and you can use the Host column in line with the Loss% column to identify where the packet loss began. If you are checking for a routing issue, you can use the Host column to identify the path the route has taken.

Once the MTR has sent 1000 packets, you should copy the entire MTR table and paste it into a text document. If you do identify an issue, you will need these results later. To copy the table from a putty window, you simply need highlight the whole table. You can see an example of a copied table below.

		Packets		Pings
	Host	Loss%	Snt	Last	Avg	Best	Wrst	St	Dev
1	□8.□29.□50.□□	0.00%	1100	0.5	0.6	0.5	0.8	0
2	e1-46.lea302.1ue.dc5.as20860.net	0.00%	1100	0.6	0.6	0.5	0.7	0
	e1-45.lea302.1ue.dc5.as20860.net
3	e3-21.bor2.dc5.as20860.net	0.00%	1100	0.7	0.7	0.7	0.9	0
4	po2-30.net1.north.dc5.as20860.net	0.00%	1100	0.4	0.3	0.3	0.4	0
5	□7.□17.□11.□□	0.00%	1100	1.2	1.4	0.9	2.4	0.3
6	□3.□42.□28.□□	0.00%	1100	0.3	0.4	0.3	0.5	0

Once you have finished running the MTR on this device and copied the table, press Q to stop the MTR.

You should now run the MTR on the destination device, to the device you just ran the MTR on above, then copy the table. If you do discover any issues that lie within our network, please supply both MTRs in a support ticket along with details of the issue you are facing and our team will investigate this issue.

If you have any more questions about MTRs, please look through our FAQ section, or raise a support ticket and we will be happy to help.

To run a MTR on a Windows device, you will first need to download a Windows compatible program, capable of running an MTR. The most common piece of software used to run an MTR on a Windows device is WinMTR; you can download this software from WinMTR’s website:

http://winmtr.net/download-winmtr/

Once you are on the WinMTR website, press download on the appropriate version of the software. A .zip file will now download; you will then need to extract all the files from this zip folder. Then locate the appropriate version of the software’s file (x32 Vs x64) and run the WinMTR.exe file. The WinMTR program will now launch.

You now need to enter the IP address of the destination device in the Host text box. Once you have entered the destination device’s IP address, press Start. What the destination device is depends on what problem you are experiencing and trying to diagnose. If you are experiencing packet loss or if there is a routing issue between two devices, you will need enter the IP address of the other device. In my example, I am running a MTR from one of my servers to another, as I believe that there may be packet loss between the two servers.

The MTR should send roughly one packet per second. You can see how many packets have been sent from the host you are running the MTR on in the top row, in-line with the host’s IP, under the sent column.

Once the MTR has sent 1000 packets, you can use the results to identify where the issue lies. We require at least 1000 packets to be sent to make sure the result are accurate.

If you are checking for packet loss, you can use the Loss% column to identify the percentage of packets lost within this hop, and you can use the Host column in line with the Loss% column to identify where the packet loss began. If you are checking for a routing issue, you can use the Host column to identify the path the route has taken.

Once the MTR has sent 1000 packets, you should copy the entire MTR table and paste it into a word document. If you do identify an issue, you will need these results later. To copy the table, simply press the Copy Text to clipboard button.

You can see an example of a copied table below.

|	WinMTR statistics	|
|	Host	-	%	|	Sent	|	Recv	|	Best	|	Avrg	|	Wrst	|	Last	|
|																|
|	□0. □4. □. □□□	-	0	|	1137	|	1137	|	0	|	4	|	152	|	0	|
|	593.core2.thn.as20860.net	-	0	|	1136	|	1136	|	1	|	7	|	287	|	9	|
|	300.asr2.dc2.as20860.net	-	0	|	1137	|	1137	|	1	|	2	|	59	|	2	|
|	□0. □53. □. □□	-	0	|	1137	|	1137	|	1	|	7	|	238	|	1	|
|	542.core1.dc2.as20860.net	-	2	|	1086	|	1073	|	1	|	9	|	344	|	2	|
|	303.asr2.dc2.as20860.net	-	0	|	1137	|	1137	|	2	|	4	|	74	|	3	|
|	300.core2.thn.as20860.net	-	0	|	1137	|	1137	|	2	|	10	|	286	|	4	|
|	593.net1.north.dc5.as20860.net	-	1	|	1132	|	1131	|	2	|	9	|	145	|	2	|
|	po2-30.bor2.dc5.as20860.net	-	0	|	1137	|	1137	|	2	|	4	|	78	|	3	|
|	e1-42.lea102.1uf.dc5.as20860.net	-	0	|	1137	|	1137	|	2	|	4	|	76	|	3	|
|	□8. □29. □18. □□	-	0	|	1137	|	1137	|	2	|	4	|	76	|	3	|
|	□8. □29. □18. □□	-	0	|	1137	|	1137	|	2	|	4	|	78	|	3	|

Once you have finished running the MTR on this device and copied the table, press the Stop button or simply close the window.

You should now run the MTR on the destination device, to the device you just ran the MTR on above, then copy the table (reverse direction). If you do discover any issues that lie within our network, please supply both MTRs in a support ticket and our team will investigate this issue.

If you have any more questions about MTRs, please look through our FAQ section, or raise a support ticket and we will be happy to help.

A broadcast storm is when we have an excessive amount of broadcast traffic on the network then all devices within the broadcast domain will suffer. The switch has to flood all broadcast frames to interfaces in the same VLAN, hosts within the VLAN might have to process these frames (ARP requests for example).

Too much broadcast traffic could be caused by malicious software but also by a malfunctioning NIC. To protect ourselves against this, Cisco switches offer the storm-control feature which automatically disables the switch port to protect against the switch CPU overheating and potentially taking down other devices in the rack. We configure a threshold on interfaces to set a limit to the number of broadcasts, multicast or unknown unicast traffic and an action when the threshold is exceeded.

As long as limits have been set and adhered, you shouldn’t get any issues with the port dropping.