How to Use router protocols to minimize network interruptions

Currently, there are many kinds of router protocols, and many people may not know how to use the Router Protocol to minimize network interruptions. It doesn't matter. After reading this article, you will certainly have a lot of GAINS, I hope this article will teach you more things. As we all know, to obtain a high network duration, you need to use a master router and a backup router with a hot fault recovery function and different network paths. But this is not enough. The Router Protocol itself, especially those on the edge of an insecure WAN, should be equipped with internal redundant hardware components, such as switching matrices, line cards, power supplies, and Route Processor RP ). High Availability router protocols must also support fast software recovery technology.

Vrouters that can isolate control and forwarding panels and use a stable restart mechanism-also known as Cisco NSF)-can greatly extend the normal running time of networks and applications. This software recovery technology can maintain the normal transmission of groups when the RP Process is interrupted, thus controlling the impact of interruption on the network.

Dual RP and continuous group forwarding

The RP contains the "brain" of the router ". It is responsible for storing the database of the optimal route information, storing the adjacent relationship with the peer-to-peer router, and processing specific management functions. Redundant hardware improves the availability of network components in the event of a fault. Cisco dual RP devices include 12000, 10000, and 7600 series high-end routers, as well as Cisco7500 and 7300 series routers. The degree of synchronization between the two RP statuses depends on the speed at which the router can restart or recover from a fault. This requires a balance between two extreme backup forms. An extreme form is RP's "cold" backup, that is, it does not contain any status information about layer-2 connections, joining relationships, and the optimal route table. In this case, all this information needs to be re-built, which may lead to a very long recovery time. Another extreme form is the uninterrupted synchronization of all information between two RP, which may occupy too much processing resources and affect the network scalability and performance.

The common approach is to maintain an appropriate balance between the two extreme RP Synchronization Methods, that is, to load most but not all of the recovery information into the backup RP. This synchronization can continue layer-3 packet forwarding when the RP and the centralized route table are switched. CiscoIOS installed on the preceding vro protocol Platform®Software 12.0 (22) S or later can support Cisco NSF. It can shorten the downtime of the router protocol when the primary RP is scheduled for maintenance or when the RP encounters an unexpected fault. In most cases, to implement Cisco NSF, the restart router and its peer vro must save the forwarding information for all networks that can be reached by restarting the router. On the router restart, when switching from the primary RP to the standby RP, the control panel and the forwarding panel must be isolated from each other so that the forwarding panel can continue to forward data traffic.

Router Protocol Extension

To achieve NSF, Some Cisco routers can use the common Router Protocol-including Border Gateway Protocol BGP), IS-IS, and Open Shortest Path-first OSPF) to implement new stable restart expansion. These extensions can continue forwarding groups and maintain network connection stability while determining whether the primary RP can be quickly restored.

To enable most Cisco NSF/stable restart deployment, the peer-to-peer Router Protocol for restarting a router must also support these extensions. This is mainly because of the following two reasons. First, RP switching does not represent topology changes, but only indicates RP recovery. A peer-to-peer router can use the smooth restart and expansion to avoid disabling external broadcast and enabling and restarting the router. This prevents unnecessary broadcast information and route changes. Second, it enables peer-to-peer routers to continue forwarding groups to the restarted vrouters during recovery to provide NSF. It must also know which messages and information should be exchanged to help the primary router recover quickly.

BGP stable restart

Because the impact of BGP restart may be very far-reaching, BGP is an important object for High Availability improvement. BGP can carry a large number of routes. Therefore, the time for network convergence after a BGP software failure is usually longer than other routing protocols that support fewer routes. In addition, Because BGP is an Inter-Domain Routing Protocol, a failed BGP process may be propagated to multiple networks, rather than confined to a specific domain. When the BGP network is restarted, the Protocol improvement starts after the initial BGP connection is established. Restarting the router and its peer vro will exchange the BGP Function Code 64 in the initial BGPOPEN message of the creation process, indicating the support for Cisco NSF. In general, when the router restarts its BGP process, the TCP connection with the peer router will be cleared, resulting in the Peer router to clear all the routes related to the restart router. However, this operation will not be performed during the stable restart of BGP. On the contrary, the peer-to-peer Router Protocol will mark these router protocols as "expired" and continue to use these route forwarding groups based on the expectation that restarting the router will quickly re-establish the BGP process. Similarly, restarting a vro will continue to forward packets when the BGP protocol is re-converged. When the router is restarted to create a new BGP process, it will again send the BGP Function Code 64 to its peer router. However, this time, the tag settings in the stable restart function switch will let the peer router know that the BGP process has been restarted.

When the forwarding group continues, the peer router sends an initial route upgrade to the restarted router. The peer-to-peer Router Protocol uses an end-of-RIBEOR mark to indicate that the upgrade has been completed. This tag is actually an empty BGPUPDATE message. After the router restarts and receives the EOR from all the peer routers, it will know that it can use the new route information to select the optimal path again. Similarly, restarting a vro sends all the upgrades to its peer vro, and then uses the EOR tag to indicate that the update is complete. This allows the peer router to replace the expired route with the upgrade received from the restart router.

IS-IS features

IETF, an Internet Engineering Task Team, IS designing a similar and stable restart process for the IS-IS connection status and single-domain Routing Protocol in the form of a draft Internet. IS-IS extension designer MikeShand from Cisco pointed out that in the current Packet®At the time of publication, IETF will publish the last version of the draft. As mentioned above, IS-IS uses the Hello protocol to discover adjacent routers and establish and maintain the adjacent relationship. When a router is restarted, it sends a signal to its peer Router Protocol through a restart request RR in the Hello protocol data unit. In an IS-IS network, a peer-to-peer router can send database information directly to the restart Router Protocol without waiting for confirmation.

After a vro is restarted, it sends a Hello group with a special RR setting to let the peer router know that it has restarted. The peer-to-peer Router Protocol will confirm the restart signal by setting a special restart confirmation RA in its own Hello message. A peer router sends a summary list of all connection status groups (LSP, then, send the LSP specified in the list. In addition, once the summary list is met, the router will be restarted to upgrade its database. From this perspective, this function is similar to the EOR in the BGP stable restart process. After the synchronization IS complete, the IS-IS and LSP data are saved to the backup RP. However, IS-IS will try a new Cisco NSF restart only after the interval ends. In addition, restarting the router will use the first summary list to verify the validity of the LSP cached by the router, so as to maintain the status of the IS-IS protocol.