A network access failure occurs when a dynamic route is blocked.

Some time ago, a strange fault occurred during Intranet access by a certain organization. The main problem was that the firewall equipment of the internal network of the organization was not very stable due to its long working time, so I bought a new firewall device of the same brand to replace the old one. I thought that after the replacement operation, the Intranet operation stability was better, after the new firewall device is put into operation, the Intranet access stability of the unit is not improved, and all terminals cannot normally access the Intranet system. The failure of the Intranet network is very important. We will track and troubleshoot the fault quickly.

Network Environment

Common clients in the LAN are connected to Layer 2 switches of eight Cisco models through M twisted pair cables. All Layer 2 switches are connected to core Switches of Cisco models through multi-mode optical fiber cables, the core switch connects to the Intranet platform system through a vro. To ensure network access security, the network management system places hardware firewall devices between the core switch and the vro, And the firewall devices work in transparent mode. To prevent broadcast storms and network viruses from affecting the operation of the entire LAN, the network management system specially divides all clients in the unit into six virtual working subnets, the Gateways of each virtual working subnet are all built on core Switches of the Cisco model.

Fault symptom

When the old firewall device is working in transparent mode, all terminals in the LAN can access the Intranet system normally. However, since the old firewall device is replaced by the new one, A network access failure occurs. All terminals in the LAN cannot successfully access the system of the Intranet platform. They can log on to any terminal and run the ping command in the system to test whether the IP address of the router is connected. At first, the network management thought that the new firewall was improperly configured. However, after careful query, it was found that the new firewall was also working in transparent mode and no security filtering rules were set, the firewall does not intercept the network access of the terminal! Later, the network administrator worried about the quality problem of the new hardware firewall device, so he temporarily removed the firewall and directly connected the router device and the new firewall device, the result shows that all the terminals in the LAN can access the Intranet platform smoothly, so the network management confirms that the new firewall device is faulty.

Troubleshooting

Because the hardware firewall is removed, terminals in the LAN can access the Intranet normally, and no obvious security filtering rules are set in the background System of the hardware firewall, therefore, the network management system will "Lock" the focus of troubleshooting on the hardware firewall. Since no problem is found in the configuration of the hardware firewall, most of the problems are the quality of the device. For this reason, the network management immediately contacted the network management of the equipment supplier, ask them to come to the site to help solve the problem. At the fault site, after the network administrator understands the fault phenomenon, it is preliminarily determined that the problem may be caused by software settings.

To check whether the software settings of the hardware firewall are faulty, the network administrator immediately logs on to the background management interface of the device through the console port, it turns out that only one security rule from any to any is set. This access rule should allow access to any network. After continuing the query, he found that the firewall had set the management IP address and gateway address. The original address was used by the network management to facilitate remote management of the new firewall, is the setting here making the hardware firewall a "obstacle "? The Network Administrator tried to delete the management address and restarted the background System of the firewall device. After the firewall was restarted and stabilized, the network administrator pinged the IP address of the router in the background System of the firewall and found that the test was successful, it is also normal to test the IP address of the core switch. Is the problem solved so quickly?

However, when the network administrator tries to test the connection from the terminal, it finds that the Intranet still cannot access the Internet normally. Obviously, the root cause of the problem is still not found. As a last resort, the network administrator had to restore all the firewall settings to the default state, and then re-configure the firewall. As a result, it was found that the core switch and the router can still ping each other, however, terminals in the LAN cannot access the Intranet normally. Due to the normal ping test operation, the network management considers the problem to be unrelated to the firewall device, and the failure of access is likely caused by the Intranet itself.

As a result, the network administrator began to suspect that there was a problem with the Intranet. For this reason, he chose a terminal from the LAN and started to track and test the packet sending, the result shows that the data packets cannot reach the vro of the Intranet. Does the firewall or core switch discard the target data packet? Considering that the firewall does not set any filtering rules, the network management system may assume that the core switch automatically filters out the Internet data packets. Therefore, log on to the core switch background system and execute the string command "show access-list ", to check which content is filtered by the core switch, but he did not think that the access list does not contain any content, which means that the core switch does not perform the packet filtering operation; by the way, run the string command "show ip route". When you view its route table records, it is found that the route records are obviously abnormal and fail to reach the Intranet route, no wonder that terminals in the LAN cannot access the Intranet normally.

Troubleshooting

Why is there no route record pointing to the Intranet on the core switch? In this status, why can I access the Intranet normally when I connect to the old hardware firewall? When the core switch is directly connected to the vro, the terminal in the LAN can also access the Intranet normally. Therefore, the Network Administrator estimates that the core switch must have enabled the ospf protocol, in this way, it can obtain a dynamic route to the Intranet. Otherwise, the terminal will never be able to access the Intranet. to verify whether its guess is correct, the network management system is in the background System of the core switch, after running the "show runn" string command, it is found that the core switch has enabled the dynamic routing function. when viewing the specific configuration of the routing protocol, the network management finds that ospf neighbors cannot be found, no wonder the core switch cannot obtain the dynamic route to the Intranet.

Is it because the ospf protocol is not enabled in the vro that the core switch cannot obtain dynamic routes from the vro? However, when the core switch is directly connected to the vro, the terminal in the LAN can normally access the Intranet. This means that the core switch can learn dynamic routing from the vro during direct connection, why can't the core switch obtain dynamic routes from the vro after connecting to the hardware firewall? For such problems, the network management considers that the ospf Protocol needs to send a hello packet to the network in multicast mode when looking for dynamic neighbors, however, by default, the hardware firewall does not allow multicast packets to pass through. As a result, the hardware firewall will prevent the core switch from learning dynamic routing from the router. After dynamic routing is blocked, terminals in the LAN naturally cannot access the Intranet platform.

After finding out the cause of the fault, the network administrator immediately reconfigured the appropriate access rules in the hardware firewall to ensure that the device would not "Block" the dynamic routing, when the Network Manager executes the "show ip ospf neighbor" string command on the core switch again, it finds the ospf neighbor. During the online test, it finds that the terminal has been able to access the Intranet smoothly, so far, the failure to access the Intranet has been successfully solved.