Network Working Group J. Moy Request for Comments: 3623 Sycamore Networks Category: Standards Track P. Pillay-Esnault Juniper Networks A. Lindem Redback Networks November 2003 Graceful OSPF Restart
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for
租赁合同备案
improvements. Plea refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Rerved.
Abstract
This memo documents an enhancement to the OSPF routing protocol,
whereby an OSPF router can stay on the forwarding path even as its
OSPF software is restarted. This is called "graceful restart" or
"non-stop forwarding". A restarting router may not be capable of
adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops, the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the
restarting router’s neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes
assumptions upon the operating environment of the restarting router; the assumptions are also documented.
Moy, et al. Standards Track [Page 1]
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Operation of Restarting Router . . . . . . . . . . . . . . . . 3 2.1. Entering Graceful Restart. . . . . . . . . . . . . . . . 4 2.2. When to Exit Graceful Restart. . . . . . . . . . . . . . 5
2.3. Actions on Exiting Graceful Restart. . . . . . . . . . . 6
3. Operation of Helper Neighbor . . . . . . . . . . . . . . . . . 7 3.1. Entering Helper Mode . . . . . . . . . . . . . . . . . . 7
3.2. Exiting Helper Mode. . . . . . . . . . . . . . . . . . . 8
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 9
5. Unplanned Outages. . . . . . . . . . . . . . . . . . . . . . . 10
6. Interaction with Traffic Engineering . . . . . . . . . . . . . 11
7. Possible Future Work . . . . . . . . . . . . . . . . . . . . . 11
8. Intellectual Property Rights Notice. . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
A. Grace-LSA Format . . . . . . . . . . . . . . . . . . . . . . . 13
B. Configurable Parameters. . . . . . . . . . . . . . . . . . . . 15 Security Considerations. . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors’ Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 18
1. Overview
Today many Internet routers implement a paration of control and
forwarding functions. Certain processors are dedicated to control
and management tasks such as OSPF routing, while other processors
perform the data forwarding tasks. This paration creates the
张俊海possibility of maintaining a router’s data forwarding capability
while the router’s control software is restarted/reloaded. We call
such a possibility "graceful restart" or "non-stop forwarding".
The OSPF protocol prents a problem to graceful restart whereby,
under normal operation, OSPF intentionally routes around a restarting router while it rebuilds its link-state databa. OSPF avoids the
restarting router to minimize the possibility of routing loops and/or black holes caud by lack of databa synchronization. Avoidance is accomplished by having the router’s neighbors reissue their LSAs,
omitting links to the restarting router.
However, if (a) the network topology remains stable and (b) the
restarting router is able to keep its forwarding table(s) across the restart, it would be safe to keep the restarting router on the
forwarding path. This memo documents an enhancement to OSPF that
makes such graceful restart possible, and automatically reverts back Moy, et al. Standards Track [Page 2]
to a standard OSPF restart for safety when network topology changes
are detected.
In a nutshell, the OSPF enhancements for graceful restart are as
follows:
- The router attempting a graceful restart originates link-local
Opaque-LSAs, herein called Grace-LSAs, announcing its intention to perform a graceful restart within a specified amount of time or
"grace period".
三年期贷款利率- During the grace period, its neighbors continue to announce the
restarting router in their LSAs as if it were fully adjacent
(i.e., OSPF neighbor state Full), but only if the network topology remains static (i.e., the contents of the LSAs in the link-state
databa having LS types 1-5,7 remain unchanged and periodic
refreshes are allowed).
总分总的作文There are two roles being played by OSPF routers during graceful
restart. First there is the router that is being restarted. The
operation of this router during graceful restart, including how the
router enters and exits graceful restart, is the subject of Section
2. Then there are the router’s neighbors, which must cooperate in
order for the restart to be graceful. During graceful restart, we
say that the neighbors are running in "helper mode". Section 3
covers the responsibilities of a router running in helper mode,
including entering and exiting helper mode.
2. Operation of Restarting Router
After the router restarts/reloads, it must change its OSPF processing somewhat until it re-establishes full adjacencies with all its former fully-adjacent neighbors. This time period, between the
restart/reload and the reestablishment of adjacencies, is called
"graceful restart". During graceful restart:
1) The restarting router does not originate LSAs with LS types 1- 5,7. Instead, the restarting router wants the other routers in the OSPF domain to calculate routes using the LSAs that it
originated prior to its restart. During this time, the
restarting router does not modify or flush received lf-
originated LSAs, (e Section 13.4 of [1]). Instead they are
accepted as valid. In particular, the grace-LSAs that the
restarting router originated before the restart are left in
place. Received lf-originated LSAs will be dealt with when
the router exits graceful restart (e Section 2.3).
Moy, et al. Standards Track [Page 3]
2) The restarting router runs its OSPF routing calculations, as
specified in Section 16 of [1]. This is necessary to return
any OSPF virtual links to operation. However, the restarting
router does *not* install OSPF routes into the system’s
forwarding table(s) and relies on the forwarding entries that
it installed prior to the restart.
3) If the restarting router determines that it was the Designated Router on a given gment prior to the restart, it elects
itlf as the Designated Router again. The restarting router
knows that it was the Designated Router if, while the
associated interface is in Waiting state, a Hello packet is
received from a neighbor listing the router as the Designated
Router.
Otherwi, the restarting router operates the same as any other OSPF router. It discovers neighbors using OSPF’s Hello protocol, elects
Designated and Backup Designated Routers, performs the Databa
Exchange procedure to initially synchronize link-state databas with its neighbors, and maintains this synchronization through flooding.
档案管理工作>总价合同The process of entering graceful restart, and of exiting graceful
restart (either successfully or not) are covered in the following
ctions.
2.1. Entering Graceful Restart
The router (call it Router X) is informed of the desire for its
graceful restart when an appropriate command is issued by the network operator. The network operator may also specify the length of the
grace period, or the necessary grace period may be calculated by the router’s OSPF software. In order to avoid the restarting router’s
LSAs from aging out, the grace period should not exceed LSRefreshTime (1800 cond) [1].
In preparation for the graceful restart, Router X must perform the
following actions before its software is restarted/reloaded:
(Note that common OSPF shutdown procedures are *not* performed,
since we want the other OSPF routers to act as if Router X remains in continuous rvice. For example, Router X does not flush its
locally originated LSAs, since we want them to remain in other
routers’ link-state databas throughout the restart period.)
1) Router X must ensure that its forwarding table(s) is/are up-
to-date and will remain in place across the restart.
Moy, et al. Standards Track [Page 4]
2) The router may need to prerve the cryptographic quence
numbers being ud on each interface in non-volatile storage.
An alternative is to u the router’s clock for cryptographic
quence number generation and ensure that the clock is
prerved across restarts (either on the same or redundant
route processors). If neither of the can be guaranteed, it
can take up to RouterDeadInterval conds after the restart
before adjacencies can be reestablished and this would force
the grace period to be lengthened greatly.
Router X then originates the grace-LSAs. The are link-local
Opaque-LSAs (e Appendix A). Their LS Age field is t to 0, and
the requested grace period (in conds) is inrted into the body of the grace-LSA. The preci contents of the grace-LSA are described
in Appendix A.
A grace-LSA is originated for each of the router’s OSPF interfaces.
If Router X wants to ensure that its neighbors receive the grace-
LSAs, it should retransmit the grace-LSAs until they are acknowledged (i.e., perform standard OSPF reliable flooding of the grace-LSAs).
If one or more fully adjacent neighbors do not receive grace-LSAs,
they will more than likely cau premature termination of the
graceful restart procedure (e Section 4).
After the grace-LSAs have been nt, the router should store the fact that it is performing graceful restart along with the length of the
requested grace period in non-volatile storage. (Note to
implementors: It may be easiest to simply store the absolute time of the end of the grace period).
The OSPF software should then be
restarted/reloaded. When the reloaded software starts executing the graceful restart, the protocol modifications in Section 2 are
followed. (Note that prior to the restart, the router does not know whether its neighbors are going to cooperate as "helpers"; the mere
reception of grace-LSAs does not imply acceptance of helper
responsibilities. This memo assumes that the router would want to
restart anyway, even if the restart is not going to be graceful).
2.2. When to Exit Graceful Restart
A Router X exits graceful restart when any of the following occurs:
1) Router X has reestablished all its adjacencies. Router X can
determine this by examining the router-LSAs that it last
originated before the restart (called the "pre-restart router- LSA"), and, on tho gments where the router is the
Designated Router, the pre-restart network-LSAs. The LSAs
will have been received from the helping neighbors, and need
not have been stored in non-volatile storage across the
Moy, et al. Standards Track [Page 5]
restart. All previous adjacencies will be listed as type-1 and type-2 links in the router-LSA, and as neighbors in the body of the network-LSA.
2) Router X receives an LSA that is inconsistent with its pre-
restart router-LSA. For example, X receives a router-LSA
originated by router Y that does not contain a link to X, even though X’s pre-start router-LSA did contain a link to Y. This indicates that either a) Y does not support graceful restart,
b) Y never received the grace-LSA or c) Y has terminated its
helper mode for some reason (Section 3.2). A special ca of
孕妇可以喝甜酒吗LSA inconsistency is when Router X establishes an adjacency
灵龟塔with router Y and doesn’t receive an instance of its own pre-
restart router LSA.
3) The grace period expires.
2.3. Actions on Exiting Graceful Restart
Upon exiting "graceful restart", the restarting router reverts back
to completely normal OSPF operation, reoriginating LSAs bad on the router’s current state and updating its forwarding table(s) bad on the current contents of the link-state databa. In particular, the following actions should be performed when exiting, either
successfully or unsuccessfully, graceful restart:
1) The router should reoriginate its router-LSAs for all attached areas in order to make sure they have the correct contents.
2) The router should reoriginate network-LSAs on all gments
where it is the Designated Router.
3) The router reruns its OSPF routing calculations (Section 16 of [1]), this time installing the results into the system
forwarding table, and originating summary-LSAs, Type-7 LSAs and AS-external-LSAs as necessary.
4) Any remnant entries in the system forwarding table that were
installed before the restart, but that are no longer valid,
should be removed.
5) Any received lf-originated LSAs that are no longer valid
should be flushed.
6) Any grace-LSAs that the router originated should be flushed. Moy, et al. Standards Track [Page 6]
