Router overload solution for virus router faults

Virus router failure router overload solution, virus router failure is a very common problem, but how can we solve the virus router failure more accurately to facilitate our use?

The topological structure of the fault location is as follows: An EnterasysSSR8000 is used as the border router, and eight virtual networks are used in the campus, each virtual network has a stack of Two-layer switches as the access device for desktops and laptops. The trunk is 1 Gigabit and MB to the desktop.

On that day, I received a call for help from a colleague, saying that his machine could not access the internet. The virtual network and network center of the colleague's host are not in the same virtual network. I heard from my colleagues that I was able to access the Internet five minutes ago. Moreover, the system installed on his machine is Windows XP. Recently, no new programs have been installed, computers have been moved, and network cables have not been pulled.

First, troubleshoot the incorrect configuration of the network client. Run the IPCONFIG command in MSDOS mode to check the IP Address Configuration of the Host: the configuration shown above is correct, and then ping your own IP address. This indicates that the IP address is effective and the NIC works properly. Run the PING command to test the connection from the local machine to the Gateway:

All the packets sent from the host to the gateway are responded, and the lines are connected. Open your browser and access the Internet normally. No problem at all. The current network is normal !? When I was wondering, I found that the Network was disconnected again! The ping packet failed to reach the gateway.

Strange, it was okay. Why can't we get through now? Is there a problem with the NIC or system? Who knows after a while, and found again. Thanks to my laptop that day, I inserted the network cable on my desktop to my computer. After configuring the IP address, I pinged the gateway, and the intermittent disconnection also occurred.

The disconnection lasted for about 50 seconds and then recovered to normal. This can basically eliminate host problems, because the probability of two unrelated hosts having the same problem is almost zero. In view of this phenomenon, I first ruled out the virus router fault of the connection cable, because the connection cable cannot be subject to this situation of intermittent disconnection, A virus router fault is most likely on a layer-2 switch at the other end of the cable.

So I came to the device room in the building and checked the switch status. This is a stack of two switches, one of which has an uplink gigabit port. I connect my laptop to one of the ports on the vswitch and then ping the gateway. Still the same virus router failure, and also found that every 4 minutes to 10 minutes, the network will be broken once, and 40 to 50 seconds after the normal recovery.

After observation, no abnormal port indicator is found, indicating that all ports of the switch are normal. Is it true that the internal system of the switch is faulty? Forget it. Simply restart the switch. After the restart, the virus router still fails. Maybe there is a problem with the switch. I was wondering if I had to switch the stack module to another switch, and my cell phone rang, another colleague told me that his machine also experienced the same fault.

The host of this colleague is in another virtual network, and there is a temporary disconnection at the same time, it is very likely that there is a problem connecting the two virtual network routers. This issue is concentrated on the vro. I hurried back to the network center, and there was no exception from the outside indicator of the router. Ping the router address on my network management machine. My network management machine is directly connected to the router's MB module.

I continued to observe for a period of time and found that every 4 minutes to 10 minutes, the indicators of all modules of the router will go off at the same time, and then the "HBT" lights on the control module will flash, then the "OK" light is on, and the lights of all modules are Online.

I will explain that the flashing "HBT" LIGHT INDICATES THAT THE vro is starting, that is, it is automatically restarting, and the network disconnection time of about 40 seconds is exactly the time required for the vro to restart. Now the problem search is over. It must have been a virus router fault on the router. Further detection is required for specific issues.

When the router is working normally, connect the comport of the notebook with the dedicated CONSOLE line of the router to establish a Super Terminal. In management mode, run the "system show bootlog" command to view the startup records of the system. It is found that the loading of each module is normal. The biggest cause of router restart is that the CPU usage reaches 100%. Run the "system show cpu-utilization" command to view CPU usage:

Sure enough, after using this command continuously, we know that the CPU usage is gradually increasing. When it reaches 95%, the router restarts automatically. It seems that the router load is too large, because normally, the CPU usage is only about 1%-6%. The CPU usage is slightly higher during peak network usage.

But what makes a router overloaded? Fortunately, I used to set a log record for the router and send the log to a log server. However, opening the logs recorded on this server does not find any useful clues. When the router load is too large, it can no longer send logs to the log server. I can only use the "system show syslog buffer" command to view the log records in the current system cache:

Obviously, "210.16.3.82" is using the ICMP protocol to launch attacks on other hosts. Based on this, the host is either poisoned or exploited by hackers. In view of the current situation analysis, there may be a host with the "Shock Wave killer" virus in the network.

The virus uses an ICMP packet of the echo type to ping the IP address segment obtained according to its own algorithm, to detect the active hosts in these IP address segments, and send a large number of loads to "aa ", the network is congested by filling in 92-byte icmp packets. Once the virus detects a surviving host, it tries to use the rpc vulnerability on port 135 and the webdav vulnerability on port 80 to launch an overflow attack.

After the overflow succeeds, the system listens to the 69TFTP professional port for file download.) A random port in the range of port and 666-765 is usually port 707. According to the virus transmission mechanism, immediately set the access control list ACL on the router) to block UDP protocol port 69 for file download), TCP port 135 Microsoft's dcom rpc port) and ICMP protocol used to discover active hosts ). The specific ACL Configuration is as follows:

Finally, apply the ACL deny-virus to uplink of the uplink interface. In this way, the "Shock Wave killer" can be blocked from the outlet of the network. To prevent the spread of hosts infected with the "Shock Wave killer" between virtual networks in the school, you must apply this ACL to the interfaces of virtual networks in the school. In this case, "system show cpu-utilization" is used to check the CPU usage, and it returns to normal again. After a period of time, there is no restart.

The router cannot automatically discard the attack packets sent by the virus, which causes the router to restart. To completely solve the problem, you must upgrade the router's IOS to use "system show version" to view the current IOS version ). I remember that two years ago, when the "red code" virus became prevalent, the routers were constantly restarted due to overload. After the upgrade of IOS, they recovered to normal. Then immediately contact the device vendor and obtain the latest IOS image file. At this point, all the virus router faults have been solved.

From this troubleshooting process, we can learn the following lessons: always pay attention to the development of the situation on the network, make corresponding solutions, and put them into practice. CERNET users can subscribe to the Security Bulletin service on the http://www.ccert.edu.cn website, once there is a new vulnerability, the CCERT Security Response Group will automatically send you an email.

After learning about the "Shock Wave" during the summer vacation, the "Shock Wave" virus did not spread over the Internet due to the timely configuration on the router, however, the subsequent "Shock Wave killer" did not set the corresponding ACL in time, so this network was paralyzed. In fact, in this attack of "Shock Wave" and "Shock Wave killer", many man networks are also paralyzed. These experiences warn us once and again: always pay attention to network security and respond positively in a timely manner.