Shulou(Shulou.com)06/01 Report--

Recently, the company does not seem to be very smooth at the beginning of the year. Users' equipment goes wrong one after another, and the network is constantly experiencing minor breakdowns. As an after-sales engineer, it is natural for firemen to go everywhere to put out a fire. I mainly want to write two small cases. summarize the whole fault handling process.

Case 1. A vlan service network is disconnected.

User A's network experienced a loop, which directly caused the whole network to be paralyzed and unable to be accessed normally. After the loop was resolved, it was found that one of the VLAN users could not get the MAC address table of the gateway, resulting in ping gateway delay or packet loss, and abnormal ping in the network.

At first, it was thought that ARP***, may have grabbed VLAN packets, and it was found that there were ARP scans or request storms in the network, but they were all normal access, so the ARP spoofing of the terminal was excluded.

Could it be that the virus in the network is rampant, and the device is not found abnormal through packet grabbing and active threats in the network, and this problem is initially eliminated.

There is no good way to bind the ip/mac of the terminal by hand.

Then determine that there may be a problem with the VLAN switch, then check the configuration, find that the configuration is not abnormal, and then prepare to unplug the test one by one in the wee hours of the morning, the problem lies in which switch (the vlan has four) are unplugged according to the design idea, and found that the fault is still wrong. I will go, what is the problem? is there a problem with core 65? find a CCIE to have a look, and there is nothing wrong with the configuration. Other network segments can normally go to ping to connect the gateway, but their own VLAN can not ping, strange, decided to restart the switch, found that a bad one in the restart process, really unlucky ah.

The failure still exists after the restart, and it seems that there is a reason why there may be a problem with the switch. is it possible that the switch is paralyzed because of a large number of loops? But there are four, and four have two links connected to the 65 core through photoelectric conversion.

Replaced with a new switch, test, found that the fault is not so obvious, and much better, the preliminary judgment may be a problem with the switch. (it's 04:30 in the morning, that's all.)

Later I asked other people about this symptom, and they told me that I should restart the photovoltaic converter, and the real problem may be here, which hasn't been verified yet.

Case 2: business traffic occurs in radware backup.

The user's network exit uses our radware link load balancing equipment, which is very old, but it plays an important role in the user's network and business. The main problem found is that the radware of the user adopts the active / standby mode, and the dual-computer judgment is made through VRRP, and it is found that there is a test network segment on the slave that has business traffic, and the user of this network segment has just made adjustments.

I am not familiar with the product yet, so I studied it one night in advance.

As there is no policy change, it is preliminary to determine whether the user's device configuration needs to be re-brushed, export the standby device, and then pour it in. After rebooting the device, it is found that the fault still exists.

At this time, consider whether it is a dual-computer problem. Compared with the host configuration, there is a problem with the dual-computer, but you can't tell what the problem is, so you decide to delete the VRRP configuration and reconfigure the Smart NAT.

The master / slave of radware is through LinkProof > Redundancy > Global Configuration >. Redundant global configuration table

Interface Grouping: enable is selected for the primary device, which means that the overall device is switched when there is a problem with one port. The standby device usually uses the default disable state.

The idea is to delete VRRP-VR Table and then re-add associated ip from the new VR Table

The second idea is to rebuild Static NAT, which is an one-to-one mapping, does not change the port, and is a two-way NAT

Since the most recent operation of the user is to create a new NAT, under all the decisions to rebuild, when choosing the NAT mode, colleagues are quick-eyed and quick, and they find that the new mode created by the standby user is not correct. Regular should choose backup.

It seems that the problem has been found. The Smart NAT is incorrect due to configuration errors. It seems that this is the problem.

When it's done, we can finally go home, but there are still problems with WAF and anti-Dos equipment, all tears.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.