GR is usually used when the active route processor (RP) fails because of a software or hardware error, or used by an administrator to perform the master/slave switchover.
Prerequisite for Implementation
On a traditional routing device, a processor implements both control and forwarding. The processor finds routes based on routing protocols, and maintains the routing table and forwarding table of the device. Mid-range and high-end devices generally adopt the multi-RP structure to improve forwarding performance and reliability. The processor in charge of routing protocols is located on the main control board, whereas the processor responsible for data forwarding is located on the interface board. The design helps to ensure the continuity of packet forwarding on the interface board during the restart of the main processor. The technology that separates control from forwarding satisfies the prerequisite for GR implementation.
At present, a GR-capable device must have two main control boards. In addition, the interface board must have an independent processor and memory.
Related Concepts
- GR Restarter: indicates a device that performs master/slave switchover triggered by the administrator or a failure. A GR Restarter must support GR.
- GR Helper: indicates the neighbor of a GR Restarter. A GR Helper must support GR.
- GR session: indicates a session, through which a GR Restarter and a GR Helper can negotiate GR capabilities.
- GR time: indicates the time when the GR Helper finds that the GR Restarter is Down but keeps the topology information or routes obtained from the GR Restarter.
- End-of-RIB (EOR): indicates BGP information, notifying a peer BGP that the first route upgrade is finished after the negotiation.
- EOR timer: indicates a maximum time of a local device waiting for the EOR information sent from the peer. If the local device does not receive the EOR information from the peer within the EOR timer, the local device will select an optimal route from the current routes.
Principles
- During BGP peer relationship establishment, devices negotiate GR capabilities by sending supported GR capabilities to each other.
- When detecting the master/slave switchover of the GR Restarter, a GR Helper does not delete the routing information and forwarding entries related to the GR Restarter within the GR time, but waits to re-establish a BGP connection with the GR Restarter.
-
After the master/slave switchover, the GR Restarter receives routes from all the negotiated peers with GR capabilities before the switchover, and starts the EOR timer. The GR Restarter selects a route when either of the following conditions is met:
- The GR Restarter receives the EOR information of all peers and the EOR timer is deleted.
- The EOR timer times out but the GR Restarter receives no EOR information from all peers.
-
The GR Restarter sends the optimal route to the GR Helper and the GR Helper starts the EOR timer. The GR Helper quits GR when either of the following conditions is met:
- The GR Helper receives the EOR information from the GR Restarter and the EOR timer is deleted.
- The EOR timer times out and the GR Helper receives no EOR information from the GR Restarter.
GR Reset
Currently, BGP does not support dynamic capability negotiation. Therefore, each time a new BGP capability (such as the IPv4, IPv6, VPNv4, and VPNv6 capabilities) is enabled on a BGP speaker, the BGP speaker tears down existing sessions with its peer and renegotiates BGP capabilities. This process will interrupt ongoing services.
To prevent the service interruptions, the CX600 provides the GR reset function that enables the CX600 to reset a BGP session in GR mode. With the GR reset function configured, when you enable a new BGP capability on the BGP speaker, the BGP speaker enters the GR state, resets the BGP session, and renegotiates BGP capabilities with the peer. In the whole process, the BGP speaker re-establishes the existing sessions but does not delete the routing entries for the existing sessions, so that the existing services are not interrupted.