Skip to main content

Network diagnostics for a dedicated server

If you encounter network problems, perform diagnostics. After diagnostics, you will be able to resolve some common issues on your own.

If the problem persists, create a ticket. In the ticket, describe the problem and attach the diagnostic results. The diagnostic method depends on the problem you have encountered.

Network issues and diagnostic methods

Perform a route trace

Perform a route trace if you encounter:

  • low connection speed;
  • high network latency;
  • connection losses;
  • packet loss during data transmission;
  • server unavailability from a specific external network.

Traceroute must be performed in two directions—from the dedicated server to a point outside the Servercore infrastructure and back. For this, you will need an external server—any server with a public IP address and internet access that is located outside the Servercore infrastructure.

We recommend performing a traceroute using the mtr (WinMTR for Windows) utility. The utility allows you to track the full path and traffic latency, and find out at which stage of the route delays or packet loss occur.

  1. Run a trace from the dedicated server to an external server.
  2. Run a trace from an external server to the dedicated server.

1. Run a trace from the dedicated server to an external server

  1. Connect to the server via SSH or a KVM console.

  2. Install the mtr utility on the dedicated server. Learn more on GitHub mtr.

  3. Optional: prepare the dedicated server for tracing — turn off utilities and applications that might affect the trace result:

    • OS firewall rules;
    • application-layer (L7, application layer) applications — web servers, mail servers, file servers, name servers, peer-to-peer network clients and servers, etc.
  4. Run a trace to the external server address:

    mtr -b <remote_ip_address>

    Specify <remote_ip_address> — the IP address of the external server.

  5. Wait for the utility to complete the trace and display information about the route and latency.

  6. Stop the trace:

    q

2. Run a trace from an external server to the dedicated server

  1. Install the utility on the external server depending on the OS used:

    • for Linux — mtr, more details on GitHub mtr;
    • for Windows — WinMTR.
  2. Optional: prepare the external server for tracing — turn off utilities and applications that might affect the trace result:

    • OS firewall rules;
    • application-layer (L7) applications — web servers, mail servers, file servers, name servers, peer-to-peer network clients and servers, etc.
  3. Run a traceroute to the dedicated server's IP address. You can find the dedicated server's IP address in the control panel: in the top menu, click ProductsDedicated ServersServers → server page → tab Operating System → field IP.

Measure data transfer speed

If you encounter issues with low data transfer speed, measure the connection speed.

Measure data transfer speed in two directions—from the dedicated server to a point outside the Servercore infrastructure and back. For this, you will need an external server—any server with a public IP address and internet access that is located outside the Servercore infrastructure.

We recommend using the iperf3 utility to measure speed.

  1. Prepare the dedicated server for speed measurement.
  2. Measure the data transfer speed.

1. Prepare the dedicated server for speed measurement

  1. Boot the server into recovery and diagnostic mode to exclude the influence of OS processes on diagnostic results.

  2. Connect to the server via SSH or a KVM console.

  3. Install the iperf3 utility on the dedicated server, see the iPerf documentation for more details.

  4. Run the iperf3 utility. The utility must run until data transfer speed measurement is complete.

    iperf3 -s

2. Measure data transfer speed

  1. Open the CLI on the external server.

  2. Install the iperf3 utility on the external server, see the iPerf documentation for more details.

  3. Measure the speed from the external server to the dedicated server. The command will perform a measurement with 20 parallel streams to maximize the link load.

    iperf3 -c <ip_address> -P20 -t60 -i10

    Specify <ip_address> — the public IP address of the dedicated server. You can view it in the control panel: in the top menu, click ProductsDedicated ServersServers → server page → tab Operating System → field IP.

  4. Perform a measurement in the reverse direction — add the -R key to the command:

    iperf3 -c <ip_address> -P20 -t60 -i10 -R

    Specify <ip_address> — the public IP address of the dedicated server. You can view it in the control panel: in the top menu, click ProductsDedicated ServersServers → server page → tab Operating System → field IP.

Check the status of network interfaces

Check the status of network interfaces if the server has no internet access.

  1. Connect to the server via SSH or a KVM console.

  2. Check the status of the network interfaces:

    ip a

    Information about the network interfaces will appear in the response. For example:

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
    valid_lft forever preferred_lft forever

    2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 1c:1b:0d:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 brd 192.168.1.255 scope global dynamic enp0s1
    valid_lft 604675sec preferred_lft 604675sec
    inet6 fe80::1234:abcd:5678:9ef0/64 scope link
    valid_lft forever preferred_lft forever

    3: enp0s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 1c:1b:0d:65:43:21 brd ff:ff:ff:ff:ff:ff
    inet 203.0.113.10/24 brd 203.0.113.255 scope global dynamic enp0s2
    valid_lft 604675sec preferred_lft 604675sec
    inet6 fe80::abcd:1234:5678:9ef0/64 scope link
    valid_lft forever preferred_lft forever

    Where:

    • enp0s1 — the name of the network interface on the local port;
    • enp0s2 — the name of the network interface on the internet port;
    • UP — the status of the network interface.
  3. If the network interface is in the DOWN status, enable it. Learn more in the IP Command Set instruction in the iproute2 documentation—this is a package of utilities that includes the ip utility.

    ip link set dev <eth_name> up

    Specify <eth_name> — the name of the network interface you obtained in step 2.

Check routing settings

Check routing settings if:

  • there is no internet access on the server;
  • the server is unreachable over the network;
  • the server is unreachable from a specific external network.
  1. Connect to the server via SSH or a KVM console.

  2. Check routing settings:

    ip r

    A route table will appear in the response. For example:

    default via 203.0.113.1 dev enp0s2 proto dhcp metric 100
    203.0.113.0/24 dev enp0s2 proto kernel scope link src 203.0.113.10 metric 100
    192.168.1.0/24 dev enp0s1 proto kernel scope link src 192.168.1.100 metric 100

    Where:

    • default via 203.0.113.1 dev enp0s2 — the default route, internet traffic goes through gateway 203.0.113.1 via the enp0s2 interface;

    • 203.0.113.0/24 dev enp0s2 — the route to the public subnet 203.0.113.0/24, traffic to this subnet goes via the enp0s2 interface;

    • 192.168.1.0/24 dev enp0s1 — the route to the private subnet 192.168.1.0/24, traffic to this subnet goes via the enp0s1 interface.

Collect a network traffic dump

If the server is unreachable from a specific external network or you observe short-term connection losses, collect a network traffic dump.

A network traffic dump is a process of recording and saving the network traffic that passes through a network or device. The dump contains information about network protocols, transmitted packets, their content, and data sources and recipients.

  1. Connect to the server via SSH or a KVM console.

  2. Install tcpdump —a utility for capturing and analyzing network traffic. Learn more in the tcpdump documentation.

    apt update
    apt install -y tcpdump
  3. Look up the name of the network interface for which you need to record a dump; to do this, list the network interfaces:

    ip a

    Information about the network interfaces will appear in the response. For example:

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
    valid_lft forever preferred_lft forever

    2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 1c:1b:0d:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 brd 192.168.1.255 scope global dynamic enp0s31f6
    valid_lft 604675sec preferred_lft 604675sec
    inet6 fe80::1234:abcd:5678:9ef0/64 scope link
    valid_lft forever preferred_lft forever

    3: enp0s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 1c:1b:0d:65:43:21 brd ff:ff:ff:ff:ff:ff
    inet 203.0.113.10/24 brd 203.0.113.255 scope global dynamic enp0s2
    valid_lft 604675sec preferred_lft 604675sec
    inet6 fe80::abcd:1234:5678:9ef0/64 scope link
    valid_lft forever preferred_lft forever

    Where enp0s2 is the name of the network interface on the internet port.

  4. Launch tcpdump:

    sudo tcpdump -i <eth_name> -w <file_name>

    Specify:

    • <eth_name> — the name of the network interface you obtained in step 3;
    • <file_name> — the name of the file to save the network traffic capture to, for example dump.pcap.
  5. Wait for the required amount of data to be collected.

  6. Stop the recording by pressing Ctrl + C.

Restart network services

Restart network services if on the server:

  • there is no internet access;
  • alternatively, if the server is unreachable from a specific external network.
  1. Connect to the server via SSH or a KVM console.

  2. Restart network services:

    systemctl restart networking

Check filtering rules

If the server is unreachable over the network, check the firewall filtering rules in the server OS.

  1. Connect to the server via SSH or a KVM console.

  2. View the list of firewall rules:

    iptables -L -n -v

    A list of rules will appear in the response. For example:

    Chain INPUT (policy DROP 1234 packets, 98765 bytes)
    pkts bytes target prot opt in out source destination
    2045 187K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
    1087 159K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
    120 8400 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
    0 0 DROP all -- * * 192.168.1.100 0.0.0.0/0

    Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination

    Chain OUTPUT (policy ACCEPT 3456 packets, 456789 bytes)
    pkts bytes target prot opt in out source destination

    Where:

    • Chain — a list of rules for packets of a specific direction:

      • INPUT — for incoming packets;
      • FORWARD — for forwarded packets;
      • OUTPUT — for outgoing packets;
    • policy — the action of the rule, for example ACCEPT or DROP.

Scan ports

If the server is unavailable over the network or from a specific external network, scan the ports. Ports can be scanned using the nmap utility.

  1. Connect to the server via SSH or a KVM console.

  2. Install nmap; for more details, see the Linux Distributions section of the nmap documentation.

  3. Scan ports:

    nmap -p <port> <ip_address>

    Specify:

    • optional: <port> — ports separated by commas, for example 22,80,443, or a range of ports, for example 20-30;
    • <ip_address> — IP address of the dedicated server. You can view the IP address of the dedicated server in the control panel in the Servers and Hardware section → Servers → server card → field IP address.

Check host network availability and measure latency

If the server is unavailable over the network, or if you notice high network latency or packet loss, check the server's availability and measure latency using the ping utility. The ping utility is part of the standard set of network tools and is pre-installed in most operating systems.

You can perform the check using the public or private IP address of the server, or the domain name linked to the server's IP address.

To perform this check, you will need a second server from which you will conduct the test. If you are testing to a private IP address, the servers must be connected via a private network.

  1. Open CLI on the server from which you will perform the check.

  2. Perform the check:

    ping <ip_address>

    Specify <ip_address> — the IP address or domain name of the server. You can view the dedicated server's IP address in the control panel: in the top menu, click ProductsDedicated ServersServers → server page → tab Operating System → field IP.

Check access from the OS in recovery and diagnostic mode

To ensure OS settings do not affect server performance and diagnostics:

  1. Boot the server into recovery and diagnostic mode.

  2. Connect to the server via SSH or a KVM console:

    • if the server responds and you can connect to it, the problem is in the software on the server. Reboot the server to restart network services. If the issue is software-related, it will be resolved when you revert to the previous OS boot template;
    • if the server is unavailable in recovery and diagnostic mode, create a ticket with a description of the issue.