Resolve IP address conflicts caused by vro software bugs

For network administrators who have been dealing with the network all day, network failures are almost inevitable! However, network faults are generally limited to failures in accessing the Internet, frequent disconnection, or slow access. However, the causes of network faults are various, which are caused by manual operations, the status of the network device may also be caused by external interference. However, in the process of actually solving network faults, we sometimes find that network faults cannot be eliminated after the various possible factors listed above are eliminated. What is the problem?

In fact, the factors listed above only have a direct impact on network faults, and some small factors that are not easy to attract attention will indirectly affect network faults, for example, detailed factors such as Power grounding, dust in the air, network application software, and operating system stability may also cause network faults, it is often difficult to troubleshoot the fault caused by these details. After all, these details are easily overlooked by network administrators. No, the following network fault is caused by a software BUG in the vro. I believe you will be inspired by the troubleshooting process below!

Fault symptom

A lan is directly connected to the Internet by renting a 2 m Fiber Channel from the local telecommunications department. All workstations in the LAN are connected to a 48-port switch, the vswitch is directly connected to a TP-LINK-type Broadband Router. In this router, the firewall function, DHCP server function and static address group function are enabled. There is also a server storing important data in the LAN. To protect the security of the server, the organization has also installed the Norton Firewall on the server. The firewall has been set to the server working mode by the author, all workstations in the LAN can normally access important information on the server.

However, in the past few days, a colleague of the author called for help and said that the workstation he used could not access the server. After receiving a call from a colleague, I subconsciously tried to access the server in my workstation to confirm whether the server encountered a fault, but the result of the attempt told me, the server is working normally, because my workstation can smoothly access the content on the server. Later, I came to the server and wanted to find some clues from the server log file. However, when I opened the server computer display screen, I saw an error message indicating IP address conflict on the System screen. When I saw this prompt, I almost concluded that my colleague's workstation must have used an IP address that is in conflict with the server; so I quickly came to the faulty workstation, opened the TCP/IP attribute setting window of the workstation, and assigned another IP address to the workstation, I thought that changing the IP address could solve the problem that the workstation could not access the server. However, when I re-accessed the connection, I found that the server was still inaccessible. Is there a problem with the network connection between workstation and server of a colleague? I was not at ease, so I opened the workstation's network neighbor window and tried to access other workstations in the LAN through the window. As a result, I found that the faulty workstation could access other workstations in the LAN smoothly, but you cannot access the server.

Fault Analysis

To test whether there is a line fault between the faulty workstation and the server, I first run the "Ping" command in the faulty workstation. The result shows that the server cannot be pinged normally, later, I run the "Ping" command in the server system, but this time I found that the server can successfully Ping the faulty workstation, obviously, the line connection between the server and the faulty workstation is normal. Will the network card equipment in the faulty workstation be unstable? Now, I open the Device Manager window in the fault workstation, find the target Nic device, and right-click the device icon, execute the "Disable" command (as shown in 1) from the shortcut menu, and then re-execute the "enable" command in the shortcut menu. When the NIC device is started, I suddenly saw that the IP address of the workstation was dynamically obtained. At this time, I thought that the DHCP service function has been enabled in the Broadband Router. Is it because the DHCP server is not running normally that the faulty workstation cannot obtain a stable IP address? To achieve this, I log on to the backend management interface of the Broadband Router, temporarily disable the DHCP server, save the backend parameters of the router, and restart the router, finally, a static IP address was assigned to the faulty workstation, but such a series of operations still failed, and the workstation of my colleagues still could not access the LAN server. Here, the author simply enters the background management interface of the Broadband Router, deletes all static address groups and MAC address records, and then restarts the Broadband Router, however, the final result is still unable to access the server.

 

Figure 1
In desperation, I log on to the vswitch background management interface and run the "Ping" command on the interface to test whether the server system and the vswitch are normal, the results showed that the server could not be pinged either. Later, I tried to Ping the server from other workstations and found that all workstations in the LAN could not be pinged to the server, however, other workstations can access the content on the server.

Troubleshooting

After the above test operation, I believe that all workstations in the LAN cannot Ping the server. It is likely that the firewall in the server has disabled the Ping test function, as a result, I quickly logged on to the server system as a system administrator, modified the firewall's working mode from the server mode to the normal mode, and adjusted some filtering rules in the firewall, then restart the server system. After the server system is successfully restarted, I tried to run the "Ping" command on the backend management interface of the switch to test whether the server can be pinged normally, the results show that the server can be pinged normally this time, And when I try to Ping the server from other workstations in the LAN, I also find that the server can be pinged normally now. Finally, I re-enabled the DHCP service function in the router, and then came to the faulty workstation to enter the wks TCP/IP attribute settings window, open the IP Address Settings page shown in 2, select the "automatically obtain IP Address" option and click "OK" to apply for an IP address from the DHCP server, I tried the server access operation again. It is gratifying that the server was finally accessible, and the failure of the server access was solved successfully!

 

 

Figure 2

Fault Summary

Although the fault has been solved, I am puzzled why the faulty workstation cannot access the server while other workstations in the LAN can access the server? After modifying the firewall parameters of the server, why can the faulty workstation access the server normally? In fact, the faulty workstation cannot access the server because the IP address obtained by the faulty workstation conflicts with the IP address of the server system, this is the cause of the address conflict prompt on the server system screen. The Faulty workstation obtains the IP address from the DHCP server, therefore, address conflicts only indicate a software BUG in the Broadband Router. As a result, the DHCP server assigns an IP address that is not in the IP address pool of the workstation. Once the IP address of the faulty workstation conflicts with the IP address of the server, the firewall on the server will automatically prohibit the faulty workstation from continuing to access the server. Therefore, when I change the working mode of the server firewall to the normal mode, after the server system is restarted, the firewall in the server will automatically cancel the access to the faulty workstation, so that after the firewall parameters are modified, the faulty workstation can naturally access the content on the server.

Summing up the troubleshooting process above, I found that at first, I had to perform targeted troubleshooting according to the address conflict prompt on the server screen, and combined with the specific network work environment, maybe we will be able to avoid a lot of detours in the troubleshooting process!