OSPF GR Technology White Paper-6W100

HomeSupportResource CenterOSPF GR Technology White Paper-6W100
Download Book
Title Size Downloads
OSPF GR Technology White Paper-6W100-book.pdf 152.44 KB
Table of Contents
Related Documents

 

 

OSPF GR Technology White Paper

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Copyright © 2021 New H3C Technologies Co., Ltd. All rights reserved.

No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of New H3C Technologies Co., Ltd.

Except for the trademarks of New H3C Technologies Co., Ltd., any trademarks that may be mentioned in this document are the property of their respective owners.

This document provides generic technical information, some of which might not be applicable to your products.

The information in this document is subject to change without notice.



Overview

Graceful Restart (GR) enables a device to forward data uninterruptedly when it performs an active/standby switchover or restarts a routing protocol. When a GR-capable device restarts a routing protocol, it notifies the event to its neighbors, which then maintain adjacencies and the routing information of the device within a specified interval. After the protocol is restarted, the device retrieves the information (topology, routing and session information) from the neighbors and restores the state before reboot. During the restart process, no route flapping occurs and no forwarding path is changed. Thus, the system can operate continuously.

OSPF GR ensures the service continuity of an OSPF-enabled router during active/standby switchover or OSPF restart.

Background

Without GR, a router, after restarting OSPF, sends hello packets to discover neighbors. The neighbor routers remove the former adjacency with the router upon receiving the hello packet, and notify other routers of the event. The restarting router and neighbors have to reestablish adjacencies and exchange routing information. This process brings route flapping and service interruption, which are unacceptable for a large network, particularly for a carrier network.

How to solve this problem?

We know that a distributed device has its control plane separated from its forwarding plane. That is, the main control board controls and manages the entire device, including protocol operation and route calculation, and the interface boards forward packets. Thus, data forwarding can be continuous during active/standby switchover or routing protocol restart; meantime, if neighbors can keep their adjacency with the restarting device, the device can retrieve route information from the neighbors and restore the routes it maintains before restart immediately.

To implement these ideas, OSPF GR was introduced, which effectively avoids route flapping and service interruption during active/standby switchover or OSPF restart.

Benefits

OSPF GR ensures service continuity, and avoids route flapping and single point of failure during active/standby switchover or OSPF restart, and thus enhances network reliability.

OSPF GR implementation

Terminology

·     GR Restarter: A GR-capable device that restarts a routing protocol.

·     GR Helper: Neighbors of a GR Restarter, which help the GR Restarter to retrieve the routing table in a GR process.

·     GR session: Refers to the GR capability negotiation process during OSPF neighbor relationship establishment between two routers. If the two routers are GR capable, they will perform GR during protocol restart.

 

 

NOTE:

A distributed device can be configured as a GR Restarter or GR Helper. A centralized device can be configured only as a GR Helper that helps the GR Restarter to complete a GR process.

H3C supports the following two OSPF GR modes:

·     IETF standard OSPF GR—The GR Restarter controls the GR process by sending Type-9 Opaque LSAs, called Grace-LSAs, to GR Helpers.

·     Non-IETF standard OSPF GR—The GR Restarter and a GR Helper exchange OSPF packets containing the LLS and OOB extension information to complete the GR process.

You can configure only one OSPF GR mode on a GR Restarter because these two GR modes are mutually exclusive.

 

Implementing IETF standard OSPF GR

IETF standard OSPF GR uses Type-9 Opaque LSAs, called Grace-LSAs, to notify neighbors to enter the GR Helper process when the GR Restarter restarts.

Grace-LSA

Figure 1 depicts the format of the Grace-LSA.

Figure 1 Format of the Grace-LSA

 

The major TLVs are:

·     Grace Period TLV. The Grace Period TLV has a Type value of 1 and a Length value of 4. It indicates the maximum time during which a neighbor acts as a GR Helper. If the GR Restarter does not complete the GR process before this period expires, the neighbor stops working as a GR Helper. Grace-LSAs must contain a Grace Period TLV.

·     Graceful Restart Reason TLV. The Graceful Restart Reason TLV has a Type value of 2 and a Length value of 1, and describes the graceful restart reason. Possible values of the Value field are 0 for unknown reason, 1 for software restart, 2 for software reloading (upgrade), and 3 for active/standby switchover of the GR Restarter. Grace-LSAs must contain a Graceful Restart Reason TLV.

·     IP Interface Address TLV. The IP Interface Address TLV has a Type value of 3 and a Length value of 4, and indicates the IP address of the interface sending the Grace-LSA. This IP address uniquely identifies the restarting device on the network.

Operating procedure

Suppose Router A keeps stable OSPF neighboring relationship with Router B and is enabled with GR. If you restart Router A, the routing information is exchanged as follows.

Figure 2 Operating procedure of IETF standard OSPF GR

 

As shown in Figure 2:

·     Once restated, Router A sends a Grace-LSA to Router B.

·     Upon receiving the Grace-LSA, Router B keeps the neighboring relationship with Router A unchanged.

·     Router A and Router B exchange hello packets and DD packets and perform LSDB synchronization. Because no LSAs are generated during a GR process, Router A stores self-originated LSAs (if any) received from Router B and labels them as stale during LSDB synchronization.

·     After LSDB synchronization, Router A sends a Grace-LSA (the Type value of the Grace Period TLV is 0) to notify Router B that it exits the GR process. Then Router A enters the normal OSPF process, regenerates LSAs, and deletes those LSAs that are labeled as stale and are not regenerated.

·     After retrieving all the routing information, Router A recalculates routes and refreshes its FIB table.

Implementing non-IETF standard OSPF GR

Compared with IETF standard OSPF GR, non-IETF standard OSPF GR supports GR through the following two extended capabilities:

·     Link-Local Signaling (LLS), which identifies the communication of option information between two routers.

·     Out-of-band LSDB Resynchronization (OOB), which is carried out when the neighboring relationship is unchanged.

LLS extension

The LLS data block is attached to OSPF hello and DD packets, and the LLS bit, called L bit, is added to the Options field of OSPF hello and DD packets. A packet with the L bit set to 1 indicates it contains the LLS data block. Figure 3 depicts the format of the Options field.

Figure 3 The Options field

 

After added with the LLS data block, the OSPF packet format is shown in Figure 4.

Figure 4 Format of OSPF packet with LLS data block

 

The format of the LLS data block is shown in Figure 5.

Figure 5 Format of the LLS data block

 

The LLS data block adopts an extensible TLV structure. For example, to support GR, the LLS data block uses the TLV that has a type value of 1 (that is, the Extended Option TLV, or EO TLV). The two major fields in the EO TLV are introduced as follows.

·     LR bit: The LSDB Resynchronization (LR) bit, as shown in Figure 6, is used for OOB capability negotiation. If a router is OOB capable, it sets the LR bit when sending OSPF hello packets and DD packets; if not, the router does not set the LR bit. For details about OOB capability, refer to OOB .

Figure 6 LR bit of the EO TLV

 

·     RS bit: The Restart Signal (RS) bit, as shown in Figure 7, is used to notify neighbors that the local router enters the GR process. When a router needs to leave the network temporarily, it sets the RS  bit in hello packets to notify its neighbors that it will enter the GR process, and then the neighbors keep adjacencies with the local router.

Figure 7 RS bit of the EO TLV

 

OOB extension

After a router completes OOB capability negotiation using LLS and makes sure that neighbor is also OOB capable, it can start LSDB synchronization when the neighboring relationship and the network topology are stable, that is, the router can enter the OOB process. Then, the router sets the R bit in the Options field of DD packets (in Figure 8) sent to the neighbor.

Figure 8 DD packet format

 

Operating procedure

Suppose Router A keeps stable OSPF neighboring relationship with Router B and is enabled with GR capability. If you restart Router A, the routing information is exchanged as follows.

Figure 9 Operating procedure of non-IETF standard OSPF GR

 

As shown in Figure 9:

·     Once restated, Router A sends to Router B a hello packet with the LR bit and RS bit set, notifying Router B that it will disconnect temporarily and it is OOB capable.

·     Upon receiving the hello packet, Router B replies with a hello packet with the LR bit on and RS bit off to notify Router A that it is OOB capable as well.

·     Router A sends a DD packet with the R bit on to Router B to request LSDB synchronization. During LSDB synchronization, Router B does not remove Router A from its neighbor table, so the neighbor state of Router A in the Router LSA (Network LSA) is full. No LSA is generated during a GR process, so Router A stores self-originated LSAs (if any) received from Router B and labels them as stale during LSDB synchronization.

·     After LSDB synchronization, Router A exits the GR process and enters the normal OSPF process. Then Router A regenerates LSAs and deletes those LSAs that are labeled as stale and are not regenerated. When the neighbor state of Router A becomes full, Router B exits the GR process and enters the normal OSPF process

·     After retrieving all the routing information, Router A recalculates routes and refreshes its FIB table.

Application scenarios

Application scenarios

Figure 10 Network diagram for OSPF GR configuration

 

Network requirements

·     As shown in Figure 10, Router A, Router B, Router C, Router D, Router E, Router F, Router G, Router H, Router I, Router J, Router K, Router L run OSPF.

·     Router A and Router B are connected to the backbone.

·     Router G, Router H, Router I, Router J, Router K, and Router L are branch nodes, which are connected to the backbone nodes through core nodes Router C, Router D, and Router E.

·     Enable GR to ensure service continuity on the backbone nodes and core nodes upon protocol restart, and to avoid route flapping.

·     The backbone nodes and core nodes act as GR Restarters (which serve as GR Helpers as well by default), and the branch nodes serve as GR Helpers. If a backbone node performs an active/standby switchover or restarts OSPF, the core nodes can serve as GR Helpers for LSDB synchronization and ensure service continuity. If a core node performs an active/standby switchover or restarts OSPF, both the backbone nodes and branch nodes can serve as GR Helpers for LSDB synchronization to ensure service continuity.

References

·     RFC 2328: OSPF Version 2

·     RFC 3623: Graceful OSPF Restart

·     RFC 4811: OSPF Out-of-Band LSDB Resynchronization

·     RFC 4812: OSPF Restart Signaling

·     RFC 4813: OSPF Link-Local Signaling