One of the most important subsystems responsible for the connection of any server with the outside world is the network one. Requests from remote systems are received through network interfaces and responses are sent through the same interfaces, which allows you to establish communication and provide/receive services. In this regard, it is especially important to be able to diagnose and monitor the network at least at a basic level in order to identify problems and make adjustments to the configuration if necessary.
For operating systems of the Linux family, many utilities have been written to help in diagnostics and monitoring. Let’s get acquainted with the most commonly used of them.
Network connectivity diagnostics (ping, arp, traceroute)
In this article, we will rely on the use of the IP version 4 protocol. According to the standards that determine the operation of this protocol, each device connected to the network must have at least an IP address and a subnet mask – parameters that allow you to uniquely identify a device within a particular network . In such a configuration, a device can exchange network packets with other devices within the same logical network. If we add the default gateway address to this set of parameters, our server will be able to communicate with hosts that are outside the local address space.
In case of any network problems, first of all, we check if the network interface settings have gone wrong. For example, the ip addr or ifconfig commands will display the IP address and netmask:
The output of the command shows a list of network interfaces recognized by the operating system. The lo interface is a pseudo-interface (loopback). It is not used in real interactions with remote hosts, but the interface named ens 192 is what we need (the naming of network interfaces differs in different branches and versions of Linux OS). The IP address and netmask assigned to this interface are specified in the inet field – /24 after the address denotes the 24-bit mask 255.255.255.0.
Now let’s check if the default gateway is specified. The ip route or route commands will show the available routes:
In the routing table, we see that there is a default route (denoted either by the default keyword or by the address 0.0.0.0 ). All packets destined for external networks must be directed to the address specified in the route through the designated network interface.
If there are errors in the interface settings, they need to be corrected – other articles will help with this, for Ubuntu 18.04 or CentOS . If everything is correct, we proceed to diagnostics using the ping utility. This command sends special network packets to a remote IP address (ICMP Request) and waits for response packets (ICMP Reply). In this way, you can check network connectivity – whether network packets are routed between the source and destination IP addresses.
The syntax for the ping IP /option name command is :
In this case, we see that both network packets sent to the address of our default gateway received responses, there are no losses. This means that at the local network level everything is in order with connectivity. In addition to the number of received/lost network packets, we can see the time it took to complete the request and response – the RTT (Round Trip Time) parameter. This parameter can be very important in diagnosing problems related to link instability and link speed.
Frequently used options:
- ping – c number – specify the number of packets that will be sent to the destination (by default, packets are sent until the user interrupts the command execution. This mode can be used to check the stability of the network connection. If the RTT parameter changes greatly during the test, means there is a problem somewhere along the route);
- ping – s count – Specify the size of the packet in bytes. By default, the check is performed in small batches. To test network devices with larger packets, you can use this option;
- ping – I interface – specify the network interface from which the request will be sent (relevant if there are several network interfaces and it is necessary to check the passage of packets along a specific network route).
If, when using the ping command, packets from the gateway (or another host located on the same local network as the sending server) do not receive a response, it is worth checking the network connectivity at the Ethernet level. Here, the so-called MAC addresses of network interfaces are used for communication between devices. The ARP (Address Resolution Protocol) protocol is responsible for resolving Ethernet addresses, and using the utility of the same name, we can check the correct operation at this level. Run the arp –n command and check the result:
The command will print a list of IP addresses (because the -n argument was used ), and their corresponding MAC addresses of hosts that are on the same network as our server. If this list contains the IP that we are trying to ping and the corresponding MAC, then the network is working and, perhaps, the ICMP packets that the ping command uses are simply blocked by the firewall (either from the sender or the receiver). Read more about managing firewall rules here and here .
Frequently used options:
- arp – n – output the contents of the local arp cache in numeric format. Without this option, an attempt will be made to resolve symbolic hostnames;
- arp – d address – remove the specified address from the cache. This can be useful for checking if the address is resolved correctly. To make sure that the address is currently being resolved correctly, you can remove it from the cache and run ping again. If everything works correctly, the address will appear in the cache again.
If all the previous steps are completed correctly, we check the operation of the router – we launch ping to a server outside our network, for example, 8.8.8.8 (DNS service from Google). If everything works correctly, we get the result:
In case of problems at this step, the traceroute utility can help us, which, using the same request and response logic, helps to see the route along which network packets are moving. Run traceroute 8.8.8.8 –n and examine the output of the program:
The first router on the packet’s path should be our local default gateway. If the packet does not go beyond it, there may be a problem in the router configuration and you need to deal with it. If packets are lost on further steps, there may be a problem in the intermediate network. Or, perhaps, intermediate routers do not send response packets. In this case, you can switch to using a different protocol in traceroute.
Frequently used options:
- traceroute – n – output the result in numerical format instead of the symbolic names of intermediate nodes;
- traceroute – I – use the ICMP protocol when tracing the route. The default is UDP datagrams;
- traceroute – s address – specify the source address for the outgoing network packet;
- traceroute – i interface – specify the network interface from which packets will be sent.
Diagnostics resolved names (nslookup, dig)
Having dealt with network connectivity and routing, we come to the next stage – domain name resolution. In most cases, when working with remote services, we do not use IP addresses, but indicate the domain names of remote resources. The DNS service is responsible for translating symbolic names into IP addresses – this is a network of servers that contain up-to-date information about the correspondence of names and IPs within the domain zones trusted to them.
The easiest way to check if name resolution is working is to run the ping utility with a domain name instead of an IP address (for example, ping ya.ru). If the response packets from the remote server come, then everything is working as it should. Otherwise, you need to check whether the DNS server is registered in the network settings and whether you can get a response from it.
The methods of finding out which DNS server our server is using differ depending on the Linux OS version and distribution used. For example, if the OS is using Network Manager to manage network interfaces (CentOS, RedHat, etc.), the output of the nmcli command may help :
In the network interface settings, in the DNS configuration section, we will see the server IP address. On Ubuntu 18.04 and above using Netplan, use the systemd – resolve — status command :
The server used will also be specified in the interface settings, in the DNS Servers section. Older versions of Ubuntu will need to check the contents of the / etc / resolve files . conf and / etc / network / interfaces . If the server is not listed, use the article for Ubuntu 18.04 or CentOS to adjust the settings.
The nslookup or dig utilities will help us check the operation of the name resolution service. Functionally, they are almost identical: the G-output of the dig utility contains more diagnostic information and is flexibly adjustable, but this is far from always necessary. Therefore, use the utility that is convenient in a particular situation. If these commands are not available, you will need to deliver packages to CentOS/RedHat:
yum install bind-utils
для Debian/Ubuntu:
sudo apt install dnsutils
After successful installation, we will make test queries:
dig ya.ru
In the Answer Section , we see the answer from the DNS server – the IP address for the A-record with the domain name ya.ru. Name resolution works correctly:
nslookup ya.ru
A similar query by the nslookup utility produces a more compact output, but all the information we need now is present in it.
What to do if there is no IP address in the response? The DNS server may not be available. For verification, you can send a test query to another DNS server. Both utilities allow you to do this. Let’s send a test request to the Google DNS server:
dig @8.8.8.8 ya.runslookup ya.ru 8.8.8.8
If the names are resolved correctly by the public DNS server, but not by default in the OS, there is probably a problem with this DNS server. A workaround for this problem can be to use a public DNS server as a server for name resolution in the operating system. In the event that name resolution does not work either through the local or through the public DNS server, it is worth checking whether the firewall rules block sending TCP / UDP packets to the remote port 53 (it is on this port that DNS servers receive requests).
Frequently used options:
- nslookup server name – resolve a domain name using an alternative server;
- nslookup – type = type name – get a record of the specified type for a domain name (for example, nslookup -type=mx ya.ru – get MX records for the ya.ru domain);
- dig @server name – resolve a domain name using an alternate server;
- dig name type – get a record of the specified type for a domain name (for example, dig ya.ru mx – get MX records for the ya.ru domain).
As usual, the full set of options and parameters for these utilities can be found in the built-in help of the operating system using the man command .
Welcome to the world of DomainRooster, where roosters (and hens) rule the roost! We're a one-stop shop for all your entrepreneurial needs, bringing together domain names and website hosting, and all the tools you need to bring your ideas to life. With our help, you'll soar to new heights and hatch great success. Think of us as your trusty sidekick, always there to lend a wing and help you navigate the sometimes-complex world of domain names and web hosting. Our team of roosters are experts in their fields and are always on hand to answer any questions and provide guidance. So why wait? Sign up today and join the ranks of the world's greatest entrepreneurs. With DomainRooster, the sky's the limit! And remember, as the saying goes, "Successful people do what unsuccessful people are not willing to do." So don't be afraid to take that leap of faith - DomainRooster is here to help you reach for the stars. Caw on!
