When configuring Graceful Restart (GR), go
to these sections for information you are interested in:
l
Introduction
to Graceful Restart
l
Configuring
Graceful Restart
l
Displaying
and Maintaining Graceful Restart
l
Graceful
Restart Configuration Examples
Throughout this
chapter, the term router in this document refers to a router in a generic sense
or an S9500 series routing switch running routing protocols.
1.1 Introduction to Graceful Restart
Graceful Restart ensures the continuity of
packet forwarding when a routing protocol restarts.
The mechanism of Graceful Restart works as
follows: when the routing protocol on a Graceful Restart capable device
restarts, the device can notify its neighbors to temporarily preserve its
adjacency with them and the routing information. After the routing protocol
restart is finished, the neighbors help the device to synchronize its routing
information and to restore it to the state prior to the restart in minimal
time. The routing and forwarding remain highly stable during the restart, the
packet forwarding paths remain the same, and the whole system can forward IP
packets continuously. Hence, it is called “Graceful Restart”.
1.1.2 Basic
Mechanism of Graceful Restart
A router with the Graceful Restart feature
enabled is called a Graceful Restart capable router. It can perform a Graceful
Restart when its routing protocol restarts. Routers that are not Graceful
Restart capable will follow the normal restart procedures after a routing
protocol restarts.
l
GR Restarter: Graceful restarting router, the
router whose routing protocol has restarted due to administrator instructions
or network failure. It must be Graceful Restart capable.
l
GR Helper: The neighbor of the GR Restarter,
which helps the GR Restarter to retain the routing information. It must be
Graceful Restart capable.
l
GR Session: A Graceful Restart session, which is
the negotiation between the GR Restarter and the GR Helper. A GR session
includes restart notification and communications across restart. Through this
session, GR Restarter and GR Helper can know the GR capability of each other.
l
GR Time: The time taken for the GR Restarter and
the GR Helper to establish a session between them. Upon detection of the down
state of a neighbor, the GR Helper will preserve the topology and routing
information sent from the GR Restarter for a period as specified by the GR
Time.
Configure a device as GR Restarter in a
network. This device and its GR Helper must support GR or be GR capable. Thus,
when GR Restarter restarts, its GR Helper can know its restart process.
l
In some cases, GR Restarter and GR Helper can
replace with each other.
l
If a router is to act as a Graceful Restarter,
it must have the ability to preserve the routing information in the routing
table (forwarding table). Routers that fail to meet this can only act as a GR
Helper.
The communication procedure between the GR
Restarter and the GR Helper works as follows:
1)
A GR session is established between the GR
Restarter and the GR Helper.

Figure 1-1 A GR session is established between the GR Restarter and the GR
Helper
As illustrated in Figure 1-1, Router A
works as GR Restarter, Router B, Router C and Router D are the GR Helpers of
Router A. A GR session is established between the GR Restarter and the GR
Helper.
2)
GR Restarter restarting

Figure 1-2 Restarting process for the GR Restarter
As illustrated in Figure 1-2. The GR
Helper detects that the GR Restarter has restarted its routing protocol and
assumes that it will recover within the GR Time. Before the GR Time expires,
the GR Helper will neither terminate the session with the GR Restarter nor
delete the topology or routing information of the latter.
3)
GR Restarter signaling to GR Helper

Figure 1-3 The GR Restarter signals to the GR Helper(s) after restart
As illustrated in Figure 1-3, after
the GR Restarter has recovered, it will signal to all its neighbors and will
reestablish GR Session.
4)
The GR Restarter obtaining topology and routing
information from the GR Helper

Figure 1-4 The GR Restarter obtains topology and routing information from the
GR Helper
As illustrated in Figure 1-4, the GR
Restarter obtains the necessary topology and routing information from all its
neighbors through the GR sessions between them and calculates its own routing
table based on this information.
Graceful restart is currently implemented
in BGP, OSPF, IS-IS, and LDP.
I. BGP-based Graceful Restart
1)
To establish a session with its peer, a
BGP-based GR Restarter needs to send an OPEN message first to its peer
including its Graceful Restart Capability.
2)
Upon receipt of this message, the peer is aware
that the sending router is capable of Graceful Restart. It will use the OPEN
messages to exchange the Graceful Restart Capability with the GR Restarter and
to establish a GR session with it. If neither party has the Graceful Restart
Capability, the session established between them will not be Graceful Restart
Capable.
3)
The GR session between the GR Restarter and the
GR Helper goes down when a BGP restarts. A Graceful Restart Capable GR Helper
will mark all routes associated with the GR Restarter as stale. However, during
the configured GR Time, it still uses these routes in packet forwarding,
ensuring that no packet will be lost when routing information from its peer is
recollected.
4)
After the restart, the GR Restarter will
reestablish the GR session with its peer and send new GR messages notifying the
completion of restart. Routing information can be exchanged between the peers
and used by the GR Restarter in creating the new routing table (forwarding
table) in place of the stale routing information. Thus the BGP routing
convergence is complete.
II. OSPF-based Graceful Restart
After an OSPF-based GR Restarter restarts
its OSPF, it needs to perform the following two tasks in order to update its
link-state database with its neighbor.
1)
To obtain once again effective OSPF adjacency
while retaining the original one.
2)
To obtain once again link-state database
information.
Before the restart, the GR Restarter
originates Grace-LSA negotiation GR capability. During the restart, the GR
Helper continues to advertise its adjacency with the GR Restarter.
After the restart, the GR Restarter will
send an OSPF GR signal to its neighbor so that the adjacency is not reset. In
this way, the GR Restarter can restore its adjacency with its neighbor upon
receiving the responses from the latter.
Upon the reestablishment of the adjacency,
the GR Restarter will update its link-state database with all of its GR Capable
neighbors and exchange routing information with them. After that, the GR
Restarter will update its own routing table (forwarding table) based on the new
routing information and delete the stale routes. In this way, the OSPF routing
convergence is complete.
III. IS-IS-based Graceful Restart
After an IS-IS based GR Restarter restarts
its IS-IS, it needs to perform the following two tasks in order to update its
link state database with its neighbor.
l
To obtain once again effective IS-IS adjacency
while retaining the original one.
l
To obtain once again link-state database
information.
After the restart, the GR Restarter will
send an IS-IS GR signal to its adjacent GR Helper so that the adjacency is not
reset. In this way, the GR Restarter can restore its adjacency with its IS-IS
neighbor upon receiving responses from the latter.
After the adjacency has been reestablished,
the GR Restarter will update its link-state database with all of its GR Capable
IS-IS neighbors and exchange routing information with them. After that, the GR
Restarter will update its own routing table (forwarding table) based on the new
routing information and delete and the stale routes. In this way, the IS-IS
routing convergence is complete.
During LDP session establishment, LDP
enabled devices need to negotiate their GR Capability. If two parties are both
GR capable, the session between them will be GR capable. If at least one party
is not GR capable, the session established will not be FT/GR capable. In order
to support Graceful Restart, a GR Restarter needs to make a backup of its FEC (forwarding
equivalence class) and label information when LDP restarts.
Suppose an LDP session is GR capable:
1)
After the GR Restarter has restarted LDP, the GR
Helper will detect an improper working state of the related LDP session.
2)
Before the Reconnect Timer times out, if the GR
Helper receives a session request from the GR Restarter, it will maintain the
LSP and label information of the session and restore the session with the GR
Restarter; otherwise, it will delete all the LDP and label information
associated with the session.
3)
After the session has recovered, the GR
Restarter and the GR Helper will activate their Neighbor Liveness Timer and
Recovery Timer, restore all the LSP information relative to this session, and
send to each other the Label Mapping (Downstream Unsolicited) and Label Request
(Downstream-on-Demand) Messages.
4)
The GR Restarter and the GR Helper will delete
the LSP stale upon receipt of the Label Mapping Message, and will delete all
the LSP information associated after the Neighbor Liveness Timer and the
Recovery Timer have timed out.
To summarize, during the Graceful Restart,
the LSP information on the data link layer will be preserved so that the MPLS
packets can be forwarded without interruption.
1.2 Configuring Graceful Restart
One device can act
as both GR Restarter and GR Helper at the same time.
Graceful Restart configuration can be
normally achieved by enabling the Graceful Restart Capability. The time
parameters can be configured if necessary, but under normal circumstances the
defaults should be used.
Follow these steps to configure BGP-based
GR on the GR Restarter and the GR Helper:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enable BGP, and enter its view
|
bgp as-number
|
Required
Disabled by default
|
|
Enable Graceful Restart Capability for
BGP
|
graceful-restart
|
Required
Disabled by default
|
|
Configure the maximum time allowed for
the peer to reestablish a BGP session
|
graceful-restart timer restart timer
|
Optional
150 seconds by default
|
|
Configure the maximum time to wait for
the End-of-RIB marker
|
graceful-restart timer wait-for-rib timer
|
Optional
180 seconds by default
|
|
Note:
End-of-RIB = End of
Router-Information-Base
|
l
In general the maximum time allowed for the peer
to reestablish a BGP session should be less than the Holdtime carried in the
OPEN message. Upon detection of the termination of the session, the GR Helper
will wait for a period of time as specified by the GR Time before it
reestablishes the BGP session.
l
The End-of-RIB marker can be used to indicate
that the updated routing information has been sent.
l
For the command related to enabling BGP and
entering BGP view, refer to BGP Commands in the IP Routing Volume.
1.2.2 Configuring OSPF-based Graceful Restart
I. Configuring OSPF-based GR
Restarter
Follow these steps to configure the
OSPF-based GR Restarter:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enable OSPF and enter OSPF view
|
ospf [ process-id
| router-id router-id | vpn-instance instance-name
] *
|
Required
Disabled by default
|
|
Enable the use of link-local signaling
|
enable link-local-signaling
|
Required
Disabled by default
|
|
Enable out-of-band resynchronization
|
enable out-of-band-resynchronization
|
Required
Disabled by default
|
|
Enable GR
for OSPF
|
graceful-restart
|
Required
Disabled
by default
|
II. Configuring OSPF-based GR
Helper
Follow these
steps to configure OSPF-based GR Helper:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Enable
OSPF, and enter OSPF view
|
ospf [ process-id | router-id router-id | vpn-instance
instance-name ] *
|
Required
Disabled
by default
|
|
Enable the use of link-local signaling
|
enable link-local-signaling
|
Required
Disabled by default
|
|
Enable out-of-band resynchronization
|
enable out-of-band-resynchronization
|
Required
Disabled by default
|
|
Configure for which OSPF neighbors the
current router can serve as a GR Helper
|
graceful-restart help { acl-number | prefix prefix-list }
|
Optional
The router can server as a GR Helper for
any OSPF neighbor by default.
|
For the command
related to enabling OSPF and entering OSPF view, refer to OSPF Commands
in the IP Routing Volume.
III. Restarting OSPF Graceful
Restart
You can perform the following configuration
on a routing switch to restart the GR process for OSPF protocol, but ensure
that the routing switch has been enabled with the following capabilities first:
l
LLS (link local signaling)
l
OOB (out of band resynchronization)
Following the step to restart the OSPF GR
process:
|
To do…
|
Use the command…
|
Remarks
|
|
Restart
OSPF Graceful Restart
|
reset
ospf [ process-id ]
process graceful-restart
|
Required
Available
in user view
|
An IS-IS restart may cause the termination
of the adjacency between a restarting switch and its neighbors, resulting in
transient network disconnection.
IS-IS-based Graceful Restart can help to
solve this problem. A switch enabled with IS-IS-based Graceful Restart can
notify its neighbors its restarting state to allow its neighbors to reestablish
the adjacency without terminating the connections with it.
The IS-IS-based Graceful Restart provides
the following enhancements:
l
In the event of an ISIS restart, a Graceful
Restart Capable switch will resend connection requests to its neighbors instead
of terminating their neighboring relationship.
l
Graceful Restart has minimized the disruption on
network traffic caused by the waiting occurred due to data synchronization
before LSP packets generation.
l
For a switch starts for the first time, in LSP
packets overload bit is set to achieve database synchronization, which ensures
no loopback is created in a network.
Graceful Restart Interval is configured as
the Remaining Lifetime contained in the IS-IS Hello PDU so that the adjacency
between a GR Restarter and its neighbors can be maintained across restart.
Setting the suppress-advertisement (SA) bit
is to suppress the advertisement of the adjacency to the restarting switch in
the Hello PDU across restart. In this way, the neighbors of the GR Restarter
will not advertise the adjacency within the specified period until the
completion of data synchronization between the GR Restarter and its GR Helpers.
This feature helps to effectively avoid the possible blackholes across GR
restart due to the sending or receiving of LSP.
Follow these steps to configure GR on the
GR Restarter GR Helper respectively:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enable IS-IS, and enter IS-IS view.
|
isis [ process-id
] [ vpn-instance vpn-instance-name ]
|
Required
Disabled by default
|
|
Enable Graceful Restart Capability for
IS-IS
|
graceful-restart
|
Required
Disabled by default
|
|
Set the Graceful Restart interval
|
graceful-restart interval interval-value
|
Optional
300 seconds by default
|
|
Configure
to set the SA (Suppress-Advertisement) bit during restart
|
graceful-restart
suppress-sa
|
Optional
By
default, the SA bit is clear.
|
For the command related to enabling IS-IS and entering IS-IS view,
refer to IS-IS Commands in the IP Routing Volume.
I. Configuring MPLS LDP-based
Graceful Restart
Follow these steps to configure GR on the
GR Restarter:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Configure the LSR ID
|
mpls lsr-id lsr-id
|
Required
No MPLS LSR ID is configured by default.
|
|
Enable MPLS, and enter MPLS view
|
mpls
|
Required
Disabled by default.
|
|
Return to system view
|
quit
|
—
|
|
Enable LDP, and enter MPLS LDP view
|
mpls ldp
|
Required
Disabled by default
|
|
Enable Graceful Restart Capability for
MPLS LDP
|
graceful-restart
|
Required
Disabled by default
|
|
Configure the FT Reconnect Timer
|
graceful-restart timer reconnect timer
|
Optional
300 seconds by default
|
|
Configure the Neighbor Liveness Timer
|
graceful-restart timer
neighbor-liveness timer
|
Optional
120 seconds by default
|
|
Configure the LDP Recovery Timer
|
graceful-restart timer recovery timer
|
Optional
300 seconds by default
|
In the MPLS LDP GR process, the GR Helper compares the locally
configured LDP Neighbor Liveness Timer with the FT Reconnect Timer configured
on the remote GR Restarter, and takes the smaller one as the local FT Reconnect
Timer; the GR Helper compares the locally configured LDP Recovery Timer with
the Recovery Timer configured on the remote GR Restarter and takes the smaller
one as the local Recovery Timer.
II. Restarting MPLS LDP
After configuring parameters for MPLS
LDP-based GR, you need to restart MPLS LDP to validate the configurations.
|
To do…
|
Use the command…
|
Remarks
|
|
Restart MPLS LDP
|
reset mpls ldp [ all | peer ldp-peer | vpn-instance ldp-vpn-instance
[ peer ldp-peer ] ]
|
Required
Available in user view
|
For related
description on the reset mpls ldp command, refer to MPLS Basics
Commands in the MPLS VPN Volume.
III. Gracefully restarting MPLS
LDP
When testing MPLS LDP GR in case
main/backup failover is not needed, you can gracefully restart MPLS LDP. Do not
perform this operation in normal cases.
Follow these steps to gracefully restart
MPLS LDP:
|
To do…
|
Use the command…
|
Remarks
|
|
Gracefully restart MPLS LDP
|
graceful-restart mpls ldp
|
Required
Available in user view
|
1.3 Displaying and Maintaining Graceful Restart
|
To do…
|
Use the command…
|
Remarks
|
|
Display
the Graceful Restart state for IS-IS
|
display
isis graceful-restart status [ level-1 |
level-2 ] [ process-id | vpn-instance vpn-instance-name
]
|
Available
in any view
|
1.4 Graceful Restart Configuration Examples
I. Network requirements
Switch A, Switch B, and Switch C belong to the
same domain and use IS-IS as their routing protocol, as illustrated in Figure 1-5.
II. Network diagram

Figure 1-5 IS-IS-based Graceful Restart configuration example
III. Configuration procedure
1)
Configure IP addresses of the interfaces on each
switch and configure IS-IS
Follow Figure 1-5 to configure the IP address and
subnet mask of each interface on the switch. The configuration procedure is
omitted.
Configure the switches as connected through
IS-IS, ensuring that Switch A, Switch B and Switch C can communicate on the
network layer and dynamic route update can be implemented among them with
IS-IS. The configuration procedure is omitted here.
2)
Configure IS-IS Graceful Restart
# Enable IS-IS Graceful Restart on Switch A
and configure the Graceful Restart Interval.
<SysnameA> system-view
[SysnameA] interface vlan-interface 100
[SysnameA-Vlan-interface100] ip
address 10.0.1.1 255.255.255.0
[SysnameA-Vlan-interface100] isis
enable 1
[SysnameA-Vlan-interface100] quit
[SysnameA] router id 1.1.1.1
[SysnameA] isis 1
[SysnameA-isis-1] graceful-restart
[SysnameA-isis-1] graceful-restart
interval 150
[SysnameA-isis-1] return
The configurations for Switch B and Switch
C are similar, therefore are omitted here.
3)
Verify the configuration
The adjacency between Switch A and Switch B
and Switch C is established respectively and routing information can be
exchanged among them. IS-IS on Switch A has restarted, which puts Switch A into
a restart state. Switch A sends connection requests to its neighbors through
the Graceful Restart mechanism to synchronize the database. Its restart status
can be displayed using the display isis graceful-restart status command.
# Restart Switch A.
<SysnameA> reset isis all 1
Warning : Reset ISIS process? [Y/N]:y
# Check the Graceful Restart status of
IS-IS on Switch A.
<SysnameA> display isis
graceful-restart status
Restart information
for IS-IS(1)
--------------------------------------------------------------------
IS-IS(1) Level-1 Restart Status
Restart Interval: 150
SA Bit Supported
Total Number of Interfaces = 1
Restart Status: RESTARTING
Number of LSPs Awaited: 3
T3 Timer Status:
Remaining Time: 239
T2 Timer Status:
Remaining Time: 59
IS-IS(1) Level-2 Restart Status
Restart Interval: 150
SA Bit Supported
Total Number of Interfaces = 1
Restart Status: RESTARTING
Number of LSPs Awaited: 3
T3 Timer Status:
Remaining Time: 239
T2 Timer Status:
Remaining Time: 59
I. Network requirements
l
Switch A, Switch B and Switch C belong to the
same autonomous system and the same OSPF domain. They are connected through
OSPF.
l
Switch A acts as the GR Restarter, and Switch B
and Switch C are the GR Helpers and remain OOB synchronized with Switch A
through GR mechanism.
II. Network diagram

Figure 1-6 OSPF-based Graceful Restart configuration example
III. Configuration procedure
1)
Configure Switch A.
<SysnameA> system-view
[SysnameA] interface vlan-interface 100
[SysnameA-Vlan-interface100] ip
address 192.1.1.1 255.255.255.0
[SysnameA-Vlan-interface100] quit
[SysnameA] router id 1.1.1.1
[SysnameA] ospf 100
[SysnameA-ospf-100] enable
link-local-signaling
[SysnameA-ospf-100] enable out-of-band-resynchronization
[SysnameA-ospf-100] graceful-restart
[SysnameA-ospf-100] area 0
[SysnameA-ospf-100-area-0.0.0.0]
network 192.1.1.0 0.0.0.255
[SysnameA-ospf-100-area-0.0.0.0] return
2)
Configure Switch B.
<SysnameB> system-view
[SysnameB] acl number 2000
[SysnameB-acl-basic-2000] rule 10
permit source 192.1.1.1 0.0.0.0
[SysnameB-acl-basic-2000] quit
[SysnameB] interface vlan-interface 100
[SysnameB-Vlan-interface100] ip
address 192.1.2.1 255.255.255.0
[SysnameB-Vlan-interface100] ospf
dr-priority 0
[SysnameB-Vlan-interface100] quit
[SysnameB] router id 2.2.2.2
[SysnameB] ospf 100
[SysnameB-ospf-100] enable link-local-signaling
[SysnameB-ospf-100] enable out-of-band-resynchronization
[SysnameB-ospf-100] graceful-restart
[SysnameB-ospf-100] area 0
[SysnameB-ospf-100-area-0.0.0.0] network
192.1.2.0 0.0.0.255
3)
Configure Switch C.
<SysnameC> system-view
[SysnameC] acl number 2000
[SysnameC-acl-basic-2000] rule 10
permit source 192.1.1.1 0.0.0.0
[SysnameC-acl-basic-2000] quit
[SysnameC] interface vlan-interface 100
[SysnameC-Vlan-interface100] ip
address 192.1.3.1 255.255.255.0
[SysnameC-Vlan-interface100] ospf
dr-priority 2
[SysnameC-Vlan-interface100] quit
[SysnameC] router id 3.3.3.3
[SysnameC] ospf process 100
[SysnameC-ospf-100] enable link-local-signaling
[SysnameC-ospf-100] enable out-of-band-resynchronization
[SysnameC-ospf-100] graceful-restart
[SysnameC-ospf-100] area 0
[SysnameC-ospf-100-area-0.0.0.0] network
192.1.3.0 0.0.0.255