Hello guys this article will give you information related to problems which we face in networking. and it will also provide information related to the solutions we need to use.
So there are some examples and some assumptions. according to a problem encounters during the assumption we need to apply a solution for the problem by using some Linux commands.
- Server Down Problem
I. Server A Can’t Talk to Server B
Let's understand this with the help of one example,
There are two servers dev1 and web1. The problem is dev1 can’t able to access the web service (port 80) on a second server web1
Now we need to understand the solution to this problem.
There are multiple steps involved to solve this issue. Let's look at some important steps we need to perform if we encounter a problem.
Client or Server Problem
The first cause of this problem ( server dev1 not able to access web1) is there might be a problem with the client or server.
So let's check whether the problem is with the Client or Server
To check this consider the second server dev2 on the same network as dev1.
If dev2 can’t access web1 then you know the problem is more likely on web1, or on the network between dev1, dev2, and web1.
If dev2 can access web1, then you know the problem is more likely on dev1.
Let's assume here dev2 can access web1, so we need to focus on troubleshooting of dev1.
So let's check some steps to solve the issues of dev1…..
A. Is It Plugged In?
Firstly we need to check the client’s connection with the network is healthy or not?
To check this we can use the ethtool program(installed via the ethtool package) to verify that our link is up. Just run the below command
If you see Link detected: yes means dev1 is physically connected. Since it is physically connected, we can move on.
B. Is the Interface Up?
Once you have established that you are physically connected to the network, the next step is to confirm that the network interface is configured correctly on your host.
For checking this use the ifconfig command
Now you can see our host has an IP address (10.1.1.7) and subnet mask (255.255.255.0) configured. This thing you need to check.
If the interface is not configured, try running ifup eth0 and then run ifconfig again to see if the interface comes up.
If the settings are wrong or the interface won’t come up, inspect /etc/ sysconfi g/ network_scripts/ifcfg-<interface> on Red Hat-based systems.
In this case, our interface is up. so let's check further steps
C. Is It on the Local Network?
Once we check our interface next step is to check whether the gateway has set up or not?
For this use route command
Here you can see that our default gateway is configured properly. So we need to check the next step.
Once you have identified the gateway, use the ping command to confirm that you can communicate with the gateway.
If ping works fine means we can communicate successfully.
If you couldn’t ping the gateway, then it could mean that your gateway is blocking ICMP packets.
In our case ping is successful so let's check further steps.
D. Is DNS Working?
Once we checked pinging to the gateway is successful. then next thing is to check whether DNS is functioning or not.
nslookup and dig tools can be used to troubleshoot DNS issues
use nslookup command
The web1 host expands into web1.example.net and resolves to the address 10.1.2.5. so make sure that this IP matches the IP that web1 is supposed to have.
E. Can we Route to Local Host?
After checking DNS functionality ,you must test whether you can route to the remote host.
Assuming ICMP is enabled on your network, one quick test might be to ping web1. After this if you can ping to host then check whether the remote port is open.
If you can’t ping web1, try to identify another host on that network and see if you can ping it.
If you are able to ping, then it’s possible web1 is down or blocking your requests
If you can’t ping any hosts on the remote network, means packets aren’t being routed correctly.
For testing this we need to use traceroute command
Once you provide traceroute with a host, it will test each hop between you and the host
For example, a successful traceroute between dev1 and web1 would look like this:
Here you can see that packets go from dev1 to its gateway (10.1.1.1), and then the next hop is web1
If you can’t ping web1, your output would look more like the following:
If you see asterisks in your output, means the problem is on your gateway
Note: If there is a problem related to ICMP blocking, you just need to install the tcptraceroute package and then run the same commands as for traceroute, only substitute tcptraceroute for traceroute.
F. Is the Remote Port Open?
So you can route to the machine but you still can’t access the web server on port 80. The next test is to see whether the port is even open.
use the following way to test this
If you see Connection refused, then either the port is down (likely Apache isn’t running on the remote host or isn’t listening on that port) or the firewall is blocking your access.
If telnet is working properly then there is no networking issue.
If the web service isn’t working then, you need to check your Apache configuration on web1
Instead of using telnet, we can also use nmap to test ports because it can often detect firewalls.
Normally when a port is actually down, nmap will report it as closed.
Here it reported it as filtered. which means some firewall is dropping the packets. This means you need to investigate any firewall rules on the gateway (10.1.1.1) and on web1 itself to see if port 80 is being blocked.
G. Test For Listening Ports
One of the first things you should do on web1 is test whether port 80 is listening.
The netstat -lnp command will list all ports that are listening along with the process that has the port open.
Here the 0.0.0.0:80 tells that the host is listening on all of its IPs for port 80 traffic.
Here you can see that Apache is running and listening. so we need to check the next step.
H. Firewall Rules
If the process is running and listening on port 80, web1 may have some kind of firewall in place.
Use the iptables command to list all of your firewall rules.
If your firewall is disabled, your output will look like this:
Notice that the default policy is set to ACCEPT.
It’s possible, that your firewall is set to drop all packets by default, even if it doesn’t list any rules.
In that case, you will see output more like the following:
if you had a firewall rule that blocked port 80, it might look like this:
so you need to modify the firewall rules to allow port 80 traffic from the host.
This are some issues we might face related to the client and server. So we need to analyze it step by step.
