JUNOS™ Software

High Availability Configuration Guide

Release 8.5

Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Part Number: 530-021940-01, Revision 1
This product includes the Envoy SNMP Engine, developed by Epilogue Technology, an Integrated Systems Company. Copyright © 1986-1997, Epilogue
Technology Corporation. All rights reserved. This program and its documentation were developed at private expense, and no part of them is in the public
domain.

This product includes memory allocation software developed by Mark Moraes, copyright © 1988, 1989, 1993, University of Toronto.

This product includes FreeBSD software developed by the University of California, Berkeley, and its contributors. All of the documentation and software
included in the 4.4BSD and 4.4BSD-Lite Releases is copyrighted by the Regents of the University of California. Copyright © 1979, 1980, 1983, 1986, 1988,
1989, 1991, 1992, 1993, 1994. The Regents of the University of California. All rights reserved.

GateD software copyright © 1995, the Regents of the University. All rights reserved. Gate Daemon was originated and developed through release 3.0 by
Cornell University and its collaborators. Gated is based on Kirton’s EGP, UC Berkeley’s routing daemon (routed), and DCN’s HELLO routing protocol.
Development of Gated has been supported in part by the National Science Foundation. Portions of the GateD software copyright © 1988, Regents of the
University of California. All rights reserved. Portions of the GateD software copyright © 1991, D. L. S. Associates.

This product includes software developed by Maker Communications, Inc., copyright © 1996, 1997, Maker Communications, Inc.

Juniper Networks, the Juniper Networks logo, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other
countries. JUNOS and JUNOSe are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service
marks are the property of their respective owners.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or
otherwise revise this publication without notice.

Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are owned by or licensed
to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347,
6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.

JUNOS™ Software High Availability Configuration Guide

Release 8.5
Copyright © 2007, Juniper Networks, Inc.
All rights reserved. Printed in USA.

Writing: Andrea Couvrey

Editing: Ben Mann
Illustration: Nathaniel Woodward
Cover Design: Edmonds Design

Revision History
12 October 2007—Revision 1

The information in this document is current as of the date listed in the revision history.

YEAR 2000 NOTICE

Juniper Networks hardware and software products are Year 2000 compliant. The JUNOS software has no known time-related limitations through the year
2038. However, the NTP application is known to have some difficulty in the year 2036.

ii ■
End User License Agreement

READ THIS END USER LICENSE AGREEMENT (“AGREEMENT”) BEFORE DOWNLOADING, INSTALLING, OR USING THE SOFTWARE. BY DOWNLOADING,
INSTALLING, OR USING THE SOFTWARE OR OTHERWISE EXPRESSING YOUR AGREEMENT TO THE TERMS CONTAINED HEREIN, YOU (AS CUSTOMER
OR IF YOU ARE NOT THE CUSTOMER, AS A REPRESENTATIVE/AGENT AUTHORIZED TO BIND THE CUSTOMER) CONSENT TO BE BOUND BY THIS
AGREEMENT. IF YOU DO NOT OR CANNOT AGREE TO THE TERMS CONTAINED HEREIN, THEN (A) DO NOT DOWNLOAD, INSTALL, OR USE THE SOFTWARE,
AND (B) YOU MAY CONTACT JUNIPER NETWORKS REGARDING LICENSE TERMS.

1. The Parties. The parties to this Agreement are Juniper Networks, Inc. and its subsidiaries (collectively “Juniper”), and the person or organization that
originally purchased from Juniper or an authorized Juniper reseller the applicable license(s) for use of the Software (“Customer”) (collectively, the “Parties”).

2. The Software. In this Agreement, “Software” means the program modules and features of the Juniper or Juniper-supplied software, and updates and
releases of such software, for which Customer has paid the applicable license or support fees to Juniper or an authorized Juniper reseller. “Embedded
Software” means Software which Juniper has embedded in the Juniper equipment.

3. License Grant. Subject to payment of the applicable fees and the limitations and restrictions set forth herein, Juniper grants to Customer a non-exclusive
and non-transferable license, without right to sublicense, to use the Software, in executable form only, subject to the following use restrictions:

a. Customer shall use the Embedded Software solely as embedded in, and for execution on, Juniper equipment originally purchased by Customer from
Juniper or an authorized Juniper reseller.

b. Customer shall use the Software on a single hardware chassis having a single processing unit, or as many chassis or processing units for which Customer
has paid the applicable license fees; provided, however, with respect to the Steel-Belted Radius or Odyssey Access Client software only, Customer shall use
such Software on a single computer containing a single physical random access memory space and containing any number of processors. Use of the
Steel-Belted Radius software on multiple computers requires multiple licenses, regardless of whether such computers are physically contained on a single
chassis.

c. Product purchase documents, paper or electronic user documentation, and/or the particular licenses purchased by Customer may specify limits to
Customer’s use of the Software. Such limits may restrict use to a maximum number of seats, registered endpoints, concurrent users, sessions, calls,
connections, subscribers, clusters, nodes, realms, devices, links, ports or transactions, or require the purchase of separate licenses to use particular features,
functionalities, services, applications, operations, or capabilities, or provide throughput, performance, configuration, bandwidth, interface, processing,
temporal, or geographical limits. In addition, such limits may restrict the use of the Software to managing certain kinds of networks or require the Software
to be used only in conjunction with other specific Software. Customer’s use of the Software shall be subject to all such limitations and purchase of all applicable
licenses.

d. For any trial copy of the Software, Customer’s right to use the Software expires 30 days after download, installation or use of the Software. Customer
may operate the Software after the 30-day trial period only if Customer pays for a license to do so. Customer may not extend or create an additional trial
period by re-installing the Software after the 30-day trial period.

e. The Global Enterprise Edition of the Steel-Belted Radius software may be used by Customer only to manage access to Customer’s enterprise network.
Specifically, service provider customers are expressly prohibited from using the Global Enterprise Edition of the Steel-Belted Radius software to support any
commercial network access services.

The foregoing license is not transferable or assignable by Customer. No license is granted herein to any user who did not originally purchase the applicable
license(s) for the Software from Juniper or an authorized Juniper reseller.

4. Use Prohibitions. Notwithstanding the foregoing, the license provided herein does not permit the Customer to, and Customer agrees not to and shall
not: (a) modify, unbundle, reverse engineer, or create derivative works based on the Software; (b) make unauthorized copies of the Software (except as
necessary for backup purposes); (c) rent, sell, transfer, or grant any rights in and to any copy of the Software, in any form, to any third party; (d) remove
any proprietary notices, labels, or marks on or in any copy of the Software or any product in which the Software is embedded; (e) distribute any copy of
the Software to any third party, including as may be embedded in Juniper equipment sold in the secondhand market; (f) use any ‘locked’ or key-restricted
feature, function, service, application, operation, or capability without first purchasing the applicable license(s) and obtaining a valid key from Juniper, even
if such feature, function, service, application, operation, or capability is enabled without a key; (g) distribute any key for the Software provided by Juniper
to any third party; (h) use the Software in any manner that extends or is broader than the uses purchased by Customer from Juniper or an authorized Juniper
reseller; (i) use the Embedded Software on non-Juniper equipment; (j) use the Software (or make it available for use) on Juniper equipment that the Customer
did not originally purchase from Juniper or an authorized Juniper reseller; (k) disclose the results of testing or benchmarking of the Software to any third
party without the prior written consent of Juniper; or (l) use the Software in any manner other than as expressly provided herein.

5. Audit. Customer shall maintain accurate records as necessary to verify compliance with this Agreement. Upon request by Juniper, Customer shall furnish
such records to Juniper and certify its compliance with this Agreement.

6. Confidentiality. The Parties agree that aspects of the Software and associated documentation are the confidential property of Juniper. As such, Customer
shall exercise all reasonable commercial efforts to maintain the Software and associated documentation in confidence, which at a minimum includes
restricting access to the Software to Customer employees and contractors having a need to use the Software for Customer’s internal business purposes.

■ iii
7. Ownership. Juniper and Juniper's licensors, respectively, retain ownership of all right, title, and interest (including copyright) in and to the Software,
associated documentation, and all copies of the Software. Nothing in this Agreement constitutes a transfer or conveyance of any right, title, or interest in
the Software or associated documentation, or a sale of the Software, associated documentation, or copies of the Software.

8. Warranty, Limitation of Liability, Disclaimer of Warranty. The warranty applicable to the Software shall be as set forth in the warranty statement that
accompanies the Software (the “Warranty Statement”). Nothing in this Agreement shall give rise to any obligation to support the Software. Support services
may be purchased separately. Any such support shall be governed by a separate, written support services agreement. TO THE MAXIMUM EXTENT PERMITTED
BY LAW, JUNIPER SHALL NOT BE LIABLE FOR ANY LOST PROFITS, LOSS OF DATA, OR COSTS OR PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES,
OR FOR ANY SPECIAL, INDIRECT, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, THE SOFTWARE, OR ANY JUNIPER OR
JUNIPER-SUPPLIED SOFTWARE. IN NO EVENT SHALL JUNIPER BE LIABLE FOR DAMAGES ARISING FROM UNAUTHORIZED OR IMPROPER USE OF ANY
JUNIPER OR JUNIPER-SUPPLIED SOFTWARE. EXCEPT AS EXPRESSLY PROVIDED IN THE WARRANTY STATEMENT TO THE EXTENT PERMITTED BY LAW,
JUNIPER DISCLAIMS ANY AND ALL WARRANTIES IN AND TO THE SOFTWARE (WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE), INCLUDING
ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT DOES JUNIPER
WARRANT THAT THE SOFTWARE, OR ANY EQUIPMENT OR NETWORK RUNNING THE SOFTWARE, WILL OPERATE WITHOUT ERROR OR INTERRUPTION,
OR WILL BE FREE OF VULNERABILITY TO INTRUSION OR ATTACK. In no event shall Juniper’s or its suppliers’ or licensors’ liability to Customer, whether
in contract, tort (including negligence), breach of warranty, or otherwise, exceed the price paid by Customer for the Software that gave rise to the claim, or
if the Software is embedded in another Juniper product, the price paid by Customer for such other product. Customer acknowledges and agrees that Juniper
has set its prices and entered into this Agreement in reliance upon the disclaimers of warranty and the limitations of liability set forth herein, that the same
reflect an allocation of risk between the Parties (including the risk that a contract remedy may fail of its essential purpose and cause consequential loss),
and that the same form an essential basis of the bargain between the Parties.

9. Termination. Any breach of this Agreement or failure by Customer to pay any applicable fees due shall result in automatic termination of the license
granted herein. Upon such termination, Customer shall destroy or return to Juniper all copies of the Software and related documentation in Customer’s
possession or control.

10. Taxes. All license fees for the Software are exclusive of taxes, withholdings, duties, or levies (collectively “Taxes”). Customer shall be responsible for
paying Taxes arising from the purchase of the license, or importation or use of the Software.

11. Export. Customer agrees to comply with all applicable export laws and restrictions and regulations of any United States and any applicable foreign
agency or authority, and not to export or re-export the Software or any direct product thereof in violation of any such restrictions, laws or regulations, or
without all necessary approvals. Customer shall be liable for any such violations. The version of the Software supplied to Customer may contain encryption
or other capabilities restricting Customer’s ability to export the Software without an export license.

12. Commercial Computer Software. The Software is “commercial computer software” and is provided with restricted rights. Use, duplication, or disclosure
by the United States government is subject to restrictions set forth in this Agreement and as provided in DFARS 227.7201 through 227.7202-4, FAR 12.212,
FAR 27.405(b)(2), FAR 52.227-19, or FAR 52.227-14(ALT III) as applicable.

13. Interface Information. To the extent required by applicable law, and at Customer's written request, Juniper shall provide Customer with the interface
information needed to achieve interoperability between the Software and another independently created program, on payment of applicable fee, if any.
Customer shall observe strict obligations of confidentiality with respect to such information and shall use such information in compliance with any applicable
terms and conditions upon which Juniper makes such information available.

14. Third Party Software. Any licensor of Juniper whose software is embedded in the Software and any supplier of Juniper whose products or technology
are embedded in (or services are accessed by) the Software shall be a third party beneficiary with respect to this Agreement, and such licensor or vendor
shall have the right to enforce this Agreement in its own name as if it were Juniper. In addition, certain third party software may be provided with the
Software and is subject to the accompanying license(s), if any, of its respective owner(s). To the extent portions of the Software are distributed under and
subject to open source licenses obligating Juniper to make the source code for such portions publicly available (such as the GNU General Public License
(“GPL”) or the GNU Library General Public License (“LGPL”)), Juniper will make such source code portions (including Juniper modifications, as appropriate)
available upon request for a period of up to three years from the date of distribution. Such request can be made in writing to Juniper Networks, Inc., 1194
N. Mathilda Ave., Sunnyvale, CA 94089, ATTN: General Counsel. You may obtain a copy of the GPL at http://www.gnu.org/licenses/gpl.html, and a copy of
the LGPL at http://www.gnu.org/licenses/lgpl.html.

15. Miscellaneous. This Agreement shall be governed by the laws of the State of California without reference to its conflicts of laws principles. The provisions
of the U.N. Convention for the International Sale of Goods shall not apply to this Agreement. For any disputes arising under this Agreement, the Parties
hereby consent to the personal and exclusive jurisdiction of, and venue in, the state and federal courts within Santa Clara County, California. This Agreement
constitutes the entire and sole agreement between Juniper and the Customer with respect to the Software, and supersedes all prior and contemporaneous
agreements relating to the Software, whether oral or written (including any inconsistent terms contained in a purchase order), except that the terms of a
separate written agreement executed by an authorized Juniper representative and Customer shall govern to the extent such terms are inconsistent or conflict
with terms contained herein. No modification to this Agreement nor any waiver of any rights hereunder shall be effective unless expressly assented to in
writing by the party to be charged. If any portion of this Agreement is held invalid, the Parties agree that such invalidity shall not affect the validity of the
remainder of this Agreement. This Agreement and associated documentation has been written in the English language, and the Parties agree that the English
version will govern. (For Canada: Les parties aux présentés confirment leur volonté que cette convention de même que tous les documents y compris tout
avis qui s'y rattaché, soient redigés en langue anglaise. (Translation: The parties confirm that this Agreement and all related documentation is and will be
in the English language)).

iv ■
Abbreviated Table of Contents
About This Guide xix

Part 1 Overview
Chapter 1 High Availability Overview 3

Part 2 Routing Engine and Switching Control Board Redundancy

Chapter 2 Routing Engine and Switching Control Board Redundancy Overview 11
Chapter 3 Routing Engine and Switching Control Board Redundancy Configuration
Guidelines 19
Chapter 4 Summary of Routing Engine and Control Board Switching Redundancy
Statements 31

Part 3 Graceful Routing Engine Switchover

Chapter 5 Graceful Routing Engine Switchover Overview 41
Chapter 6 Graceful Routing Engine Switchover Configuration Guidelines 53
Chapter 7 Summary of Graceful Routing Engine Switchover Configuration
Statements 55

Part 4 Nonstop Bridging

Chapter 8 Nonstop Bridging Overview 59
Chapter 9 Nonstop Bridging Configuration Guidelines 63
Chapter 10 Summary of Nonstop Bridging Statements 65

Part 5 Nonstop Routing

Chapter 11 Nonstop Routing Overview 69
Chapter 12 Nonstop Routing Configuration Guidelines 75
Chapter 13 Summary of Nonstop Routing Configuration Statements 81

Part 6 Graceful Restart

Chapter 14 Graceful Restart Overview 87
Chapter 15 Graceful Restart Configuration Guidelines 95
Chapter 16 Summary of Graceful Restart Configuration Statements 133

Abbreviated Table of Contents ■ v

JUNOS 8.5 High Availability Configuration Guide

Part 7 Virtual Router Redundancy Protocol

Chapter 17 VRRP Overview 147
Chapter 18 VRRP Configuration Guidelines 149
Chapter 19 Summary of VRRP Configuration Statements 163

Part 8 Index
Index 185
Index of Commands and Statements 191

vi ■
Table of Contents
About This Guide xix

Objectives .....................................................................................................xix
Audience ......................................................................................................xix
Supported Routing Platforms .........................................................................xx
Using the Indexes .........................................................................................xxi
Using the Examples in This Manual ..............................................................xxi
Merging a Full Example ..........................................................................xxi
Merging a Snippet .................................................................................xxii
Documentation Conventions .......................................................................xxii
List of Technical Publications ......................................................................xxiv
Documentation Feedback ............................................................................xxx
Requesting Support .....................................................................................xxx

Part 1 Overview

Chapter 1 High Availability Overview 3

Routing Engine Redundancy ...........................................................................3

Graceful Routing Engine Switchover ................................................................3
Nonstop Bridging ............................................................................................4
Nonstop Routing .............................................................................................4
Graceful Restart ...............................................................................................5
VRRP ...............................................................................................................5
Comparison of High Availability Features ........................................................6
Related Features ..............................................................................................7

Part 2 Routing Engine and Switching Control Board Redundancy

Chapter 2 Routing Engine and Switching Control Board Redundancy

Overview 11

Routing Engine Redundancy .........................................................................11

Platform Support ....................................................................................12
Conditions That Trigger a Routing Engine Failover .................................13

Table of Contents ■ vii

JUNOS 8.5 High Availability Configuration Guide

Default Routing Engine Redundancy Behavior ........................................13

Situations That Require You to Halt Routing Engines ..............................14
Switching Control Board Redundancy ...........................................................14
Redundant CFEBs on the M10i Router ....................................................15
Redundant FEBs on the M120 Router .....................................................15
Redundant SSBs on the M20 Router .......................................................17
Redundant SFMs on the M40e and M160 Routers ..................................18

Chapter 3 Routing Engine and Switching Control Board Redundancy

Configuration Guidelines 19

Chassis Redundancy Hierarchy .....................................................................19

Configuring Routing Engine Redundancy ......................................................20
Modifying the Default Routing Engine Mastership ...................................20
Copying a Configuration File from One Routing Engine to the Other ......21
Loading a Software Package from the Other Routing Engine ..................22
Changing to the Backup Routing Engine If It Detects a Hard Disk Error
on the Master Routing Engine ..........................................................23
Changing to the Backup Routing Engine Without Interruption to Packet
Forwarding .......................................................................................23
Changing to the Backup Routing Engine If It Detects Loss of Keepalive
Signal ...............................................................................................23
Routing Engines on a TX Matrix Platform ...............................................24
Manually Switching Routing Engine Mastership ......................................25
Verifying Routing Engine Redundancy Status .........................................25
Configuring CFEB Redundancy on the M10i Router ......................................26
Configuring FEB Redundancy on the M120 Router ........................................28
Example: Configuring FEB Redundancy ..................................................28
Configuring SFM Redundancy on M40e and M160 Routers ...........................29
Configuring SSB Redundancy on the M20 Router ..........................................30

Chapter 4 Summary of Routing Engine and Control Board Switching Redundancy

Statements 31

cfeb ...............................................................................................................31
description ....................................................................................................32
failover ..........................................................................................................32
feb .................................................................................................................33
keepalive-time ...............................................................................................34
no-auto-failover .............................................................................................34
on-disk-failure ...............................................................................................35
on-loss-of-keepalives .....................................................................................35
redundancy ...................................................................................................36
redundancy-group .........................................................................................37
routing-engine ...............................................................................................37
sfm ................................................................................................................38
ssb ................................................................................................................38

viii ■ Table of Contents

 Table of Contents

Part 3 Graceful Routing Engine Switchover

Chapter 5 Graceful Routing Engine Switchover Overview 41

Graceful Routing Engine Switchover Concepts ..............................................41

Graceful Routing Engine Switchover System Requirements ...........................44
Graceful Routing Engine Switchover Platform Support ............................44
Graceful Routing Engine Switchover Feature Support .............................44
Graceful Routing Engine Switchover and Extended DHCP Relay
Agent ................................................................................................45
Graceful Routing Engine Switchover DPC Support ..................................46
Graceful Routing Engine Switchover PIC Support ....................................46

Chapter 6 Graceful Routing Engine Switchover Configuration Guidelines 53

Configuring Graceful Routing Engine Switchover ...........................................53

Enabling Graceful Routing Engine Switchover .........................................53
Synchronizing the Routing Engine Configuration ....................................54
Verifying Graceful Routing Engine Switchover Operation ........................54
Requirements for Routers with a Backup Router Configuration .....................54
Resetting Local Statistics ...............................................................................54

Chapter 7 Summary of Graceful Routing Engine Switchover Configuration

Statements 55

graceful-switchover .......................................................................................55

Part 4 Nonstop Bridging

Chapter 8 Nonstop Bridging Overview 59

Nonstop Bridging Concepts ...........................................................................59

Nonstop Bridging System Requirements .......................................................61
Platform Support ....................................................................................61
Protocol Support .....................................................................................62

Chapter 9 Nonstop Bridging Configuration Guidelines 63

Configuring Nonstop Bridging .......................................................................63

Enabling Nonstop Bridging .....................................................................63
Synchronizing the Routing Engine Configuration ....................................63
Verifying Nonstop Bridging Operation ....................................................64

Table of Contents ■ ix
JUNOS 8.5 High Availability Configuration Guide

Chapter 10 Summary of Nonstop Bridging Statements 65

nonstop-bridging ...........................................................................................65

Part 5 Nonstop Routing

Chapter 11 Nonstop Routing Overview 69

Nonstop Routing Concepts ............................................................................69

Nonstop Routing System Requirements ........................................................71
Platform Support ....................................................................................72
Protocol Support .....................................................................................72
BFD Support ...........................................................................................72

Chapter 12 Nonstop Routing Configuration Guidelines 75

Configuring Nonstop Routing ........................................................................75

Enabling Nonstop Routing ......................................................................75
Synchronizing the Routing Engine Configuration ....................................76
Verifying Nonstop Routing Operation .....................................................76
Tracing Nonstop Routing Synchronization Events .........................................77
Resetting Local Statistics ...............................................................................77
Example: Configuring Nonstop Routing .........................................................78

Chapter 13 Summary of Nonstop Routing Configuration Statements 81

commit synchronize ......................................................................................81

nonstop-routing .............................................................................................82
traceoptions ..................................................................................................83

Part 6 Graceful Restart

Chapter 14 Graceful Restart Overview 87

Graceful Restart Concepts .............................................................................87

Graceful Restart System Requirements ..........................................................88
Aggregate and Static Routes ..........................................................................89
Routing Protocols ..........................................................................................89
BGP .........................................................................................................89
ES-IS .......................................................................................................90
IS-IS ........................................................................................................90
OSPF and OSPFv3 ..................................................................................90
PIM Sparse Mode ....................................................................................91
RIP and RIPng .........................................................................................91

x ■ Table of Contents
 Table of Contents

MPLS-Related Protocols .................................................................................91

LDP .........................................................................................................91
RSVP .......................................................................................................92
CCC and TCC ..........................................................................................92
Layer 2 and Layer 3 VPNs .............................................................................92
Logical Routers ..............................................................................................93

Chapter 15 Graceful Restart Configuration Guidelines 95

Configuring Aggregate and Static Route Graceful Restart ...............................95

Configuring Routing Protocols Graceful Restart .............................................95
Configuring Graceful Restart Globally ......................................................96
Configuring Graceful Restart Options for BGP .........................................96
Configuring Graceful Restart Options for ES-IS ........................................97
Configuring Graceful Restart Options for IS-IS .........................................97
Configuring Graceful Restart Options for OSPF and OSPFv3 ...................98
Configuring Graceful Restart Options for RIP and RIPng .........................99
Configuring Graceful Restart Options for PIM Sparse Mode ....................99
Tracking Graceful Restart Events ..........................................................100
Configuring Graceful Restart for MPLS-Related Protocols .............................100
Configuring Graceful Restart Globally ....................................................101
Configuring Graceful Restart Options for RSVP, CCC, and TCC .............101
Configuring Graceful Restart Options for LDP .......................................102
Configuring VPN Graceful Restart ................................................................103
Configuring Graceful Restart Globally ....................................................103
Configuring Graceful Restart for the Routing Instance ...........................103
Configuring Logical Router Graceful Restart ................................................104
Configuring Graceful Restart Globally ....................................................104
Configuring Graceful Restart for a Routing Instance ..............................105
Verifying Graceful Restart Operation ...........................................................105
Graceful Restart Operational Mode Commands ....................................106
Verifying BGP Graceful Restart ..............................................................106
Verifying IS-IS and OSPF Graceful Restart .............................................107
Verifying CCC and TCC Graceful Restart ...............................................107
Example: Configuring Graceful Restart ........................................................108

Chapter 16 Summary of Graceful Restart Configuration Statements 133

disable .........................................................................................................133
graceful-restart ............................................................................................134
helper-disable ..............................................................................................135
maximum-helper-recovery-time ..................................................................135
maximum-helper-restart-time .....................................................................136
maximum-recovery-time .............................................................................136
notify-duration ............................................................................................137
no-strict-lsa-checking ...................................................................................137
recovery-time ..............................................................................................138
restart-duration ...........................................................................................139
restart-time .................................................................................................140

Table of Contents ■ xi
JUNOS 8.5 High Availability Configuration Guide

stale-routes-time ..........................................................................................141
traceoptions ................................................................................................142

Part 7 Virtual Router Redundancy Protocol

Chapter 17 VRRP Overview 147

Chapter 18 VRRP Configuration Guidelines 149

VRRP Configuration Hierarchy ....................................................................149

VRRP for IPv6 Configuration Hierarchy .......................................................150
VRRP Trace and Startup Configuration Statements .....................................150
Configuring Basic VRRP Support .................................................................151
Configuring VRRP Authentication (IPv4 Only) .............................................153
Configuring the Advertisement Interval for the VRRP Master Router ...........153
Modifying the Advertisement Interval in Seconds .................................154
Modifying the Advertisement Interval in Milliseconds ...........................154
Configuring a Backup Router to Preempt the Master Router ........................155
Modifying the Preemption Hold-Time Value .........................................155
Configuring an Interface to Accept Packets Destined for the Virtual IP
Address .................................................................................................155
Configuring a Logical Interface to Be Tracked ..............................................156
Tracing VRRP Operations ............................................................................157
Configuring the Silent Period .......................................................................158
Configuring Passive ARP Learning for Backup VRRP Routers ......................158
Example: Configuring VRRP ........................................................................159
Example: Configuring VRRP for IPv6 ...........................................................161

Chapter 19 Summary of VRRP Configuration Statements 163

accept-data ..................................................................................................163
advertise-interval .........................................................................................164
authentication-key .......................................................................................165
authentication-type .....................................................................................166
bandwidth-threshold ...................................................................................167
fast-interval .................................................................................................168
hold-time .....................................................................................................169
inet6-advertise-interval ................................................................................170
interface ......................................................................................................171
no-accept-data .............................................................................................171
no-preempt .................................................................................................171
preempt ......................................................................................................172
priority ........................................................................................................173
priority-cost .................................................................................................174
priority-hold-time ........................................................................................175
startup-silent-period ....................................................................................175
traceoptions ................................................................................................176

xii ■ Table of Contents

 Table of Contents

track ............................................................................................................178
virtual-address .............................................................................................179
virtual-inet6-address ....................................................................................179
virtual-link-local-address ..............................................................................180
vrrp-group ...................................................................................................181
vrrp-inet6-group ..........................................................................................182

Part 8 Index

Index ...........................................................................................................185
Index of Commands and Statements ..........................................................191

Table of Contents ■ xiii

JUNOS 8.5 High Availability Configuration Guide

xiv ■ Table of Contents

List of Figures
Figure 1: Preparing for a Graceful Routing Engine Switchover .......................42
Figure 2: Graceful Routing Engine Switchover Process ..................................43
Figure 3: Nonstop Bridging Architecture and the Switchover Preparation
Process ...................................................................................................60
Figure 4: Nonstop Bridging Architecture During a Switchover .......................61
Figure 5: Nonstop Routing Architecture and the Switchover Preparation
Process ...................................................................................................70
Figure 6: Nonstop Routing Architecture During a Switchover ........................71
Figure 7: Layer 3 VPN Graceful Restart Topology ........................................108
Figure 8: Basic VRRP ...................................................................................148

List of Figures ■ xv
JUNOS 8.5 High Availability Configuration Guide

xvi ■ List of Figures

List of Tables
Table 1: Notice Icons ..................................................................................xxiii
Table 2: Text and Syntax Conventions ........................................................xxiii
Table 3: Technical Documentation for Supported Routing Platforms ..........xxiv
Table 4: JUNOS Software Network Operations Guides ...............................xxviii
Table 5: Additional Books Available Through
http://www.juniper.net/books ...............................................................xxix
Table 6: Comparison of High Availability Features ..........................................6
Table 7: Routing Engine Mastership Log ........................................................25
Table 8: Graceful Routing Engine Switchover Feature Support ......................44
Table 9: Graceful Routing Engine Switchover PIC Support .............................47
Table 10: Interface State and Priority Cost Usage ........................................157

List of Tables ■ xvii

JUNOS 8.5 High Availability Configuration Guide

xviii ■ List of Tables

About This Guide

This preface provides the following guidelines for using the JUNOS™ Software High
Availability Configuration Guide:
■ Objectives on page xix
■ Audience on page xix
■ Supported Routing Platforms on page xx
■ Using the Indexes on page xxi
■ Using the Examples in This Manual on page xxi
■ Documentation Conventions on page xxii
■ List of Technical Publications on page xxiv
■ Documentation Feedback on page xxx
■ Requesting Support on page xxx

Objectives
This guide is designed to provide an overview of high availability concepts and
techniques. By understanding the redundancy features of Juniper Networks routing
platforms and the JUNOS software, a network administrator can enhance the reliability
of a network and deliver highly available services to customers.

NOTE: This guide documents Release 8.5 of the JUNOS software. For additional
information about the JUNOS software—either corrections to or information that
might have been omitted from this guide—see the software release notes at
http://www.juniper.net/.

Audience
This guide is designed for network administrators who are configuring and monitoring
a Juniper Networks J-series, M-series, MX-series, or T-series routing platform.

Objectives ■ xix
JUNOS 8.5 High Availability Configuration Guide

To use this guide, you need a broad understanding of networks in general, the Internet
in particular, networking principles, and network configuration. You must also be
familiar with one or more of the following Internet routing protocols:
■ Border Gateway Protocol (BGP)
■ Distance Vector Multicast Routing Protocol (DVMRP)
■ Intermediate System-to-Intermediate System (IS-IS)
■ Internet Control Message Protocol (ICMP) router discovery
■ Internet Group Management Protocol (IGMP)
■ Multiprotocol Label Switching (MPLS)
■ Open Shortest Path First (OSPF)
■ Protocol-Independent Multicast (PIM)
■ Resource Reservation Protocol (RSVP)
■ Routing Information Protocol (RIP)
■ Simple Network Management Protocol (SNMP)

Personnel operating the equipment must be trained and competent; must not conduct
themselves in a careless, willfully negligent, or hostile manner; and must abide by
the instructions provided by the documentation.

Supported Routing Platforms

For the features described in this manual, the JUNOS software currently supports
the following routing platforms:
■ J-series
■ M-series
■ MX-series
■ T-series

xx ■ Supported Routing Platforms

 About This Guide

Using the Indexes

This reference contains two indexes: a complete index that includes topic entries,
and an index of statements and commands only.

In the index of statements and commands, an entry refers to a statement summary

section only. In the complete index, the entry for a configuration statement or
command contains at least two parts:
■ The primary entry refers to the statement summary section.
■ The secondary entry, usage guidelines, refers to the section in a configuration
guidelines chapter that describes how to use the statement or command.

Using the Examples in This Manual

If you want to use the examples in this manual, you can use the load merge or the
load merge relative command. These commands cause the software to merge the
incoming configuration into the current candidate configuration. If the example
configuration contains the top level of the hierarchy (or multiple hierarchies), the
example is a full example. In this case, use the load merge command.

If the example configuration does not start at the top level of the hierarchy, the
example is a snippet. In this case, use the load merge relative command. These
procedures are described in the following sections.

Merging a Full Example

To merge a full example, follow these steps:
1. From the HTML or PDF version of the manual, copy a configuration example
into a text file, save the file with a name, and copy the file to a directory on your
routing platform.

For example, copy the following configuration to a file and name the file
ex-script.conf. Copy the ex-script.conf file to the /var/tmp directory on your routing
platform.

system {
scripts {
commit {
file ex-script.xsl;
}
}
}
interfaces {
fxp0 {
disable;
unit 0 {
family inet {
address 10.0.0.1/24;
}
}
}

Using the Indexes ■ xxi

JUNOS 8.5 High Availability Configuration Guide

2. Merge the contents of the file into your routing platform configuration by issuing
the load merge configuration mode command:

[edit]
user@host#load merge /var/tmp/ex-script.conf
load complete

Merging a Snippet
To merge a snippet, follow these steps:
1. From the HTML or PDF version of the manual, copy a configuration snippet into
a text file, save the file with a name, and copy the file to a directory on your
routing platform.

For example, copy the following snippet to a file and name the file
ex-script-snippet.conf. Copy the ex-script-snippet.conf file to the /var/tmp directory
on your routing platform.

commit {
file ex-script-snippet.xsl; }

2. Move to the hierarchy level that is relevant for this snippet by issuing the following
configuration mode command:

[edit]
user@host#edit system scripts
[edit system scripts]

3. Merge the contents of the file into your routing platform configuration by issuing
the load merge relative configuration mode command:

[edit system scripts]

user@host#load merge relative /var/tmp/ex-script-snippet.conf
load complete

For more information about the load command, see the JUNOS CLI User Guide.

Documentation Conventions
Table 1 on page xxiii defines notice icons used in this guide.

xxii ■ Documentation Conventions

 About This Guide

Table 1: Notice Icons

Icon Meaning Description

Informational note Indicates important features or

instructions.

Caution Indicates a situation that might result in

loss of data or hardware damage.

Table 2 on page xxiii defines the text and syntax conventions used in this guide.

Table 2: Text and Syntax Conventions

Convention Description Examples

Bold text like this Represents text that you type. To enter configuration mode, type the
configure command:

user@host> configure

Fixed-width text like this Represents output that appears on the user@host> show chassis alarms
terminal screen. No alarms currently active

Italic text like this ■ Introduces important new terms. ■ A policy term is a named structure
■ Identifies book names. that defines match conditions and
actions.
■ Identifies RFC and Internet draft
titles. ■ JUNOS System Basics Configuration
Guide
■ RFC 1997, BGP Communities
Attribute

Italic text like this Represents variables (options for which Configure the machine’s domain name:
you substitute a value) in commands or
configuration statements. [edit]
root@# set system domain-name
domain-name

Plain text like this Represents names of configuration ■ To configure a stub area, include
statements, commands, files, and the stub statement at the [edit
directories; IP addresses; configuration protocols ospf area area-id]
hierarchy levels; or labels on routing hierarchy level.
platform components. ■ The console port is labeled
CONSOLE.

< > (angle brackets) Enclose optional keywords or variables. stub <default-metric metric>;

| (pipe symbol) Indicates a choice between the mutually broadcast | multicast

exclusive keywords or variables on either
side of the symbol. The set of choices is (string1 | string2 | string3)
often enclosed in parentheses for clarity.

Documentation Conventions ■ xxiii

JUNOS 8.5 High Availability Configuration Guide

Table 2: Text and Syntax Conventions (continued)

Convention Description Examples

# (pound sign) Indicates a comment specified on the rsvp { # Required for dynamic MPLS only
same line as the configuration statement
to which it applies.

[ ] (square brackets) Enclose a variable for which you can community name members [
substitute one or more values. community-ids ]

Indention and braces ( { } ) Identify a level in the configuration [edit]

hierarchy. routing-options {
static {
; (semicolon) Identifies a leaf statement at a route default {
configuration hierarchy level. nexthop address;
retain;
}
}
}

J-Web GUI Conventions

Bold text like this Represents J-Web graphical user ■ In the Logical Interfaces box, select
interface (GUI) items you click or select. All Interfaces.
■ To cancel the configuration, click
Cancel.

> (bold right angle bracket) Separates levels in a hierarchy of J-Web In the configuration editor hierarchy,
selections. select Protocols>Ospf.

List of Technical Publications

Table 3 on page xxiv lists the software and hardware guides and release notes for
Juniper Networks J-series, M-series, MX-series, and T-series routing platforms and
describes the contents of each document. Table 4 on page xxviii lists the books included
in the Network Operations Guide series.

Table 5 on page xxix lists additional books on Juniper Networks solutions that you can
order through your bookstore. A complete list of such books is available at
http://www.juniper.net/books.

Table 3: Technical Documentation for Supported Routing Platforms

Book Description

JUNOS Software for Supported Routing Platforms

Access Privilege Explains how to configure access privileges in user classes by using
permission flags and regular expressions. Lists the permission flags
along with their associated command-line interface (CLI) operational
mode commands and configuration statements.

xxiv ■ List of Technical Publications

 About This Guide

Table 3: Technical Documentation for Supported Routing Platforms (continued)

Book Description

Class of Service Provides an overview of the class-of-service (CoS) functions of the

JUNOS software and describes how to configure CoS features,
including configuring multiple forwarding classes for transmitting
packets, defining which packets are placed into each output queue,
scheduling the transmission service level for each queue, and
managing congestion through the random early detection (RED)
algorithm.

CLI User Guide Describes how to use the JUNOS command-line interface (CLI) to
configure, monitor, and manage Juniper Networks routing
platforms. This material was formerly covered in the JUNOS System
Basics Configuration Guide.

Feature Guide Provides a detailed explanation and configuration examples for

several of the most complex features in the JUNOS software.

High Availability Provides an overview of hardware and software resources that

ensure a high level of continuous routing platform operation and
describes how to configure high availability (HA) features such as
nonstop routing (NSR) and graceful Routing Engine switchover
(GRES).

MPLS Applications Provides an overview of traffic engineering concepts and describes

how to configure traffic engineering protocols.

Multicast Protocols Provides an overview of multicast concepts and describes how to

configure multicast routing protocols.

Multiplay Solutions Describes how you can deploy IPTV and voice over IP (VoIP)
services in your network.

Network Interfaces Provides an overview of the network interface functions of the

JUNOS software and describes how to configure the network
interfaces on the routing platform.

Network Management Provides an overview of network management concepts and

describes how to configure various network management features,
such as SNMP and accounting options.

Policy Framework Provides an overview of policy concepts and describes how to

configure routing policy, firewall filters, and forwarding options.

Routing Protocols Provides an overview of routing concepts and describes how to

configure routing, routing instances, and unicast routing protocols.

Secure Configuration Guide for Common Criteria Provides an overview of secure Common Criteria and JUNOS-FIPS
and JUNOS-FIPS protocols for the JUNOS software and describes how to install and
configure secure Common Criteria and JUNOS-FIPS on a routing
platform.

Services Interfaces Provides an overview of the services interfaces functions of the

JUNOS software and describes how to configure the services
interfaces on the router.

List of Technical Publications ■ xxv

JUNOS 8.5 High Availability Configuration Guide

Table 3: Technical Documentation for Supported Routing Platforms (continued)

Book Description

Software Installation and Upgrade Guide Describes the JUNOS software components and packaging and
explains how to initially configure, reinstall, and upgrade the JUNOS
system software. This material was formerly covered in the JUNOS
System Basics Configuration Guide.

System Basics Describes Juniper Networks routing platforms and explains how
to configure basic system parameters, supported protocols and
software processes, authentication, and a variety of utilities for
managing your router on the network.

VPNs Provides an overview and describes how to configure Layer 2 and

Layer 3 virtual private networks (VPNs), virtual private LAN service
(VPLS), and Layer 2 circuits. Provides configuration examples.

JUNOS References
Hierarchy and RFC Reference Describes the JUNOS configuration mode commands. Provides a
hierarchy reference that displays each level of a configuration
hierarchy, and includes all possible configuration statements that
can be used at that level. This material was formerly covered in
the JUNOS System Basics Configuration Guide.

Interfaces Command Reference Describes the JUNOS software operational mode commands you
use to monitor and troubleshoot interfaces.

Routing Protocols and Policies Command Describes the JUNOS software operational mode commands you
Reference use to monitor and troubleshoot routing policies and protocols,
including firewall filters.

System Basics and Services Command Reference Describes the JUNOS software operational mode commands you
use to monitor and troubleshoot system basics, including
commands for real-time monitoring and route (or path) tracing,
system software management, and chassis management. Also
describes commands for monitoring and troubleshooting services
such as class of service (CoS), IP Security (IPSec), stateful firewalls,
flow collection, and flow monitoring.

System Log Messages Reference Describes how to access and interpret system log messages
generated by JUNOS software modules and provides a reference
page for each message.

J-Web User Guide

J-Web Interface User Guide Describes how to use the J-Web graphical user interface (GUI) to
configure, monitor, and manage Juniper Networks routing
platforms.

JUNOS API and Scripting Documentation

JUNOScript API Guide Describes how to use the JUNOScript application programming
interface (API) to monitor and configure Juniper Networks routing
platforms.

JUNOS XML API Configuration Reference Provides reference pages for the configuration tag elements in the
JUNOS XML API.

xxvi ■ List of Technical Publications

 About This Guide

Table 3: Technical Documentation for Supported Routing Platforms (continued)

Book Description

JUNOS XML API Operational Reference Provides reference pages for the operational tag elements in the
JUNOS XML API.

NETCONF API Guide Describes how to use the NETCONF API to monitor and configure
Juniper Networks routing platforms.

JUNOS Configuration and Diagnostic Automation Describes how to use the commit script and self-diagnosis features
Guide of the JUNOS software. This guide explains how to enforce custom
configuration rules defined in scripts, how to use commit script
macros to provide simplified aliases for frequently used
configuration statements, and how to configure diagnostic event
policies.

Hardware Documentation
Hardware Guide Describes how to install, maintain, and troubleshoot routing
platforms and components. Each platform has its own hardware
guide.

PIC Guide Describes the routing platform's Physical Interface Cards (PICs).
Each platform has its own PIC guide.

DPC Guide Describes the Dense Port Concentrators (DPCs) for all MX-series
routers.

JUNOScope Documentation
JUNOScope Software User Guide Describes the JUNOScope software graphical user interface (GUI),
how to install and administer the software, and how to use the
software to manage routing platform configuration files and monitor
routing platform operations.

J-series Routing Platform Documentation

Getting Started Guide Provides an overview, basic instructions, and specifications for
J-series routing platforms. The guide explains how to prepare your
site for installation, unpack and install the router and its
components, install licenses, and establish basic connectivity. Use
the Getting Started Guide for your router model.

Basic LAN and WAN Access Configuration Guide Explains how to configure the interfaces on J-series Services Routers
for basic IP routing with standard routing protocols, ISDN backup,
and digital subscriber line (DSL) connections.

Advanced WAN Access Configuration Guide Explains how to configure J-series Services Routers in virtual private
networks (VPNs) and multicast networks, configure data link
switching (DLSw) services, and apply routing techniques such as
policies, stateless and stateful firewall filters, IP Security (IPSec)
tunnels, and class-of-service (CoS) classification for safer, more
efficient routing.

Administration Guide Shows how to manage users and operations, monitor network
performance, upgrade software, and diagnose common problems
on J-series Services Routers.

Release Notes

List of Technical Publications ■ xxvii

JUNOS 8.5 High Availability Configuration Guide

Table 3: Technical Documentation for Supported Routing Platforms (continued)

Book Description

JUNOS Release Notes Summarize new features and known problems for a particular
software release, provide corrections and updates to published
JUNOS, JUNOScript, and NETCONF manuals, provide information
that might have been omitted from the manuals, and describe
upgrade and downgrade procedures.

Hardware Release Notes Describe the available documentation for the routing platform and
summarize known problems with the hardware and accompanying
software. Each platform has its own release notes.

JUNOScope Release Notes Contain corrections and updates to the published JUNOScope
manual, provide information that might have been omitted from
the manual, and describe upgrade and downgrade procedures.

J-series Services Router Release Notes Briefly describe Services Router features, identify known hardware
problems, and provide upgrade and downgrade instructions.

Table 4: JUNOS Software Network Operations Guides

Book Description

Baseline Describes the most basic tasks for running a network using Juniper
Networks products. Tasks include upgrading and reinstalling JUNOS
software, gathering basic system management information,
verifying your network topology, and searching log messages.

Interfaces Describes tasks for monitoring interfaces. Tasks include using

loopback testing and locating alarms.

MPLS Describes tasks for configuring, monitoring, and troubleshooting

an example MPLS network. Tasks include verifying the correct
configuration of the MPLS and RSVP protocols, displaying the status
and statistics of MPLS running on all routing platforms in the
network, and using the layered MPLS troubleshooting model to
investigate problems with an MPLS network.

MPLS Log Reference Describes MPLS status and error messages that appear in the output
of the show mpls lsp extensive command. The guide also describes
how and when to configure Constrained Shortest Path First (CSPF)
and RSVP trace options, and how to examine a CSPF or RSVP
failure in a sample network.

MPLS Fast Reroute Describes operational information helpful in monitoring and

troubleshooting an MPLS network configured with fast reroute
(FRR) and load balancing.

Hardware Describes tasks for monitoring M-series and T-series routing

platforms.

xxviii ■ List of Technical Publications

 About This Guide

Table 5: Additional Books Available Through http://www.juniper.net/books

Book Description

Interdomain Multicast Provides background and in-depth analysis of multicast routing using Protocol Independent
Routing Multicast sparse mode (PIM SM) and Multicast Source Discovery Protocol (MSDP); details
any-source and source-specific multicast delivery models; explores multiprotocol BGP (MBGP)
and multicast IS-IS; explains Internet Gateway Management Protocol (IGMP) versions 1, 2, and
3; lists packet formats for IGMP, PIM, and MSDP; and provides a complete glossary of multicast
terms.

JUNOS Cookbook Provides detailed examples of common JUNOS software configuration tasks, such as basic
router configuration and file management, security and access control, logging, routing policy,
firewalls, routing protocols, MPLS, and VPNs.

MPLS-Enabled Applications Provides an overview of Multiprotocol Label Switching (MPLS) applications (such as Layer 3
virtual private networks [VPNs], Layer 2 VPNs, virtual private LAN service [VPLS], and
pseudowires), explains how to apply MPLS, examines the scaling requirements of equipment
at different points in the network, and covers the following topics: point-to-multipoint label
switched paths (LSPs), DiffServ-aware traffic engineering, class of service, interdomain traffic
engineering, path computation, route target filtering, multicast support for Layer 3 VPNs, and
management and troubleshooting of MPLS networks.

OSPF and IS-IS: Choosing an Explores the full range of characteristics and capabilities for the two major link-state routing
IGP for Large-Scale Networks protocols: Open Shortest Path First (OSPF) and IS-IS. Explains architecture, packet types, and
addressing; demonstrates how to improve scalability; shows how to design large-scale networks
for maximum security and reliability; details protocol extensions for MPLS-based traffic
engineering, IPv6, and multitopology routing; and covers troubleshooting for OSPF and IS-IS
networks.

Routing Policy and Protocols Provides a brief history of the Internet, explains IP addressing and routing (Routing Information
for Multivendor IP Networks Protocol [RIP], OSPF, IS-IS, and Border Gateway Protocol [BGP]), explores ISP peering and
routing policies, and displays configurations for both Juniper Networks and other vendors'
routers.

The Complete IS-IS Protocol Provides the insight and practical solutions necessary to understand the IS-IS protocol and how
it works by using a multivendor, real-world approach.

List of Technical Publications ■ xxix

JUNOS 8.5 High Availability Configuration Guide

Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can
improve the documentation. You can send your comments to
techpubs-comments@juniper.net, or fill out the documentation feedback form at
http://www.juniper.net/techpubs/docbug/docbugreport.html. If you are using e-mail, be sure
to include the following information with your comments:
■ Document name
■ Document part number
■ Page number
■ Software release version

Requesting Support
For technical support, open a support case with the Case Manager link at
http://www.juniper.net/support/ or call 1-888-314-JTAC (from the United States, Canada,
or Mexico) or 1-408-745-9500 (from elsewhere).

xxx ■ Documentation Feedback

Part 1
Overview
■ High Availability Overview on page 3

Overview ■ 1
JUNOS 8.5 High Availability Configuration Guide

2 ■ Overview
Chapter 1
High Availability Overview

For Juniper Networks routing platforms running JUNOS software, high availability
refers to the hardware and software components that provide redundancy and
reliability for packet-based communications. This guide covers the following high
availability features:
■ Routing Engine Redundancy on page 3
■ Graceful Routing Engine Switchover on page 3
■ Nonstop Bridging on page 4
■ Nonstop Routing on page 4
■ Graceful Restart on page 5
■ VRRP on page 5
■ Comparison of High Availability Features on page 6
■ Related Features on page 7

Routing Engine Redundancy

Redundant Routing Engines are two Routing Engines that are installed in the same
routing platform. One functions as the master, while the other stands by as a backup
should the master Routing Engine fail. On routing platforms with dual Routing
Engines, network reconvergence takes place more quickly than on routing platforms
with a single Routing Engine.

Graceful Routing Engine Switchover

Graceful Routing Engine switchover (GRES) enables a routing platform with redundant
Routing Engines to continue forwarding packets, even if one Routing Engine fails.
Graceful Routing Engine switchover preserves interface and kernel information.
Traffic is not interrupted. However, graceful Routing Engine switchover does not
preserve the control plane. Neighboring routers detect that the router has experienced
a restart and react to the event in a manner prescribed by individual routing protocol
specifications. To preserve routing during a switchover, graceful Routing Engine
switchover must be combined with either graceful restart protocol extensions or
nonstop routing. For more information, see “Graceful Routing Engine Switchover
Overview” on page 41.

Routing Engine Redundancy ■ 3

JUNOS 8.5 High Availability Configuration Guide

Nonstop Bridging
Nonstop bridging enables a routing platform with redundant Routing Engines to
switch from a primary Routing Engine to a backup Routing Engine without losing
Layer 2 Control Protocol (L2CP) information. Nonstop bridging uses the same
infrastructure as graceful Routing Engine switchover to preserve interface and kernel
information. However, nonstop bridging also saves L2CP information by running
the Layer 2 Control Protocol process (l2cpd) on the backup Routing Engine.

NOTE: To use nonstop bridging, you must first enable graceful Routing Engine
switchover.

Nonstop bridging is supported for the following Layer 2 control protocols:

■ Spanning Tree Protocol (STP)
■ Rapid Spanning Tree Protocol (RSTP)
■ Multiple Spanning Tree Protocol (MSTP)

For more information, see “Nonstop Bridging Overview” on page 59.

Nonstop Routing
Nonstop routing (NSR) enables a routing platform with redundant Routing Engines
to switch from a primary Routing Engine to a backup Routing Engine without alerting
peer nodes that a change has occurred. Nonstop routing uses the same infrastructure
as graceful Routing Engine switchover to preserve interface and kernel information.
However, nonstop routing also preserves routing information and protocol sessions
by running the routing protocol process (rpd) on both Routing Engines. In addition,
nonstop routing preserves TCP connections maintained in the kernel.

NOTE: To use nonstop routing, you must also configure graceful Routing Engine
switchover.

Nonstop routing is supported for the following protocols:

■ Border Gateway Protocol (BGP)
■ End System-to-Intermediate System (ES-IS)
■ Intermediate System-to-Intermediate System (IS-IS)
■ Label Distribution Protocol (LDP)
■ Open Shortest Path First (OSPF)/OSPFv3

Routing protocols use bidirectional forwarding detection (BFD) for fast liveliness
detection of their neighbors. With nonstop routing enabled, BFD session state is
saved on both the master Routing Engine and the backup Routing Engine. When a
Routing Engine switchover event occurs, the BFD session state does not need to be

4 ■ Nonstop Bridging
 Chapter 1: High Availability Overview

restarted and peer routers continue to interface with the routing platform as if no
change had occurred.

For more information, see “Nonstop Routing Overview” on page 69.

Graceful Restart
Graceful restart provides extensions to routing protocols so that neighboring helper
routers restore routing information to a restarting router. These extensions signal
neighboring routers about the graceful restart and prevent the neighbors from reacting
to the router restart and from propagating the change in state to the network during
the graceful restart period. Neighbors provide the routing information that enables
the restarting router to stop and restart routing protocols without causing network
reconvergence.

Graceful restart is supported for the following protocols and applications:

■ BGP
■ ES-IS
■ IS-IS
■ OSPF/OSPFv3
■ PIM sparse mode
■ RIP/RIPng
■ MPLS-related protocols, including:
■ Label Distribution Protocol (LDP)
■ Resource Reservation Protocol (RSVP)

■ Circuit cross-connect (CCC)

■ Translational cross-connect (TCC)

■ Layer 2 and Layer 3 virtual private networks (VPNs)

For more information, see “Graceful Restart Overview” on page 87.

VRRP
For Ethernet, Fast Ethernet, Gigabit Ethernet, 10-Gigabit Ethernet, and logical
interfaces, you can configure the Virtual Router Redundancy Protocol (VRRP) or VRRP
for IPv6. VRRP enables hosts on a LAN to make use of redundant routing platforms
on that LAN without requiring more than the static configuration of a single default
route on the hosts. The VRRP routing platforms share the IP address corresponding
to the default route configured on the hosts. At any time, one of the VRRP routing
platforms is the master (active) and the others are backups. If the master fails, one
of the backup routers becomes the new master router, providing a virtual default
routing platform and allowing traffic on the LAN to be routed without relying on a
single routing platform. Using VRRP, a backup router can take over a failed default

Graceful Restart ■ 5
JUNOS 8.5 High Availability Configuration Guide

router within few seconds. This is done with minimum VRRP traffic and without any
interaction with the hosts.

Routers running VRRP dynamically elect master and backup routers. You can also
force assignment of master and backup routers using priorities from 1 through 255,
with 255 being the highest priority. In VRRP operation, the default master router
sends advertisements to backup routers at regular intervals. The default interval is
1 second. If a backup router does not receive an advertisement for a set period, the
backup router with the next highest priority takes over as master and begins
forwarding packets.

For more information, see “VRRP Overview” on page 147.

Comparison of High Availability Features

Table 6 on page 6 provides a comparison of high availability features. Remember
that:
■ Graceful Routing Engine switchover, nonstop bridging, and nonstop routing
require dual Routing Engines.
■ Nonstop bridging and nonstop routing require graceful Routing Engine switchover
to be configured.

NOTE: Because graceful restart helper mode (where a neighboring router assists in
a restart) is enabled by default (except for BGP), a router can both act as a helper
and be configured to support nonstop routing, although helper mode is not sustained
during a graceful Routing Engine switchover (GRES) event.

However, you cannot configure a router to undergo a graceful restart (by including
the graceful-restart statement at the [edit routing-options] hierarchy level) and configure
nonstop routing (by including the nonstop-routing option at the [edit routing-options]
hierarchy level) at the same time.

To obtain BGP helper mode support, you must first configure the router to undergo
a graceful restart. Therefore, when nonstop routing is enabled, BGP cannot provide
helper support.

Table 6: Comparison of High Availability Features

Feature Benefits Considerations

Dual Routing Engines without graceful When the switchover to the new master Traffic is interrupted while the Packet
Routing Engine switchover Routing Engine is complete, routing Forwarding Engine is reinitialized. All
convergence takes place and traffic is kernel and forwarding processes are
resumed. restarted.

Graceful Routing Engine switchover Traffic is not interrupted during the Graceful restart or nonstop routing must
switchover. Interface and kernel be configured in order to quickly restore
information is preserved. or to preserve routing information,
respectively.

6 ■ Comparison of High Availability Features

 Chapter 1: High Availability Overview

Table 6: Comparison of High Availability Features (continued)

Feature Benefits Considerations

Nonstop bridging Traffic is not interrupted during the Nonstop bridging can be used in
switchover. Interface, kernel, and Layer conjunction with nonstop routing.
2 control protocol information is
preserved.

Nonstop routing Traffic is not interrupted during the Unsupported protocols must be
switchover. Interface, kernel, and routing refreshed using the normal recovery
protocol information is preserved. mechanisms inherent in each protocol.
Neighbors are not required to have any
special configuration.

Graceful restart Traffic is not interrupted during the Neighbors are required to support
switchover. Interface and kernel graceful restart. The routing protocol
information is preserved. Graceful restart process (rpd) restarts. A graceful restart
protocol extensions quickly collect and interval is required. For certain
restore routing information from the protocols, a significant change in the
neighboring routers. network can cause graceful restart to
stop.

VRRP The backup router takes over the failed –

default router within few seconds. This
is done with minimum VRRP traffic and
without any interaction with the hosts.

Related Features
Related redundancy and reliability features include:
■ Redundant power supplies, host modules, host subsystems, and forwarding
boards. For more information, see the JUNOS System Basics Configuration Guide
and the JUNOS Hardware Network Operations Guide.
■ Additional link-layer redundancy, including Automatic Protection Switching (APS)
for SONET interfaces, Multiplex Section Protection (MSP) for SDH interfaces, and
DLSw redundancy for Ethernet interfaces, For more information, see the JUNOS
Network Interfaces Configuration Guide.
■ Bidirectional Forwarding Detection (BFD) works with other routing protocols to
detect failures rapidly. For more information, see the JUNOS Routing Protocols
Configuration Guide.
■ Redirection of Multiprotocol Label Switching (MPLS) label-switched path (LSP)
traffic—Mechanisms such as link protection, node-link protection, and fast reroute
recognize link and node failures, allowing MPLS LSPs to select a bypass LSP to
circumvent failed links or devices. For more information, see the JUNOS MPLS
Applications Configuration Guide.

Related Features ■ 7
JUNOS 8.5 High Availability Configuration Guide

8 ■ Related Features
Part 2
Routing Engine and Switching Control
Board Redundancy
■ Routing Engine and Switching Control Board Redundancy Overview on page 11
■ Routing Engine and Switching Control Board Redundancy Configuration
Guidelines on page 19
■ Summary of Routing Engine and Control Board Switching Redundancy
Statements on page 31

Routing Engine and Switching Control Board Redundancy ■ 9

JUNOS 8.5 High Availability Configuration Guide

10 ■ Routing Engine and Switching Control Board Redundancy

Chapter 2
Routing Engine and Switching Control
Board Redundancy Overview

For routers that have redundant Routing Engines or redundant switching control
boards, including Switching and Forwarding Modules (SFMs). System and Switch
Boards (SSBs), Forwarding Engine Boards (FEBs), or Compact Forwarding Engine
Board (CFEBs), you can configure redundancy properties. This chapter includes the
following topics:
■ Routing Engine Redundancy on page 11
■ Switching Control Board Redundancy on page 14

Routing Engine Redundancy

With redundant Routing Engines, one functions as the master, while the other stands
by as a backup should the master Routing Engine fail. When a Routing Engine is
configured as master, it has full functionality. It receives and transmits routing
information, builds and maintains routing tables, communicates with interfaces and
Packet Forwarding Engine components, and has full control over the chassis. When
a Routing Engine is configured to be the backup, it does not communicate with the
Packet Forwarding Engine or chassis components.

NOTE: A failover from the master Routing Engine to the backup Routing Engine
occurs automatically when the master Routing Engine experiences a hardware failure
or when you have configured the software to support a change in mastership based
on specific conditions. You can also manually switch Routing Engine mastership by
issuing one of the request chassis routing-engine commands. In this chapter, the term
failover refers to an automatic event, whereas switchover refers to either an automatic
or a manual event.

If nonstop routing is configured, the backup Routing Engine receives routing messages,
but does not send them to the network. If nonstop routing is not configured, the
backup Routing Engine does not maintain routing tables.

When a switchover occurs, the backup takes control of the system as the new master
Routing Engine. If graceful Routing Engine switchover is configured, the Packet
Forwarding Engine is not reinitialized and traffic is not interrupted. If graceful Routing
Engine switchover is not configured, when the backup Routing Engine becomes

Routing Engine Redundancy ■ 11

JUNOS 8.5 High Availability Configuration Guide

master, it resets the switch plane and downloads its own version of the microkernel
to the Packet Forwarding Engine components.

NOTE: With the introduction of JUNOS Release 8.4, both Routing Engines cannot be
configured to be master at the same time. This configuration causes the commit
check to fail.

For more information about Routing Engine redundancy, see the following sections:
■ Platform Support on page 12
■ Conditions That Trigger a Routing Engine Failover on page 13
■ Default Routing Engine Redundancy Behavior on page 13
■ Situations That Require You to Halt Routing Engines on page 14

Platform Support
The following platforms support redundant Routing Engines:
■ M10i router—Each High-Availability Chassis Manager (HCM) and Routing Engine
function as a unit. Keepalive messages are sent between Routing Engines over
the interconnected HCM switches.
■ M20 router—A single System and Switch Board (SSB) communicates with the
Routing Engines. Keepalive messages are sent between the master and backup
Routing Engine through the switch on the SSB. In this way, the master and the
backup Routing Engines exchange state information.
■ M40e and M160 routers—Each Miscellaneous Control Subsystem (MCS) and
Routing Engine function as a unit, or host module. Keepalive messages are sent
from one Routing Engine to the other over the fpx2 interface across the Peripheral
Component Interconnect (PCI) bridge. The keepalive message is received by the
other host module on the fpx1 interface. A keepalive response is sent back over
the fpx2 interface to the other Routing Engine.
■ M120 router, M320 router, T320 router, T640 router, and T1600 router—Each
Routing Engine and Control Board (CB) function as a unit, or host subsystem.
Keepalive messages are sent from the Routing Engine over the em0 interface.
The keepalive message is forwarded to the other host subsystem over the bcm0
interface on the Control Board. A keepalive response is sent back over the em0
interface to the other Routing Engine.
■ MX–series Ethernet Services routers—Each Routing Engine and Switch Control
Board (SCB) function as a unit, or host subsystem. Keepalive messages are sent
between Routing Engines over either the em0 interface or the em1 interface.

12 ■ Routing Engine Redundancy

 Chapter 2: Routing Engine and Switching Control Board Redundancy Overview

Conditions That Trigger a Routing Engine Failover

The following events can result in an automatic change in Routing Engine mastership,
depending on your configuration:
■ The routing platform experiences a hardware failure. A change in Routing Engine
mastership occurs if either the Routing Engine or the associated host module or
subsystem is abruptly powered off. You can also configure the backup Routing
Engine to take mastership if it detects a hard disk error on the master Routing
Engine. To enable this feature, include the on-disk-failure statement at the [edit
chassis redundancy failover] hierarchy level.
■ The routing platform experiences a software failure, such as a kernel crash or a
CPU lock. You must configure the backup Routing Engine to take mastership
when it detects a loss of keepalive signal. To enable this failover method, include
the on-loss-of-keepalives statement at the [edit chassis redundancy failover]
hierarchy level.
■ A specific software process fails. You can configure the backup Routing Engine
to take mastership when one or more specified processes fail at least four times
within 30 seconds. Include the failover statement at the [edit system processes
process-name] hierarchy level.

If any of these conditions is met, a message is logged and the backup Routing Engine
attempts to take mastership. An alarm is generated when the backup Routing Engine
becomes active. After the backup Routing Engine takes mastership, it continues to
function as master even after the originally configured master Routing Engine has
successfully resumed operation. You must manually restore it to its previous backup
status. (However, if at any time one of the Routing Engines is not present, the other
Routing Engine becomes master automatically, regardless of how redundancy is
configured.)

Default Routing Engine Redundancy Behavior

By default, the JUNOS software uses re0 as the master Routing Engine and re1 as
the backup Routing Engine. Unless otherwise specified in the configuration, re0
always becomes master when the acting master Routing Engine is rebooted.

NOTE: A single Routing Engine in the chassis always becomes the master Routing
Engine even if it was previously the backup Routing Engine.

Perform the following steps to see how the default Routing Engine redundancy setting
works:
1. Ensure that re0 is the master Routing Engine.
2. Manually switch the state of Routing Engine mastership by issuing the request
chassis routing-engine master switch command from the master Routing Engine.
re0 is now the backup Routing Engine and re1 is the master Routing Engine.

Routing Engine Redundancy ■ 13

JUNOS 8.5 High Availability Configuration Guide

NOTE: On the next reboot of the master Routing Engine, the JUNOS software returns
the router to the default state because you have not configured the Routing Engines
to maintain this state after a reboot.

3. Reboot the master Routing Engine re1.

The Routing Engine boots up and reads the configuration. Because you have not
specified in the configuration which Routing Engine is the master, re1 uses the
default configuration as the backup. Now both re0 and re1 are in a backup state.
The JUNOS software detects this conflict and, to prevent a no-master state, reverts
to the default configuration to direct re0 to become master.

Situations That Require You to Halt Routing Engines

Before you shut the power off to a routing platform that has two Routing Engines or
before you remove the master Routing Engine, you must first halt the backup Routing
Engine and then halt the master Routing Engine. Otherwise, you might need to
reinstall the JUNOS software. You can use the request system halt both-routing-engines
command on the master Routing Engine, which first shuts down the master Routing
Engine and then shuts down the backup Routing Engine. To shut down only the
backup Routing Engine, issue the request system halt command on the backup
Routing Engine.

If you halt the master Routing Engine and do not power it off or remove it, the backup
Routing Engine remains inactive unless you have configured it to become the master
when it detects a loss of keepalive signal from the master Routing Engine.

NOTE: To restart the router, you must log in to the console port (rather than the
Ethernet management port) of the Routing Engine. When you log in to the console
port of the master Routing Engine, the system automatically reboots. After you log
in to the console port of the backup Routing Engine, press Enter to reboot it.

NOTE: If you have upgraded the backup Routing Engine, first reboot it and then
reboot the master Routing Engine.

Switching Control Board Redundancy

This section describes the following redundant switching control boards:
■ Redundant CFEBs on the M10i Router on page 15
■ Redundant FEBs on the M120 Router on page 15
■ Redundant SSBs on the M20 Router on page 17
■ Redundant SFMs on the M40e and M160 Routers on page 18

14 ■ Switching Control Board Redundancy

 Chapter 2: Routing Engine and Switching Control Board Redundancy Overview

NOTE: A failover from a master switching control board to a backup switching control
board occurs automatically when the master experiences a hardware failure or when
you have configured the software to support a change in mastership based on specific
conditions. You can also manually switch mastership by issuing specific request
chassis commands. In this chapter, the term failover refers to an automatic event,
whereas switchover refers to either an automatic or a manual event.

Redundant CFEBs on the M10i Router

On the M10i router, the CFEB performs the following functions:
■ Route lookups—Performs route lookups using the forwarding table stored in
synchronous SRAM (SSRAM).
■ Management of shared memory—Uniformly allocates incoming data packets
throughout the router’s shared memory.
■ Transfer of outgoing data packets—Passes data packets to the destination Fixed
Interface Card (FIC) or Physical Interface Card (PIC) when the data is ready to
be transmitted.
■ Transfer of exception and control packets—Passes exception packets to the
microprocessor on the CFEB, which processes almost all of them. The remainder
are sent to the Routing Engine for further processing. Any errors originating in
the Packet Forwarding Engine and detected by the CFEB are sent to the Routing
Engine using system log messages.

The M10i router has two CFEBs, one that is configured to act as the master and the
other that serves as a backup in case the master fails. You can initiate a manual
switchover by issuing the request chassis cfeb master switch command. For more
information, see the JUNOS System Basics and Services Command Reference.

Redundant FEBs on the M120 Router

On the M120 router, which supports as many as six Forwarding Engine Boards (FEBs),
you can configure one FEB as a backup for one or more FEBs. To enable FEB
redundancy, you configure a FEB group, which is a named collection of two or more
FEBs, and specify one backup FEB for the group. You cannot configure more than
one backup FEB for each redundancy group. You can optionally specify one primary
FEB. The backup FEB is aligned with the state of the primary FEB if one is specified.
Each redundancy group must have a unique backup FEB, and each FEB can belong
to only one redundancy group.

You can also map a connection between any FEB and any Flexible PIC Concentrator
(FPC) on the M120 router. You cannot specify a connection between an FPC and a
FEB configured as a backup. If an FPC in slot x is not specified to connect to a FEB,
the FPC in slot x is automatically assigned a connection to the FEB in slot x. If the
FEB in slot x is a backup FEB, you must explicitly configure the FPC either not to
connect to any FEB or to connect to a different FEB. Use the none statement at the
[edit chassis fpc-feb-connectivity fpc slot-number feb] hierarchy level to disconnect the
backup FEB from the FPC. For more information about the fpc-feb-connectivity
statement, see the JUNOS System Basics Configuration Guide.

Switching Control Board Redundancy ■ 15

JUNOS 8.5 High Availability Configuration Guide

Failover to a backup FEB occurs automatically if a FEB in a redundancy group fails.

You can disable automatic failover for any redundancy group.

You can also initiate a manual switchover by issuing the request chassis redundancy
feb slot slot-number switch-to-backup command, where slot-number is the number of
the active FEB. For more information, see the JUNOS System Basics and Services
Command Reference.

The following conditions result in automatic failover as long as the backup FEB in a
redundancy group is available:
■ The FEB is absent.
■ The FEB experienced a hard error while coming online.
■ A software failure on the FEB resulted in a crash.
■ Ethernet connectivity from a FEB to a Routing Engine failed.
■ A hard error on the FEB, such as a power failure, occurred.
■ The FEB was disabled when the offline button for the FEB was pressed.
■ The software watchdog timer on the FEB expired.
■ Errors occurred on the links between all the active fabric planes and the FEB.
This situation results in failover to the backup FEB if it has at least one valid
fabric link.
■ Errors occurred on the link between the FEB and all of the FPCs connected to
it.

A manual switchover from a primary FEB to a backup FEB results in less than 1
second of traffic loss. Automatic failover from the primary FEB to the backup FEB
results in less than 10 seconds of traffic loss if the backup FEB is ready before the
switchover. Automatic failover from a FEB that is not specified as a primary FEB
results in higher packet loss. The duration of packet loss depends on the number of
interfaces and on the size of the routing table, but can be minutes.

NOTE: For a switchover from a nonprimary FEB when no primary FEB is specified
for the redundancy group, the backup FEB does not reboot and the interfaces on the
FPCs connected to the previously active FEB remain online. The backup FEB can
take minutes to obtain the entire forwarding state from the Routing Engine following
a switchover. If you do not want the interfaces to remain online during the switchover
for a nonprimary FEB, configure a primary FEB for the redundancy group.

If switchover occurs from a primary FEB, the backup FEB does not reboot. If
switchover occurs from a nonprimary FEB and a primary FEB is specified for the
group, the backup FEB reboots.

After a switchover occurs, a backup FEB is no longer available for the redundancy
group. You can revert from the backup FEB to the previously active FEB by issuing
the operational mode command request chassis redundancy feb slot slot-number
revert-from-backup, where slot-number is the number of the previously active FEB. For
more information, see the JUNOS System Basics and Services Command Reference.

16 ■ Switching Control Board Redundancy

 Chapter 2: Routing Engine and Switching Control Board Redundancy Overview

When you revert from the backup FEB, it becomes available again for a switchover.
If the redundancy group does not have a primary FEB, the backup FEB reboots after
you revert back to the previously active FEB. If the FEB to which you revert back is
not a primary FEB, the backup FEB is rebooted so that it can aligned with the state
of the primary FEB.

If you modify the configuration for an existing redundancy group so that a FEB
connects to a different FPC, the FEB is rebooted unless the FEB was already connected
to one or two Type 1 FPCs and the change only resulted in the FEB being connected
either to one additional or one fewer Type 1 FPC. For more information about how
to map a connection between an FPC and a FEB, see the JUNOS System Basics
Configuration Guide. If you change the primary FEB in a redundancy group, the backup
FEB is rebooted. The FEB is also rebooted if you change a backup FEB to a nonbackup
FEB or change an active FEB to a backup FEB.

To view the status of configured FEB redundancy groups, issue the show chassis
redundancy feb operational mode command. For more information, see the JUNOS
System Basics and Services Command Reference.

Redundant SSBs on the M20 Router

The System and Switch Board (SSB) on the M20 router performs the following major
functions:
■ Shared memory management on the FPCs—The Distributed Buffer Manager
ASIC on the SSB uniformly allocates incoming data packets throughout shared
memory on the FPCs.
■ Outgoing data cell transfer to the FPCs—A second Distributed Buffer Manager
ASIC on the SSB passes data cells to the FPCs for packet reassembly when the
data is ready to be transmitted.
■ Route lookups—The Internet Processor ASIC on the SSB performs route lookups
using the forwarding table stored in SSRAM. After performing the lookup, the
Internet Processor ASIC informs the midplane of the forwarding decision, and
the midplane forwards the decision to the appropriate outgoing interface.
■ System component monitoring—The SSB monitors other system components
for failure and alarm conditions. It collects statistics from all sensors in the system
and relays them to the Routing Engine, which sets the appropriate alarm. For
example, if a temperature sensor exceeds the first internally defined threshold,
the Routing Engine issues a “high temp” alarm. If the sensor exceeds the second
threshold, the Routing Engine initiates a system shutdown.
■ Exception and control packet transfer—The Internet Processor ASIC passes
exception packets to a microprocessor on the SSB, which processes almost all
of them. The remaining packets are sent to the Routing Engine for further
processing. Any errors that originate in the Packet Forwarding Engine and are
detected by the SSB are sent to the Routing Engine using system log messages.
■ FPC reset control—The SSB monitors the operation of the FPCs. If it detects
errors in an FPC, the SSB attempts to reset the FPC. After three unsuccessful
resets, the SSB takes the FPC offline and informs the Routing Engine. Other FPCs
are unaffected, and normal system operation continues.

Switching Control Board Redundancy ■ 17

JUNOS 8.5 High Availability Configuration Guide

The M20 router holds up to two SSBs. One SSB is configured to act as the master
and the other is configured to serve as a backup in case the master fails. You can
initiate a manual switchover by issuing the request chassis ssb master switch
command. For more information, see the JUNOS System Basics and Services Command
Reference.

Redundant SFMs on the M40e and M160 Routers

The M40e and M160 routers have redundant Switching and Forwarding Modules
(SFMs). The SFMs contain the Internet Processor II ASIC and two Distributed Buffer
Manager ASICs. SFMs ensure that all traffic leaving the FPCs is handled properly.
SFMs provide route lookup, filtering, and switching.

The M40e router holds up to two SFMs, one that is configured to act as the master
and the other configured to serve as a backup in case the master fails. Removing the
standby SFM has no effect on router function. If the active SFM fails or is removed
from the chassis, forwarding halts until the standby SFM boots and becomes active.
It takes approximately 1 minute for the new SFM to become active. Synchronizing
router configuration information can take additional time, depending on the
complexity of the configuration.

The M160 router holds up to four SFMs. All SFMs are active at the same time. A
failure or taking an SFM offline has no effect on router function. Forwarding continues
uninterrupted.

You can initiate a manual switchover by issuing the request chassis sfm master switch
command. For more information, see the JUNOS System Basics and Services Command
Reference.

18 ■ Switching Control Board Redundancy

Chapter 3
Routing Engine and Switching Control
Board Redundancy Configuration
Guidelines

This chapter includes the following topics:

■ Chassis Redundancy Hierarchy on page 19
■ Configuring Routing Engine Redundancy on page 20
■ Configuring CFEB Redundancy on the M10i Router on page 26
■ Configuring FEB Redundancy on the M120 Router on page 28
■ Configuring SFM Redundancy on M40e and M160 Routers on page 29
■ Configuring SSB Redundancy on the M20 Router on page 30

Chassis Redundancy Hierarchy

redundancy {
cfeb slot (always | preferred);
failover{
on-disk-failure
on-loss-of-keepalives;
}
feb {
redundancy-group group-name {
feb slot-number (backup | primary);
description description;
no-auto-failover;
}
}
graceful-switchover;
keepalive-time seconds;
routing-engine slot-number (master | backup | disabled);
sfm slot-number (always | preferred);
ssb slot-number (always | preferred);
}

Chassis Redundancy Hierarchy ■ 19

JUNOS 8.5 High Availability Configuration Guide

Configuring Routing Engine Redundancy

The following sections describe how to configure Routing Engine redundancy:
■ Modifying the Default Routing Engine Mastership on page 20
■ Copying a Configuration File from One Routing Engine to the Other on page 21
■ Loading a Software Package from the Other Routing Engine on page 22
■ Changing to the Backup Routing Engine If It Detects a Hard Disk Error on the
Master Routing Engine on page 23
■ Changing to the Backup Routing Engine Without Interruption to Packet
Forwarding on page 23
■ Changing to the Backup Routing Engine If It Detects Loss of Keepalive
Signal on page 23
■ Routing Engines on a TX Matrix Platform on page 24
■ Manually Switching Routing Engine Mastership on page 25
■ Verifying Routing Engine Redundancy Status on page 25

Modifying the Default Routing Engine Mastership

For routers with two Routing Engines, you can configure which Routing Engine is
the master and which is the backup. By default, the Routing Engine in slot 0 is the
master (re0) and the one in slot 1 is the backup (re1).

NOTE: In systems with two Routing Engines, both Routing Engines cannot be
configured to be master at the same time. This configuration causes the commit
check to fail.

To modify the default configuration, include the routing-engine statement at the [edit
chassis redundancy] hierarchy level:

[edit chassis redundancy]

routing-engine slot-number (master | backup | disabled);

slot-number can be 0 or 1. To configure the Routing Engine to be the master, specify

the master option. To configure it to be the backup, specify the backup option. To
disable a Routing Engine, specify the disabled option.

NOTE: To switch between the master and the backup Routing Engines, you must
modify the configuration and then activate it by issuing the commit synchronize
command.

20 ■ Configuring Routing Engine Redundancy

 Chapter 3: Routing Engine and Switching Control Board Redundancy Configuration Guidelines

Copying a Configuration File from One Routing Engine to the Other

You can use either the console port or the management Ethernet port to establish
connectivity between the two Routing Engines. You can then copy or use FTP to
transfer the configuration from the master to the backup, and load the file and commit
it in the normal way.

To connect to the other Routing Engine using the management Ethernet port, issue
the following command:

user@host> request routing-engine login (other-routing-engine | re0 | re1)

On a TX Matrix platform, to make connections to the other Routing Engine using

the management Ethernet port, issue the following command:

user@host> request routing-engine login (backup | lcc number | master |

other-routing-engine | re0 | re1)

For more information about the request routing-engine login command, see the JUNOS
System Basics and Services Command Reference.

To copy a configuration file from one Routing Engine to the other, issue the file copy
command:

user@host> file copy source destination

In this case, source is the name of the configuration file. These files are stored in the
directory /config. The active configuration is /config/juniper.conf, and older
configurations are in /config/juniper.conf {1...9}. The destination is a file on the other
Routing Engine.

The following example copies a configuration file from Routing Engine 0 to Routing
Engine 1:

user@host> file copy /config/juniper.conf re1:/var/tmp/copied-juniper.conf

The following example copies a configuration file from Routing Engine 0 to Routing
Engine 1 on a TX Matrix platform:

user@host> file copy /config/juniper.conf scc-re1:/var/tmp/copied-juniper.conf

To load the configuration file, enter the load replace command at the [edit] hierarchy
level:

user@host> load replace /var/tmp/copied-juniper.conf

CAUTION: Make sure you change any IP addresses specified in fxp0 on Routing
Engine 0 to addresses appropriate for Routing Engine 1.

You can use configuration groups to ensure that the correct IP addresses are used
for each Routing Engine and to maintain a single configuration file for both
Routing Engines.

Configuring Routing Engine Redundancy ■ 21

JUNOS 8.5 High Availability Configuration Guide

The following example defines configuration groups re0 and re1 with separate IP
addresses. These well-known configuration group names take effect only on the
appropriate Routing Engine.

groups {
re0 {
system {
host-name my-re0;
}
interfaces {
fxp0 {
description "10/100 Management interface";
unit 0 {
family inet {
address 10.255.2.40/24;
}
}
}
}
}
re1 {
system {
host-name my-re1;
}
interfaces {
fxp0 {
description "10/100 Management interface";
unit 0 {
family inet {
address 10.255.2.41/24;
}
}
}
}
}
}

For information about the initial configuration of dual Routing Engines, see the JUNOS
Software Installation and Upgrade Guide.

Loading a Software Package from the Other Routing Engine

You can load a package from the other Routing Engine onto the local Routing Engine
using the existing request system software add package-name command:

user@host> request system software add re(0|1):/filename

In the re portion of the URL, specify the number of the other Routing Engine. In the
filename portion of the URL, specify the path to the package. Packages are typically
in the directory /var/sw/pkg.

22 ■ Configuring Routing Engine Redundancy

 Chapter 3: Routing Engine and Switching Control Board Redundancy Configuration Guidelines

Changing to the Backup Routing Engine If It Detects a Hard Disk Error on the Master
Routing Engine
After you configure a backup Routing Engine, you can direct it to take mastership
automatically if it detects a hard disk error from the master Routing Engine. To enable
this feature, include the on-disk-failure statement at the [edit chassis redundancy
failover] hierarchy level:

[edit chassis redundancy failover]

on-disk-failure;

Changing to the Backup Routing Engine Without Interruption to Packet Forwarding

For routers with two Routing Engines, you can configure graceful Routing Engine
switchover (GRES). When graceful switchover is configured, socket reconnection
occurs seamlessly without interruption to packet forwarding. To configure graceful
Routing Engine switchover, include the graceful-switchover statement at the [edit
chassis redundancy] hierarchy level.

For information about configuring graceful Routing Engine switchover, see “Graceful
Routing Engine Switchover Configuration Guidelines” on page 53.

Changing to the Backup Routing Engine If It Detects Loss of Keepalive Signal

After you configure a backup Routing Engine, you can direct it to take mastership
automatically if it detects a loss of keepalive signal from the master Routing Engine.
This method is useful for networks that contain a mixture of routers that do not all
support graceful Routing Engine switchover.

To enable failover on receiving a loss of keepalive signal, include the

on-loss-of-keepalives statement at the [edit chassis redundancy failover] hierarchy level:

[edit chassis redundancy failover]

on-loss-of-keepalives;

By default, failover occurs after 300 seconds (5 minutes). You can configure a shorter
or longer time interval. To change the keepalive time period, include the keepalive-time
statement at the [edit chassis redundancy] hierarchy level:

[edit chassis redundancy]

keepalive-time seconds;

The range for keepalive-time is 2 through 10,000 seconds.

NOTE: When graceful Routing Engine switchover is configured, the keepalive signal
is automatically enabled and the failover time is set to 2 seconds. You cannot manually
reset the keepalive time.

Configuring Routing Engine Redundancy ■ 23

JUNOS 8.5 High Availability Configuration Guide

The following example describes the sequence of events if you configure the backup
Routing Engine to detect a loss of keepalive signal in the master Routing Engine:
1. Manually configure a keepalive-time of 25 seconds.
2. After the Packet Forwarding Engine connection to the primary Routing Engine
is lost and the keepalive timer expires, packet forwarding is interrupted.
3. After 25 seconds of keepalive loss, a message is logged, and the backup Routing
Engine attempts to take mastership. An alarm is generated when the backup
Routing Engine becomes active, and the display is updated with the current
status of the Routing Engine.
4. After the backup Routing Engine takes mastership, it continues to function as
master.

A former master Routing Engine becomes a backup Routing Engine if it returns to

service after a failover to the backup Routing Engine. To restore master status to the
former master Routing Engine, you can use the request chassis routing-engine master
switch operational mode command.

If at any time one of the Routing Engines is not present, the remaining Routing
Engine becomes master automatically, regardless of how redundancy is configured.

Routing Engines on a TX Matrix Platform

On a routing matrix, all master Routing Engines in the TX Matrix platform and
connected T640 routing nodes must run the same JUNOS software release. Likewise,
all backup Routing Engines in a routing matrix must run the same JUNOS software
release. When you run the same JUNOS software release on all master and backup
Routing Engines in the routing matrix, a change in mastership to any backup Routing
Engine in the routing matrix does not cause a change in mastership in any other
chassis in the routing matrix.

If the same JUNOS software release is not running on all master and backup Routing
Engines in the routing matrix, the following consequences occur when the
on-loss-of-keepalives statement is included at the [edit chassis redundancy failover]
hierarchy level:
■ When the on-loss-of-keepalives statement is included at the [edit chassis
redundancy failover] hierarchy level and you or a host subsystem initiate a change
in mastership to the backup Routing Engine in the TX Matrix platform, the master
Routing Engines in the T640 routing nodes detect a software release mismatch
with the new master Routing Engine in the TX Matrix platform and switch
mastership to their backup Routing Engines.
■ When you manually change mastership to a backup Routing Engine in a T640
routing node using the request chassis routing-engine master command, the new
master Routing Engine in the T640 routing node detects a software release
mismatch with the master Routing Engine in the TX Matrix platform and
relinquishes mastership to the original master Routing Engine. (Routing Engine
mastership in the TX Matrix platform does not switch in this case.)
■ When a host subsystem initiates a change in mastership to a backup Routing
Engine in a T640 routing node because the master Routing Engine has failed,
the T640 routing node is logically disconnected from the TX Matrix platform. To

24 ■ Configuring Routing Engine Redundancy

 Chapter 3: Routing Engine and Switching Control Board Redundancy Configuration Guidelines

reconnect the T640 routing node, initiate a change in mastership to the backup
Routing Engine in the TX Matrix platform, or replace the failed Routing Engine
in the T640 routing node and switch mastership to it. The replacement Routing
Engine must be running the same software release as the master Routing Engine
in the TX Matrix platform.

If the same JUNOS software release is not running on all master and backup Routing
Engines in the routing matrix, the following consequences occur when the
on-loss-of-keepalives statement is not included at the [edit chassis redundancy failover]
hierarchy level:
■ If you initiate a change in mastership to the backup Routing Engine in the TX
Matrix platform, all T640 routing nodes are logically disconnected from the TX
Matrix platform. To reconnect the T640 routing nodes, switch mastership of all
master Routing Engines in the T640 routing nodes to their backup Routing
Engines.
■ If you initiate a change in mastership to a backup Routing Engine in a T640
routing node, the T640 routing node is logically disconnected from the TX Matrix
platform. To reconnect the T640 routing node, switch mastership of the new
master Routing Engine in the T640 routing node back to the original master
Routing Engine.

Manually Switching Routing Engine Mastership

To manually switch the Routing Engine mastership, use one of the following
commands:
■ On the backup Routing Engine, request that the backup Routing Engine take
mastership by issuing the request chassis routing-engine master acquire command.
■ On the master Routing Engine, request that the backup Routing Engine take
mastership by using the request chassis routing-engine master release command.
■ On either Routing Engine, switch mastership by issuing the request chassis
routing-engine master switch command.

Verifying Routing Engine Redundancy Status

A separate log file is provided for redundancy logging at /var/log/mastership. To
view the log, use the file show /var/log/mastership command. Table 7 on page 25
lists the mastership log event codes and descriptions.

Table 7: Routing Engine Mastership Log

Event Code Description

E_NULL = 0 The event is a null event.

E_CFG_M The Routing Engine is configured as master.

E_CFG_B The Routing Engine is configured as backup.

Configuring Routing Engine Redundancy ■ 25

JUNOS 8.5 High Availability Configuration Guide

Table 7: Routing Engine Mastership Log (continued)

Event Code Description

E_CFG_D The Routing Engine is configured as disabled.

E_MAXTRY The maximum number of tries to acquire or release mastership was exceeded.

E_REQ_C A claim mastership request was sent.

E_ACK_C A claim mastership acknowledgement was received.

E_NAK_C A claim mastership request was not acknowledged.

E_REQ_Y Confirmation of mastership is requested.

E_ACK_Y Mastership is acknowledged.

E_NAK_Y Mastership is not acknowledged.

E_REQ_G A release mastership request was sent by a Routing Engine.

E_ACK_G . The Routing Engine acknowledged release of mastership.

E_CMD_A . The command request chassis routing-engine master acquire was issued from the
backup Routing Engine.

E_CMD_F The command request chassis routing-engine master acquire force was issued from
the backup Routing Engine.

E_CMD_R The command request chassis routing-engine master release was issued from the
master Routing Engine.

E_CMD_S The command request chassis routing-engine master switch was issued from a Routing
Engine.

E_NO_ORE No other Routing Engine is detected.

E_TMOUT A request timed out.

E_NO_IPC Routing Engine connection was lost.

E_ORE_M Other Routing Engine state was changed to master.

E_ORE_B Other Routing Engine state was changed to backup.

E_ORE_D Other Routing Engine state was changed to disabled.

Configuring CFEB Redundancy on the M10i Router

The Compact Forwarding Engine Board (CFEB) on the M10i router provides route
lookup, filtering, and switching on incoming data packets, then directs outbound
packets to the appropriate interface for transmission to the network. The CFEB
communicates with the Routing Engine using a dedicated 100-Mbps Fast Ethernet
link that transfers routing table data from the Routing Engine to the forwarding table

26 ■ Configuring CFEB Redundancy on the M10i Router

 Chapter 3: Routing Engine and Switching Control Board Redundancy Configuration Guidelines

in the integrated ASIC. The link is also used to transfer from the CFEB to the Routing
Engine routing link-state updates and other packets destined for the router that have
been received through the router interfaces.

To configure a CFEB redundancy group, include the following statements at the [edit
chassis redundancy] hierarchy level:

[edit chassis redundancy]

cfeb slot-number (always | preferred);

slot-number can be 0 or 1.

always defines the CFEB as the sole device.

preferred defines a preferred CFEB.

To manually switch CFEB mastership, issue the request chassis cfeb master switch
command. To view CFEB status, issue the show chassis cfeb command.

Configuring CFEB Redundancy on the M10i Router ■ 27

JUNOS 8.5 High Availability Configuration Guide

Configuring FEB Redundancy on the M120 Router

To configure a FEB redundancy group for the M120 router, include the following
statements at the [edit chassis redundancy feb] hierarchy level:

redundancy-group group-name {
feb slot-number (backup | primary);
description description;
no-auto-failover;
}

group-name is the unique name for the redundancy group. The maximum length is
39 alphanumeric characters.

slot-number is the slot-number of each FEB you want to include in the redundancy
group. The range is 0 through 5. You must specify a unique backup FEB and make
sure that the FEB is not connected to an FPC. Specifying a primary FEB is optional.

You can optionally specify a description for a redundancy group. To configure a

description, include the description statement at the [edit chassis redundancy feb
redundancy-group group-name] hierarchy level:

[edit chassis redundancy feb redundancy-group group-name]

description description;

Automatic failover is enabled by default. To disable automatic failover, include the

no-auto-failover statement at the [edit chassis redundancy feb redundancy-group
group-name] hierarchy level:

[edit chassis redundancy feb redundancy-group group-name]

no-auto-failover;

If you disable automatic failover, you can perform only a manual switchover using
the operational command request chassis redundancy feb slot slot-number
switch-to-backup. To view FEB status, issue the show chassis feb command. For more
information, see the JUNOS System Basics and Services Command Reference.

Example: Configuring FEB Redundancy

In the following configuration, two FEB redundancy groups are created:
■ A FEB redundancy group named group0 with the following properties:
■ Contains three FEBs (0 through 2).
■ Has a primary FEB (2).

■ Has a unique backup FEB (0).

■ Automatic failover is disabled.

When an active FEB in group0 fails, automatic failover to the backup FEB
does not occur. For group0, you can only perform a manual switchover.

■ A FEB redundancy group named group1 with the following properties:

28 ■ Configuring FEB Redundancy on the M120 Router

 Chapter 3: Routing Engine and Switching Control Board Redundancy Configuration Guidelines

■ Two FEBs (3 and 5). There is no primary FEB.

■ A unique backup FEB (5).

■ Automatic failover is enabled by default.

When feb 3 in group1 fails, an automatic failover occurs.

Because you must explicitly configure an FPC not to connect to the backup FEB,
connectivity is set to none between fpc 0 and feb 0 and between fpc 5 and feb 5.

NOTE: For information about the fpc-feb-connectivity statement, see the JUNOS System
Basics Configuration Guide.

FPC to primary FEB connectivity is not explicitly configured, so by default, the

software automatically assigns connectivity based on numerical order of the FPCs.

[edit]
chassis {
fpc-feb-connectivity {
fpc 0 feb none;
fpc 5 feb none;
}
redundancy feb {
redundancy-group group0 {
description “Interfaces to Customer X”;
feb 2 primary;
feb 1;
feb 0 backup;
no-auto-failover;
}
redundancy-group group1 {
feb 3;
feb 5 backup;
}
}

Configuring SFM Redundancy on M40e and M160 Routers

By default, the SFM in slot 0 is the master and the SFM in slot 1 is the backup. To
modify the default configuration, include the sfm statement at the [edit chassis
redundancy] hierarchy level:

[edit chassis redundancy]

sfm slot-number (always | preferred);

On the M40e router, slot-number is 0 or 1. On the M160 router, slot-number is 0

through 3.

always defines the SFM as the sole device.

preferred defines a preferred SFM.

Configuring SFM Redundancy on M40e and M160 Routers ■ 29

JUNOS 8.5 High Availability Configuration Guide

To manually switch mastership between SFMs, issue the request chassis sfm master
switch command. To view SFM status, issue the show chassis sfm command. For
more information, see the JUNOS System Basics and Services Command Reference

Configuring SSB Redundancy on the M20 Router

For M20 routers with two SSBs, you can configure which SSB is the master and which
is the backup. By default, the SSB in slot 0 is the master and the SSB in slot 1 is the
backup. To modify the default configuration, include the ssb statement at the [edit
chassis redundancy] hierarchy level:

[edit chassis redundancy]

ssb slot-number (always | preferred);

slot-number is 0 or 1.

always defines the SSB as the sole device.

preferred defines a preferred SSB.

To manually switch mastership between SSBs, issue the request chassis ssb master
switch command.

To display SSB status information, issue the show chassis ssb command. The
command output displays the number of times the mastership has changed, the SSB
slot number, and the current state of the SSB: master, backup, or empty. For more
information, see the JUNOS System Basics and Services Command Reference.

30 ■ Configuring SSB Redundancy on the M20 Router

Chapter 4
Summary of Routing Engine and Control
Board Switching Redundancy Statements

This chapter provides a reference for each of the Routing Engine and control board
switching redundancy configuration statements. The statements are organized
alphabetically.

cfeb

Syntax cfeb slot-number (always | preferred);

Hierarchy Level [edit chassis redundancy]

Release Information Statement introduced before JUNOS Release 7.4.

Description On M10i routers only, configure which Compact Forwarding Engine Board (CFEB)
is the master and which is the backup.

Default By default, the CFEB in slot 0 is the master and the CFEB in slot 1 is the backup.

Options slot-number—Specify which slot is the master and which is the backup.

always—Define this CFEB as the sole device.

preferred—Define this CFEB as the preferred device of at least two.

Usage Guidelines See “Configuring CFEB Redundancy on the M10i Router” on page 26.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

cfeb ■ 31
JUNOS 8.5 High Availability Configuration Guide

description

Syntax description description;

Hierarchy Level [edit chassis redundancy feb redundancy redundancy-group name]

Release Information Statement introduced before JUNOS Release 7.4.

Description Provide a description of the FEB redundancy group.

Options description—Provide a description for the FEB redundancy group.

Usage Guidelines See “Configuring FEB Redundancy on the M120 Router” on page 28

Required Privilege Level view-level—To view this statement in the configuration.

control-level—To add this statement to the configuration.

failover

Syntax failover {
on-disk-failure;
on-loss-of-keepalives
}

Hierarchy Level [edit chassis redundancy]

Release Information Statement introduced before JUNOS Release 7.4.

Description Instruct the backup router to take mastership if it detects hard disk errors on, or does
not receive the keepalive signal from, the master Routing Engine.

Options The remaining statements are described separately.

Usage Guidelines See “Changing to the Backup Routing Engine If It Detects a Hard Disk Error on the
Master Routing Engine” on page 23.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

32 ■ description
 Chapter 4: Summary of Routing Engine and Control Board Switching Redundancy Statements

feb

Syntax feb {
redundancy-group group-name {
description description
feb slot-number (backup | primary)
no-auto-failover
}
}

Hierarchy Level [edit chassis redundancy]

Release Information Statement introduced in JUNOS Release 8.2.

Description On M120 routers only, configure a Forwarding Engine Board (FEB) as a backup to
one or more FEBs.

Options The remaining statements are described separately.

Usage Guidelines See “Configuring FEB Redundancy on the M120 Router” on page 28.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

feb ■ 33
JUNOS 8.5 High Availability Configuration Guide

keepalive-time

Syntax keepalive-time seconds;

Hierarchy Level [edit chassis redundancy]

Release Information Statement introduced before JUNOS Release 7.4.

Description Configure the time period that must elapse before the backup router takes mastership
when it detects loss of the keepalive signal.

Default If the on-loss-of-keepalives statement at the [edit chassis redundancy] hierarchy level
is not included, failover will not occur.

When the on-loss-of-keepalives statement is included and graceful Routing Engine

switchover is not configured, failover occurs after 300 seconds (5 minutes).

When the on-loss-of-keepalives statement is included and graceful Routing Engine

switchover is configured, the keepalive signal is automatically enabled and the failover
time is set to 2 seconds. You cannot manually reset the keepalive time.

Options seconds—Time, in seconds, before the backup router takes mastership when it detects
loss of the keepalive signal. The range of values is 2 through 10,000.

Usage Guidelines See “Changing to the Backup Routing Engine If It Detects Loss of Keepalive
Signal” on page 23.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

no-auto-failover

Syntax no-auto-failover;

Hierarchy Level [edit chassis redundancy feb redundancy-group group-name]

Release Information Statement introduced before JUNOS Release 7.4.

Description Disable automatic failover to a backup FEB when an active FEB in a redundancy
group fails.

Default Automatic failover is enabled by default.

Usage Guidelines See “Configuring FEB Redundancy on the M120 Router” on page 28.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

34 ■ keepalive-time
 Chapter 4: Summary of Routing Engine and Control Board Switching Redundancy Statements

on-disk-failure

Syntax on-disk-failure;

Hierarchy Level [edit chassis redundancy failover]

Release Information Statement introduced before JUNOS Release 7.4.

Description Instruct the backup router to take mastership if it detects hard disk errors on the
master Routing Engine.

Usage Guidelines See “Changing to the Backup Routing Engine If It Detects a Hard Disk Error on the
Master Routing Engine” on page 23.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

on-loss-of-keepalives

Syntax on-loss-of-keepalives;

Hierarchy Level [edit chassis redundancy failover]

Release Information Statement introduced before JUNOS Release 7.4.

Description Instruct the backup router to take mastership if it detects a loss of keepalive signal
from the master Routing Engine.

Default If the on-loss-of-keepalives statement at the [edit chassis redundancy] hierarchy level
is not included, failover will not occur.

When the on-loss-of-keepalives statement is included and graceful Routing Engine

switchover is not configured, failover occurs after 300 seconds (5 minutes).

When the on-loss-of-keepalives statement is included and graceful Routing Engine

switchover is configured, the keepalive signal is automatically enabled and the failover
time is set to 2 seconds. You cannot manually reset the keepalive time.

Usage Guidelines See “Changing to the Backup Routing Engine If It Detects Loss of Keepalive
Signal” on page 23.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

on-disk-failure ■ 35
JUNOS 8.5 High Availability Configuration Guide

redundancy

Syntax redundancy {
cfeb slot–number (always | preferred);
feb {
redundancy-group group-name {
description description
feb slot-number (backup | primary)
no-auto-failover
}
failover {
on-disk-failure
on-loss-of-keepalives
}
keepalive-time seconds;
routing-engine slot-number (backup | disabled | master);
sfm slot-number (always | preferred);
ssb slot-number (always | preferred);
}

Hierarchy Level [edit chassis]

Release Information Statement introduced before JUNOS Release 7.4.

Description Configure a redundant Routing Engine or switching control board in the chassis.

Options The statements are explained separately.

Usage Guidelines See “Routing Engine and Switching Control Board Redundancy Configuration
Guidelines” on page 19.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

36 ■ redundancy
 Chapter 4: Summary of Routing Engine and Control Board Switching Redundancy Statements

redundancy-group

Syntax redundancy-group group-name {

description description
feb slot-number (backup | primary)
no-auto-failover
}

Hierarchy Level [edit chassis redundancy feb]

Release Information Statement introduced in JUNOS Release 8.2.

Description On M120 routers only, configure a Forwarding Engine Board (FEB) redundancy group.

Options group-name is the unique name for the redundancy group. The maximum length is
39 alphanumeric characters.

Other statements are explained separately.

Usage Guidelines See “Configuring FEB Redundancy on the M120 Router” on page 28.

Required Privilege Level view-level—To view this statement in the configuration.

control-level—To add this statement to the configuration.

routing-engine

Syntax routing-engine slot-number (backup | disabled | master);

Hierarchy Level [edit chassis redundancy]

Release Information Statement introduced before JUNOS Release 7.4.

Description Configure a redundant Routing Engine in the chassis as a backup for the chassis.

Default By default, the Routing Engine in slot 0 is the master Routing Engine and the Routing
Engine in slot 1 is the backup Routing Engine.

Options slot-number—Specify the slot number (0 or 1).

Set the function of the Routing Engine for the specified slot:
■ master—Routing Engine in the specified slot is the master.
■ backup—Routing Engine in the specified slot is the backup.
■ disabled—Routing Engine in the specified slot is disabled.

Usage Guidelines See “Configuring Routing Engine Redundancy” on page 20.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

redundancy-group ■ 37
JUNOS 8.5 High Availability Configuration Guide

sfm

Syntax sfm slot-number (always | preferred);

Hierarchy Level [edit chassis redundancy]

Release Information Statement introduced before JUNOS Release 7.4.

Description On M40e and M160 routers, configure which Switching and Forwarding Module
(SFM) is the master and which is the backup.

Default By default, the SFM in slot 0 is the master and the SFM in slot 1 is the backup.

Options slot-number—Specify which slot is the master and which is the backup. On the M40e
router, slot-number can be 0 or 1. On the M160 router, slot-number can be 0
through 3.

always—Define this SFM as the sole device.

preferred—Define this SFM as the preferred device of at least two.

Usage Guidelines See “Configuring SFM Redundancy on M40e and M160 Routers” on page 29.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

ssb

Syntax ssb slot-number (always | preferred);

Hierarchy Level [edit chassis redundancy]

Release Information Statement introduced before JUNOS Release 7.4.

Description On M20 routers, configure which System and Switch Board (SSB) is the master and
which is the backup.

Default By default, the SSB in slot 0 is the master and the SSB in slot 1 is the backup.

Options slot-number—Specify which slot is the master and which is the backup.

always—Define this SSB as the sole device.

preferred—Define this SSB as the preferred device of at least two.

Usage Guidelines See “Configuring SSB Redundancy on the M20 Router” on page 30.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

38 ■ sfm
Part 3
Graceful Routing Engine Switchover
■ Graceful Routing Engine Switchover Overview on page 41
■ Graceful Routing Engine Switchover Configuration Guidelines on page 53
■ Summary of Graceful Routing Engine Switchover Configuration
Statements on page 55

Graceful Routing Engine Switchover ■ 39

JUNOS 8.5 High Availability Configuration Guide

40 ■ Graceful Routing Engine Switchover

Chapter 5
Graceful Routing Engine Switchover
Overview

This chapter contains the following sections:

■ Graceful Routing Engine Switchover Concepts on page 41
■ Graceful Routing Engine Switchover System Requirements on page 44

Graceful Routing Engine Switchover Concepts

Graceful Routing Engine switchover enables a routing platform with dual Routing
Engines to switch from a master Routing Engine to a backup Routing Engine without
interruption to packet forwarding. When you configure graceful Routing Engine
switchover, the backup Routing Engine automatically synchronizes with the master
Routing Engine to preserve kernel state information and forwarding state. Any updates
to the master Routing Engine are replicated to the backup Routing Engine as soon
as they occur. If the kernel on the master Routing Engine stops operating, the master
Routing Engine experiences a hardware failure, or the administrator initiates a manual
switchover, mastership switches to the backup Routing Engine.

NOTE: To quickly restore or to preserve routing protocol state information during a

switchover, graceful Routing Engine switchover must be combined with either graceful
restart or nonstop routing (NSR), respectively. For more information about graceful
restart, see “Graceful Restart Overview” on page 87. For more information about
nonstop routing, see “Nonstop Routing Overview” on page 69.

If the backup Routing Engine does not receive a keepalive from the master Routing
Engine after 2 seconds, it determines that the master Routing Engine has failed and
takes mastership. The Packet Forwarding Engine seamlessly disconnects from the
old master Routing Engine and reconnects to the new master Routing Engine. The
Packet Forwarding Engine does not reboot, and traffic is not interrupted. The new
master Routing Engine and the Packet Forwarding Engine then become synchronized.
If the new master Routing Engine detects that the Packet Forwarding Engine state
is not up to date, it resends state update messages.

NOTE: Successive graceful Routing Engine switchover events must be a minimum

of 5 minutes apart after both Routing Engines have come up.

Graceful Routing Engine Switchover Concepts ■ 41

JUNOS 8.5 High Availability Configuration Guide

Figure 1 on page 42 shows the system architecture of graceful Routing Engine

switchover and the process a routing platform follows to prepare for a switchover.

Figure 1: Preparing for a Graceful Routing Engine Switchover

The switchover preparation process for graceful Routing Engine switchover follows
these steps:
1. The master Routing Engine starts.
2. The routing platform processes (such as the chassis process [chassisd]) start.
3. The Packet Forwarding Engine starts and connects to the master Routing Engine.
4. All state information is updated in the system.
5. The backup Routing Engine starts.
6. The system determines whether graceful Routing Engine switchover has been
enabled.
7. The kernel synchronization process (ksyncd) synchronizes the backup Routing
Engine with the master Routing Engine.
8. All state information is updated in the system.

42 ■ Graceful Routing Engine Switchover Concepts

 Chapter 5: Graceful Routing Engine Switchover Overview

Figure 2 on page 43 shows the effects of a switchover on the routing platform.

Figure 2: Graceful Routing Engine Switchover Process

When a switchover occurs, the switchover process follows these steps:

1. When keepalives from the master Routing Engine are lost, the system switches
over gracefully to the backup Routing Engine.
2. The Packet Forwarding Engine connects to the backup Routing Engine, which
becomes the new master.
3. Routing platform processes that are not part of graceful Routing Engine switchover
(such as the routing protocol process [rpd]) restart.
4. State information learned from the point of the switchover is updated in the
system.
5. If configured, graceful restart protocol extensions collect and restore routing
information from neighboring peer helper routers.

Graceful Routing Engine Switchover Concepts ■ 43

JUNOS 8.5 High Availability Configuration Guide

Graceful Routing Engine Switchover System Requirements

Graceful Routing Engine Switchover is supported on all routing platforms that contain
dual Routing Engines. All Routing Engines configured for graceful Routing Engine
switchover must run the same JUNOS software release. Hardware and software
support for graceful Routing Engine switchover is described in the following sections:
■ Graceful Routing Engine Switchover Platform Support on page 44
■ Graceful Routing Engine Switchover Feature Support on page 44
■ Graceful Routing Engine Switchover and Extended DHCP Relay Agent on page 45
■ Graceful Routing Engine Switchover DPC Support on page 46
■ Graceful Routing Engine Switchover PIC Support on page 46

Graceful Routing Engine Switchover Platform Support

To enable graceful Routing Engine switchover, your system must meet these minimum
requirements:
■ M20 and M40e routers—JUNOS Release 5.7 or later
■ M10i router—JUNOS Release 6.1 or later
■ M320 router—JUNOS Release 6.2 or later
■ T-series routing platforms and TX Matrix platform—JUNOS Release 7.0 or later
■ M120 router—JUNOS Release 8.2 or later
■ MX-series Ethernet Services routers—JUNOS Release 8.3 or later
■ T1600 router—JUNOS Release 8.5 or later

Graceful Routing Engine Switchover Feature Support

Graceful Routing Engine switchover supports most JUNOS software features in Release
5.7 and later. Particular JUNOS software features require specific versions of the
JUNOS software. See Table 8 on page 44.

Table 8: Graceful Routing Engine Switchover Feature Support

Application JUNOS Release

Aggregated Ethernet interfaces with Link Aggregation Control Protocol 6.2

(LACP) and aggregated SONET interfaces

Asynchronous Transfer Mode (ATM) virtual circuits (VCs) 6.2

Logical routers 6.3

Multicast 6.4 (7.0 for TX

Matrix)

44 ■ Graceful Routing Engine Switchover System Requirements

 Chapter 5: Graceful Routing Engine Switchover Overview

Table 8: Graceful Routing Engine Switchover Feature Support (continued)

Application JUNOS Release

Multilink Point-to-Point Protocol (MLPPP) and Multilink Frame Relay 7.0

(MLFR)

Automatic Protection Switching (APS)—The current active interface (either 7.4

the designated working or the designated protect interface) remains the
active interface during a Routing Engine switchover.

Point-to-multipoint Multiprotocol Label Switching MPLS LSPs (transit 7.4

only)

Compressed Real-Time Transport Protocol (CRTP) 7.6

Virtual private LAN service (VPLS) 8.2

Extended DHCP relay agent (See “Graceful Routing Engine Switchover 8.5
and Extended DHCP Relay Agent” on page 45 for more information.)

The following constraints apply to graceful Routing Engine switchover feature support:
■ When graceful Routing Engine switchover and Aggregated Ethernet interfaces
are configured in the same system, the aggregated Ethernet interfaces must not
be configured for fast polling LACP. When fast polling is configured, the LACP
polls time out at the remote end during the Routing Engine mastership switchover.
When LACP polling times out, the aggregated link and interface are disabled.
The Routing Engine mastership change is fast enough that standard and slow
LACP polling do not time out during the procedure.
■ Ethernet Operation, Administration, and Management (OAM) as defined by IEEE
802.1ag currently does not interoperate with graceful Routing Engine switchover.
When a switchover occurs, the OAM hello times out, triggering protocol
convergence. In this case, neither nonstop routing nor graceful restart provides
link-state change protection. However, OAM as defined by IEEE 802.3ah is
supported by graceful Routing Engine switchover. Both nonstop routing and
graceful restart provide link-state change protection.
■ VRRP changes mastership when a Routing Engine switchover occurs, even when
graceful Routing Engine switchover is configured.

Graceful Routing Engine Switchover and Extended DHCP Relay Agent

The extended DHCP relay agent supports graceful Routing Engine switchover on all
routing platforms that contain dual Routing Engines. To support graceful Routing
Engine switchover, the DHCP relay agent automatically mirrors (replicates)
information about the state of bound DHCP clients from the master Routing Engine
to the backup Routing Engine. A bound client is one that currently has an active lease
on an IP address from the DHCP server.

To enable graceful Routing Engine switchover support for the extended DHCP relay
agent, include the graceful-switchover statement at the [edit chassis redundancy]
hierarchy level. You cannot disable graceful Routing Engine switchover support for

Graceful Routing Engine Switchover System Requirements ■ 45

JUNOS 8.5 High Availability Configuration Guide

the extended DHCP relay agent when the router is configured for graceful Routing
Engine switchover.

The DHCP relay agent process that runs on any Routing Engine always maintains
the state of active DHCP client leases in persistent storage. When you enable graceful
Routing Engine switchover on a routing platform that contains dual Routing Engines,
the primary DHCP relay agent process that runs on the master Routing Engine
communicates with the secondary DHCP relay agent process that runs on the backup
Routing Engine to keep it updated with information about the DHCP clients that it
is adding or deleting.

Specifically, graceful Routing Engine switchover support for the DHCP relay agent
prevents the loss of state information for active DHCP clients. If mastership switches
to the backup Routing Engine on routing platforms that contain dual Routing Engines,
the secondary DHCP relay agent waits in a warm state and resumes control from
the failed primary DHCP relay agent. The new primary DHCP relay agent restores
state information about DHCP clients that were active before the switchover to the
new master Routing Engine.

Graceful Routing Engine Switchover DPC Support

Graceful Routing Engine switchover supports all Dense Port Concentrators (DPCs)
on the MX-series routing platform running the appropriate version of JUNOS software:

The following DPCs are supported in JUNOS Release 8.3 and later:
■ DPC-R-40GE-SFP
■ DPC-R-4XGE-XFP

The following DPCs are supported in JUNOS Release 8.4 and later:
■ DPCE-R-40GE-SFP
■ DPCE-R-4XGE-XFP
■ DPCE-X-40GE-SFP
■ DPCE-X-4XGE-XFP

The following DPCs are supported in JUNOS Release 8.5 and later:
■ DPCE-R-Q-40GE-SFP
■ DPCE-R-Q-4XGE-XFP
■ DPCE-X-Q-40GE-SFP
■ DPCE-X-Q-4XGE-XFP

Graceful Routing Engine Switchover PIC Support

Graceful Routing Engine switchover supports most Physical Interface Cards (PICs)
on the M10i, M20, M40e, M120, M320, T320, T640, and T1600 routers and on the
TX Matrix routing platform.

46 ■ Graceful Routing Engine Switchover System Requirements

 Chapter 5: Graceful Routing Engine Switchover Overview

Use Table 9 on page 47 to determine which JUNOS software release provides initial
graceful Routing Engine switchover support for PICs installed in your router. A dash
(–) indicates that support is not available. Except where noted, the JUNOS software
release is R1.

NOTE: When an unsupported PIC is online, you cannot enable graceful Routing
Engine switchover. If graceful Routing Engine switchover is already enabled, an
unsupported PIC cannot come online.

The following constraints apply to graceful Routing Engine switchover PIC support:
■ You can include the graceful-switchover statement at the [edit chassis redundancy]
hierarchy level on a router with Adaptive Services and MultiServices PICs
configured on it and issue the commit command. The commit will succeed.
However, all services on these PICs are reset during a switchover.
■ Graceful Routing Engine switchover is not supported on any Monitoring Services
PICs or Multilink Services PICs. If you include the graceful-switchover statement
at the [edit chassis redundancy] hierarchy level on a router with either of these
PIC types configured on it and issue the commit command, the commit fails.
■ Graceful Routing Engine switchover is not supported on Multiservices 400 PICs
configured for monitoring services applications. If you include the
graceful-switchover statement, the commit fails.

Table 9: Graceful Routing Engine Switchover PIC Support

TX
PIC Type M10i M20 M40e M120 M320 T320 T640 Matrix T1600

Adaptive 7.3 7.3 7.3 – – – – – –

Services PICs

Adaptive 7.2 7.2 7.2 8.2 7.2 7.2 7.2 7.3 8.5
Services II PICs

Adaptive 7.6 7.6 7.6 8.2 7.6 7.6 7.6 n/a 8.5
Services II PICs
with Link
Services IQ
(LSQ) interfaces

Adaptive 7.3 – 7.3 8.2 7.3 – – – –

Services II FIPS
PICs

ATM2 DS3 IQ 6.1 6.1 6.1 8.2 6.4 – 8.0 8.0 8.5
PICs

ATM2 E3 IQ 6.1 6.1 6.1 8.2 6.3 7.4 7.4 7.4 8.5
PICs

Graceful Routing Engine Switchover System Requirements ■ 47

JUNOS 8.5 High Availability Configuration Guide

Table 9: Graceful Routing Engine Switchover PIC Support (continued)

TX
PIC Type M10i M20 M40e M120 M320 T320 T640 Matrix T1600

ATM2 6.1 6.0 6.0 8.2 6.2 6.0 7.6 7.6 8.5
OC3/STM1 IQ
PICs

ATM2 6.1 6.0 6.0 8.2 6.2 6.0 8.0 8.0 8.5
OC12/STM4 IQ
PICs, 1-port

ATM2 – – 6.0 8.2 6.2 6.0 6.0 7.0 8.5

OC12/STM4 IQ
PICs, 2-port

ATM2 – – 7.3 8.2 7.3 7.3 7.3 7.3 8.5

OC48/STM16 IQ
PICs with SFP

Channelized 6.1 6.0 6.0 – – – – – –

DS3 PICs

Channelized 6.1 6.0 6.0 – – – – – –

OC12 PICs

Channelized 6.1 6.1 6.1 8.2 6.2 6.3 8.0 8.0 8.5
DS3 IQ PICs

Channelized E1 6.1 6.1 6.1 8.2 6.2 – – – –

IQ PICs

Channelized 7.1 7.1 7.1 8.2 7.1 7.1 7.6 7.6 8.5
OC3 IQ PICs

Channelized 6.1 6.1 6.1 8.2 6.2 6.1 6.3 7.0 8.5
OC12 IQ PICs

Channelized 6.1 6.1 6.1 8.2 6.2 6.1 7.5 7.5 8.5
STM1 IQ PICs

Channelized T1 7.4 7.4 7.4 8.2 7.4 – – – –

IQ PICs

DS3 PICs 6.1 6.0 6.0 8.2 6.2 6.0 6.3 7.0 8.5

E1 PICs 6.1 6.0 6.0 8.2 6.4 – – – –

E3 PICs 6.1 – – – 6.3 – – – –

E3 IQ PICs 6.1 6.1 6.1 8.2 6.2 6.2 6.3 7.3 8.5

EIA-530 PICs 6.1 6.0 6.0 – – – – – –

ES PICs 6.1 6.1 6.1 – 6.2 6.1 – – –

Fast Ethernet 6.1 6.0 6.0 8.2 6.2 6.0 6.3 7.0 8.5
PICs, 4-port

48 ■ Graceful Routing Engine Switchover System Requirements

 Chapter 5: Graceful Routing Engine Switchover Overview

Table 9: Graceful Routing Engine Switchover PIC Support (continued)

TX
PIC Type M10i M20 M40e M120 M320 T320 T640 Matrix T1600

Fast Ethernet 6.1 6.0 6.0 8.2 6.3 – – – –

PICs, 8-port

Fast Ethernet 6.1 6.0 6.0 8.2 6.2 6.1 – – –

PICs, 12-port

Fast Ethernet – – 6.0 8.2 6.4 – – – –

PICs, 48-port

Fast Ethernet 6.2 6.2 6.2 8.2 6.2 6.2 6.2 7.0 8.5
PICs
(aggregated)

Gigabit Ethernet 6.4 6.4 6.4 8.2 6.4 6.4 8.0 8.0 8.5
PICs with SFP,
1-port

Gigabit Ethernet 6.4 6.4 6.4 8.2 6.4 6.4 8.0 8.0 8.5
PICs with SFP,
1-port

Gigabit Ethernet – – 6.4 8.2 6.4 6.4 6.4 7.0 8.5

PICs with SFP,
2-port

Gigabit Ethernet – – 7.0 8.2 7.0 7.0 7.0 7.0 8.5

PICs with SFP,
4-port

Gigabit Ethernet – – – 8.2 6.2 6.0 6.0 7.0 8.5

PICs with SFP,
10-port

Gigabit Ethernet 7.0 7.0 7.0 8.2 7.0 7.0 8.0 8.0 8.5
IQ PICs, 1-port

Gigabit Ethernet – – 7.0 8.2 7.0 7.0 7.0 7.3 8.5

IQ PICs, 2-port

Gigabit Ethernet 7.6 – 7.6 8.2 7.6 7.6 7.6 7.6 8.5
IQ2 PICs, 4-port

Gigabit Ethernet – – 7.6 8.2 7.6 7.6 7.6 7.6 8.5

IQ2 PICs, 8-port

10-Gigabit – – – 8.2 7.5 7.5 7.5 7.5 8.5

Ethernet
DWDM PICs

10-Gigabit – – – 8.2 6.2 6.2 6.2 7.0 8.5

Ethernet
XENPACK PICs

Graceful Routing Engine Switchover System Requirements ■ 49

JUNOS 8.5 High Availability Configuration Guide

Table 9: Graceful Routing Engine Switchover PIC Support (continued)

TX
PIC Type M10i M20 M40e M120 M320 T320 T640 Matrix T1600

Link Services 7.0 7.0 7.0 – 7.0 – – – –

PICs

Multiservices 8.1R2 – 8.1R2 8.2 8.1R2 8.1R2 8.1R2 8.1R2 8.5

100

Multiservices – – 8.1R2 8.2 8.1R2 8.1R2 8.1R2 8.1R2 8.5

400

Multiservices – – – 8.3 8.3 8.3 8.3 8.3 8.5

500

SONET/SDH 6.1 – – – – – – – –
OC3c/STM1
PICs, 2-port
Type 1

SONET/SDH 6.1 6.0 6.0 8.2 6.2 7.1 7.1 7.1 8.5
OC3c/STM1
PICs,4-port
Type 1

SONET/SDH – – – – – 6.0 6.0 7.0 8.5

OC3c/STM1
PICs, 4-port
Type 2

SONET/SDH 8.4 8.4 – – – – – – –

OC3/STM1 PICs
with SFP, 2-port
Type 1

SONET/SDH 8.4 8.4 8.4 8.4 8.4 8.4 8.4 8.4 8.5
OC3/STM1
(Multi-Rate)
with SFP,
4–port Type 1

SONET/SDH – – 8.3 8.3 8.3 8.3 8.3 8.3 8.5

OC3/STM1
(Multi-Rate)
with SFP,
4–port Type 2

SONET/SDH 6.1 6.0 6.0 8.2 6.2 7.5 6.0 7.0 8.5
OC12c/STM4
SMIR PICs,
1-port Type 1

SONET/SDH – – – – – – 7.1 7.1 8.5

OC12c/STM4
MM PICs, 1-port
Type 1

50 ■ Graceful Routing Engine Switchover System Requirements

 Chapter 5: Graceful Routing Engine Switchover Overview

Table 9: Graceful Routing Engine Switchover PIC Support (continued)

TX
PIC Type M10i M20 M40e M120 M320 T320 T640 Matrix T1600

SONET/SDH – – 6.0 8.2 6.2 6.0 6.0 7.0 8.5

OC12c/STM4
PICs, 4-port
Type 2

SONET/SDH 8.4 8.4 8.4 8.4 8.4 8.4 8.4 8.4 8.5
OC12/STM4
(Multi-Rate)
with SFP, 1-port
Type 1

SONET/SDH – – 8.3 8.3 8.3 8.3 8.3 8.3 8.5

OC12/STM4
(Multi-Rate)
with SFP, 4-port
Type 2

SONET/SDH 6.4 6.1 – – – – – – –

OC48c/STM16
PICs with SFP,
1-port
quad-wide Type
1

SONET/SDH – – 6.1 8.2 6.2 6.1 6.1 7.0 8.5

OC48c/STM16
PICs with SFP,
1-port Type 2

SONET/SDH – – – 8.2 6.2 6.2 6.2 7.0 8.5

OC48c/STM16
PICs with SFP,
4-port Type 3

SONET/SDH – – 8.3 8.3 8.3 8.3 8.3 8.3 8.5

OC48/STM16
(Multi-Rate)
with SFP,
1-port, Type 2

SONET/SDH – – – 8.2 6.2 6.0 6.0 7.0 8.5

OC192c/STM64
PICs, 1-port
Type 3

SONET/SDH – – – – – – 7.5 7.5 8.5

OC768c/STM256
PICs, 1-port
Type 4

SONET/SDH 6.2 6.2 6.2 8.2 6.2 6.2 6.2 7.0 8.5
PICs
(aggregated)

T1 PICs 6.1 6.0 6.0 8.2 6.4 – – – –

Graceful Routing Engine Switchover System Requirements ■ 51

JUNOS 8.5 High Availability Configuration Guide

Table 9: Graceful Routing Engine Switchover PIC Support (continued)

TX
PIC Type M10i M20 M40e M120 M320 T320 T640 Matrix T1600

Tunnel Services 6.1 6.0 7.0 8.2 6.2 6.1 8.0 8.0 8.5
PICs, Type 1

Tunnel Services – – 7.0 8.2 6.2 6.1 6.1 7.0 8.5

PICs, Type 2

Tunnel Services – – – 8.2 6.3 6.0 6.0 7.0 8.5

PICs, Type 3

Tunnel Services – – – – – – 8.0 8.0 8.5

PICs, 40-Gigabit

52 ■ Graceful Routing Engine Switchover System Requirements

Chapter 6
Graceful Routing Engine Switchover
Configuration Guidelines

This chapter contains the following information:

■ Configuring Graceful Routing Engine Switchover on page 53
■ Requirements for Routers with a Backup Router Configuration on page 54
■ Resetting Local Statistics on page 54

Configuring Graceful Routing Engine Switchover

This section contains the following topics:
■ Enabling Graceful Routing Engine Switchover on page 53
■ Synchronizing the Routing Engine Configuration on page 54
■ Verifying Graceful Routing Engine Switchover Operation on page 54

Enabling Graceful Routing Engine Switchover

By default, graceful Routing Engine switchover is disabled. To configure graceful
Routing Engine switchover, include the graceful-switchover statement at the [edit
chassis redundancy] hierarchy level.

[edit chassis redundancy]

graceful-switchover;

When you enable graceful Routing Engine switchover, the command-line interface
(CLI) indicates which Routing Engine you are using. For example:

{master} [edit]
user@host#

To disable graceful Routing Engine switchover, remove the graceful-switchover

statement from the [edit chassis redundancy] hierarchy level.

Configuring Graceful Routing Engine Switchover ■ 53

JUNOS 8.5 High Availability Configuration Guide

Synchronizing the Routing Engine Configuration

A newly inserted backup Routing Engine automatically synchronizes its configuration
with the master Routing Engine configuration.

When you configure graceful Routing Engine switchover, you can bring the backup
Routing Engine online after the master Routing Engine is already running. There is
no requirement to start the two Routing Engines simultaneously.

Verifying Graceful Routing Engine Switchover Operation

To verify whether graceful Routing Engine switchover is enabled, issue the show
system switchover command. When the output of the command indicates that the
Graceful switchover field is set to on, graceful Routing Engine switchover is operational.
For more information about the show system switchover command, see the JUNOS
System Basics and Services Command Reference.

Requirements for Routers with a Backup Router Configuration

If your Routing Engine configuration includes a backup-router statement or an

inet6-backup-router statement, you must also use the destination statement to specify
a subnet address or multiple subnet addresses for the backup router. Include
destination subnets for the backup Routing Engine at the [edit system (backup-router
| inet6-backup-router) address] hierarchy level. This requirement also applies to any
T640 routing node connected to a TX Matrix platform that includes a backup-router
or inet6-backup-router statement.

Resetting Local Statistics

When you enable graceful Routing Engine switchover, the master Routing Engine
configuration is copied and loaded to the backup Routing Engine. User files,
accounting information, and trace options information are not replicated to the
backup Routing Engine.

When a graceful Routing Engine switchover occurs, local statistics such as process
statistics and networking statistics are displayed as a cumulative value from the time
the process first came online. Because processes on the master Routing Engine can
start at different times from the processes on the backup Routing Engine, the statistics
on the two Routing Engines for the same process might differ. After a graceful Routing
Engine switchover, we recommend that you issue the clear interface statistics
(interface-name | all) command to reset the cumulative values for local statistics.
Forwarding statistics are not affected by graceful Routing Engine switchover.

For information about how to use the clear command to clear statistics and protocol
database information, see the JUNOS System Basics and Services Command Reference.

NOTE: The clear firewall command cannot be used to clear the Routing Engine filter
counters on a backup Routing Engine that is enabled for graceful Routing Engine
switchover.

54 ■ Requirements for Routers with a Backup Router Configuration

Chapter 7
Summary of Graceful Routing Engine
Switchover Configuration Statements

This chapter provides a reference for the graceful Routing Engine switchover
configuration statement.

graceful-switchover

Syntax graceful-switchover;

Hierarchy Level [edit chassis redundancy]

Release Information Statement introduced before JUNOS Release 7.4.

Description For routing platforms with two Routing Engines, configure a master Routing Engine
to switch over gracefully to a backup Routing Engine without interruption to packet
forwarding.

Usage Guidelines See “Configuring Graceful Routing Engine Switchover” on page 53.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

graceful-switchover ■ 55
JUNOS 8.5 High Availability Configuration Guide

56 ■ graceful-switchover
Part 4
Nonstop Bridging
■ Nonstop Bridging Overview on page 59
■ Nonstop Bridging Configuration Guidelines on page 63
■ Summary of Nonstop Bridging Statements on page 65

Nonstop Bridging ■ 57
JUNOS 8.5 High Availability Configuration Guide

58 ■ Nonstop Bridging
Chapter 8
Nonstop Bridging Overview

This chapter contains the following information:

■ Nonstop Bridging Concepts on page 59
■ Nonstop Bridging System Requirements on page 61

Nonstop Bridging Concepts

Nonstop bridging uses the same infrastructure as graceful Routing Engine switchover
(GRES) to preserve interface and kernel information. However, nonstop bridging also
saves Layer 2 Control Protocol (L2CP) information by running the Layer 2 Control
Protocol process (l2cpd) on the backup Routing Engine.

NOTE: To use nonstop bridging, you must first enable graceful Routing Engine
switchover on your routing platform. For more information about graceful Routing
Engine switchover, see “Graceful Routing Engine Switchover Overview” on page 41.

Nonstop Bridging Concepts ■ 59

JUNOS 8.5 High Availability Configuration Guide

Figure 3 on page 60 shows the system architecture of nonstop bridging and the
process a routing platform follows to prepare for a switchover.

Figure 3: Nonstop Bridging Architecture and the Switchover Preparation Process

The switchover preparation process for nonstop bridging follows these steps:
1. The master Routing Engine starts.
2. The routing platform processes on the master Routing Engine (such as the chassis
process [chassisd] and the Layer 2 Control Protocol process [l2cpd]) start.
3. The Packet Forwarding Engine starts and connects to the master Routing Engine.
4. All state information is updated in the system.
5. The backup Routing Engine starts, including the chassis process (chassisd) and
the Layer 2 Control Protocol process (l2cpd).
6. The system determines whether graceful Routing Engine switchover and nonstop
bridging have been enabled.
7. The kernel synchronization process (ksyncd) synchronizes the backup Routing
Engine with the master Routing Engine.
8. For supported protocols, state information is updated directly between the l2cpds
on the master and backup Routing Engines.

Figure 4 on page 61 shows the effects of a switchover on the routing platform.

60 ■ Nonstop Bridging Concepts

 Chapter 8: Nonstop Bridging Overview

Figure 4: Nonstop Bridging Architecture During a Switchover

The switchover process follows these steps:

1. When keepalives from the master Routing Engine are lost, the system switches
over gracefully to the backup Routing Engine.
2. The Packet Forwarding Engine connects to the backup Routing Engine, which
becomes the new master. Because the Layer 2 Control Protocol process (l2cpd)
and chassis process (chassisd) are already running, these processes do not need
to restart.
3. State information learned from the point of the switchover is updated in the
system. Forwarding and bridging are continued during the switchover, resulting
in minimal packet loss.

Nonstop Bridging System Requirements

This section contains the following topics:
■ Platform Support on page 61
■ Protocol Support on page 62

Platform Support
Nonstop bridging is supported on MX-series Ethernet Services routers. Your system
must be running JUNOS Release 8.4 or later.

NOTE: All Routing Engines configured for nonstop bridging must be running the
same JUNOS software release.

Nonstop Bridging System Requirements ■ 61

JUNOS 8.5 High Availability Configuration Guide

Protocol Support
Nonstop bridging is supported for the following Layer 2 control protocols:
■ Spanning Tree Protocol (STP)
■ Rapid Spanning Tree Protocol (RSTP)
■ Multiple Spanning Tree Protocol (MSTP)

62 ■ Nonstop Bridging System Requirements

Chapter 9
Nonstop Bridging Configuration
Guidelines

This chapter contains the following section:

■ Configuring Nonstop Bridging on page 63

Configuring Nonstop Bridging

This section includes the following topics:
■ Enabling Nonstop Bridging on page 63
■ Synchronizing the Routing Engine Configuration on page 63
■ Verifying Nonstop Bridging Operation on page 64

Enabling Nonstop Bridging

Nonstop bridging requires you to configure graceful Routing Engine switchover
(GRES). To enable graceful Routing Engine switchover, include the graceful-switchover
statement at the [edit chassis redundancy] hierarchy level:

[edit chassis redundancy]

graceful-switchover;

By default, nonstop bridging is disabled. To enable nonstop bridging, include the

nonstop-bridging statement at the [edit protocols layer2-control] hierarchy level:

[edit protocols layer2-control]

nonstop-bridging;

To disable nonstop routing, remove the nonstop-bridging statement from the [edit
protocols layer2–control] hierarchy level.

Synchronizing the Routing Engine Configuration

When you configure nonstop bridging, you must also include the commit synchronize
statement at the [edit system] hierarchy level so that, by default, when you issue the
commit command, the configuration changes are synchronized on both Routing
Engines. If you issue the commit synchronize command at the [edit] hierarchy level

Configuring Nonstop Bridging ■ 63

JUNOS 8.5 High Availability Configuration Guide

on the backup Routing Engine, the JUNOS system software displays a warning and
commits the candidate configuration.

NOTE: A newly inserted backup Routing Engine automatically synchronizes its

configuration with the master Routing Engine configuration.

When you configure nonstop bridging, you can bring the backup Routing Engine
online after the master Routing Engine is already running. There is no requirement
to start the two Routing Engines simultaneously.

Verifying Nonstop Bridging Operation

When you enable nonstop bridging, you can issue Layer 2 Control Protocol-related
operational mode commands on the backup Routing Engine. However, the output
of the commands might not match the output of the same commands issued on the
master Routing Engine.

64 ■ Configuring Nonstop Bridging

Chapter 10
Summary of Nonstop Bridging Statements

This chapter provides a reference for the nonstop-bridging configuration statement.

nonstop-bridging

Syntax nonstop-bridging;

Hierarchy Level [edit protocols layer2-control]

Release Information Statement introduced in JUNOS Release 8.4.

Description For routing platforms with two Routing Engines, configure a master Routing Engine
to switch over gracefully to a backup Routing Engine and preserve Layer 2 Control
Protocol (L2CP) information.

Usage Guidelines See “Configuring Nonstop Bridging” on page 63.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

nonstop-bridging ■ 65
JUNOS 8.5 High Availability Configuration Guide

66 ■ nonstop-bridging
Part 5
Nonstop Routing
■ Nonstop Routing Overview on page 69
■ Nonstop Routing Configuration Guidelines on page 75
■ Summary of Nonstop Routing Configuration Statements on page 81

Nonstop Routing ■ 67
JUNOS 8.5 High Availability Configuration Guide

68 ■ Nonstop Routing
Chapter 11
Nonstop Routing Overview

This chapter contains the following information:

■ Nonstop Routing Concepts on page 69
■ Nonstop Routing System Requirements on page 71

Nonstop Routing Concepts

Nonstop routing (NSR) uses the same infrastructure as graceful Routing Engine
switchover (GRES) to preserve interface and kernel information. However, nonstop
routing also saves routing protocol information by running the routing protocol
process (rpd) on the backup Routing Engine. By saving this additional information,
nonstop routing is self-contained and does not rely on helper routers to assist the
routing platform in restoring routing protocol information. Nonstop routing is
advantageous in networks where neighbor routers do not support graceful restart
protocol extensions. As a result of this enhanced functionality, nonstop routing is a
natural replacement for graceful restart.

NOTE: Because graceful restart helper mode (where a neighboring router assists in
a restart) is enabled by default (except for BGP), a router can both act as a helper
and be configured to support nonstop routing, although helper mode is not sustained
during a graceful Routing Engine switchover (GRES) event.

However, you cannot configure a router to undergo a graceful restart (by including
the graceful-restart statement at the [edit routing-options] hierarchy level) and configure
nonstop routing (by including the nonstop-routing option at the [edit routing-options]
hierarchy level) at the same time.

To obtain BGP helper mode support, you must first configure the router to undergo
a graceful restart. Therefore, when nonstop routing is enabled, BGP cannot provide
helper support.

NOTE: To use nonstop routing, you must first enable graceful Routing Engine
switchover on your routing platform. For more information about graceful Routing
Engine switchover, see “Graceful Routing Engine Switchover Overview” on page 41.

Nonstop Routing Concepts ■ 69

JUNOS 8.5 High Availability Configuration Guide

Figure 5 on page 70 shows the system architecture of nonstop routing and the process
a routing platform follows to prepare for a switchover.

Figure 5: Nonstop Routing Architecture and the Switchover Preparation Process

The switchover preparation process for nonstop routing follows these steps:
1. The master Routing Engine starts.
2. The routing platform processes on the master Routing Engine (such as the chassis
process [chassisd] and the routing protocol process [rpd]) start.
3. The Packet Forwarding Engine starts and connects to the master Routing Engine.
4. All state information is updated in the system.
5. The backup Routing Engine starts, including the chassis process (chassisd) and
the routing protocol process (rpd).
6. The system determines whether graceful Routing Engine switchover and nonstop
routing have been enabled.
7. The kernel synchronization process (ksyncd) synchronizes the backup Routing
Engine with the master Routing Engine.
8. For supported protocols, state information is updated directly between the routing
protocol processes on the master and backup Routing Engines.

Figure 6 on page 71 shows the effects of a switchover on the routing platform.

70 ■ Nonstop Routing Concepts

 Chapter 11: Nonstop Routing Overview

Figure 6: Nonstop Routing Architecture During a Switchover

The switchover process follows these steps:

1. When keepalives from the master Routing Engine are lost, the system switches
over gracefully to the backup Routing Engine.
2. The Packet Forwarding Engine connects to the backup Routing Engine, which
becomes the new master. Because the routing protocol process (rpd) and chassis
process (chassisd) are already running, these processes do not need to restart.
3. State information learned from the point of the switchover is updated in the
system. Forwarding and routing are continued during the switchover, resulting
in minimal packet loss.
4. Peer routers continue to interact with the routing platform as if no change had
occurred. TCP sessions for BGP, IS-IS neighbor adjacencies, and OSPF neighbor
adjacencies are preserved and not reset.

Nonstop Routing System Requirements

This section contains the following topics:
■ Platform Support on page 72
■ Protocol Support on page 72
■ BFD Support on page 72

Nonstop Routing System Requirements ■ 71

JUNOS 8.5 High Availability Configuration Guide

Platform Support
Nonstop routing is supported on the following routing platforms with dual Routing
Engines.
■ M10i router (JUNOS 8.4 or later)
■ M20 router (JUNOS 8.4 or later)
■ M40e router (JUNOS 8.4 or later)
■ M320 router (JUNOS 8.4 or later)
■ T320 router, T640 router, and TX Matrix platform (JUNOS 8.4 or later)
■ T1600 router (JUNOS 8.5 or later)

NOTE: All Routing Engines configured for nonstop routing must be running the same
JUNOS software release.

Protocol Support
Nonstop routing is supported for aggregate and static routes and for the following
protocols:
■ Border Gateway Protocol (BGP)
■ Intermediate System-to-Intermediate System (IS-IS)
■ Label Distribution Protocol (LDP)
■ Open Shortest Path First (OSPF)/OSPFv3

NOTE: If you configure a protocol that is not supported by nonstop routing, the
protocol operates as usual. When a switchover occurs, the state information for the
unsupported protocol is not preserved and must be refreshed using the normal
recovery mechanisms inherent in the protocol.

NOTE: Nonstop routing is not supported on logical routers.

BFD Support
Routing protocols use bidirectional forwarding detection (BFD) for fast liveliness
detection of their neighbors. With nonstop routing enabled, BFD session state is
saved on both the master Routing Engine and the backup Routing Engine. When a
Routing Engine switchover event occurs, the BFD session state does not need to be
restarted and peer routers continue to interface with the routing platform as if no
change had occurred.

72 ■ Nonstop Routing System Requirements

 Chapter 11: Nonstop Routing Overview

NOTE: BFD session states are saved only for clients using aggregate or static routes
or for BGP, IS-IS, or OSPF/OSPFv3. Nonstop routing must be enabled.

When a BFD session is distributed to the Packet Forwarding Engine, BFD packets
continue to be sent during a Routing Engine switchover. If non-distributed BFD
sessions are to be kept alive during a switchover, you must ensure that the session
failure detection time is greater than the Routing Engine switchover time. The
following BFD sessions are not distributed to the Packet Forwarding Engine: multi-hop
sessions, tunnel-encapsulated sessions, and sessions over aggregated Ethernet and
Integrated Routing and Bridging (IRB) interfaces.

NOTE: For BFD sessions to remain up during a Routing Engine switchover event
when nonstop routing is configured, the value for the minimum-interval configuration
statement (a BFD liveness detection parameter) must be at least 2500 msec for
Routing Engine-based sessions and at least 100 msec for distributed BFD sessions.

Nonstop Routing System Requirements ■ 73

JUNOS 8.5 High Availability Configuration Guide

74 ■ Nonstop Routing System Requirements

Chapter 12
Nonstop Routing Configuration Guidelines

This chapter contains the following sections:

■ Configuring Nonstop Routing on page 75
■ Tracing Nonstop Routing Synchronization Events on page 77
■ Resetting Local Statistics on page 77
■ Example: Configuring Nonstop Routing on page 78

Configuring Nonstop Routing

This section includes the following topics:
■ Enabling Nonstop Routing on page 75
■ Synchronizing the Routing Engine Configuration on page 76
■ Verifying Nonstop Routing Operation on page 76

Enabling Nonstop Routing

Nonstop routing (NSR) requires you to configure graceful Routing Engine switchover
(GRES). To enable graceful Routing Engine switchover, include the graceful-switchover
statement at the [edit chassis redundancy] hierarchy level:

[edit chassis redundancy]

graceful-switchover;

By default, nonstop routing is disabled. To enable nonstop routing, include the

nonstop-routing statement at the [edit routing-options] hierarchy level:

[edit routing-options]
nonstop-routing;

To disable nonstop routing, remove the nonstop-routing statement from the [edit
routing-options] hierarchy level.

To enable the routing platform to switch over to the backup Routing Engine when
the routing protocol process (rpd) fails rapidly three times in succession, include the
other-routing-engine statement at the [edit system processes routing failover] hierarchy
level.

Configuring Nonstop Routing ■ 75

JUNOS 8.5 High Availability Configuration Guide

For more information about the other-routing-engine statement, see the JUNOS System
Basics Configuration Guide.

Synchronizing the Routing Engine Configuration

When you configure nonstop routing, you must also include the commit synchronize
statement at the [edit system] hierarchy level so that configuration changes are
synchronized on both Routing Engines:

[edit system]
commit synchronize;

If you try to commit the nonstop routing configuration without including the commit
synchronize statement, the commit fails.

If you issue the commit synchronize command at the [edit] hierarchy level on the
backup Routing Engine, the JUNOS system software displays a warning and commits
the candidate configuration.

NOTE: A newly inserted backup Routing Engine automatically synchronizes its

configuration with the master Routing Engine configuration.

When you configure nonstop routing, you can bring the backup Routing Engine
online after the master Routing Engine is already running. There is no requirement
to start the two Routing Engines simultaneously.

Verifying Nonstop Routing Operation

To see whether or not nonstop routing is enabled, issue the show task replication
command. For BGP nonstop routing, you can also issue the show bgp replication
command. For more information on these commands, see the JUNOS System Basics
and Services Command Reference and JUNOS Routing Protocols and Policies Command
Reference, respectively.

When you enable nonstop routing and issue routing-related operational mode
commands on the backup Routing Engine (such as show route, show bgp neighbor,
show ospf database, and so on), the output might not match the output of the same
commands issued on the master Routing Engine.

NOTE: The output from the show bgp summary command includes an OutQ field that
indicates the number of BGP packets that are queued to be transmitted to a particular
neighbor. The count is normally 0 because the queue is usually emptied quickly.
When nonstop routing is enabled, the value might be nonzero; this is normal.

To display BFD state replication status, issue the show bfd session command. The
replicated flag appears in the output for this command when a BFD session has been
replicated to the backup Routing Engine. For more information, see the JUNOS Routing
Protocols and Policies Command Reference.

76 ■ Configuring Nonstop Routing

 Chapter 12: Nonstop Routing Configuration Guidelines

Tracing Nonstop Routing Synchronization Events

To track the progress of nonstop routing synchronization between Routing Engines,
you can configure nonstop routing trace options flags for each supported protocol
and for BFD sessions and record these operations to a log file.

To configure nonstop routing trace options for supported routing protocols, include
the nsr-synchronization statement at the [edit protocols protocol-name traceoptions flag]
hierarchy level and specify the detail, disable, receive, or send option.

[edit protocols]
bgp {
traceoptions {
flag nsr-synchronization [detail | disable | receive | send];
}
}
isis {
traceoptions {
flag nsr-synchronization [detail | disable | receive | send];
}
}
ldp {
traceoptions {
flag nsr-synchronization [detail | disable | receive | send];
}
}
(ospf | ospf3) {
traceoptions {
flag nsr-synchronization [detail | disable | receive | send];
}
}

To configure nonstop routing trace options for BFD sessions, include the
nsr-synchronization and nsr-packets statements at the [edit protocols bfd traceoptions
flag] hierarchy level.

[edit protocols]
bfd {
traceoptions {
flag nsr-synchronization;
flag nsr-packet;
}
}

Resetting Local Statistics

After a graceful Routing Engine switchover, we recommend that you issue the clear
interface statistics (interface-name | all) command to reset the cumulative values for
local statistics on the new master Routing Engine.

Tracing Nonstop Routing Synchronization Events ■ 77

JUNOS 8.5 High Availability Configuration Guide

Example: Configuring Nonstop Routing

The following example enables graceful Routing Engine switchover, nonstop routing,
and nonstop routing trace options for BGP, IS-IS, and OSPF.

[edit]
system commit {
synchronize;
}
chassis {
redundancy {
graceful-switchover; # This enables graceful Routing Engine switchover on the
routing platform.
}
}
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.0.1.1/30;
}
family iso;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.1.1/30;
}
family iso;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.2.1.1/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.3.1.1/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.2.1/32;
}
family iso {
address 49.0004.1921.6800.2001.00;

78 ■ Example: Configuring Nonstop Routing

 Chapter 12: Nonstop Routing Configuration Guidelines

}
}
}
}
routing-options {
nonstop-routing; # This enables nonstop routing on the routing platform.
router-id 192.168.2.1;
autonomous-system 65432;
}
protocols {
bgp {
traceoptions {
flag nsr-synchronization detail; # This logs nonstop routing events for BGP.
}
local-address 192.168.2.1;
group external-group {
type external;
export BGP_export;
neighbor 192.168.1.1 {
family inet {
unicast;
}
peer-as 65103;
}
}
group internal-group {
type internal;
neighbor 192.168.10.1;
neighbor 192.168.11.1;
neighbor 192.168.12.1;
}
}
isis {
traceoptions {
flag nsr-synchronization detail; # This logs nonstop routing events for IS-IS.
}
interface all;
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
ospf {
traceoptions {
flag nsr-synchronization detail; # This logs nonstop routing events for OSPF.
}
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}

Example: Configuring Nonstop Routing ■ 79

JUNOS 8.5 High Availability Configuration Guide

}
}
}
policy-options {
policy-statement BGP_export {
term direct {
from {
protocol direct;
}
then accept;
}
term final {
then reject;
}
}
}

80 ■ Example: Configuring Nonstop Routing

Chapter 13
Summary of Nonstop Routing
Configuration Statements

This chapter provides a reference for each of the nonstop routing configuration
statements. The statements are organized alphabetically.

commit synchronize

Syntax commit sychronize;

Hierarchy Level [edit system]

Release Information Statement introduced in JUNOS Release 7.4.

Description Configure a commit command to automatically result in a commit synchronize. The
Routing Engine on which you execute the commit command (requesting Routing
Engine) copies and loads its candidate configuration to the other (responding) Routing
Engines. All Routing Engines then perform a syntax check on the candidate
configuration file being committed. If no errors are found, the configuration is
activated and becomes the current operational configuration on all Routing Engines.

NOTE: When you configure nonstop routing (NSR), you must include the commit
synchronize statement. Otherwise, the commit fails.

Usage Guidelines See “Synchronizing the Routing Engine Configuration” on page 76.

Required Privilege Level system—To view this statement in the configuration.

system-control—To add this statement to the configuration.

commit synchronize ■ 81
JUNOS 8.5 High Availability Configuration Guide

nonstop-routing

Syntax nonstop-routing;

Hierarchy Level [edit routing-options]

Release Information Statement introduced in JUNOS Release 8.4.

Description For routing platforms with two Routing Engines, configure a master Routing Engine
to switch over gracefully to a backup Routing Engine and preserve routing protocol
information.

Usage Guidelines See “Configuring Nonstop Routing” on page 75.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

82 ■ nonstop-routing
 Chapter 13: Summary of Nonstop Routing Configuration Statements

traceoptions

Syntax traceoptions {
file name <replace> <size size> <files number > <no-stamp> <(world-readable |
no-world-readable)>;
flag flag <flag-modifier> <disable>;
}

Hierarchy Level [edit protocols bfd],

[edit protocols bgp],
[edit protocols isis],
[edit protocols ldp],
[edit protocols ospf]

Release Information Statement introduced before JUNOS Release 7.4.

nsr-synchronization flag for BGP, IS-IS, LDP, and OSPF introduced in JUNOS Release
8.4.
nsr-synchronization and nsr-packet flags for BFD sessions introduced in JUNOS Release
8.5.
Description Define tracing operations that track nonstop routing (NSR) functionality in the router.

To specify more than one tracing operation, include multiple flag statements.

Default If you do not include this statement, no global tracing operations are performed.

Options disable—(Optional) Disable the tracing operation. You can use this option to disable
a single operation when you have defined a broad group of tracing operations,
such as all.

file name—Name of the file to receive the output of the tracing operation. Enclose
the name within quotation marks. All files are placed in the directory /var/log.
We recommend that you place global routing protocol tracing output in the file
routing-log.

files number—(Optional) Maximum number of trace files. When a trace file named
trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1,
and so on, until the maximum number of trace files is reached. Then the oldest
trace file is overwritten.
Range: 2 through 1000 files
Default: 2 files

If you specify a maximum number of files, you also must specify a maximum file
size with the size option.

flag flag—Tracing operation to perform. To specify more than one tracing operation,
include multiple flag statements. The nonstop routing tracing options are:
■ nsr-packet—Detailed trace information for BFD nonstop routing only
■ nsr-synchronization—Tracing operations for nonstop routing

traceoptions ■ 83
JUNOS 8.5 High Availability Configuration Guide

flag-modifier—(Optional) Modifier for the tracing flag. Except for BFD sessions, you
can specify one or more of these modifiers:
■ detail—Detailed trace information

■ receive—Packets being received

■ send—Packets being transmitted

no-stamp—(Optional) Do not place timestamp information at the beginning of each

line in the trace file.
Default: If you omit this option, timestamp information is placed at the beginning
of each line of the tracing output.

replace—(Optional) Replace an existing trace file if there is one.

Default: If you do not include this option, tracing output is appended to an
existing trace file.

size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes
(MB), or gigabytes (GB). When a trace file named trace-file reaches this size, it is
renamed trace-file.0. When the trace-file again reaches its maximum size,
trace-file.0 is renamed trace-file.1 and trace-file is renamed trace-file.0. This
renaming scheme continues until the maximum number of trace files is reached.
Then the oldest trace file is overwritten.
Syntax: xk to specify KB, xm to specify MB, or xg to specify GB
Range: 10 KB through the maximum file size supported on your system
Default: 128 KB

If you specify a maximum file size, you also must specify a maximum number of
trace files with the files option.

Usage Guidelines See “Tracing Nonstop Routing Synchronization Events” on page 77.

Required Privilege Level routing and trace—To view this statement in the configuration.
routing-control and trace-control—To add this statement to the configuration.

84 ■ traceoptions
Part 6
Graceful Restart
■ Graceful Restart Overview on page 87
■ Graceful Restart Configuration Guidelines on page 95
■ Summary of Graceful Restart Configuration Statements on page 133

Graceful Restart ■ 85
JUNOS 8.5 High Availability Configuration Guide

86 ■ Graceful Restart
Chapter 14
Graceful Restart Overview

This chapter contains the following sections:

■ Graceful Restart Concepts on page 87
■ Graceful Restart System Requirements on page 88
■ Aggregate and Static Routes on page 89
■ Routing Protocols on page 89
■ MPLS-Related Protocols on page 91
■ Layer 2 and Layer 3 VPNs on page 92
■ Logical Routers on page 93

Graceful Restart Concepts

With standard implementations of routing protocols, any service interruption requires
an affected router to recalculate adjacencies with neighboring routers, restore routing
table entries, and update other protocol-specific information. An unprotected restart
of a router can result in forwarding delays, route flapping, wait times stemming from
protocol reconvergence, and even dropped packets.

Graceful restart enables a restarting router and its neighbors to continue forwarding
packets without disrupting network performance. Because neighboring routers assist
in the restart (these neighbors are called helper routers), the restarting router can
quickly resume full operation without recalculating algorithms.

Three main types of graceful restart are available on Juniper Networks routing
platforms:
■ Graceful restart for aggregate and static routes and for routing protocols—Provides
protection for aggregate and static routes and for Border Gateway Protocol (BGP),
End System-to-Intermediate System (ES-IS), Intermediate System-to-Intermediate
System (IS-IS), Open Shortest Path First (OSPF), Routing Information Protocol
(RIP), next-generation RIP (RIPng), and Protocol Independent Multicast (PIM)
sparse mode routing protocols.
■ Graceful restart for MPLS-related protocols—Provides protection for Label
Distribution Protocol (LDP), Resource Reservation Protocol (RSVP), circuit
cross-connect (CCC), and translational cross-connect (TCC).

Graceful Restart Concepts ■ 87

JUNOS 8.5 High Availability Configuration Guide

■ Graceful restart for virtual private networks (VPNs)—Provides protection for

Layer 2 and Layer 3 VPNs.

NOTE: Graceful restart for BFD sessions is supported in the case where the router is
in helper mode. When the BFD session on the remote peer is running on its Packet
Forwarding Engine and it undergoes a graceful restart, the local peer can help the
remote peer with the graceful restart.

Graceful restart works similarly for routing protocols and MPLS protocols and
combines components of these protocol types to enable graceful restart in VPNs.
The main benefits of graceful restart are uninterrupted packet forwarding and
temporary suppression of all routing protocol updates. Graceful restart thus enables
a router to pass through intermediate convergence states that are hidden from the
rest of the network.

Most graceful restart implementations define two types of routers—the restarting

router and the helper router. The restarting router requires rapid restoration of
forwarding state information so it can resume the forwarding of network traffic. The
helper router assists the restarting router in this process. Graceful restart configuration
statements typically affect either the restarting router or the helper router.

NOTE: Because graceful restart helper mode (where a neighboring router assists in
a restart) is enabled by default (except for BGP), a router can both act as a helper
and be configured to support nonstop routing, although helper mode is not sustained
during a graceful Routing Engine switchover (GRES) event.

However, you cannot configure a router to undergo a graceful restart (by including
the graceful-restart statement at the [edit routing-options] hierarchy level) and configure
nonstop routing (by including the nonstop-routing option at the [edit routing-options]
hierarchy level) at the same time.

To obtain BGP helper mode support, you must first configure the router to undergo
a graceful restart. Therefore, when nonstop routing is enabled, BGP cannot provide
helper support.

Graceful Restart System Requirements

Graceful restart is supported on all routing platforms. To implement graceful restart
for particular features, your system must meet these minimum requirements:

88 ■ Graceful Restart System Requirements

 Chapter 14: Graceful Restart Overview

■ JUNOS Release 5.3 or later for aggregate route, BGP, IS-IS, OSPF, RIP, RIPng, or
static route graceful restart
■ JUNOS Release 5.5 or later for RSVP on egress provider edge (PE) routers
■ JUNOS Release 5.5 or later for LDP graceful restart
■ JUNOS Release 5.6 or later for the CCC, TCC, Layer 2 VPN, or Layer 3 VPN
implementations of graceful restart
■ JUNOS Release 6.1 or later for RSVP graceful restart on ingress PE routers
■ JUNOS Release 6.4 or later for PIM sparse mode graceful restart
■ JUNOS Release 7.4 or later for ES-IS graceful restart (J-series routing platform)
■ JUNOS Release 8.5 or later for BFD session (helper mode only) graceful restart

Aggregate and Static Routes

When you include the graceful-restart statement at the [edit routing-options] hierarchy
level, any static routes or aggregated routes that have been configured are protected.
Because there no helper router assists in the restart, these routes are retained in the
forwarding table while the router restarts (rather than being discarded or refreshed).

Routing Protocols
This section covers the following topics:
■ BGP on page 89
■ ES-IS on page 90
■ IS-IS on page 90
■ OSPF and OSPFv3 on page 90
■ PIM Sparse Mode on page 91
■ RIP and RIPng on page 91

BGP
When a router enabled for BGP graceful restart restarts, it retains BGP peer routes
in its forwarding table and marks them as stale. However, it continues to forward
traffic to other peers (or receiving peers) during the restart. To reestablish sessions,
the restarting router sets the “restart state” bit in the BGP OPEN message and sends
it to all participating peers. The receiving peers reply to the restarting router with
messages containing end-of-routing-table markers. When the restarting router receives
all replies from the receiving peers, the restarting router performs route selection,
the forwarding table is updated, and the routes previously marked as stale are
discarded. At this point, all BGP sessions are reestablished and the restarting peer
can receive and process BGP messages as usual.

While the restarting router does its processing, the receiving peers also temporarily
retain routing information. When a receiving peer detects a TCP transport reset, it

Aggregate and Static Routes ■ 89

JUNOS 8.5 High Availability Configuration Guide

retains the routes received and marks the routes as stale. After the session is
reestablished with the restarting router, the stale routes are replaced with updated
route information.

ES-IS
When graceful restart for ES-IS is enabled, the routes to end systems or intermediate
systems are not removed from the forwarding table. The adjacencies are reestablished
after restart is complete.

NOTE: ES-IS is supported only on the J-series Services Router.

IS-IS
Normally, IS-IS routers move neighbor adjacencies to the down state when changes
occur. However, a router enabled for IS-IS graceful restart sends out Hello messages
with the Restart Request (RR) bit set in a restart type length value (TLV) message.
This indicates to neighboring routers that a graceful restart is in progress and to leave
the IS-IS adjacency intact. The neighboring routers must interpret and implement
restart signaling themselves. Besides maintaining the adjacency, the neighbors send
complete sequence number PDUs (CSNPs) to the restarting router and flood their
entire database.

The restarting router never floods any of its own link-state PDUs (LSPs), including
pseudonode LSPs, to IS-IS neighbors while undergoing graceful restart. This enables
neighbors to reestablish their adjacencies without transitioning to the down state
and enables the restarting router to reinitiate a smooth database synchronization.

OSPF and OSPFv3

When a router enabled for OSPF graceful restart restarts, it retains routes learned
before the restart in its forwarding table. The router does not allow new OSPF
link-state advertisements (LSAs) to update the routing table. This router continues to
forward traffic to other OSPF neighbors (or helper routers), and sends only a limited
number of LSAs during the restart period. To reestablish OSPF adjacencies with
neighbors, the restarting router must send a grace LSA to all neighbors. In response,
the helper routers enter helper mode and send an acknowledgement back to the
restarting router. If there are no topology changes, the helper routers continue to
advertise LSAs as if the restarting router had remained in continuous OSPF operation.

When the restarting router receives replies from all the helper routers, the restarting
router selects routes, updates the forwarding table, and discards the old routes. At
this point, full OSPF adjacencies are reestablished and the restarting router receives
and processes OSPF LSAs as usual. When the helper routers no longer receive grace
LSAs from the restarting router or the topology of the network changes, the helper
routers also resume normal operation.

90 ■ Routing Protocols
 Chapter 14: Graceful Restart Overview

PIM Sparse Mode

PIM sparse mode uses a mechanism called a generation identifier to indicate the need
for graceful restart. Generation identifiers are included by default in PIM hello
messages. An initial generation identifier is created by each PIM neighbor to establish
device capabilities. When one of the PIM neighbors restarts, it sends a new generation
identifier to its neighbors. All neighbors that support graceful restart and are connected
by point-to-point links assist by sending multicast updates to the restarting neighbor.

The restart phase completes when either the PIM state becomes stable or when the
restart interval timer expires. If the neighbors do not support graceful restart or
connect to each other using multipoint interfaces, the restarting router uses the restart
interval timer to define the restart period.

RIP and RIPng

When a router enabled for RIP graceful restart restarts, routes that have been
configured are protected. Because no helper router assists in the restart, these routes
are retained in the forwarding table while the router restarts (rather than being
discarded or refreshed).

MPLS-Related Protocols
This section contains the following topics:
■ LDP on page 91
■ RSVP on page 92
■ CCC and TCC on page 92

LDP
LDP graceful restart enables a router whose LDP control plane is undergoing a restart
to continue to forward traffic while recovering its state from neighboring routers. It
also enables a router on which helper mode is enabled to assist a neighboring router
that is attempting to restart LDP.

During session initialization, a router advertises its ability to perform LDP graceful
restart or to take advantage of a neighbor performing LDP graceful restart by sending
the graceful restart TLV. This TLV contains two fields relevant to LDP graceful restart:
the reconnect time and the recovery time. The values of the reconnect and recovery
times indicate the graceful restart capabilities supported by the router.

The reconnect time is configured in the JUNOS software as 60 seconds and is not
user-configurable. The reconnect time is how long the helper router waits for the
restarting router to establish a connection. If the connection is not established within
the reconnect interval, graceful restart for the LDP session is terminated. The
maximum reconnect time is 120 seconds and is not user-configurable. The maximum
reconnect time is the maximum value that a helper router accepts from its restarting
neighbor.

MPLS-Related Protocols ■ 91
JUNOS 8.5 High Availability Configuration Guide

When a router discovers that a neighboring router is restarting, it waits until the end
of the recovery time before attempting to reconnect. The recovery time is the length
of time a router waits for LDP to restart gracefully. The recovery time period begins
when an initialization message is sent or received. This time period is also typically
the length of time that a neighboring router maintains its information about the
restarting router, so it can continue to forward traffic.

You can configure LDP graceful restart both in the master instance for the LDP
protocol and for a specific routing instance. You can disable graceful restart at the
global level for all protocols, at the protocol level for LDP only, and for a specific
routing instance only.

RSVP
RSVP graceful restart enables a router undergoing a restart to inform its adjacent
neighbors of its condition. The restarting router requests a grace period from the
neighbor or peer, which can then cooperate with the restarting router. The restarting
router can still forward MPLS traffic during the restart period; convergence in the
network is not disrupted. The restart is not visible to the rest of the network, and the
restarting router is not removed from the network topology. RSVP graceful restart
can be enabled on both transit routers and ingress routers. It is available for both
point-to-point LSPs and point-to-multipoint LSPs.

CCC and TCC

CCC and TCC graceful restart enables Layer 2 connections between customer edge
(CE) routers to restart gracefully. These Layer 2 connections are configured with the
remote-interface-switch or lsp-switch statements. Because these CCC and TCC
connections have an implicit dependency on RSVP LSPs, graceful restart for CCC
and TCC uses the RSVP graceful restart capabilities.

RSVP graceful restart must be enabled on the provider edge (PE) routers and provider
(P) routers to enable graceful restart for CCC and TCC. Also, because RSVP is used
as the signaling protocol for signaling label information, the neighboring router must
use helper mode to assist with the RSVP restart procedures.

Layer 2 and Layer 3 VPNs

VPN graceful restart uses three types of restart functionality:
1. BGP graceful restart functionality is used on all PE-to-PE BGP sessions. This affects
sessions carrying any service signaling data for network layer reachability
information (NLRI), for example, an IPv4 VPN or Layer 2 VPN NLRI.
2. OSPF, IS-IS, LDP, or RSVP graceful restart functionality is used in all core routers.
Routes added by these protocols are used to resolve Layer 2 and Layer 3 VPN
NLRI.
3. Protocol restart functionality is used for any Layer 3 protocol (RIP, OSPF, LDP,
and so on) used between the PE and customer edge (CE) routers. This does not
apply to Layer 2 VPNs because Layer 2 protocols used between the CE and PE
routers do not have graceful restart capabilities.

92 ■ Layer 2 and Layer 3 VPNs

 Chapter 14: Graceful Restart Overview

Before VPN graceful restart can work properly, all of the components must restart
gracefully. In other words, the routers must preserve their forwarding states and
request neighbors to continue forwarding to the router in case of a restart. If all of
the conditions are satisfied, VPN graceful restart imposes the following rules on a
restarting router:
■ The router must wait to receive all BGP NLRI information from other PE routers
before advertising routes to the CE routers.
■ The router must wait for all protocols in all routing instances to converge (or
complete the restart process) before it sends CE router information to other PE
routers. In other words, the router must wait for all instance information (whether
derived from local configuration or advertisements received from a remote peer)
to be processed before it sends this information to other PE routers.
■ The router must preserve all forwarding state in the instance.mpls.0 tables until
the new labels and transit routes are allocated and announced to other PE routers
(and CE routers in a carrier-of-carriers scenario).

If any condition is not met, VPN graceful restart does not succeed in providing
uninterrupted forwarding between CE routers across the VPN infrastructure.

Logical Routers
Graceful restart for a logical router functions much as graceful restart does in the
main router. The only difference is the location of the graceful-restart statement:
■ For a logical router, include the graceful-restart statement at the [edit logical-routers
logical-router-name routing-options] hierarchy level.
■ For a routing instance inside a logical router, include the graceful-restart statement
at both the [edit logical-routers logical-router-name routing-options] and [edit
logical-routers logical-router-name routing-instances instance-name routing-options]
hierarchy levels.

Logical Routers ■ 93
JUNOS 8.5 High Availability Configuration Guide

94 ■ Logical Routers
Chapter 15
Graceful Restart Configuration Guidelines

To implement graceful restart, you must configure the following:

■ Configuring Aggregate and Static Route Graceful Restart on page 95
■ Configuring Routing Protocols Graceful Restart on page 95
■ Configuring Graceful Restart for MPLS-Related Protocols on page 100
■ Configuring VPN Graceful Restart on page 103
■ Configuring Logical Router Graceful Restart on page 104
■ Verifying Graceful Restart Operation on page 105
■ Example: Configuring Graceful Restart on page 108

Configuring Aggregate and Static Route Graceful Restart

To configure graceful restart for aggregate and static routes, include the graceful-restart
statement at the [edit routing-options] hierarchy level. To disable graceful restart,
include the disable statement at the [edit routing-options graceful-restart] hierarchy
level.

Configuring Routing Protocols Graceful Restart

This section includes the following topics:
■ Configuring Graceful Restart Globally on page 96
■ Configuring Graceful Restart Options for BGP on page 96
■ Configuring Graceful Restart Options for ES-IS on page 97
■ Configuring Graceful Restart Options for IS-IS on page 97
■ Configuring Graceful Restart Options for OSPF and OSPFv3 on page 98
■ Configuring Graceful Restart Options for RIP and RIPng on page 99
■ Configuring Graceful Restart Options for PIM Sparse Mode on page 99
■ Tracking Graceful Restart Events on page 100

Configuring Aggregate and Static Route Graceful Restart ■ 95

JUNOS 8.5 High Availability Configuration Guide

Configuring Graceful Restart Globally

To configure graceful restart globally, include the graceful-restart statement at the
[edit routing-options] hierarchy level. To configure the duration of the graceful restart
period, include the restart-duration at the [edit routing-options graceful-restart] hierarchy
level.

[edit]
routing-options {
graceful-restart {
disable;
restart-duration seconds;
}
}

To disable graceful restart globally, include the disable statement at the [edit
routing-options graceful-restart] hierarchy level.

When graceful restart is enabled for all routing protocols at the [edit routing-options
graceful-restart] hierarchy level, you can disable graceful restart on a per-protocol
basis.

NOTE: If you configure graceful restart after a BGP session has been established, the
BGP session restarts and the peers negotiate graceful restart capabilities.

Configuring Graceful Restart Options for BGP

To configure the duration of the BGP graceful restart period, include the restart-time
statement at the [edit protocols bgp graceful-restart] hierarchy level. To set the amount
of time the router waits to receive messages from restarting neighbors before declaring
them down, include the stale-routes-time statement at the [edit protocols bgp
graceful-restart] hierarchy level.

[edit]
protocols {
bgp {
graceful-restart {
disable;
restart-time seconds;
stale-routes-time seconds;
}
}
}

To disable BGP graceful restart capability for all BGP sessions, include the disable
statement at the [edit protocols bgp graceful-restart] hierarchy level.

96 ■ Configuring Routing Protocols Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

NOTE: To set BGP graceful restart properties or disable them for a group, include
the desired statements at the [edit protocols bgp group group-name graceful-restart]
hierarchy level.

To set BGP graceful restart properties or disable them for a specific neighbor in a
group, include the desired statements at the [edit protocols bgp group group-name
neighbor ip-address graceful-restart] hierarchy level.

Configuring Graceful Restart Options for ES-IS

On J-series Services Routers, to configure the duration of the ES-IS graceful restart
period, include the restart-duration statement at the [edit protocols esis graceful-restart]
hierarchy level.

[edit]
protocols {
esis {
graceful-restart {
disable;
restart-duration seconds;
}
}
}

To disable ES-IS graceful restart capability, include the disable statement at the [edit
protocols esis graceful-restart] hierarchy level.

Configuring Graceful Restart Options for IS-IS

To configure the duration of the IS-IS graceful restart period, include the restart-duration
statement at the [edit protocols isis graceful-restart] hierarchy level.

[edit]
protocols {
isis {
graceful-restart {
disable;
helper-disable;
restart-duration seconds;
}
}
}

To disable IS-IS graceful restart helper capability, include the helper-disable statement
at the [edit protocols isis graceful-restart] hierarchy level. To disable IS-IS graceful
restart capability, include the disable statement at the [edit protocols isis
graceful-restart] hierarchy level.

Configuring Routing Protocols Graceful Restart ■ 97

JUNOS 8.5 High Availability Configuration Guide

NOTE: If you configure Bidirectional Forwarding Detection (BFD) and graceful restart
for IS-IS, graceful restart might not work as expected.

NOTE: You can also track graceful restart events with the traceoptions statement at
the [edit protocols isis] hierarchy level. For more information, see “Tracking Graceful
Restart Events” on page 100.

Configuring Graceful Restart Options for OSPF and OSPFv3

To configure the duration of the OSPF/OSPFv3 graceful restart period, include the
restart-duration statement at the [edit protocols (ospf | ospf3) graceful-restart] hierarchy
level. To specify the length of time for which the router notifies helper routers that
it has completed graceful restart, include the notify-duration at the [edit protocols (ospf
| ospf3) graceful-restart] hierarchy level. Strict OSPF link-state advertisement (LSA)
checking results in the termination of graceful restart by a helping router. To disable
strict LSA checking, include the no-strict-lsa-checking statement at the [edit protocols
(ospf | ospf3) graceful-restart] hierarchy level.

[edit]
protocols {
ospf {
graceful-restart {
disable;
helper-disable;
no-strict-lsa-checking
notify-duration seconds;
restart-duration seconds;
}
}
}

To disable OSPF/OSPFv3 graceful restart, include the disable statement at the [edit
protocols (ospf | ospf3) graceful-restart] hierarchy level. To disable the OSPF helper
capability, include the helper-disable statement at the [edit protocols (ospf | ospf3)
graceful-restart] hierarchy level.

NOTE: You can also track graceful restart events with the traceoptions statement at
the [edit protocols (ospf | ospf3)] hierarchy level. For more information, see “Tracking
Graceful Restart Events” on page 100.

NOTE: You cannot enable OSPFv3 graceful restart between a routing platform running
JUNOS Release 7.5 and earlier and a routing platform running JUNOS 7.6 or later.
As a workaround, make sure both routing platforms use the same JUNOS software
version.

98 ■ Configuring Routing Protocols Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

NOTE: If you configure BFD and graceful restart for OSPF, graceful restart might not
work as expected.

Configuring Graceful Restart Options for RIP and RIPng

To configure the duration of the RIP or RIPng graceful restart period, include the
restart-time statement at the [edit protocols (rip | ripng) graceful-restart] hierarchy level.

[edit]
protocols {
(rip | ripng) {
graceful-restart {
disable;
restart-time seconds;
}
}
}

To disable RIP or RIPng graceful restart capability, include the disable statement at
the [edit protocols (rip | ripng) graceful-restart] hierarchy level.

Configuring Graceful Restart Options for PIM Sparse Mode

PIM sparse mode continues to forward existing multicast packet streams during a
graceful restart, but does not forward new streams until after the restart is complete.
After a restart, the routing platform updates the forwarding state with any updates
that were received from neighbors and occurred during the restart period. For
example, the routing platform relearns the join and prune states of neighbors during
the restart, but does not apply the changes to the forwarding table until after the
restart.

PIM sparse mode-enabled routing platforms generate a unique 32-bit random number
called a generation identifier. Generation identifiers are included by default in PIM
hello messages, as specified in the IETF Internet draft Protocol Independent Multicast
- Sparse Mode (PIM-SM): Protocol Specification (Revised). When a routing platform
receives PIM hellos containing generation identifiers on a point-to-point interface,
the JUNOS software activates an algorithm that optimizes graceful restart.

Before PIM sparse mode graceful restart occurs, each routing platform creates a
generation identifier and sends it to its multicast neighbors. If a PIM sparse
mode-enabled routing platform restarts, it creates a new generation identifier and
sends it to its neighbors. When a neighbor receives the new identifier, it resends
multicast updates to the restarting router to allow it to exit graceful restart efficiently.
The restart phase completes when either the PIM state becomes stable or when the
restart interval timer expires.

If a routing platform does not support generation identifiers or if PIM is enabled on

multipoint interfaces, the PIM sparse mode graceful restart algorithm does not activate
and a default restart timer is used as the restart mechanism.

Configuring Routing Protocols Graceful Restart ■ 99

JUNOS 8.5 High Availability Configuration Guide

To configure the duration of the PIM graceful restart period, include the restart-duration
statement at the [edit protocols pim graceful-restart] hierarchy level.

[edit]
protocols {
pim {
graceful-restart {
disable;
restart-duration seconds;
}
}
}

To disable PIM sparse mode graceful restart capability, include the disable statement
at the [edit protocols pim graceful-restart] hierarchy level.

NOTE: Multicast forwarding can be interrupted in two ways. First, if the underlying
routing protocol is unstable, multicast reverse-path-forwarding (RPF) checks can fail
and cause an interruption. Second, because the forwarding table is not updated
during the graceful restart period, new multicast streams are not forwarded until
graceful restart is complete.

Tracking Graceful Restart Events

To track the progress of a graceful restart event, you can configure graceful restart
trace options flags for IS-IS and OSPF/OSPFv3. To configure graceful restart trace
options, include the graceful-restart statement at the [edit protocols protocol traceoptions
flag] hierarchy level.

[edit protocols]
isis {
traceoptions {
flag graceful-restart;
}
}
(ospf | ospf3) {
traceoptions {
flag graceful-restart;
}
}

Configuring Graceful Restart for MPLS-Related Protocols

This section contains the following topics:
■ Configuring Graceful Restart Globally on page 101
■ Configuring Graceful Restart Options for RSVP, CCC, and TCC on page 101
■ Configuring Graceful Restart Options for LDP on page 102

100 ■ Configuring Graceful Restart for MPLS-Related Protocols

 Chapter 15: Graceful Restart Configuration Guidelines

Configuring Graceful Restart Globally

To configure graceful restart globally for all MPLS-related protocols, include the
graceful-restart statement at the [edit routing-options] hierarchy level. To configure the
duration of the graceful restart period, include the restart-duration at the [edit
routing-options graceful-restart] hierarchy level.

[edit]
routing-options {
graceful-restart {
disable;
restart-duration seconds;
}
}

NOTE: Because graceful restart helper mode (where a neighboring router assists in
a restart) is enabled by default (except for BGP), a router can both act as a helper
and be configured to support nonstop routing, although helper mode is not sustained
during a graceful Routing Engine switchover (GRES) event.

However, you cannot configure a router to undergo a graceful restart (by including
the graceful-restart statement at the [edit routing-options] hierarchy level) and configure
nonstop routing (by including the nonstop-routing option at the [edit routing-options]
hierarchy level) at the same time.

To obtain BGP helper mode support, you must first configure the router to undergo
a graceful restart. Therefore, when nonstop routing is enabled, BGP cannot provide
helper support.

To disable graceful restart globally, include the disable statement at the [edit
routing-options graceful-restart] hierarchy level.

Configuring Graceful Restart Options for RSVP, CCC, and TCC

Because CCC and TCC rely on RSVP, you must modify these three protocols as a
single group.

To configure how long the router retains the state of its RSVP neighbors while they
undergo a graceful restart, include the maximum-helper-recovery-time statement at the
[edit protocols rsvp graceful-restart] hierarchy level. This value is applied to all
neighboring routers, so it should be based on the time required by the slowest RSVP
neighbor to recover.

To configure the delay between when the router discovers that a neighboring router
has gone down and when it declares the neighbor down, include the
maximum-helper-restart-time statement at the [edit protocols rsvp graceful-restart]
hierarchy level. This value is applied to all neighboring routers, so it should be based
on the time required by the slowest RSVP neighbor to restart.

[edit]
protocols {

Configuring Graceful Restart for MPLS-Related Protocols ■ 101

JUNOS 8.5 High Availability Configuration Guide

rsvp {
graceful-restart {
disable;
helper-disable;
maximum-helper-recovery-time;
maximum-helper-restart-time;
}
}
}

NOTE: Because graceful restart helper mode (where a neighboring router assists in
a restart) is enabled by default (except for BGP), a router can both act as a helper
and be configured to support nonstop routing, although helper mode is not sustained
during a graceful Routing Engine switchover (GRES) event.

However, you cannot configure a router to undergo a graceful restart (by including
the graceful-restart statement at the [edit routing-options] hierarchy level) and configure
nonstop routing (by including the nonstop-routing option at the [edit routing-options]
hierarchy level) at the same time.

To obtain BGP helper mode support, you must first configure the router to undergo
a graceful restart. Therefore, when nonstop routing is enabled, BGP cannot provide
helper support.

To disable RSVP, CCC, and TCC graceful restart, include the disable statement at the
[edit protocols rsvp graceful-restart] hierarchy level. To disable RSVP, CCC, and TCC
helper capability, include the helper-disable statement at the [edit protocols rsvp
graceful-restart] hierarchy level.

Configuring Graceful Restart Options for LDP

To configure the amount of time that helper routers are required to maintain the old
forwarding state during a graceful restart, include the recovery-time statement at the
[edit protocols ldp graceful-restart] hierarchy level.

On the helper router, you can configure a statement that overrides the request from
the restarting router and sets the maximum amount of time the helper router will
maintain the old forwarding state. To configure this feature, include the
maximum-recovery-time statement at the [edit protocols ldp graceful-restart] hierarchy
level.

[edit]
protocols {
ldp {
graceful-restart {
disable;
helper-disable;
maximum-recovery-time seconds;
recovery-time seconds;
}
}

102 ■ Configuring Graceful Restart for MPLS-Related Protocols

 Chapter 15: Graceful Restart Configuration Guidelines

NOTE: The value for the recovery-time and maximum-recovery-time statements at the
[edit protocols ldp graceful-restart] hierarchy level should be approximately 80 seconds
longer than the value for the restart-duration statement at the [edit routing-options
graceful-restart] hierarchy level. Otherwise, a warning message appears when you
try to commit the configuration.

To disable LDP graceful restart capability, include the disable statement at the [edit
protocols ldp graceful-restart] hierarchy level. To disable LDP graceful restart helper
capability, include the helper-disable statement at the [edit protocols ldp graceful-restart]
hierarchy level.

Configuring VPN Graceful Restart

To implement graceful restart for a Layer 2 VPN, virtual private LAN service (VPLS)
instance, or Layer 3 VPN, configure the following:
■ Configuring Graceful Restart Globally on page 103
■ Configuring Graceful Restart for the Routing Instance on page 103

Configuring Graceful Restart Globally

To configure graceful restart globally, include the graceful-restart statement at the
[edit routing-options] hierarchy level. To configure the duration of the graceful restart
period, include the restart-duration statement at the [edit routing-options graceful-restart]
hierarchy level.

[edit]
routing-options {
graceful-restart {
disable;
restart-duration seconds;
}
}

To disable graceful restart globally, include the disable statement at the [edit
routing-options graceful-restart] hierarchy level.

Configuring Graceful Restart for the Routing Instance

For Layer 3 VPNs only, you must also configure graceful restart for all routing and
MPLS-related protocols within a routing instance by including the graceful-restart
statement at the [edit routing-instances instance-name routing-options] hierarchy level.
Because you can configure multi-instance BGP and multi-instance LDP, graceful
restart for a carrier-of-carriers scenario is supported. To configure the duration of
the graceful restart period for the routing instance, include the restart-duration
statement at the [edit routing-instances instance-name routing-options].

Configuring VPN Graceful Restart ■ 103

JUNOS 8.5 High Availability Configuration Guide

[edit]
routing-instances {
instance-name {
routing-options {
graceful-restart {
disable;
restart-duration seconds;
}
}
}
}

You can disable graceful restart for individual protocols with the disable statement
at the [edit routing-instances instance-name protocols protocol-name graceful-restart]
hierarchy level.

Configuring Logical Router Graceful Restart

Graceful restart for a logical router functions much as graceful restart does in the
main router. The only difference is the location of the graceful-restart statement.

To implement graceful restart in a logical router, configure the following:

■ Configuring Graceful Restart Globally on page 104
■ Configuring Graceful Restart for a Routing Instance on page 105

Configuring Graceful Restart Globally

To configure graceful restart globally in a logical router, include the graceful-restart
statement at the [edit logical-routers logical-router-name routing-options] hierarchy level.
To configure the duration of the graceful restart period, include the restart-duration
statement at the [edit logical-routers logical-router-name routing-options graceful-restart]
hierarchy level.

[edit]
logical-routers {
logical-router-name {
routing-options {
graceful-restart {
disable;
restart-duration seconds;
}
}
}
}

To disable graceful restart globally, include the disable statement at the [edit
logical-routers logical-router-name routing-options graceful-restart] hierarchy level.

104 ■ Configuring Logical Router Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

Configuring Graceful Restart for a Routing Instance

For Layer 3 VPNs only, you must also configure graceful restart globally for a routing
instance inside a logical router. To configure, include the graceful-restart statement
at the [edit logical-routers logical-router-name routing-instances instance-name
routing-options] hierarchy level. Because you can configure multi-instance BGP and
multi-instance LDP, graceful restart for a carrier-of-carriers scenario is supported. To
configure the duration of the graceful restart period for the routing instance, include
the restart-duration statement at the [edit logical-routers logical-router-name
routing-instances instance-name routing-options].

[edit]
logical-routers {
logical-router-name {
routing-instances {
instance-name {
routing-options {
graceful-restart {
disable;
restart-duration seconds;
}
}
}
}
}
}

To disable graceful restart for individual protocols with the disable statement at the
[edit logical-routers logical-router-name routing-instances instance-name protocols
protocol-name graceful-restart] hierarchy level.

Verifying Graceful Restart Operation

This section contains the following topics:
■ Graceful Restart Operational Mode Commands on page 106
■ Verifying BGP Graceful Restart on page 106
■ Verifying IS-IS and OSPF Graceful Restart on page 107
■ Verifying CCC and TCC Graceful Restart on page 107

Verifying Graceful Restart Operation ■ 105

JUNOS 8.5 High Availability Configuration Guide

Graceful Restart Operational Mode Commands

To verify proper operation of graceful restart, use the following commands:
■ show bgp neighbor (for BGP graceful restart)
■ show log (for IS-IS and OSPF/OSPFv3 graceful restart)
■ show rsvp neighbor detail (for RSVP graceful restart—helper router)
■ show rsvp version (for RSVP graceful restart—restarting router)
■ show ldp session detail (for LDP graceful restart)
■ show connections (for CCC and TCC graceful restart)
■ show route instance detail (for Layer 3 VPN graceful restart and for any protocols
using graceful restart in a routing instance)
■ show route protocol l2vpn (for Layer 2 VPN graceful restart)

Verifying BGP Graceful Restart

To view graceful restart information for BGP sessions, use the show bgp neighbor
command:

user@PE1> show bgp neighbor 192.255.10.1

Peer: 192.255.10.1+179 AS 64595 Local: 192.255.5.1+1106 AS 64595
Type: Internal State: Established Flags: <>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ static ]
Options:<Preference LocalAddress HoldTime GracefulRestart Damping PeerAS Refresh>

Local Address: 192.255.5.1 Holdtime: 90 Preference: 170

IPSec SA Name: hope
Number of flaps: 0
Peer ID: 192.255.10.1 Local ID: 192.255.5.1 Active Holdtime: 90
Keepalive Interval: 30
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 180
Stale routes from peer are kept for: 180
Restart time requested by this peer: 300
NLRI that peer supports restart for: inet-unicast
NLRI that peer saved forwarding for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Table inet.0 Bit: 10000
RIB State: restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Suppressed due to damping: 0
Last traffic (seconds): Received 19 Sent 19 Checked 19
Input messages: Total 2 Updates 1 Refreshes 0 Octets 42

106 ■ Verifying Graceful Restart Operation

 Chapter 15: Graceful Restart Configuration Guidelines

Output messages: Total 3 Updates 0 Refreshes 0 Octets 116

Output Queue[0]: 0

Verifying IS-IS and OSPF Graceful Restart

To view graceful restart information for IS-IS and OSPF, configure traceoptions (see
“Tracking Graceful Restart Events” on page 100).

Here is the output of a traceoptions log from an OSPF restarting router:

Oct 8 05:20:12 Restart mode - sending grace lsas

Oct 8 05:20:12 Restart mode - estimated restart duration timer triggered
Oct 8 05:20:13 Restart mode - Sending more grace lsas

Here is the output of a traceoptions log from an OSPF helper router:

Oct 8 05:20:14 Helper mode for neighbor 192.255.5.1

Oct 8 05:20:14 Received multiple grace lsa from 192.255.5.1

Verifying CCC and TCC Graceful Restart

To view graceful restart information for CCC and TCC connections, use the show
connections command. The following example assumes four remote interface CCC
connections between CE1 and CE2:

user@PE1> show connections

CCC and TCC connections [Link Monitoring On]
Legend for status (St) Legend for connection types
UN -- uninitialized if-sw: interface switching
NP -- not present rmt-if: remote interface switching
WE -- wrong encapsulation lsp-sw: LSP switching
DS -- disabled
Dn -- down Legend for circuit types
-> -- only outbound conn is up intf -- interface
<- -- only inbound conn is up tlsp -- transmit LSP
Up -- operational rlsp -- receive LSP
RmtDn -- remote CCC down
Restart -- restarting

CCC Graceful restart : Restarting

Connection/Circuit Type St Time last up # Up trans

CE1-CE2-0 rmt-if Restart ----- 0
fe-1/1/0.0 intf Up
PE1-PE2-0 tlsp Up
PE2-PE1-0 rlsp Up
CE1-CE2-1 rmt-if Restart ----- 0
fe-1/1/0.1 intf Up
PE1-PE2-1 tlsp Up
PE2-PE1-1 rlsp Up
CE1-CE2-2 rmt-if Restart ----- 0
fe-1/1/0.2 intf Up
PE1-PE2-2 tlsp Up
PE2-PE1-2 rlsp Up
CE1-CE2-3 rmt-if Restart ----- 0
fe-1/1/0.3 intf Up

Verifying Graceful Restart Operation ■ 107

JUNOS 8.5 High Availability Configuration Guide

PE1-PE2-3 tlsp Up
PE2-PE1-3 rlsp Up

Example: Configuring Graceful Restart

Figure 7 on page 108 shows a standard MPLS VPN network. Routers CE1 and CE2
are customer edge routers, PE1 and PE2 are provider edge routers, and P0 is a
provider core router. Several Layer 3 VPNs are configured across this network, as
well as one Layer 2 VPN. Interfaces are shown in the diagram and are not included
in the configuration example that follows.

Figure 7: Layer 3 VPN Graceful Restart Topology

Router CE1 On Router CE1, configure the following protocols on the logical interfaces of t3-3/1/0:
OSPF on unit 101, RIP on unit 102, BGP on unit 103, and IS-IS on unit 512. Also
configure graceful restart, BGP, IS-IS, OSPF, and RIP on the main instance to be able
to connect to the routing instances on Router PE1.

[edit]
interfaces {
t3-3/1/0 {
encapsulation frame-relay;
unit 100 {
dlci 100;
family inet {
address 10.96.100.2/30;
}
}
unit 101 {
dlci 101;
family inet {
address 10.96.101.2/30;
}
}
unit 102 {
dlci 102;
family inet {
address 10.96.102.2/30;
}
}
unit 103 {
dlci 103;
family inet {
address 10.96.103.2/30;

108 ■ Example: Configuring Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

}
}
unit 512 {
dlci 512;
family inet {
address 10.96.252.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.245.14.172/32;
primary;
}
address 10.96.110.1/32;
address 10.96.111.1/32;
address 10.96.112.1/32;
address 10.96.113.1/32;
address 10.96.116.1/32;
}
family iso {
address 47.0005.80ff.f800.0000.0108.0001.0102.4501.4172.00;
}
}
}
routing-options {
graceful-restart;
autonomous-system 65100;
}
protocols {
bgp {
group CE-PE-INET {
type external;
export BGP_INET_LB_DIRECT;
neighbor 10.96.103.1 {
local-address 10.96.103.2;
family inet {
unicast;
}
peer-as 65103;
}
}
}
isis {
export ISIS_L2VPN_LB_DIRECT;
interface t3-3/1/0.512;
}
ospf {
export OSPF_LB_DIRECT;
area 0.0.0.0 {
interface t3-3/1/0.101;
}
}
rip {
group RIP {

Example: Configuring Graceful Restart ■ 109

JUNOS 8.5 High Availability Configuration Guide

export RIP_LB_DIRECT;
neighbor t3-3/1/0.102;
}
}
}
policy-options {
policy-statement OSPF_LB_DIRECT {
term direct {
from {
protocol direct;
route-filter 10.96.101.0/30 exact;
route-filter 10.96.111.1/32 exact;
}
then accept;
}
term final {
then reject;
}
}
policy-statement RIP_LB_DIRECT {
term direct {
from {
protocol direct;
route-filter 10.96.102.0/30 exact;
route-filter 10.96.112.1/32 exact;
}
then accept;
}
term final {
then reject;
}
}
policy-statement BGP_INET_LB_DIRECT {
term direct {
from {
protocol direct;
route-filter 10.96.103.0/30 exact;
route-filter 10.96.113.1/32 exact;
}
then accept;
}
term final {
then reject;
}
}
policy-statement ISIS_L2VPN_LB_DIRECT {
term direct {
from {
protocol direct;
route-filter 10.96.116.1/32 exact;
}
then accept;
}
term final {
then reject;
}

110 ■ Example: Configuring Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

}
}

Router PE1 On Router PE1, configure graceful restart in the master instance, along with BGP,
OSPF, MPLS, and LDP. Next, configure several protocol-specific instances of graceful
restart. By including instances for BGP, OSPF, Layer 2 VPNs, RIP, and static routes,
you can observe the wide range of options available when you implement graceful
restart. Configure the following protocols in individual instances on the logical
interfaces of t3-0/0/0: a static route on unit 100, OSPF on unit 101, RIP on unit 102,
BGP on unit 103, and Frame Relay on unit 512 for the Layer 2 VPN instance.

[edit]
interfaces {
t3-0/0/0 {
dce;
encapsulation frame-relay-ccc;
unit 100 {
dlci 100;
family inet {
address 10.96.100.1/30;
}
family mpls;
}
unit 101 {
dlci 101;
family inet {
address 10.96.101.1/30;
}
family mpls;
}
unit 102 {
dlci 102;
family inet {
address 10.96.102.1/30;
}
family mpls;
}
unit 103 {
dlci 103;
family inet {
address 10.96.103.1/30;
}
family mpls;
}
unit 512 {
encapsulation frame-relay-ccc;
dlci 512;
}
}
t1-0/1/0 {
unit 0 {
family inet {
address 10.96.0.2/30;
}
family mpls;

Example: Configuring Graceful Restart ■ 111

JUNOS 8.5 High Availability Configuration Guide

}
}
lo0 {
unit 0 {
family inet {
address 10.245.14.176/32;
}
family iso {
address 47.0005.80ff.f800.0000.0108.0001.0102.4501.4176.00;
}
}
}
}
routing-options {
graceful-restart;
router-id 10.245.14.176;
autonomous-system 69;
}
protocols {
mpls {
interface all;
}
bgp {
group PEPE {
type internal;
neighbor 10.245.14.182 {
local-address 10.245.14.176;
family inet-vpn {
unicast;
}
family l2vpn {
unicast;
}
}
}
}
ospf {
area 0.0.0.0 {
interface t1-0/1/0.0;
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
}
ldp {
interface all;
}
}
policy-options {
policy-statement STATIC-import {
from community STATIC;
then accept;
}

112 ■ Example: Configuring Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

policy-statement STATIC-export {
then {
community add STATIC;
accept;
}
}
policy-statement OSPF-import {
from community OSPF;
then accept;
}
policy-statement OSPF-export {
then {
community add OSPF;
accept;
}
}
policy-statement RIP-import {
from community RIP;
then accept;
}
policy-statement RIP-export {
then {
community add RIP;
accept;
}
}
policy-statement BGP-INET-import {
from community BGP-INET;
then accept;
}
policy-statement BGP-INET-export {
then {
community add BGP-INET;
accept;
}
}
policy-statement L2VPN-import {
from community L2VPN;
then accept;
}
policy-statement L2VPN-export {
then {
community add L2VPN;
accept;
}
}
community BGP-INET members target:69:103;
community L2VPN members target:69:512;
community OSPF members target:69:101;
community RIP members target:69:102;
community STATIC members target:69:100;
}
routing-instances {
BGP-INET {
instance-type vrf;
interface t3-0/0/0.103;

Example: Configuring Graceful Restart ■ 113

JUNOS 8.5 High Availability Configuration Guide

route-distinguisher 10.245.14.176:103;
vrf-import BGP-INET-import;
vrf-export BGP-INET-export;
routing-options {
graceful-restart;
autonomous-system 65103;
}
protocols {
bgp {
group BGP-INET {
type external;
export BGP-INET-import;
neighbor 10.96.103.2 {
local-address 10.96.103.1;
family inet {
unicast;
}
peer-as 65100;
}
}
}
}
}
L2VPN {
instance-type l2vpn;
interface t3-0/0/0.512;
route-distinguisher 10.245.14.176:512;
vrf-import L2VPN-import;
vrf-export L2VPN-export;
protocols {# There is no graceful-restart statement for Layer 2 VPN instances.
l2vpn {
encapsulation-type frame-relay;
site CE1-ISIS {
site-identifier 512;
interface t3-0/0/0.512 {
remote-site-id 612;
}
}
}
}
}
OSPF {
instance-type vrf;
interface t3-0/0/0.101;
route-distinguisher 10.245.14.176:101;
vrf-import OSPF-import;
vrf-export OSPF-export;
routing-options {
graceful-restart;
}
protocols {
ospf {
export OSPF-import;
area 0.0.0.0 {
interface all;
}

114 ■ Example: Configuring Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

}
}
}
RIP {
instance-type vrf;
interface t3-0/0/0.102;
route-distinguisher 10.245.14.176:102;
vrf-import RIP-import;
vrf-export RIP-export;
routing-options {
graceful-restart;
}
protocols {
rip {
group RIP {
export RIP-import;
neighbor t3-0/0/0.102;
}
}
}
}
STATIC {
instance-type vrf;
interface t3-0/0/0.100;
route-distinguisher 10.245.14.176:100;
vrf-import STATIC-import;
vrf-export STATIC-export;
routing-options {
graceful-restart;
static {
route 10.96.110.1/32 next-hop t3-0/0/0.100;
}
}
}
}

Router P0 On Router P0, configure graceful restart in the main instance, along with OSPF,
MPLS, and LDP. This allows the protocols on the PE routers to reach each other.

[edit]
interfaces {
t3-0/1/3 {
unit 0 {
family inet {
address 10.96.0.5/30;
}
family mpls;
}
}
t1-0/2/0 {
unit 0 {
family inet {
address 10.96.0.1/30;
}
family mpls;

Example: Configuring Graceful Restart ■ 115

JUNOS 8.5 High Availability Configuration Guide

}
}
lo0 {
unit 0 {
family inet {
address 10.245.14.174/32;
}
family iso {
address 47.0005.80ff.f800.0000.0108.0001.0102.4501.4174.00;
}
}
}
}
routing-options {
graceful-restart;
router-id 10.245.14.174;
autonomous-system 69;
}
protocols {
mpls {
interface all;
}
ospf {
area 0.0.0.0 {
interface t1-0/2/0.0;
interface t3-0/1/3.0;
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
}
ldp {
interface all;
}
}

Router PE2 On Router PE2, configure BGP, OSPF, MPLS, LDP, and graceful restart in the master
instance. Configure the following protocols in individual instances on the logical
interfaces of t1-0/1/3: a static route on unit 200, OSPF on unit 201, RIP on unit 202,
BGP on unit 203, and Frame Relay on unit 612 for the Layer 2 VPN instance. Also
configure protocol-specific graceful restart in all routing instances, except the Layer 2
VPN instance.

[edit]
interfaces {
t3-0/0/0 {
unit 0 {
family inet {
address 10.96.0.6/30;
}
family mpls;
}

116 ■ Example: Configuring Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

}
t1-0/1/3 {
dce;
encapsulation frame-relay-ccc;
unit 200 {
dlci 200;
family inet {
address 10.96.200.1/30;
}
family mpls;
}
unit 201 {
dlci 201;
family inet {
address 10.96.201.1/30;
}
family mpls;
}
unit 202 {
dlci 202;
family inet {
address 10.96.202.1/30;
}
family mpls;
}
unit 203 {
dlci 203;
family inet {
address 10.96.203.1/30;
}
family mpls;
}
unit 612 {
encapsulation frame-relay-ccc;
dlci 612;
}
}
lo0 {
unit 0 {
family inet {
address 10.245.14.182/32;
}
family iso {
address 47.0005.80ff.f800.0000.0108.0001.0102.4501.4182.00;
}
}
}
}
routing-options {
graceful-restart;
router-id 10.245.14.182;
autonomous-system 69;
}
protocols {
mpls {
interface all;

Example: Configuring Graceful Restart ■ 117

JUNOS 8.5 High Availability Configuration Guide

}
bgp {
group PEPE {
type internal;
neighbor 10.245.14.176 {
local-address 10.245.14.182;
family inet-vpn {
unicast;
}
family l2vpn {
unicast;
}
}
}
}
ospf {
area 0.0.0.0 {
interface t3-0/0/0.0;
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
}
ldp {
interface all;
}
policy-options {
policy-statement STATIC-import {
from community STATIC;
then accept;
}
policy-statement STATIC-export {
then {
community add STATIC;
accept;
}
}
policy-statement OSPF-import {
from community OSPF;
then accept;
}
policy-statement OSPF-export {
then {
community add OSPF;
accept;
}
}
policy-statement RIP-import {
from community RIP;
then accept;
}
policy-statement RIP-export {
then {

118 ■ Example: Configuring Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

community add RIP;

accept;
}
}
policy-statement BGP-INET-import {
from community BGP-INET;
then accept;
}
policy-statement BGP-INET-export {
then {
community add BGP-INET;
accept;
}
}
policy-statement L2VPN-import {
from community L2VPN;
then accept;
}
policy-statement L2VPN-export {
then {
community add L2VPN;
accept;
}
}
community BGP-INET members target:69:103;
community L2VPN members target:69:512;
community OSPF members target:69:101;
community RIP members target:69:102;
community STATIC members target:69:100;
}
routing-instances {
BGP-INET {
instance-type vrf;
interface t1-0/1/3.203;
route-distinguisher 10.245.14.182:203;
vrf-import BGP-INET-import;
vrf-export BGP-INET-export;
routing-options {
graceful-restart;
autonomous-system 65203;
}
protocols {
bgp {
group BGP-INET {
type external;
export BGP-INET-import;
neighbor 10.96.203.2 {
local-address 10.96.203.1;
family inet {
unicast;
}
peer-as 65200;
}
}
}
}

Example: Configuring Graceful Restart ■ 119

JUNOS 8.5 High Availability Configuration Guide

}
L2VPN {
instance-type l2vpn;
interface t1-0/1/3.612;
route-distinguisher 10.245.14.182:612;
vrf-import L2VPN-import;
vrf-export L2VPN-export;
protocols {# There is no graceful-restart statement for Layer 2 VPN instances.
l2vpn {
encapsulation-type frame-relay;
site CE2-ISIS {
site-identifier 612;
interface t1-0/1/3.612 {
remote-site-id 512;
}
}
}
}
}
OSPF {
instance-type vrf;
interface t1-0/1/3.201;
route-distinguisher 10.245.14.182:201;
vrf-import OSPF-import;
vrf-export OSPF-export;
routing-options {
graceful-restart;
}
protocols {
ospf {
export OSPF-import;
area 0.0.0.0 {
interface all;
}
}
}
}
RIP {
instance-type vrf;
interface t1-0/1/3.202;
route-distinguisher 10.245.14.182:202;
vrf-import RIP-import;
vrf-export RIP-export;
routing-options {
graceful-restart;
}
protocols {
rip {
group RIP {
export RIP-import;
neighbor t1-0/1/3.202;
}
}
}
}
STATIC {

120 ■ Example: Configuring Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

instance-type vrf;
interface t1-0/1/3.200;
route-distinguisher 10.245.14.182:200;
vrf-import STATIC-import;
vrf-export STATIC-export;
routing-options {
graceful-restart;
static {
route 10.96.210.1/32 next-hop t1-0/1/3.200;
}
}
}
}
}

Router CE2 On Router CE2, complete the Layer 2 and Layer 3 VPN configuration by mirroring
the protocols already set on PE2 and CE1. Specifically, configure the following on
the logical interfaces of t1-0/0/3: OSPF on unit 201, RIP on unit 202, BGP on unit
203, and IS-IS on unit 612. Finally, configure graceful restart, BGP, IS-IS, OSPF, and
RIP on the main instance to be able to connect to the routing instances on PE2.

[edit]
interfaces {
t1-0/0/3 {
encapsulation frame-relay;
unit 200 {
dlci 200;
family inet {
address 10.96.200.2/30;
}
}
unit 201 {
dlci 201;
family inet {
address 10.96.201.2/30;
}
}
unit 202 {
dlci 202;
family inet {
address 10.96.202.2/30;
}
}
unit 203 {
dlci 203;
family inet {
address 10.96.203.2/30;
}
}
unit 512 {
dlci 512;
family inet {
address 10.96.252.2/30;
}
}

Example: Configuring Graceful Restart ■ 121

JUNOS 8.5 High Availability Configuration Guide

}
lo0 {
unit 0 {
family inet {
address 10.245.14.180/32 {
primary;
}
address 10.96.210.1/32;
address 10.96.111.1/32;
address 10.96.212.1/32;
address 10.96.213.1/32;
address 10.96.216.1/32;
}
family iso {
address 47.0005.80ff.f800.0000.0108.0001.0102.4501.4180.00;
}
}
}
}
routing-options {
graceful-restart;
autonomous-system 65200;
}
protocols {
bgp {
group CE-PE-INET {
type external;
export BGP_INET_LB_DIRECT;
neighbor 10.96.203.1 {
local-address 10.96.203.2;
family inet {
unicast;
}
peer-as 65203;
}
}
}
isis {
export ISIS_L2VPN_LB_DIRECT;
interface t1-0/0/3.612;
}
ospf {
export OSPF_LB_DIRECT;
area 0.0.0.0 {
interface t1-0/0/3.201;
}
}
rip {
group RIP {
export RIP_LB_DIRECT;
neighbor t1-0/0/3.202;
}
}
}
policy-options {
policy-statement OSPF_LB_DIRECT {

122 ■ Example: Configuring Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

term direct {
from {
protocol direct;
route-filter 10.96.201.0/30 exact;
route-filter 10.96.211.1/32 exact;
}
then accept;
}
term final {
then reject;
}
}
policy-statement RIP_LB_DIRECT {
term direct {
from {
protocol direct;
route-filter 10.96.202.0/30 exact;
route-filter 10.96.212.1/32 exact;
}
then accept;
}
term final {
then reject;
}
}
policy-statement BGP_INET_LB_DIRECT {
term direct {
from {
protocol direct;
route-filter 10.96.203.0/30 exact;
route-filter 10.96.213.1/32 exact;
}
then accept;
}
term final {
then reject;
}
}
policy-statement ISIS_L2VPN_LB_DIRECT {
term direct {
from {
protocol direct;
route-filter 10.96.216.1/32 exact;
}
then accept;
}
term final {
then reject;
}
}
}

Router PE1 Status The following example displays neighbor relationships on Router PE1 before a restart
Before a Restart happens:

Example: Configuring Graceful Restart ■ 123

JUNOS 8.5 High Availability Configuration Guide

user@PE1> show bgp neighbor

Peer: 10.96.103.2+3785 AS 65100 Local: 10.96.103.1+179 AS 65103
Type: External State: Established Flags: <>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ BGP-INET-import ]
Options: <Preference LocalAddress HoldTime GracefulRestart AddressFamily PeerAS
Refresh>
Address families configured: inet-unicast
Local Address: 10.96.103.1 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 10.96.110.1 Local ID: 10.96.103.1 Active Holdtime: 90
Keepalive Interval: 30
Local Interface: t3-0/0/0.103
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI peer can save forwarding state: inet-unicast
NLRI that peer saved forwarding for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Table BGP-INET.inet.0 Bit: 30001
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Suppressed due to damping: 0
Last traffic (seconds): Received 8 Sent 3 Checked 3
Input messages: Total 15 Updates 0 Refreshes 0 Octets 321
Output messages: Total 18 Updates 2 Refreshes 0 Octets 450
Output Queue[2]: 0

Peer: 10.245.14.182+4701 AS 69 Local: 10.245.14.176+179 AS 69

Type: Internal State: Established Flags: <>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress HoldTime GracefulRestart AddressFamily
Rib-group Refresh>
Address families configured: inet-vpn-unicast l2vpn
Local Address: 10.245.14.176 Holdtime: 90 Preference: 170
Number of flaps: 1
Peer ID: 10.245.14.182 Local ID: 10.245.14.176 Active Holdtime: 90
Keepalive Interval: 30
NLRI for restart configured on peer: inet-vpn-unicast l2vpn
NLRI advertised by peer: inet-vpn-unicast l2vpn
NLRI for this session: inet-vpn-unicast l2vpn
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-vpn-unicast l2vpn
NLRI peer can save forwarding state: inet-vpn-unicast l2vpn
NLRI that peer saved forwarding for: inet-vpn-unicast l2vpn
NLRI that restart is negotiated for: inet-vpn-unicast l2vpn

124 ■ Example: Configuring Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

NLRI of all end-of-rib markers sent: inet-vpn-unicast l2vpn

Table bgp.l3vpn.0 Bit: 10000
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Suppressed due to damping: 0
Table bgp.l2vpn.0 Bit: 20000
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Suppressed due to damping: 0
Table BGP-INET.inet.0 Bit: 30000
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Suppressed due to damping: 0
Table OSPF.inet.0 Bit: 60000
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Suppressed due to damping: 0
Table RIP.inet.0 Bit: 70000
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Suppressed due to damping: 0
Table STATIC.inet.0 Bit: 80000
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Suppressed due to damping: 0
Table L2VPN.l2vpn.0 Bit: 90000
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Suppressed due to damping: 0
Last traffic (seconds): Received 28 Sent 28 Checked 28
Input messages: Total 2 Updates 0 Refreshes 0 Octets 86
Output messages: Total 13 Updates 10 Refreshes 0 Octets 1073
Output Queue[0]: 0
Output Queue[1]: 0
Output Queue[2]: 0
Output Queue[3]: 0
Output Queue[4]: 0
Output Queue[5]: 0
Output Queue[6]: 0
Output Queue[7]: 0

Example: Configuring Graceful Restart ■ 125

JUNOS 8.5 High Availability Configuration Guide

Output Queue[8]: 0

user@PE1> show route instance detail

master:
Router ID: 10.245.14.176
Type: forwarding State: Active
Restart State: Complete Path selection timeout: 300
Tables:
inet.0 : 17 routes (15 active, 0 holddown, 1 hidden)
Restart Complete
inet.3 : 2 routes (2 active, 0 holddown, 0 hidden)
Restart Complete
iso.0 : 1 routes (1 active, 0 holddown, 0 hidden)
Restart Complete
mpls.0 : 19 routes (19 active, 0 holddown, 0 hidden)
Restart Complete
bgp.l3vpn.0 : 10 routes (10 active, 0 holddown, 0 hidden)
Restart Complete
inet6.0 : 2 routes (2 active, 0 holddown, 0 hidden)
Restart Complete
bgp.l2vpn.0 : 1 routes (1 active, 0 holddown, 0 hidden)
Restart Complete
BGP-INET:
Router ID: 10.96.103.1
Type: vrf State: Active
Restart State: Complete Path selection timeout: 300
Interfaces:
t3-0/0/0.103
Route-distinguisher: 10.245.14.176:103
Vrf-import: [ BGP-INET-import ]
Vrf-export: [ BGP-INET-export ]
Tables:
BGP-INET.inet.0 : 4 routes (4 active, 0 holddown, 0 hidden)
Restart Complete
L2VPN:
Router ID: 0.0.0.0
Type: l2vpn State: Active
Restart State: Complete Path selection timeout: 300
Interfaces:
t3-0/0/0.512
Route-distinguisher: 10.245.14.176:512
Vrf-import: [ L2VPN-import ]
Vrf-export: [ L2VPN-export ]
Tables:
L2VPN.l2vpn.0 : 2 routes (2 active, 0 holddown, 0 hidden)
Restart Complete
OSPF:
Router ID: 10.96.101.1
Type: vrf State: Active
Restart State: Complete Path selection timeout: 300
Interfaces:
t3-0/0/0.101
Route-distinguisher: 10.245.14.176:101
Vrf-import: [ OSPF-import ]
Vrf-export: [ OSPF-export ]
Tables:
OSPF.inet.0 : 8 routes (7 active, 0 holddown, 0 hidden)
Restart Complete
RIP:
Router ID: 10.96.102.1
Type: vrf State: Active

126 ■ Example: Configuring Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

Restart State: Complete Path selection timeout: 300

Interfaces:
t3-0/0/0.102
Route-distinguisher: 10.245.14.176:102
Vrf-import: [ RIP-import ]
Vrf-export: [ RIP-export ]
Tables:
RIP.inet.0 : 6 routes (6 active, 0 holddown, 0 hidden)
Restart Complete
STATIC:
Router ID: 10.96.100.1
Type: vrf State: Active
Restart State: Complete Path selection timeout: 300
Interfaces:
t3-0/0/0.100
Route-distinguisher: 10.245.14.176:100
Vrf-import: [ STATIC-import ]
Vrf-export: [ STATIC-export ]
Tables:
STATIC.inet.0 : 4 routes (4 active, 0 holddown, 0 hidden)
Restart Complete
__juniper_private1__:
Router ID: 0.0.0.0
Type: forwarding State: Active

user@PE1> show route protocol l2vpn

inet.0: 16 destinations, 17 routes (15 active, 0 holddown, 1 hidden)
Restart Complete
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
Restart Complete
BGP-INET.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
Restart Complete
OSPF.inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
Restart Complete
RIP.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
Restart Complete
STATIC.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
Restart Complete
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Restart Complete
mpls.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
800003 *[L2VPN/7] 00:06:00
> via t3-0/0/0.512, Pop Offset: 4
t3-0/0/0.512 *[L2VPN/7] 00:06:00
> via t1-0/1/0.0, Push 800003, Push 100004(top) Offset: -4
bgp.l3vpn.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
Restart Complete
inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
Restart Complete
L2VPN.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
10.245.14.176:512:512:611/96
*[L2VPN/7] 00:06:01
Discard

bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

Restart Complete

Example: Configuring Graceful Restart ■ 127

JUNOS 8.5 High Availability Configuration Guide

Router PE1 Status Before you can verify that graceful restart is working, you must simulate a router
During a Restart restart. To cause the routing process to refresh and simulate a restart, use the restart
routing operational mode command:

user@PE1> restart routing

Routing protocol daemon started, pid 3558

The following sample output is captured during the router restart:

user@PE1> show bgp neighbor

Peer: 10.96.103.2 AS 65100 Local: 10.96.103.1 AS 65103
Type: External State: Active Flags: <ImportEval>
Last State: Idle Last Event: Start
Last Error: None
Export: [ BGP-INET-import ]
Options: <Preference LocalAddress HoldTime GracefulRestart AddressFamily PeerAS
Refresh>
Address families configured: inet-unicast
Local Address: 10.96.103.1 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer: 10.245.14.182+179 AS 69 Local: 10.245.14.176+2131 AS 69
Type: Internal State: Established Flags: <ImportEval>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress HoldTime GracefulRestart AddressFamily
Rib-group Refresh>
Address families configured: inet-vpn-unicast l2vpn
Local Address: 10.245.14.176 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 10.245.14.182 Local ID: 10.245.14.176 Active Holdtime: 90
Keepalive Interval: 30
NLRI for restart configured on peer: inet-vpn-unicast l2vpn
NLRI advertised by peer: inet-vpn-unicast l2vpn
NLRI for this session: inet-vpn-unicast l2vpn
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-vpn-unicast l2vpn
NLRI peer can save forwarding state: inet-vpn-unicast l2vpn
NLRI that peer saved forwarding for: inet-vpn-unicast l2vpn
NLRI that restart is negotiated for: inet-vpn-unicast l2vpn
NLRI of received end-of-rib markers: inet-vpn-unicast l2vpn
Table bgp.l3vpn.0 Bit: 10000
RIB State: BGP restart in progress
RIB State: VPN restart in progress
Send state: in sync
Active prefixes: 10
Received prefixes: 10
Suppressed due to damping: 0
Table bgp.l2vpn.0 Bit: 20000
RIB State: BGP restart in progress
RIB State: VPN restart in progress
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Suppressed due to damping: 0
Table BGP-INET.inet.0 Bit: 30000
RIB State: BGP restart in progress

128 ■ Example: Configuring Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

RIB State: VPN restart in progress

Send state: in sync
Active prefixes: 2
Received prefixes: 2
Suppressed due to damping: 0
Table OSPF.inet.0 Bit: 60000
RIB State: BGP restart is complete
RIB State: VPN restart in progress
Send state: in sync
Active prefixes: 2
Received prefixes: 2
Suppressed due to damping: 0
Table RIP.inet.0 Bit: 70000
RIB State: BGP restart is complete
RIB State: VPN restart in progress
Send state: in sync
Active prefixes: 2
Received prefixes: 2
Suppressed due to damping: 0
Table STATIC.inet.0 Bit: 80000
RIB State: BGP restart is complete
RIB State: VPN restart in progress
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Suppressed due to damping: 0
Table L2VPN.l2vpn.0 Bit: 90000
RIB State: BGP restart is complete
RIB State: VPN restart in progress
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Suppressed due to damping: 0
Last traffic (seconds): Received 0 Sent 0 Checked 0
Input messages: Total 14 Updates 13 Refreshes 0 Octets 1053
Output messages: Total 3 Updates 0 Refreshes 0 Octets 105
Output Queue[0]: 0
Output Queue[1]: 0
Output Queue[2]: 0
Output Queue[3]: 0
Output Queue[4]: 0
Output Queue[5]: 0
Output Queue[6]: 0
Output Queue[7]: 0
Output Queue[8]: 0

user@PE1> show route instance detail

master:
Router ID: 10.245.14.176
Type: forwarding State: Active
Restart State: Pending Path selection timeout: 300
Tables:
inet.0 : 17 routes (15 active, 1 holddown, 1 hidden)
Restart Pending: OSPF LDP
inet.3 : 2 routes (2 active, 0 holddown, 0 hidden)
Restart Pending: OSPF LDP
iso.0 : 1 routes (1 active, 0 holddown, 0 hidden)
Restart Complete
mpls.0 : 23 routes (23 active, 0 holddown, 0 hidden)
Restart Pending: LDP VPN
bgp.l3vpn.0 : 10 routes (10 active, 0 holddown, 0 hidden)

Example: Configuring Graceful Restart ■ 129

JUNOS 8.5 High Availability Configuration Guide

Restart Pending: BGP VPN

inet6.0 : 2 routes (2 active, 0 holddown, 0 hidden)
Restart Complete
bgp.l2vpn.0 : 1 routes (1 active, 0 holddown, 0 hidden)
Restart Pending: BGP VPN
BGP-INET:
Router ID: 10.96.103.1
Type: vrf State: Active
Restart State: Pending Path selection timeout: 300
Interfaces:
t3-0/0/0.103
Route-distinguisher: 10.245.14.176:103
Vrf-import: [ BGP-INET-import ]
Vrf-export: [ BGP-INET-export ]
Tables:
BGP-INET.inet.0 : 6 routes (5 active, 0 holddown, 0 hidden)
Restart Pending: VPN
L2VPN:
Router ID: 0.0.0.0
Type: l2vpn State: Active
Restart State: Pending Path selection timeout: 300
Interfaces:
t3-0/0/0.512
Route-distinguisher: 10.245.14.176:512
Vrf-import: [ L2VPN-import ]
Vrf-export: [ L2VPN-export ]
Tables:
L2VPN.l2vpn.0 : 2 routes (2 active, 0 holddown, 0 hidden)
Restart Pending: VPN L2VPN
OSPF:
Router ID: 10.96.101.1
Type: vrf State: Active
Restart State: Pending Path selection timeout: 300
Interfaces:
t3-0/0/0.101
Route-distinguisher: 10.245.14.176:101
Vrf-import: [ OSPF-import ]
Vrf-export: [ OSPF-export ]
Tables:
OSPF.inet.0 : 8 routes (7 active, 1 holddown, 0 hidden)
Restart Pending: OSPF VPN
RIP:
Router ID: 10.96.102.1
Type: vrf State: Active
Restart State: Pending Path selection timeout: 300
Interfaces:
t3-0/0/0.102
Route-distinguisher: 10.245.14.176:102
Vrf-import: [ RIP-import ]
Vrf-export: [ RIP-export ]
Tables:
RIP.inet.0 : 8 routes (6 active, 2 holddown, 0 hidden)
Restart Pending: RIP VPN
STATIC:
Router ID: 10.96.100.1
Type: vrf State: Active
Restart State: Pending Path selection timeout: 300
Interfaces:
t3-0/0/0.100
Route-distinguisher: 10.245.14.176:100
Vrf-import: [ STATIC-import ]

130 ■ Example: Configuring Graceful Restart

 Chapter 15: Graceful Restart Configuration Guidelines

Vrf-export: [ STATIC-export ]
Tables:
STATIC.inet.0 : 4 routes (4 active, 0 holddown, 0 hidden)
Restart Pending: VPN
__juniper_private1__:
Router ID: 0.0.0.0
Type: forwarding State: Active

user@PE1> show route instance summary

Instance Type Primary rib Active/holddown/hidden
master forwarding
inet.0 15/0/1
iso.0 1/0/0
mpls.0 35/0/0
l3vpn.0 0/0/0
inet6.0 2/0/0
l2vpn.0 0/0/0
l2circuit.0 0/0/0
BGP-INET vrf
BGP-INET.inet.0 5/0/0
BGP-INET.iso.0 0/0/0
BGP-INET.inet6.0 0/0/0
L2VPN l2vpn
L2VPN.inet.0 0/0/0
L2VPN.iso.0 0/0/0
L2VPN.inet6.0 0/0/0
L2VPN.l2vpn.0 2/0/0
OSPF vrf
OSPF.inet.0 7/0/0
OSPF.iso.0 0/0/0
OSPF.inet6.0 0/0/0
RIP vrf
RIP.inet.0 6/0/0
RIP.iso.0 0/0/0
RIP.inet6.0 0/0/0
STATIC vrf
STATIC.inet.0 4/0/0
STATIC.iso.0 0/0/0
STATIC.inet6.0 0/0/0
__juniper_private1__ forwarding
__juniper_priva.inet.0 0/0/0
__juniper_privat.iso.0 0/0/0
__juniper_priv.inet6.0 0/0/0

user@PE1> show route protocol l2vpn

inet.0: 16 destinations, 17 routes (15 active, 1 holddown, 1 hidden)

Restart Pending: OSPF LDP

inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

Restart Pending: OSPF LDP

BGP-INET.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)

Restart Pending: VPN

OSPF.inet.0: 7 destinations, 8 routes (7 active, 1 holddown, 0 hidden)

Restart Pending: OSPF VPN

RIP.inet.0: 6 destinations, 8 routes (6 active, 2 holddown, 0 hidden)

Restart Pending: RIP VPN

Example: Configuring Graceful Restart ■ 131

JUNOS 8.5 High Availability Configuration Guide

STATIC.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

Restart Pending: VPN

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

Restart Complete

mpls.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)

Restart Pending: LDP VPN
+ = Active Route, - = Last Active, * = Both

800001 *[L2VPN/7] 00:00:13

> via t3-0/0/0.512, Pop Offset: 4
t3-0/0/0.512 *[L2VPN/7] 00:00:13
> via t1-0/1/0.0, Push 800003, Push 100004(top) Offset: -4

bgp.l3vpn.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)

Restart Pending: BGP VPN

inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

Restart Complete

L2VPN.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

Restart Pending: VPN L2VPN
+ = Active Route, - = Last Active, * = Both

10.245.14.176:512:512:611/96
*[L2VPN/7] 00:00:13
Discard
bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Restart Pending: BGP VPN

132 ■ Example: Configuring Graceful Restart

Chapter 16
Summary of Graceful Restart
Configuration Statements

This chapter provides a reference for each of the graceful restart configuration
statements. The statements are organized alphabetically.

disable

Syntax disable;

Hierarchy Level [edit logical-routers logical-router-name protocols (bgp | isis | ldp | ospf | ospf3 | pim | rip
| ripng | rsvp) graceful-restart],
[edit logical-routers logical-router-name routing-instances routing-instance-name protocols
(bgp | ldp | ospf | ospf3 | pim) graceful-restart],
[edit protocols (bgp | esis | isis | ospf | ospf3 | ldp | pim | rip | ripng | rsvp) graceful-restart],
[edit protocols bgp group group-name graceful-restart],
[edit protocols bgp group group-name neighbor ip-address graceful-restart],
[edit routing-instances routing-instance-name protocols (bgp | ldp | ospf | ospf3 | pim)
graceful-restart],
[edit routing-instances routing-instance-name routing-options graceful-restart],
[edit routing-options graceful-restart]

Release Information Statement introduced before JUNOS Release 7.4.

Description Disable graceful restart.

Usage Guidelines See “Graceful Restart Configuration Guidelines” on page 95.

Required Privilege Level routing—To view this statement in the configuration.

routing-control—To add this statement to the configuration.

disable ■ 133
JUNOS 8.5 High Availability Configuration Guide

graceful-restart

Syntax graceful-restart {
disable;
helper-disable;
maximum-helper-recovery-time seconds;
maximum-helper-restart-time seconds;
notify-duration seconds;
recovery-time seconds;
restart-duration seconds;
stale-routes-time seconds;
}

Hierarchy Level [edit logical-routers logical-router-name protocols (bgp | isis | ldp | ospf | ospf3 | pim | rip
| ripng | rsvp)],
[edit logical-routers logical-router-name routing-instances routing-instance-name protocols
(bgp | ldp | ospf | ospf3 | pim)],
[edit logical-routers logical-router-name routing-instances routing-instance-name
routing-options],
[edit protocols (bgp | esis | isis | ospf | ospf3 | ldp | pim | rip | ripng | rsvp)],
[edit protocols bgp group group-name],
[edit protocols bgp group group-name neighbor ip-address],
[edit routing-instances routing-instance-name protocols (bgp | ldp | ospf | ospf3 | pim)],
[edit routing-options]

Release Information Statement introduced before JUNOS Release 7.4.

Description Enable graceful restart.

Options The statements are explained separately.

Usage Guidelines See “Graceful Restart Configuration Guidelines” on page 95.

Required Privilege Level routing—To view this statement in the configuration.

routing-control—To add this statement to the configuration.

134 ■ graceful-restart
 Chapter 16: Summary of Graceful Restart Configuration Statements

helper-disable

Syntax helper-disable;

Hierarchy Level [edit logical-routers logical-router-name protocols (isis | ldp | ospf | ospf3 | rsvp)
graceful-restart],
[edit logical-routers logical-router-name routing-instances routing-instance-name protocols
(ldp | ospf | ospf3)] graceful-restart],
[edit protocols (isis | ldp | ospf | ospf3 | rsvp) graceful-restart],
[edit routing-instances routing-instance-name protocols (ldp | ospf | ospf3) graceful-restart]

Release Information Statement introduced before JUNOS Release 7.4.

Description Disable helper mode for graceful restart. When helper mode is disabled, a router
cannot help a neighboring router that is attempting to restart.

Default Helper mode is enabled by default for these supported protocols: Intermediate
System-to-Intermediate System, Label Distribution Protocol, OSPF/OSPFv3, and
RSVP.

Usage Guidelines See “Graceful Restart Configuration Guidelines” on page 95.

Required Privilege Level routing—To view this statement in the configuration.

routing-control—To add this statement to the configuration.

maximum-helper-recovery-time

Syntax maximum-helper-recovery-time seconds;

Hierarchy Level [edit protocols rsvp graceful-restart],

[edit logical-routers logical-router-name protocols rsvp graceful-restart]

Release Information Statement introduced before JUNOS Release 7.4.

Description Specify the amount of time the router retains the state of its Resource Reservation
Protocol (RSVP) neighbors while they undergo a graceful restart.

Options seconds—Amount of time, in seconds, the router retains the state of its Resource
Reservation Protocol (RSVP) neighbors while they undergo a graceful restart.
Range: 1 through 3600 seconds
Default: 180 seconds
Usage Guidelines See “Configuring Graceful Restart Options for RSVP, CCC, and TCC” on page 101.

Required Privilege Level routing—To view this statement in the configuration.

routing-control—To add this statement to the configuration.
Related Topics maximum-helper-restart-time

helper-disable ■ 135
JUNOS 8.5 High Availability Configuration Guide

maximum-helper-restart-time

Syntax maximum-helper-restart-time seconds;

Hierarchy Level [edit protocols rsvp graceful-restart],

[edit logical-routers logical-router-name protocols rsvp graceful-restart]

Release Information Statement introduced in JUNOS Release 8.3.

Description Specify the amount of time the router waits after it discovers that a neighboring
router has gone down before it declares the neighbor down. This value is applied to
all RSVP neighbor routers and should be based on the time that the slowest RSVP
neighbor requires for restart.

Options seconds—Number of seconds the router waits after it discovers that a neighboring
router has gone down before it declares the neighbor down.
Range: 1 through 1800 seconds
Default: 180 seconds
Usage Guidelines See “Configuring Graceful Restart Options for RSVP, CCC, and TCC” on page 101.

Required Privilege Level view-level—To view this statement in the configuration.

control-level—To add this statement to the configuration.
Related Topics maximum-helper-recovery-time

maximum-recovery-time

Syntax maximum-recovery-time seconds;

Hierarchy Level [edit protocols ldp graceful-restart],

[edit logical-routers logical-router-name protocols ldp graceful-restart],
[edit routing-instances instance-name protocols ldp graceful-restart]

Release Information Statement introduced in JUNOS Release 8.3.

Description Specify the amount of time the router retains the state of its Label Distribution Protocol
(LDP) neighbors while they undergo a graceful restart.

Options seconds—Time, in seconds, the router retains the state of its LDP neighbors while
they undergo a graceful restart.
Range: 140 through 1900 seconds
Default: 140 seconds
Usage Guidelines See “Configuring Graceful Restart Options for LDP” on page 102.

Required Privilege Level view-level—To view this statement in the configuration.

control-level—To add this statement to the configuration.
Related Topics no-strict-lsa-checking
recovery-time

136 ■ maximum-helper-restart-time
 Chapter 16: Summary of Graceful Restart Configuration Statements

notify-duration

Syntax notify-duration seconds;

Hierarchy Level [edit protocols (ospf | ospf3) graceful-restart],

[edit logical-routers logical-router-name protocols (ospf | ospf3) graceful-restart],
[edit logical-routers logical-router-name routing-instances instance-name protocols (ospf
| ospf3) graceful-restart],
[edit routing-instances instance-name protocols (ospf | ospf3) graceful-restart]

Release Information Statement introduced in JUNOS Release 8.3.

Description Specify the length of time the router notifies helper OSPF routers that it has completed
graceful restart.

Options seconds—Amount of time in seconds, the router notifies helper OSPF routers that it
has completed graceful restart.
Range: 1 through 3600 seconds
Default: 180 seconds
Usage Guidelines See “Configuring Graceful Restart Options for OSPF and OSPFv3” on page 98.

Required Privilege Level view-level—To view this statement in the configuration.

control-level—To add this statement to the configuration.
Related Topics restart-duration

no-strict-lsa-checking

Syntax no-strict-lsa-checking;

Hierarchy Level [edit protocols (ospf | ospf3) graceful-restart]

Release Information Statement introduced in JUNOS Release 8.5.

Description Disable strict OSPF link-state advertisement (LSA) checking to prevent the termination
of graceful restart by a helping router.

Default By default, LSA checking is enabled.

Usage Guidelines See “Configuring Graceful Restart Options for OSPF and OSPFv3” on page 98

Required Privilege Level view-level—To view this statement in the configuration.

control-level—To add this statement to the configuration.
Related Topics maximum-recovery-time
recovery-time

notify-duration ■ 137
JUNOS 8.5 High Availability Configuration Guide

recovery-time

Syntax recovery-time seconds;

Hierarchy Level [edit logical-routers logical-router-name protocols ldp graceful-restart],

[edit logical-routers logical-router-name routing-instances routing-instance-name protocols
ldp graceful-restart],
[edit protocols ldp graceful-restart],
[edit routing-instances routing-instance-name protocols ldp graceful-restart]

Release Information Statement introduced before JUNOS Release 7.4.

Description Specify the amount of time a router waits for Label Distribution Protocol (LDP)
neighbors to assist it with a graceful restart.

Options seconds—Time, in seconds, the router waits for LDP to restart gracefully.
Range: 120 through 1800 seconds
Default: 140 seconds
Usage Guidelines See “Configuring Graceful Restart Options for LDP” on page 102.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.
Related Topics maximum-recovery-time
no-strict-lsa-checking

138 ■ recovery-time
 Chapter 16: Summary of Graceful Restart Configuration Statements

restart-duration

Syntax restart-duration seconds;

Hierarchy Level [edit logical-routers logical-router-name protocols (isis | ospf | ospf3 | pim) graceful-restart],
[edit logical-routers logical-router-name routing-instances routing-instance-name protocols
(ospf | ospf3 | pim) graceful-restart],
[edit protocols (esis | isis | ospf | ospf3 | pim) graceful-restart],
[edit routing-instances routing-instance-name protocols (ospf | ospf3 | pim)
graceful-restart],
[edit routing-options graceful-restart]

Release Information Statement introduced before JUNOS Release 7.4.

Description Configure the duration of the graceful restart period globally. Additionally, you can
individually configure the duration of the graceful restart period for the End
System-to-Intermediate System (ES-IS), Intermediate System-to-Intermediate System
(IS-IS), Open Shortest Path First (OSPF), and OSPFv3 protocols and for Protocol
Independent Multicast (PIM) sparse mode.

Options seconds—Time, in seconds, for the graceful restart period.

Default: 180

When set globally (at the [edit routing-options graceful-restart] hierarchy level), the
range of values is:
Range: 120 through 900

When set at any other hierarchy level for ES-IS, IS-IS, or PIM, the range of values is:
Range: 30 through 300

When set at any other hierarchy level for OSPF/OSPFv3, the range of values is:
Range: 1 through 3600
Usage Guidelines See “Graceful Restart Configuration Guidelines” on page 95.

Required Privilege Level routing—To view this statement in the configuration.

routing-control—To add this statement to the configuration.

restart-duration ■ 139
JUNOS 8.5 High Availability Configuration Guide

restart-time

Syntax restart-time seconds;

Hierarchy Level [edit protocols (bgp | rip | ripng) graceful-restart],

[edit logical-routers logical-router-name protocols (bgp | rip | ripng) graceful-restart],
[edit logical-routers logical-router-name routing-instances routing-instance-name protocols
bgp graceful-restart],
[edit routing-instances routing-instance-name protocols bgp graceful-restart]

Release Information Statement introduced in JUNOS Release 8.3.

Description Configure the duration of the Border Gateway Protocol (BGP), Routing Information
Protocol (RIP), or next-generation RIP (RIPng) graceful restart period.

Options seconds—Amount of time, in seconds, for the graceful restart period.

Range: 1 through 600
Default: 300
Usage Guidelines See “Configuring Graceful Restart Options for BGP” on page 96 and “Configuring
Graceful Restart Options for RIP and RIPng” on page 99.

Required Privilege Level view-level—To view this statement in the configuration.

control-level—To add this statement to the configuration.
Related Topics stale-routes-time

140 ■ restart-time
 Chapter 16: Summary of Graceful Restart Configuration Statements

stale-routes-time

Syntax stale-routes-time seconds;

Hierarchy Level [edit logical-routers logical-routing-name protocols bgp graceful-restart],

[edit logical-routers logical-routing-name routing-instances routing-instance-name protocols
bgp graceful-restart],
[edit protocols bgp graceful-restart],
[edit routing-instances routing-instance-name protocols bgp graceful-restart]

Release Information Statement introduced in JUNOS Release 8.3.

Description Configure amount of time the router waits to receive restart messages from restarting
Border Gateway Protocol (BGP) neighbors before declaring them down.

Options seconds—Time, in seconds, the router waits to receive messages from restarting
neighbors before declaring them down.
Range: 1 through 600
Default: 300
Usage Guidelines See “Configuring Graceful Restart Options for BGP” on page 96.

Required Privilege Level view-level—To view this statement in the configuration.

control-level—To add this statement to the configuration.
Related Topics restart-time

stale-routes-time ■ 141
JUNOS 8.5 High Availability Configuration Guide

traceoptions

Syntax traceoptions {
file name <replace> <size size> <files number> <no-stamp> <(world-readable |
no-world-readable)>;
flag flag <flag-modifier> <disable>;
}

Hierarchy Level [edit protocols isis]

[edit protocols (ospf | ospf3)]

Release Information Statement introduced before JUNOS Release 7.4.

graceful-restart flag for IS-IS and OSPF/OSPFv3 introduced in JUNOS Release 8.4.
Description Define tracing operations that graceful restart functionality in the router.

To specify more than one tracing operation, include multiple flag statements.

Default If you do not include this statement, no global tracing operations are performed.

Options disable—(Optional) Disable the tracing operation. You can use this option to disable
a single operation when you have defined a broad group of tracing operations,
such as all.

file name—Name of the file to receive the output of the tracing operation. Enclose
the name within quotation marks. All files are placed in the directory /var/log.
We recommend that you place global routing protocol tracing output in the file
routing-log.

files number—(Optional) Maximum number of trace files. When a trace file named
trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1,
and so on, until the maximum number of trace files is reached. Then the oldest
trace file is overwritten.
Range: 2 through 1000 files
Default: 2 files

If you specify a maximum number of files, you also must specify a maximum file
size with the size option.

flag flag—Tracing operation to perform. To specify more than one tracing operation,
include multiple flag statements. The nonstop routing tracing option is:
■ graceful-restart—Tracing operations for nonstop routing

no-stamp—(Optional) Do not place timestamp information at the beginning of each

line in the trace file.
Default: If you omit this option, timestamp information is placed at the beginning
of each line of the tracing output.

replace—(Optional) Replace an existing trace file if there is one.

142 ■ traceoptions
 Chapter 16: Summary of Graceful Restart Configuration Statements

Default: If you do not include this option, tracing output is appended to an

existing trace file.

size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes
(MB), or gigabytes (GB). When a trace file named trace-file reaches this size, it is
renamed trace-file.0. When the trace-file again reaches its maximum size,
trace-file.0 is renamed trace-file.1 and trace-file is renamed trace-file.0. This
renaming scheme continues until the maximum number of trace files is reached.
Then the oldest trace file is overwritten.
Syntax: xk to specify KB, xm to specify MB, or xg to specify GB
Range: 10 KB through the maximum file size supported on your system
Default: 128 KB

If you specify a maximum file size, you also must specify a maximum number of
trace files with the files option.

Usage Guidelines See “Tracking Graceful Restart Events” on page 100.

Required Privilege Level routing and trace—To view this statement in the configuration.
routing-control and trace-control—To add this statement to the configuration.

traceoptions ■ 143
JUNOS 8.5 High Availability Configuration Guide

144 ■ traceoptions
Part 7
Virtual Router Redundancy Protocol
■ VRRP Overview on page 147
■ VRRP Configuration Guidelines on page 149
■ Summary of VRRP Configuration Statements on page 163

Virtual Router Redundancy Protocol ■ 145

JUNOS 8.5 High Availability Configuration Guide

146 ■ Virtual Router Redundancy Protocol

Chapter 17
VRRP Overview

For Ethernet, Fast Ethernet, Gigabit Ethernet, 10-Gigabit Ethernet, and logical
interfaces, you can configure the Virtual Router Redundancy Protocol (VRRP) or VRRP
for IPv6. VRRP enables hosts on a LAN to make use of redundant routing platforms
on that LAN without requiring more than the static configuration of a single default
route on the hosts. The VRRP routing platforms share the IP address corresponding
to the default route configured on the hosts. At any time, one of the VRRP routing
platforms is the master (active) and the others are backups. If the master fails, one
of the backup routers becomes the new master router, providing a virtual default
routing platform and enabling traffic on the LAN to be routed without relying on a
single routing platform. Using VRRP, a backup router can take over a failed default
router within few seconds. This is done with minimum VRRP traffic and without any
interaction with the hosts.

Routers running VRRP dynamically elect master and backup routers. You can also
force assignment of master and backup routers using priorities from 1 through 255,
with 255 being the highest priority. In VRRP operation, the default master router
sends advertisements to backup routers at regular intervals. The default interval is
1 second. If a backup router does not receive an advertisement for a set period, the
backup router with the next highest priority takes over as master and begins
forwarding packets.

VRRP for IPv6 provides a much faster switchover to an alternate default router than
IPv6 Neighbor Discovery (ND) procedures. Typical deployments use only one backup
router.

Figure 8 on page 148 illustrates a basic VRRP topology. In this example, Routers A,
B, and C are running VRRP and together they make up a virtual router. The IP address
of this virtual router is 10.10.0.1 (the same address as the physical interface of Router
A).

■ 147
JUNOS 8.5 High Availability Configuration Guide

Figure 8: Basic VRRP

Because the virtual router uses the IP address of the physical interface of Router A,
Router A is the master VRRP router, while routers B and C function as backup VRRP
routers. Clients 1 through 3 are configured with the default gateway IP address of
10.10.0.1. As the master router, Router A forwards packets sent to its IP address. If
the master virtual router fails, the router configured with the higher priority becomes
the master virtual router and provides uninterrupted service for the LAN hosts. When
Router A recovers, it becomes the master virtual router again.

VRRP is defined in RFC 3768, Virtual Router Redundancy Protocol. VRRP for IPv6 is
defined in Virtual Router Redundancy Protocol for IPv6, draft-ietf-vrrp-ipv6-spec-08.txt.
See also Definitions of Managed Objects for the VRRP over IPv4 and IPv6,
draft-ietf-vrrp-unified-mib-06.txt.

148 ■
Chapter 18
VRRP Configuration Guidelines

This chapter contains the following topics:

■ VRRP Configuration Hierarchy on page 149
■ VRRP for IPv6 Configuration Hierarchy on page 150
■ VRRP Trace and Startup Configuration Statements on page 150
■ Configuring Basic VRRP Support on page 151
■ Configuring VRRP Authentication (IPv4 Only) on page 153
■ Configuring the Advertisement Interval for the VRRP Master Router on page 153
■ Configuring a Backup Router to Preempt the Master Router on page 155
■ Configuring an Interface to Accept Packets Destined for the Virtual IP
Address on page 155
■ Configuring a Logical Interface to Be Tracked on page 156
■ Tracing VRRP Operations on page 157
■ Configuring the Silent Period on page 158
■ Configuring Passive ARP Learning for Backup VRRP Routers on page 158
■ Example: Configuring VRRP on page 159
■ Example: Configuring VRRP for IPv6 on page 161

VRRP Configuration Hierarchy

To configure VRRP, include the following statements at the [edit interfaces

interface-name unit logical-unit-number family inet address address] or [edit logical-router
logical-router-name interfaces interface-name unit logical-unit-number family inet address
address] hierarchy level:

vrrp-group group-number {
(accept-data | no-accept-data);
advertise-interval seconds;
authentication-key key;
authentication-type authentication;
fast-interval milliseconds;
(preempt | no-preempt) {

VRRP Configuration Hierarchy ■ 149

JUNOS 8.5 High Availability Configuration Guide

hold-time seconds;
}
priority number;
track {
priority-hold-time ;
interface interface-name {
priority-cost priority;
bandwidth-threshold bits-per-second {
priority-cost ;
}
}
}
virtual-address [ addresses ];
}

VRRP for IPv6 Configuration Hierarchy

To configure VRRP for IPv6, include the following statements at the [edit interfaces
interface-name unit logical-unit-number family inet6 address address] or [edit logical-router
logical-router-name interfaces interface-name unit logical-unit-number family inet6 address
address] hierarchy level:

vrrp-inet6-group group-number {
(accept-data | no-accept-data);
fast-interval milliseconds;
inet6-advertise-interval seconds;
(preempt | no-preempt) {
hold-time seconds;
}
priority number;
track {
priority-hold-time ;
interface interface-name {
priority-cost priority;
bandwidth-threshold bits-per-second {
priority-cost ;
}
}
}
virtual-inet6-address [ addresses ];
virtual-link-local-address
}

VRRP Trace and Startup Configuration Statements

To trace VRRP operations, include the traceoptions statement at the [edit protocols
vrrp] hierarchy level:

[edit protocols vrrp traceoptions]

file {
filename filename;
files number;
microsecond-stamp

150 ■ VRRP for IPv6 Configuration Hierarchy

 Chapter 18: VRRP Configuration Guidelines

size size;
(world-readable | no-world-readable);
}
flag flag;

To configure the startup period for VRRP operations, include the startup-silent-period
statement at the [edit protocols vrrp] hierarchy level:

[edit protocols vrrp]

startup-silent-period seconds;

Configuring Basic VRRP Support

An interface can be a member of one or more VRRP groups.

To configure basic VRRP support, configure VRRP groups on interfaces by including

the following statements at the [edit interfaces interface-name unit logical-unit-number
family inet address address] or [edit logical-router logical-router-name interfaces
interface-name unit logical-unit-number family inet address address] hierarchy levels:

vrrp-group group-number {
priority number;
virtual-address [ addresses ];
}

To configure basic VRRP for IPv6 support, configure VRRP group support on interfaces
by including the following statements at the [edit interfaces interface-name unit
logical-unit-number family inet6 address address] or [edit logical-router logical-router-name
interfaces interface-name unit logical-unit-number family inet6 address address] hierarchy
levels:

vrrp-inet6-group group-number {
priority number;
virtual-inet6-address [ addresses ];
virtual-link-local-address
}

The following restrictions apply:

■ On a single routing platform, you cannot configure the same VRRP group on
multiple interfaces.
■ On a single routing platform, you cannot configure the same VRRP group on the
same virtual IP address.
■ Within a single VRRP group, the master and backup routers cannot be the same
routing platform.
■ Mixed tagging (configuring two logical interfaces on the same Ethernet port, one
with single-tag framing and one with dual-tag framing) is supported only for
interfaces on Gigabit Ethernet IQ2 and IQ PICs. If you include the
flexible-vlan-tagging statement at the [edit interfaces interface-name] hierarchy level
for a VRRP-enabled interface on a PIC that does not support mixed tagging, VRRP
on that interface is disabled. In the output of the show vrrp summary command,
the interface status is listed as Down.

Configuring Basic VRRP Support ■ 151

JUNOS 8.5 High Availability Configuration Guide

For each group, you must configure the following:

■ Group number—Identifies the VRRP group. It can be a value from 0 through
255. If you also enable MAC source address filtering on the interface, you must
include the virtual MAC address in the list of source MAC addresses that you
specify in the source-address-filter statement at the [edit interfaces interface-name]
hierarchy. (For more information, see the JUNOS Network Interfaces Configuration
Guide.) MAC addresses ranging from 00:00:5e:00:01:00 through 00:00:5e:00:01:ff
are reserved for VRRP, as defined in RFC 2378. The VRRP group number must
be the decimal equivalent of the last hexadecimal byte of the virtual MAC address.
■ Addresses of one or more virtual routers that are members of the VRRP
group—Normally, you configure only one virtual IP address per group. You can
configure up to eight addresses. In the addresses, specify the address only. Do
not include a prefix length. The following considerations apply to configuring
virtual IP addresses:
■ The virtual IP addresses must be the same for all routing platforms in the
VRRP group.
■ You cannot configure both IPv4 and IPv6 virtual IP addresses for a single
interface.

■ If you configure a virtual IP address to be the same as the interface’s address

(the address configured with the address statement), the interface becomes
the master virtual router for the group. In this case, you must configure the
priority to be 255 and you must configure preemption by including the
preempt statement.

■ If you have multiple VRRP groups on an interface, the interface can be the
master virtual router for only one of the groups.

■ If the virtual IP address you choose is not the same as the interface’s address,
you must ensure that this address does not appear anywhere else in the
routing platform’s configuration. Verify that you do not use this address for
other interfaces, for the IP address of a tunnel, or for the IP address of static
ARP entries.

■ You cannot configure a virtual IP address to be the same as the interface’s

address for an aggregated Ethernet interface. This configuration is not
supported.

■ For VRRP for IPv6, the EUI-64 option cannot be used. In addition, the
Duplicate Address Detection (DAD) process will not run for virtual IPv6
addresses.

■ Virtual link local address—(VRRP for IPv6 only) Identifies the link-local address
associated with the VRRP for IPv6 group. You must explicitly define the link-local
address when configuring VRRP for IPv6. This link-local address must be in the
same subnet as that of interface link-local address.

152 ■ Configuring Basic VRRP Support

 Chapter 18: VRRP Configuration Guidelines

■ Priority for this routing platform to become the master virtual router—Value
used to elect the master virtual router in the VRRP group. It can be a number
from 1 through 255. The default value for backup routers is 100. A larger value
indicates a higher priority. The routing platform with the highest priority within
the group becomes the master router.

Configuring VRRP Authentication (IPv4 Only)

VRRP (IPv4 only) protocol exchanges can be authenticated to guarantee that only
trusted routing platforms participate in routing in an autonomous system (AS). By
default, VRRP authentication is disabled. You can configure one of the following
authentication methods; each VRRP group must use the same method:
■ Simple authentication—Uses a text password included in the transmitted packet.
The receiving routing platform uses an authentication key (password) to verify
the packet.
■ Message Digest 5 (MD5) algorithm—Creates the authentication data field in the
IP authentication header. This header is used to encapsulate the VRRP PDU. The
receiving routing platform uses an authentication key (password) to verify the
authenticity of the IP authentication header and VRRP PDU.

To enable authentication and specify an authentication method, include the

authentication-type statement at the [edit interfaces interface-name unit
logical-unit-number family inet6 address address vrrp-inet6-group] or [edit logical-router
logical-router-name interfaces interface-name unit logical-unit-number family inet6 address
address vrrp-inet6-group] hierarchy levels:

authentication-type number;

authentication can be simple or md5. The authentication type must be the same for
all routing platforms in the VRRP group.

If you included the authentication-type statement to select an authentication method,

you can configure a key (password) on each interface by including the
authentication-key statement at the [edit interfaces interface-name unit logical-unit-number
family inet6 address address vrrp-inet6-group] or [edit logical-router logical-router-name
interfaces interface-name unit logical-unit-number family inet6 address address
vrrp-inet6-group] hierarchy levels:

authentication-key key;

The key (password) is an ASCII string. For simple authentication, it can be 1 through
8 characters long. For MD5 authentication, it can be 1 through 16 characters long.
If you include spaces, enclose all characters in quotation marks (“ ”). The key must
be the same for all routing platforms in the VRRP group.

Configuring the Advertisement Interval for the VRRP Master Router

By default, the master router sends VRRP advertisement packets every second to all
members of the VRRP group. These packets indicate that the master router is still

Configuring VRRP Authentication (IPv4 Only) ■ 153

JUNOS 8.5 High Availability Configuration Guide

operational. If the master router fails or becomes unreachable, the backup router
with the highest priority value becomes the new master router.

You can modify the advertisement interval in seconds or in milliseconds; the interval
must be the same for all routing platforms in the VRRP group.

For VRRP for IPv6, you must configure router advertisements for the interface on
which VRRP is configured to send IPv6 router advertisements for the VRRP group.
When an interface receives an IPv6 Router Solicitation message, it sends IPv6 Router
Advertisement to all VRRP groups configured on it. In the case of logical routers,
IPv6 router advertisements are not sent to VRRP groups.

Modifying the Advertisement Interval in Seconds

To modify the time, in seconds, between the sending of VRRP advertisement packets,
include the advertise-interval statement at the [edit interfaces interface-name unit
logical-unit-number family inet address address] or [edit logical-router logical-router-name
interfaces interface-name unit logical-unit-number family Inet address address] hierarchy
levels:

advertise-interval;

The interval can be from 1 through 255 seconds.

To modify the time, in seconds, between the sending of VRRP for IPv6 advertisement
packets, include the inet6-advertise-interval statement at the [edit interfaces
interface-name unit logical-unit-number family inet6 address address] or [edit logical-router
logical-router-name interfaces interface-name unit logical-unit-number family inet6 address
address] hierarchy levels:

inet6-advertise-interval;

Modifying the Advertisement Interval in Milliseconds

To modify the time, in milliseconds, between the sending of VRRP advertisement
packets, include the fast-interval statement at the [edit interfaces interface-name unit
logical-unit-number family (inet | inet6) address address] or [edit logical-router
logical-router-name interfaces interface-name unit logical-unit-number family (inet | inet6)
address address] hierarchy levels:

fast-interval milliseconds;

You can include this statement at the following hierarchy levels:

The interval can be from 100 through 999 milliseconds.

NOTE: In the VRRP PDU, the JUNOS software sets the advertisement interval to 0.
When you configure VRRP with other vendors’ routers, the fast-interval statement
works correctly only when the other routers also have an advertisement interval set
to 0 in the VRRP PDUs. Otherwise, the JUNOS software interprets other routers’
settings as advertisement timer errors.

154 ■ Configuring the Advertisement Interval for the VRRP Master Router
 Chapter 18: VRRP Configuration Guidelines

Configuring a Backup Router to Preempt the Master Router

By default, a higher-priority backup router preempts a lower-priority master router.
To explicitly enable the master router to be preempted, include the preempt statement
at the [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-name] or [edit logical-router logical-router-name
interfaces interface-name unit logical-unit-number family (Inet | inet6) address address
(vrrp-group | vrrp-inet6-group) group-name] hierarchy levels:

preempt;

To prohibit a higher-priority backup router from preempting a lower priority master

router, include the no-preempt statement:

no-preempt;

Modifying the Preemption Hold-Time Value

The hold time is the maximum number of seconds that can elapse before a
higher-priority backup router preempts the master router. You might want to configure
a hold time so that all the JUNOS software components converge before preemption.

By default, the hold-time value is 0 seconds. A value of 0 means that preemption

can occur immediately after the backup router comes online. Note that the hold time
is counted from the time the backup router comes online. The hold time is only valid
when the VRRP router is just coming online.

To modify the preemption hold-time value, include the hold-time statement at the
[edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-name] preempt or [edit logical-router
logical-router-name interfaces interface-name unit logical-unit-number family (Inet | inet6)
address address (vrrp-group | vrrp-inet6-group) group-name] preempt:

hold-time seconds;

The hold time can be from 0 through 3600 seconds.

Configuring an Interface to Accept Packets Destined for the Virtual IP Address

To configure an interface to accept packets destined for the virtual IP address, include
the accept-data statement at the [edit interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp-group | vrrp-inet6-group)] or [edit logical-router
logical-router-name interfaces interface-name unit logical-unit-number family (Inet | inet6)
address address (vrrp-group | vrrp-inet6-group)] hierarchy levels:

accept-data;

To prohibit the interface from accepting packets destined for the virtual IP address,
include the no-accept-data statement:

no-accept-data;

Configuring a Backup Router to Preempt the Master Router ■ 155

JUNOS 8.5 High Availability Configuration Guide

The accept-data statement has the following consequences:

■ If the master router owns the virtual IP address, the accept-data statement is not
valid.
■ If the priority of the master router is set to 255, the accept-data statement is not
valid.
■ To restrict incoming IP packets to ICMP only, you must configure firewall filters
to accept only ICMP packets.
■ If the master router owns the virtual IP address, the master router responds to
Internet Control Message Protocol (ICMP) message requests only.
■ If you include the accept-data statement:
■ Your routing platform configuration does not comply with RFC 2378.
■ VRRP clients can process gratuitous ARP.

■ VRRP clients must not use packets other than ARP replies to update their
ARP cache.

Configuring a Logical Interface to Be Tracked

VRRP can track whether a logical interface is up, down, or not present, and can also
dynamically change the priority of the VRRP group based on the state of the tracked
logical interface, which might trigger a new master router election. VRRP can also
track the operational speed of a logical interface and dynamically update the priority
of the VRRP group when the speed crosses a configured threshold.

When interface tracking is enabled, you cannot configure a priority of 255, thereby
designating the master router. For each VRRP group, you can track up to 10 logical
interfaces.

To configure a logical interface to be tracked, include the track statement at the [edit
interfaces interface-name unit logical-unit-number family (inet | inet6) address address
(vrrp-group | vrrp-inet6-group)] or [edit logical-router logical-router-name interfaces
interface-name unit logical-unit-number family (Inet | inet6) address address (vrrp-group
| vrrp-inet6-group)] hierarchy levels:

track {
priority-hold-time ;
interface interface-name {
priority-cost priority;
bandwidth-threshold bits-per-second {
priority-cost ;
}
}
}

The priority hold time is the minimum length of time that must elapse between
dynamic priority changes. If the dynamic priority changes because of a tracking
event, the priority hold timer begins. If another tracking event or manual configuration
change occurs while the timer is running, the new dynamic priority update is
postponed until the timer expires.

156 ■ Configuring a Logical Interface to Be Tracked

 Chapter 18: VRRP Configuration Guidelines

The bandwidth threshold specifies a threshold for the tracked interface. When the
bandwidth of the tracked interface drops below the configured bandwidth threshold
value, the VRRP group uses the bandwidth threshold priority cost. You can track up
to five bandwidth threshold statements for each tracked interface.

The priority cost is the value to be subtracted from the configured VRRP priority
when the tracked logical interface goes down, forcing a new master router election.
The value can be from 1 through 254. The sum of the costs for all tracked logical
interfaces or routes must be less than or equal to the configured priority of the VRRP
group.

If you are tracking more than one interface, the router applies the sum of the priority
costs for the tracked interfaces (at most, only one priority cost for each tracked
interface) to the VRRP group priority. However, the interface priority cost and
bandwidth threshold priority cost values for each VRRP group are not cumulative.
The router uses only one priority cost to a tracked interface as indicated in
Table 10 on page 157:

Table 10: Interface State and Priority Cost Usage

Tracked Interface State Priority Cost Usage

Down priority-cost priority

Not down; media speed below one or more Priority-cost of the lowest applicable bandwidth
bandwidth thresholds threshold

You must configure an interface priority cost only if you have configured no bandwidth
thresholds. If you have not configured an interface priority cost value, and the
interface is down, the interface uses the bandwidth threshold priority cost value of
the lowest bandwidth threshold.

Tracing VRRP Operations

To trace VRRP operations, include the traceoptions statement at the [edit protocols
vrrp] hierarchy level.

By default, VRRP logs the error, data carrier detect (DCD) configuration, and routing
socket events in a file in the /var/log directory. By default, this file is named
/var/log/vrrpd. The default file size is 1 megabyte (MB), and three files are created
before the first one gets overwritten.

To change the configuration of the logging file, include the file statement at the [edit
protocols vrrp traceoptions] hierarchy level:

[edit protocols vrrp traceoptions]

file {
filename filename;
files number;
match regex;
size size;

Tracing VRRP Operations ■ 157

JUNOS 8.5 High Availability Configuration Guide

(world-readable | no-world-readable);
}
flag flag;

You can specify the following VRRP tracing flags:

■ all—Trace all VRRP operations.
■ database—Trace all database changes.
■ general—Trace all general events.
■ interfaces—Trace all interface changes.
■ normal—Trace all normal events.
■ packets—Trace all packets sent and received.
■ state—Trace all state transitions.
■ timer—Trace all timer events.

Configuring the Silent Period

The silent period starts when the interface state is changed from down to up. During
this period, the Master Down Event is ignored. Configure the silent period interval
to avoid alarms caused by the delay or interruption of the incoming VRRP
advertisement packets during the interface startup phase.

To configure the silent period interval that the Master Down Event timer ignores,
include the startup-silent-period statement at the [edit protocols vrrp] hierarchy level:

[edit protocols vrrp]

startup-silent-period seconds;

Configuring Passive ARP Learning for Backup VRRP Routers

By default, the backup VRRP router drops ARP requests for the VRRP-IP to VRRP-MAC
address translation. This means that the backup router does not learn the ARP
(IP-to-MAC address) mappings for the hosts sending the requests. When it detects a
failure of the master router and transitions to become the new master router, the
backup router must learn all the entries that were present in the ARP cache of the
master router. In environments with many directly attached hosts, such as metro
Ethernet environments, the number of ARP entries to learn can be high. This can
cause a significant transition delay, during which the traffic transmitted to some of
the hosts might be dropped.

Passive ARP learning enables the ARP cache in the backup router to hold
approximately the same contents as the ARP cache in the master router, thus
preventing the problem of learning ARP entries in a burst. To enable passive ARP
learning, include the passive-learning statement at the [edit system arp] hierarchy
level:

[edit system arp]

passive-learning;

158 ■ Configuring the Silent Period

 Chapter 18: VRRP Configuration Guidelines

We recommend setting passive learning on both the backup and master VRRP routers.
Doing so prevents the need to manually intervene when the master router becomes
the backup router. While a router is operating as the master router, the passive
learning configuration has no operational impact. The configuration takes effect only
when the router is operating as a backup router.

For information about configuring gratuitous ARP and the ARP aging timer, see the
JUNOS System Basics Configuration Guide.

Example: Configuring VRRP

Configure one master (Router A) and one backup (Router B) routing platform. The
address configured in the virtual-address statements differs from the addresses
configured in the address statements. When you configure multiple VRRP groups on
an interface, you configure one to be the master virtual router for that group.
On Router A [edit]
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 192.168.1.20/24 {
vrrp-group 27 {
virtual-address 192.168.1.15;
priority 254;
authentication-type simple;
authentication-key booJUM;
}
}
}
}
}
}

On Router B [edit]
interfaces {
ge-4/2/0 {
unit 0 {
family inet {
address 192.168.1.24/24 {
vrrp-group 27 {
virtual-address 192.168.1.15;
priority 200;
authentication-type simple;
authentication-key booJUM;
}
}
}
}
}
}

Example: Configuring VRRP ■ 159

JUNOS 8.5 High Availability Configuration Guide

Configuring One Router [edit]

to be the Master Virtual interfaces {
Router for the Group ge-0/0/0 {
unit 0 {
family inet {
address 192.168.1.20/24 {
vrrp-group 2 {
virtual-address 192.168.1.20;
priority 255;
advertise-interval 3;
preempt;
}
vrrp-group 10 {
virtual-address 192.168.1.55;
priority 201;
advertise-interval 3;
}
vrrp-group 1 {
virtual-address 192.168.1.54;
priority 22;
advertise-interval 4;
}
}
}
}
}
}

Configuring VRRP and The VRRP group number is the decimal equivalent of the last byte of the virtual MAC
MAC Source Address address.
Filtering
[edit interfaces]
ge-5/2/0 {
gigether-options {
source-filtering;
source-address-filter {
00:00:5e:00:01:0a; # Virtual MAC address
}
}
unit 0 {
family inet {
address 192.168.1.10/24 {
vrrp-group 10 { # VRRP group number
virtual-address 192.168.1.10;
priority 255;
preempt;
}
}
}
}

160 ■ Example: Configuring VRRP

 Chapter 18: VRRP Configuration Guidelines

Example: Configuring VRRP for IPv6

Configure VRRP properties for IPv6 in one master (Router A) and one backup (Router
B).
On Router A [edit interfaces ]
ge-1/0/0 {
unit 0 {
family inet6 {
address fe80::5:0:0:6/64;
address fec0::5:0:0:6/64 {
vrrp-inet6-group 3 { # VRRP inet6 group number
virtual-inet6-address fec0::5:0:0:7;
virtual-link-local-address fe80::5:0:0:7;
priority 200;
preempt;
}
}
}
}

[edit protocols]
router-advertisement {
interface ge-1/0/0.0 {
prefix fec0::/64;
max-advertisement-interval 4;
}
}
On Router B [edit interfaces]
ge-1/0/0 {
unit 0 {
family inet6 {
address fe80::5:0:0:8/64;
address fec0::5:0:0:8/64 {
vrrp-inet6-group 3 { # VRRP inet6 group number
virtual-inet6-address fec0::5:0:0:7;
virtual-link-local-address fe80::5:0:0:7;
priority 100;
preempt;
}
}
}
}

[edit protocols]
router-advertisement {
interface ge-1/0/0.0 {
prefix fec0::/64;
max-advertisement-interval 4;
}
}

Example: Configuring VRRP for IPv6 ■ 161

JUNOS 8.5 High Availability Configuration Guide

162 ■ Example: Configuring VRRP for IPv6

Chapter 19
Summary of VRRP Configuration
Statements

This chapter provides a reference for each of the VRRP configuration statements.
The statements are organized alphabetically.

accept-data

Syntax (accept-data | no-accept-data);

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-number],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-number]

Release Information Statement introduced before JUNOS Release 7.4.

Description In a Virtual Router Redundancy Protocol (VRRP) configuration, determine whether
or not an interface accepts packets destined for the virtual IP address:
■ accept-data—Enable the interface to accept packets destined for the virtual IP
address.
■ no-accept-data—Prevent the interface from accepting packets destined for the
virtual IP address.

Default If the accept-data statement is not configured, the master router responds to Internet
Control Message Protocol (ICMP) message requests only.

Usage Guidelines See “Configuring an Interface to Accept Packets Destined for the Virtual IP
Address” on page 155.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

accept-data ■ 163
JUNOS 8.5 High Availability Configuration Guide

advertise-interval

Syntax advertise-interval seconds;

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family inet address address
vrrp-group group-number],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family inet address address vrrp-group group-number]

Release Information Statement introduced before JUNOS Release 7.4.

Description Configure the interval between Virtual Router Redundancy Protocol (VRRP) IPv4
advertisement packets.

All routers in the VRRP group must use the same advertisement interval.

Options seconds—Interval between advertisement packets.

Range: 1 through 255 seconds
Default: 1 second
Usage Guidelines See “Configuring the Advertisement Interval for the VRRP Master Router” on page 153.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.
Related Topics fast-interval
inet6-advertise-interval

164 ■ advertise-interval
 Chapter 19: Summary of VRRP Configuration Statements

authentication-key

Syntax authentication-key key;

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family inet address address
vrrp-group group-number],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family inet address address vrrp-group group-number]

Release Information Statement introduced before JUNOS Release 7.4.

Description Configure a Virtual Router Redundancy Protocol (VRRP) IPv4 authentication key.
You also must specify a VRRP authentication scheme by including the
authentication-type statement.

All routers in the VRRP group must use the same authentication scheme and
password.

Options key—Authentication password. For simple authentication, it can be 1 through 8

characters long. For Message Digest 5 (MD5) authentication, it can be 1 through
16 characters long. If you include spaces, enclose all characters in quotation
marks (“ ”).

Usage Guidelines See “Configuring VRRP Authentication (IPv4 Only)” on page 153.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.
Related Topics authentication-type

authentication-key ■ 165
JUNOS 8.5 High Availability Configuration Guide

authentication-type

Syntax authentication-type authentication;

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family inet address address
vrrp-group group-number],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family inet address address vrrp-group group-number]

Release Information Statement introduced before JUNOS Release 7.4.

Description Enable Virtual Router Redundancy Protocol (VRRP) IPv4 authentication and specify
the authentication scheme for the VRRP group. If you enable authentication, you
must specify a password by including the authentication-key statement.

All routers in the VRRP group must use the same authentication scheme and
password.

Options authentication—Authentication scheme:

■ simple—Use a simple password. The password is included in the transmitted
packet, making this method of authentication relatively insecure.

■ md5—Use the MD5 algorithm to create an encoded checksum of the packet. The
encoded checksum is included in the transmitted packet. The receiving routing
platform uses the authentication key to verify the packet, discarding it if the
digest does not match. This algorithm provides a more secure authentication
scheme.
Default: none (No authentication is performed)
Usage Guidelines See “Configuring VRRP Authentication (IPv4 Only)” on page 153.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.
Related Topics authentication-key

166 ■ authentication-type
 Chapter 19: Summary of VRRP Configuration Statements

bandwidth-threshold

Syntax bandwidth-threshold bits-per-second {

priority-cost priority;
}

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-number) track interface interface-name],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-number)
group-number) track interface interface-name]

Release Information Statement introduced in JUNOS Release 8.1.

Description Specify the bandwidth threshold for Virtual Router Redundancy Protocol (VRRP)
logical interface tracking.

Options bits-per-second—Bandwidth threshold for the tracked interface. When the bandwidth
of the tracked interface drops below the specified value, the VRRP group uses
the bandwidth threshold priority cost value. You can include up to five bandwidth
threshold statements for each interface you track.
Range: 1 through 10000000000000 bits per second

The remaining statement is described separately.

Usage Guidelines See “Configuring a Logical Interface to Be Tracked” on page 156.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.
Related Topics priority-cost

bandwidth-threshold ■ 167
JUNOS 8.5 High Availability Configuration Guide

fast-interval

Syntax fast-interval milliseconds;

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address vrrp-group group-number],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address vrrp-group group-number]

Release Information Statement introduced before JUNOS Release 7.4.

Description Configure the interval, in milliseconds, between Virtual Router Redundancy Protocol
(VRRP) advertisement packets.

All routers in the VRRP group must use the same advertisement interval.

Options milliseconds—Interval between advertisement packets.

Range: 100 through 999 milliseconds
Default: 1 second
Usage Guidelines See “Configuring the Advertisement Interval for the VRRP Master Router” on page 153.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.
Related Topics advertise-interval
inet6-advertise-interval

168 ■ fast-interval
 Chapter 19: Summary of VRRP Configuration Statements

hold-time

Syntax hold-time seconds;

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp | vrrp-inet6-group) group-number preempt],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp | vrrp-inet6-group) group-number preempt]

Release Information Statement introduced before JUNOS Release 7.4.

Description In a Virtual Router Redundancy Protocol (VRRP) configuration, set the hold time
before a higher-priority backup router preempts the master router.

Default VRRP preemption is not timed.

Options seconds—Hold-time period.

Range: 0 through 3600 seconds
Default: 0 seconds (VRRP preemption is not timed.)
Usage Guidelines See “Configuring a Backup Router to Preempt the Master Router” on page 155.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

hold-time ■ 169
JUNOS 8.5 High Availability Configuration Guide

inet6-advertise-interval

Syntax inet6-advertise-interval seconds

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family inet6 address address
vrrp-inet6-group group-number],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family Inet6 address address vrrp-inet6-group group-number]

Release Information Statement introduced before JUNOS Release 7.4.

Description Configure the interval between Virtual Router Redundancy Protocol (VRRP) IPv6
advertisement packets.

All routers in the VRRP group must use the same advertisement interval.

Options seconds—Interval between advertisement packets.

Range: 1 through 255 seconds
Default: 1 second
Usage Guidelines See “Configuring the Advertisement Interval for the VRRP Master Router” on page 153.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.
Related Topics fast-interval
advertise-interval

170 ■ inet6-advertise-interval
 Chapter 19: Summary of VRRP Configuration Statements

interface

Syntax interface interface-name {

priority priority;
bandwidth-threshold bits-per-second {
priority-cost priority;
}
}

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) track],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp-group | vrrp-inet6-group) track]

Release Information Statement introduced in JUNOS Release 7.5.

bandwidth-threshold statement added in JUNOS Release 8.1.
Description Enable logical interface tracking for a Virtual Router Redundancy Protocol (VRRP)
group.

Options interface interface-name—Interface to be tracked for this VRRP group

Range: 1 through 10 interfaces

The remaining statements are described separately.

Usage Guidelines See “Configuring a Logical Interface to Be Tracked” on page 156.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.
Related Topics JUNOS Services Interfaces Configuration Guide

no-accept-data

See accept-data

no-preempt

See preempt

interface ■ 171
JUNOS 8.5 High Availability Configuration Guide

preempt

Syntax (preempt | no-preempt) {

hold-time seconds;
}

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address vrrp-group | vrrp-inet6-group) group-number],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address vrrp-group | vrrp-inet6-group) group-number]

Release Information Statement introduced before JUNOS Release 7.4.

Description In a Virtual Router Redundancy Protocol (VRRP) configuration, determine whether
or not a backup router can preempt a master router:
■ preempt—Allow the master router to be preempted.
■ no-preempt—Prohibit the preemption of the master router.

The remaining statement is explained separately.

Default If you omit this statement, the backup router cannot preempt a master router.

Usage Guidelines See “Configuring a Backup Router to Preempt the Master Router” on page 155.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

172 ■ preempt
 Chapter 19: Summary of VRRP Configuration Statements

priority

Syntax priority priority;

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address vrrp-group | vrrp-inet6-group) group-number],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address vrrp-group | vrrp-inet6-group) group-number]

Release Information Statement introduced before JUNOS Release 7.4.

Description Configure a Virtual Router Redundancy Protocol (VRRP) router’s priority for becoming
the master default router. The router with the highest priority within the group
becomes the master.

Options priority—Router’s priority for being elected to be the master router in the VRRP group.
A larger value indicates a higher priority for being elected.
Range: 1 through 255
Default: 100 (for backup routers)
Usage Guidelines See “Configuring Basic VRRP Support” on page 151.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

priority ■ 173
JUNOS 8.5 High Availability Configuration Guide

priority-cost

Syntax priority-cost priority;

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp | vrrp-inet-group) group-number interface interface-name],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp | vrrp-inet6-group) group-number interface
interface-name],
[edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp | vrrp-inet6-group) group-number interface interface-name
bandwidth-threshold bits-per-second],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp | vrrp-inet6-group) group-number interface
interface-name bandwidth-threshold bits-per-second]

Release Information Statement introduced in JUNOS Release 8.1.

Description Configure a Virtual Router Redundancy Protocol (VRRP) router’s priority cost for
becoming the master default router. The router with the highest priority within the
group becomes the master.

Options priority-cost priority—The value subtracted from the configured VRRP priority when
the tracked interface is down, forcing a new master router election. The sum of
all the costs for all interfaces or routes that are tracked must be less than or equal
to the configured priority of the VRRP group.
Range: 1 through 254
Usage Guidelines See “Configuring a Logical Interface to Be Tracked” on page 156.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

174 ■ priority-cost
 Chapter 19: Summary of VRRP Configuration Statements

priority-hold-time

Syntax priority-hold-time seconds;

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp | vrrp-inet6-group) group-number track],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp | vrrp-inet6-group) group-number track]

Release Information Statement introduced in JUNOS Release 8.1.

Description Configure a Virtual Router Redundancy Protocol (VRRP) router’s priority hold time
to define the minimum length of time that must elapse between dynamic priority
changes. If the dynamic priority changes because of a tracking event, the priority
hold timer begins. If another tracking event or manual configuration change occurs
while the timer is running, the new dynamic priority update is postponed until the
timer expires.

Options seconds—The minimum length of time that must elapse between dynamic priority
changes.
Range: 1 through 3600 seconds
Usage Guidelines See “Configuring a Logical Interface to Be Tracked” on page 156.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

startup-silent-period

Syntax startup-silent-period seconds;

Hierarchy Level [edit protocols vrrp]

Release Information Statement introduced before JUNOS Release 7.4.

Description Instruct the system to ignore the Master Down Event when an interface transitions
from the disabled state to the enabled state. This statement is used to avoid an
incorrect error alarm caused by delay or interruption of incoming Virtual Router
Redundancy Protocol (VRRP) advertisement packets during the interface startup
phase.

Options seconds—Number of seconds.

Default: 4 seconds
Range: 1 through 2000 seconds
Usage Guidelines See “Configuring the Silent Period” on page 158.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

priority-hold-time ■ 175
JUNOS 8.5 High Availability Configuration Guide

traceoptions

Syntax traceoptions {
file {
filename filename;
files number;
match regex;
size size;
(world-readable | no-world-readable);
}
flag flag;
}

Hierarchy Level [edit protocols vrrp]

Release Information Statement introduced before JUNOS Release 7.4.

Description Define tracing operations for the Virtual Router Redundancy Protocol (VRRP) process.

To specify more than one tracing operation, include multiple flag statements.

By default, VRRP logs the error, dcd configuration, and routing socket events in a file
in the directory /var/log.

Default If you do not include this statement, no VRRP-specific tracing operations are
performed.

Options filename filename—Name of the file to receive the output of the tracing operation.
Enclose the name within quotation marks. All files are placed in the directory
/var/log. By default, VRRP tracing output is placed in the file vrrpd.

files number—(Optional) Maximum number of trace files. When a trace file named
trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1,
and so on, until the maximum number of trace files is reached. When the
maximum number is reached, the oldest trace file is overwritten.
Range: 0 through 4,294,967,296 files
Default: 3 files

If you specify a maximum number of files, you also must specify a maximum file
size with the size option.

flag flag—Tracing operation to perform. To specify more than one tracing operation,
include multiple flag statements. These are the VRRP-specific tracing options:
■ all—All VRRP tracing operations

■ database—Database changes

■ general—General events

■ interfaces—Interface changes

176 ■ traceoptions
 Chapter 19: Summary of VRRP Configuration Statements

■ normal—Normal events

■ packets—Packets sent and received

■ state—State transitions

■ timer—Timer events

match regex—(Optional) Refine the output to include only those lines that match the
given regular expression.

microsecond-stamp—(Optional) Provide a timestamp with microsecond granularity.

size size—(Optional) Maximum size of each trace file, in kilobytes, megabytes, or

gigabytes. When a trace file named trace-file reaches this size, it is renamed
trace-file.0. When the trace-file again reaches its maximum size, trace-file.0 is
renamed trace-file.1 and trace-file is renamed trace-file.0. This renaming scheme
continues until the maximum number of trace files is reached. Then the oldest
trace file is overwritten.
Syntax: xk to specify kB, xm to specify MB, or xg to specify GB
Range: 10 KB through the maximum file size supported on your routing platform
Default: 1 MB

If you specify a maximum file size, you also must specify a maximum number of
trace files with the files option.

world-readable | no-world-readable—Specifies whether any reader can read the log file.

Usage Guidelines See “Tracing VRRP Operations” on page 157.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

traceoptions ■ 177
JUNOS 8.5 High Availability Configuration Guide

track

Syntax track {
priority-hold-time seconds;
interface interface-name {
priority-cost priority;
bandwidth-threshold bits-per-second {
priority-cost priority;
}
}
}

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address vrrp-group | vrrp-inet6-group) group-number],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address vrrp-group | vrrp-inet6-group) group-number]

Release Information Statement introduced before JUNOS Release 7.4.

bandwidth-threshold statement added in JUNOS Release 8.1.
Description Enable logical interface tracking for a Virtual Router Redundancy Protocol (VRRP)
group.

Options The remaining statements are described separately.

Usage Guidelines See “Configuring a Logical Interface to Be Tracked” on page 156.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

178 ■ track
 Chapter 19: Summary of VRRP Configuration Statements

virtual-address

Syntax virtual-address [ addresses ];

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family inet address address
vrrp-group group-number],
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number
family inet address address vrrp-group group-number]

Release Information Statement introduced before JUNOS Release 7.4.

Description Configure the addresses of the virtual routers in a Virtual Router Redundancy Protocol
(VRRP) IPv4 group. You can configure up to eight addresses.

Options addresses—Addresses of one or more virtual routers. Do not include a prefix length.
If the address is the same as the interface’s physical address, the interface
becomes the master virtual router for the group.

Usage Guidelines See “Configuring Basic VRRP Support” on page 151.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

virtual-inet6-address

Syntax virtual-inet6-address [ addresses ];

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family inet6 address address
vrrp-inet6-group group-number],
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number
family inet6 address address vrrp-inet6-group group-number]

Release Information Statement introduced before JUNOS Release 7.4.

Description Configure the addresses of the virtual routers in a Virtual Router Redundancy Protocol
(VRRP) IPv6 group. You can configure up to eight addresses.

Options addresses—Addresses of one or more virtual routers. Do not include a prefix length.
If the address is the same as the interface’s physical address, the interface
becomes the master virtual router for the group.

Usage Guidelines See “Configuring Basic VRRP Support” on page 151.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

virtual-address ■ 179
JUNOS 8.5 High Availability Configuration Guide

virtual-link-local-address

Syntax virtual-link-local-address ipv6-address;

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family inet6 address address
vrrp-inet6-group group-number],
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number
family inet6 address address vrrp-inet6-group group-number]

Release Information Statement introduced in JUNOS Release 8.4.

Description Configure a virtual link local address for a Configure the addresses of the virtual
routers in a Virtual Router Redundancy Protocol (VRRP) IPv6 group.

Options ipv6-address—Virtual link local IPv6 address for VRRP for an IPv6 group.
Range: 0 through 255

The remaining statements are explained separately.

Usage Guidelines See “Configuring Basic VRRP Support” on page 151.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

180 ■ virtual-link-local-address
 Chapter 19: Summary of VRRP Configuration Statements

vrrp-group

Syntax vrrp-group group-number {

(accept-data | no-accept-data);
advertise-interval seconds;
authentication-key key;
authentication-type authentication;
fast-interval milliseconds;
(preempt | no-preempt) {
hold-time seconds;
}
priority number;
track {
priority-hold-time ;
interface interface-name {
priority-cost priority;
bandwidth-threshold bits-per-second {
priority-cost ;
}
}
}
virtual-address [ addresses ];
}

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family inet address address],
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number
family inet address address]

Release Information Statement introduced before JUNOS Release 7.4.

bandwidth-threshold statement added in JUNOS Release 8.1.
Description Configure a Virtual Router Redundancy Protocol (VRRP) IPv4 group. On a single
routing platform, you cannot configure the same VRRP group on multiple interfaces.

Options group-number—VRRP group identifier. If you enable MAC source address filtering on
the interface, you must include the virtual MAC address in the list of source MAC
addresses that you specify in the source-address-filter statement. MAC addresses
ranging from 00:00:5e:00:01:00 through 00:00:5e:00:01:ff are reserved for
VRRP, as defined in RFC 2338. The VRRP group number must be the decimal
equivalent of the last hexadecimal byte of the virtual MAC address.
Range: 0 through 255

The remaining statements are explained separately.

Usage Guidelines See “VRRP Configuration Guidelines” on page 149.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

vrrp-group ■ 181
JUNOS 8.5 High Availability Configuration Guide

vrrp-inet6-group

Syntax vrrp-inet6-group group-number {

(accept-data | no-accept-data);
fast-interval milliseconds;
inet6-advertise-interval seconds;
(preempt | no-preempt) {
hold-time seconds;
}
priority number;
track {
priority-hold-time ;
interface interface-name {
priority-cost priority;
bandwidth-threshold bits-per-second {
priority-cost ;
}
}
}
virtual-inet6-address [ addresses ];
virtual-link-local-address
}

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family inet address address],
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number
family inet address address]

Release Information Statement introduced before JUNOS Release 7.4.

bandwidth-threshold statement added in JUNOS Release 8.1.
Description Configure a Virtual Router Redundancy Protocol (VRRP) IPv6 group. On a single
routing platform, you cannot configure the same VRRP group on multiple interfaces.

Options group-number—VRRP group identifier. If you enable MAC source address filtering on
the interface, you must include the virtual MAC address in the list of source MAC
addresses that you specify in the source-address-filter statement. MAC addresses
ranging from 00:00:5e:00:01:00 through 00:00:5e:00:01:ff are reserved for
VRRP, as defined in RFC 2338. The VRRP group number must be the decimal
equivalent of the last hexadecimal byte of the virtual MAC address.
Range: 0 through 255

The remaining statements are explained separately.

Usage Guidelines See “VRRP Configuration Guidelines” on page 149.

Required Privilege Level interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration.

182 ■ vrrp-inet6-group
Part 8
Index
■ Index on page 185
■ Index of Commands and Statements on page 191

Index ■ 183
JUNOS 8.5 High Availability Configuration Guide

184 ■ Index
Index
CFEB redundancy
configuring............................................................26
Symbols overview...............................................................15
#, comments in configuration statements.................xxiv cfeb statement.............................................................31
( ), in syntax descriptions..........................................xxiii usage guidelines....................................................27
< >, in syntax descriptions......................................xxiii circuit cross-connect See CCC
[ ], in configuration statements..................................xxiv comments, in configuration statements....................xxiv
{ }, in configuration statements................................xxiv commit synchronize statement....................................81
| (pipe), in syntax descriptions..................................xxiii usage guidelines....................................................76
Compact Forwarding Engine Board See CFEB
redundancy
A configuration files, copying between Routing
accept-data statement................................................163 Engines....................................................................21
usage guidelines..................................................155 conventions
advertise-interval statement.......................................164 text and syntax..................................................xxiii
usage guidelines..................................................153 curly braces, in configuration statements..................xxiv
advertisement intervals, VRRP...................................153 customer support.......................................................xxx
aggregate routes contacting JTAC...................................................xxx
graceful restart......................................................87
nonstop routing....................................................72
authentication, VRRP.................................................153 D
authentication-key statement.....................................165 description statement..................................................32
usage guidelines..................................................153 usage guidelines....................................................28
authentication-type statement....................................166 disable statement.......................................................133
usage guidelines..................................................153 usage guidelines
aggregate routes............................................95
BGP...............................................................96
B ES-IS..............................................................97
backup routers, VRRP................................................147 global.....................................96, 101, 103, 104
bandwidth-threshold statement.................................167 IS-IS...............................................................97
usage guidelines..................................................156 OSPF ............................................................98
BFD, nonstop routing...................................................72 OSPFv3..........................................................98
BGP PIM................................................................99
graceful restart......................................................87 RIP................................................................99
nonstop routing....................................................72 RIPng.............................................................99
bidirectional forwarding detection See BFD routing instances.........................................103
Border Gateway Protocol See BGP routing instances inside a logical router.......105
braces, in configuration statements...........................xxiv RSVP...........................................................101
brackets static routes...................................................95
angle, in syntax descriptions..............................xxiii documentation set
square, in configuration statements...................xxiv comments on......................................................xxx

C E
CCC, graceful restart....................................................87 ES-IS
graceful restart......................................................87

Index ■ 185
JUNOS 8.5 High Availability Configuration Guide

F OSPFv3..........................................................98
failover statement .......................................................32 PIM................................................................99
fast-interval statement...............................................168 RIP................................................................99
usage guidelines..................................................154 RIPng.............................................................99
FEB redundancy routing instances.........................................103
configuration example..........................................28 routing instances inside a logical router.......105
configuring............................................................28 RSVP...........................................................101
overview...............................................................15 static routes...................................................95
feb statement...............................................................33 graceful-switchover statement......................................55
usage guidelines....................................................28 usage guidelines....................................................53
file copy command GRES See graceful Routing Engine switchover
usage guidelines....................................................21
font conventions.......................................................xxiii
Forwarding Engine Board See FEB redundancy H
helper-disable statement............................................135
usage guidelines
G IS-IS...............................................................97
graceful restart LDP.............................................................102
commands, operational mode............................106 OSPF ............................................................98
concepts...............................................................87 OSPFv3..........................................................98
configuration procedure RSVP...........................................................101
aggregate routes............................................95 high availability features
MPLS protocols............................................100 comparison of.........................................................6
routing protocols...........................................95 graceful restart......................................................87
static routes...................................................95 graceful Routing Engine switchover......................41
VPNs............................................................103 nonstop bridging...................................................59
example configuration........................................108 nonstop routing....................................................69
overview...............................................................87 overview.................................................................3
aggregate routes............................................89 VRRP..................................................................147
MPLS protocols..............................................91 hold-time statement...................................................169
routing protocols...........................................89
static routes...................................................89
VPNs..............................................................92 I
protocol support...................................................87 icons defined, notice..................................................xxii
system requirements............................................88 inet6-advertise-interval statement..............................170
trace options.......................................................100 usage guidelines..................................................154
verifying operation of.........................................106 interface statement....................................................171
graceful Routing Engine switchover usage guidelines..................................................156
concepts...............................................................41 Intermediate System-to-Intermediate System See IS-IS
DPC support.........................................................46 IS-IS
enabling................................................................53 graceful restart......................................................87
extended DHCP relay agent..................................45 nonstop routing....................................................72
feature support.....................................................44
PIC support...........................................................46
platform support...................................................44 K
system architecture...............................................42 keepalive-time statement.............................................34
system requirements............................................44 usage guidelines....................................................23
verifying status of.................................................54
graceful-restart statement..........................................134
usage guidelines L
aggregate routes............................................95 Label Distribution Protocol See LDP
BGP...............................................................96 LDP
global.....................................96, 101, 103, 104 graceful restart......................................................87
IS-IS...............................................................97 nonstop routing....................................................72
LDP.............................................................102
OSPF ............................................................98

186 ■ Index
 Index

M O
manuals on-disk-failure statement..............................................35
comments on......................................................xxx usage guidelines....................................................23
master router, VRRP..................................................147 on-loss-of-keepalives statement....................................35
maximum-helper-recovery-time statement................135 usage guidelines....................................................23
usage guidelines..................................................101 Open Shortest Path First See OSPF
maximum-helper-restart-time statement....................136 OSPF
usage guidelines..................................................101 graceful restart......................................................87
maximum-recovery-time statement...........................136 nonstop routing....................................................72
usage guidelines..................................................102 OSPFv3
MPLS, graceful restart..................................................87 nonstop routing....................................................72
MSTP, nonstop bridging...............................................62
Multiple Spanning Tree Protocol See MSTP
P
parentheses, in syntax descriptions...........................xxiii
N passive ARP learning, VRRP.......................................158
next-generation RIP See RIPng PIM, graceful restart.....................................................87
no-accept-data statement...........................................171 preempt statement....................................................172
usage guidelines..................................................155 usage guidelines..................................................155
no-auto-failover statement...........................................34 preempting master router, VRRP...............................155
usage guidelines....................................................28 priority statement......................................................173
no-preempt statement...............................................171 usage guidelines..................................................151
usage guidelines..................................................155 priority-cost statement...............................................174
no-strict-lsa-checking statement.................................137 usage guidelines..................................................156
usage guidelines priority-hold-time statement......................................175
OSPF.............................................................98 usage guidelines..................................................156
OSPFv3..........................................................98 Protocol Independent Multicast See PIM
nonstop bridging
concepts...............................................................59
enabling................................................................63 R
platform support...................................................61 Rapid Spanning Tree Protocol See RSTP
protocol support...................................................62 recovery-time statement............................................138
system architecture...............................................60 usage guidelines..................................................102
system requirements............................................61 redundancy feb statement
verifying status of ................................................64 usage guidelines....................................................28
nonstop routing redundancy statement.................................................36
concepts...............................................................69 usage guidelines....................................................19
enabling................................................................75 redundancy-group statement.......................................37
example configuration..........................................78 usage guidelines....................................................28
platform support...................................................72 request chassis cfeb master switch command
protocol support...................................................72 usage guidelines....................................................27
system architecture...............................................70 request chassis redundancy feb command
system requirements............................................71 usage guidelines....................................................28
trace options.........................................................77 request chassis routing-engine master acquire
verifying status of ................................................76 command
nonstop-bridging statement.........................................65 usage guidelines....................................................25
usage guidelines....................................................63 request chassis routing-engine master release
nonstop-routing statement...........................................82 command
usage guidelines....................................................75 usage guidelines....................................................25
notice icons defined...................................................xxii request chassis routing-engine master switch command
notify-duration statement...........................................137 usage guidelines....................................................25
usage guidelines....................................................98 request chassis sfm master switch command
NSR See nonstop routing usage guidelines....................................................30
request chassis ssb master switch command
usage guidelines....................................................30

Index ■ 187
JUNOS 8.5 High Availability Configuration Guide

request routing-engine login command show chassis feb command

usage guidelines....................................................21 usage guidelines....................................................28
request system software add command show chassis sfm command
usage guidelines....................................................22 usage guidelines....................................................30
Resource Reservation Protocol See RSVP show chassis ssb command
restart-duration statement..........................................139 usage guidelines....................................................30
usage guidelines show task replication command
ES-IS..............................................................97 usage guidelines....................................................76
global.....................................96, 101, 103, 104 software packages
IS-IS...............................................................97 transferring between Routing Engines..................22
OSPF ............................................................98 Spanning Tree Protocol See STP
OSPFv3..........................................................98 SSB redundancy
PIM................................................................99 configuring............................................................30
routing instances.........................................103 overview...............................................................17
routing instances inside a logical router.......105 ssb statement...............................................................38
restart-time statement................................................140 usage guidelines....................................................30
usage guidelines stale-routes-time statement........................................141
BGP...............................................................96 usage guidelines....................................................96
RIP................................................................99 startup period, VRRP..................................................151
RIPng.............................................................99 startup-silent-period statement...................................175
RIP, graceful restart......................................................87 usage guidelines..................................................151
RIPng, graceful restart..................................................87 static routes
Routing Engine redundancy graceful restart......................................................87
copying configuration files....................................21 nonstop routing....................................................72
default behavior....................................................13 STP, nonstop bridging..................................................62
failover support, technical See technical support
conditions......................................................13 Switching and Forwarding Module See SFM redundancy
on loss of keepalive signal.............................23 switching control board redundancy See CFEB
graceful Routing Engine switchover......................23 redundancy, FEB redundancy, SFM redundancy, SSB
halting Routing Engines........................................14 redundancy
log file, viewing.....................................................25 synchronizing Routing Engines
mastership graceful Routing Engine switchover......................54
default setup, modifying................................20 nonstop routing....................................................76
switching, manually.......................................25 Routing Engine redundancy..................................63
overview...............................................................11 syntax conventions...................................................xxiii
platform support...................................................12 System and Switch Board See SSB redundancy
software packages, loading ..................................22 system requirements
TX Matrix, running the same JUNOS release.........24 graceful restart......................................................88
Routing Information Protocol See RIP graceful Routing Engine switchover......................44
routing-engine statement.............................................37 nonstop bridging...................................................61
usage guidelines....................................................20 nonstop routing....................................................71
RSTP, nonstop bridging................................................62
RSVP
graceful restart......................................................87 T
TCC, graceful restart.....................................................87
technical support
S contacting JTAC...................................................xxx
SFM redundancy traceoptions statement
configuring............................................................29 graceful restart ...................................................142
overview...............................................................18 usage guidelines..........................................100
sfm statement..............................................................38 nonstop routing....................................................83
usage guidelines....................................................29 usage guidelines............................................77
show bgp replication command VRRP..................................................................176
usage guidelines....................................................76 usage guidelines..........................................157
show chassis cfeb command track statement..........................................................178
usage guidelines....................................................27 usage guidelines..................................................156

188 ■ Index
 Index

translational cross-connect See TCC

TX Matrix platform
Routing Engine redundancy..................................24

V
Virtual Router Redundancy Protocol See VRRP
virtual-address statement...........................................179
usage guidelines..................................................151
virtual-inet6-address statement..................................179
usage guidelines..................................................151
virtual-link-local-address statement............................180
usage guidelines..................................................151
VPNs, graceful restart...................................................88
VRRP
advertisement interval........................................153
authentication.....................................................153
basic configuration..............................................151
example configuration........................................159
overview.............................................................147
passive ARP learning..........................................158
preempting master router...................................155
trace operations..................................................157
tracking logical interface status...........................156
vrrp-group statement.................................................181
usage guidelines..................................................151
vrrp-inet6-group statement........................................182
usage guidelines..................................................151

Index ■ 189
JUNOS 8.5 High Availability Configuration Guide

190 ■ Index
Index of Commands and Statements

Symbols K
keepalive-time statement.............................................34

A
accept-data statement................................................163 M
advertise-interval statement.......................................164 maximum-helper-recovery-time statement................135
authentication-key statement.....................................165 maximum-helper-restart-time statement....................136
authentication-type statement....................................166 maximum-recovery-time statement...........................136

B N
bandwidth-threshold statement.................................167 no-accept-data statement...........................................171
no-auto-failover statement ..........................................34
no-preempt statement...............................................171
C no-strict-lsa-checking statement.................................137
cfeb statement.............................................................31 nonstop-bridging statement.........................................65
commit synchronize statement....................................81 nonstop-routing statement...........................................82
notify-duration statement...........................................137

D
description statement..................................................32 O
disable statement.......................................................133 on-disk-failure statement .............................................35
on-loss-of-keepalives statement ...................................35

F
failover statement .......................................................32 P
fast-interval statement...............................................168 preempt statement....................................................172
feb statement...............................................................33 priority statement......................................................173
priority-cost statement...............................................174
priority-hold-time statement......................................175
G
graceful-restart statement..........................................134
graceful-switchover statement......................................55 R
recovery-time statement............................................138
redundancy statement.................................................36
H redundancy-group statement.......................................37
helper-disable statement............................................135 restart-duration statement..........................................139
hold-time statement...................................................169 restart-time statement................................................140
routing-engine statement.............................................37

I
inet6-advertise-interval statement..............................170 S
interface statement....................................................171 sfm statement..............................................................38
ssb statement...............................................................38

Index of Commands and Statements ■ 191

JUNOS 8.5 High Availability Configuration Guide

stale-routes-time statement........................................141
startup-silent-period statement...................................175

T
traceoptions statement
graceful restart....................................................142
nonstop routing....................................................83
VRRP..................................................................176
track statement..........................................................178

V
virtual-address statement...........................................179
virtual-inet6-address statement..................................179
virtual-link-local-address statement............................180
vrrp-group statement.................................................181
vrrp-inet6-group statement........................................182

192 ■ Index of Commands and Statements