OSI Model
Network monitoring and networking tools are essential when we develop, more than anything, because there may be a problem with the network, making it difficult for the component to function properly. The objective of this blog is to demonstrate some problems that may arise and how to solve them. We know well that the OSI model is a reference model for network protocols. It consists of 7 different layers. Previously, you would have to know each layer’s logic and how it works to understand what this blog is about.
I leave you an image to refresh the OSI model’s operation and the logic that works with HTTP requests to the browser and the different abstraction layers.
What are networking tools?
A networking tool is essential to ensure the functioning of computer systems and to prevent network failures. It also helps us optimize the network since it provides us with detailed information on broadband and other network resources.
Some examples are SNMP, PING, WIRESHARK, TRACEROUTE. They change according to operating systems.
Demo
The optimal way to perform network monitoring is through the layers of the OSI model. This demo will show how to monitor network problems from layer 1 (physical) to layer 4 (transport).
The demo’s objective is to copy a file from a remote directory with some obstacles on the different layers.
The network is unreachable. As index, we always stop at layer 3, the network layer, and from there, we can know if the problem is down physically or in the transport of data. When we cannot access a server, the best way to test the connection is to ping. Ping is a layer 3 monitoring tool.
Ping verifies end-to-end IP connectivity between the source system, us, and our destination (192.168.1.1) and verifies Layer 3 functionality, and we certainly don’t have it.
We can review our iIProutes, to know if the destination address has a route.
And as you can see, we don’t even have a network route that reaches 192.168.1.1. This can lead to the belief that there is a bad configuration in our network. We verify with iIPaddr:
It is seen that in the enp0s3 interface, we do not have an IP address, and the status is down; therefore, we do not have a physical connection. We go down to layer 2 and check if we have a mapping from layer 2 to layer 3. This is done with arp:
It is empty. So we know that we don’t even have connectivity. So we should look at a lower layer, layer 1.
There is the ethtool command and then the network interface, in this case, enp0s3.
At the bottom, you can see that it does not detect a link. We do not have a physical connection.
That can be several things like not having the ethernet cable connected. It already depends on the physical. If we do an IPaddr again, the state will change to UP, and it will be seen that it has an IP address.
We can test by pinging if we can now.
The network is still unreachable, but we already know that we have connectivity from layer 1, so let’s move on to review data link layer 2
We still don’t have connectivity in layer 2. We are going to check our routes.
Now we have a route that says 192.168.1.96/29, and our IP configuration at the output of the IP addr command above is 192.168.1.100, the configured IP address (192.168.1.96) and the transmission address (192.168.1.103) stores us In the address space of 93 to 103, it is seen that the netmask is incorrect and / 29 should be / 24. Therefore we proceed to change it in the sysconfig / network-scripts / ifcfg-enp0s3. If we do an IP route, the output should be:
The same would change on the IP adrr screen, the mask would change to / 24, and the transmission address would change from 103 to 255, so now it would cover all the iIPaddresses from 0 to 255. And then you could ping.
Therefore we solved problems that came from layers 1 and 2 to establish a connection in layer 3.
If you’re ready for a challenging career in the telecommunications industry, check out our open positions.
