Juniper Networks 9.1 JUNOS Software Configuration Guide
Publicité
Publicité
JUNOS™ Software
High Availability Configuration Guide
Release 9.1
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Part Number: 530-024083-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 9.1
Copyright © 2008, Juniper Networks, Inc.
All rights reserved. Printed in USA.
Writing: Andrea Couvrey, Alan Twhigg
Editing: Ben Mann
Illustration: Nathaniel Woodward
Cover Design: Edmonds Design
Revision History
10 April 2008—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
Part 1
Part 2
Part 3
Overview
Chapter 1 High Availability Overview
Routing Engine and Switching Control Board Redundancy
Chapter 2 Routing Engine and Switching Control Board Redundancy Overview
Chapter 3 Routing Engine and Switching Control Board Redundancy Configuration
Chapter 4 Summary of Routing Engine and Control Board Switching Redundancy
Graceful Routing Engine Switchover
Chapter 5 Graceful Routing Engine Switchover Overview
Chapter 6 Graceful Routing Engine Switchover Configuration Guidelines
Chapter 7 Summary of Graceful Routing Engine Switchover Configuration
Part 4
Part 5
Nonstop Bridging
Chapter 8 Nonstop Bridging Overview
Chapter 9 Nonstop Bridging Configuration Guidelines
Chapter 10 Summary of Nonstop Bridging Statements
Nonstop Active Routing
Chapter 11 Nonstop Active Routing Overview
Chapter 12 Nonstop Active Routing Configuration Guidelines
Chapter 13 Summary of Nonstop Active Routing Configuration Statements
Part 6 Graceful Restart
Chapter 14 Graceful Restart Overview
Chapter 15 Graceful Restart Configuration Guidelines
Chapter 16 Summary of Graceful Restart Configuration Statements
Abbreviated Table of Contents
■ v
JUNOS 9.1 High Availability Configuration Guide
Part 7 Virtual Router Redundancy Protocol
Chapter 18 VRRP Configuration Guidelines
Chapter 19 Summary of VRRP Configuration Statements
Part 8
Part 9
Unified ISSU
Chapter 20 Unified ISSU Overview
Chapter 21 Unified ISSU Configuration Guidelines
Chapter 22 Unified ISSU Configuration Statements Summary
Index
Index of Statements and Commands
vi ■
Table of Contents
Using the Examples in This Manual ..............................................................xxi
Merging a Full Example ..........................................................................xxi
Part 1
Part 2
Overview
Graceful Routing Engine Switchover ................................................................3
Comparison of High Availability Features ........................................................6
Routing Engine and Switching Control Board Redundancy
Routing Engine and Switching Control Board Redundancy
Conditions That Trigger a Routing Engine Failover .................................12
Default Routing Engine Redundancy Behavior ........................................13
Table of Contents
■ vii
JUNOS 9.1 High Availability Configuration Guide
Routing Engine Redundancy on a TX Matrix Platform ............................14
Situations That Require You to Halt Routing Engines ..............................15
Switching Control Board Redundancy ...........................................................15
Redundant CFEBs on the M10i Router ....................................................16
Redundant FEBs on the M120 Router .....................................................16
Redundant SSBs on the M20 Router .......................................................18
Redundant SFMs on the M40e and M160 Routers ..................................19
Routing Engine and Switching Control Board Redundancy
Chassis Redundancy Hierarchy .....................................................................21
Copying a Configuration File from One Routing Engine to the Other ............23
Loading a Software Package from the Other Routing Engine .........................24
Configuring Routing Engine Redundancy ......................................................24
Modifying the Default Routing Engine Mastership ...................................25
Configuring Automatic Failover to the Backup Routing Engine ...............25
Without Interruption to Packet Forwarding ......................................25
On Detection of a Hard Disk Error on the Master Routing
Engine .......................................................................................25
On Detection of a Loss of Keepalive Signal from the Master Routing
Engine .......................................................................................26
When A Software Process Fails ........................................................26
Manually Switching Routing Engine Mastership ......................................27
Verifying Routing Engine Redundancy Status .........................................27
Configuring CFEB Redundancy on the M10i Router ......................................28
Configuring FEB Redundancy on the M120 Router ........................................30
Example: Configuring FEB Redundancy ..................................................30
Configuring SFM Redundancy on M40e and M160 Routers ...........................31
Configuring SSB Redundancy on the M20 Router ..........................................32
Summary of Routing Engine and Control Board Switching Redundancy
viii ■
Table of Contents
Table of Contents
Part 3
Part 4
Graceful Routing Engine Switchover
Graceful Routing Engine Switchover Overview 43
Graceful Routing Engine Switchover Concepts ..............................................43
Graceful Routing Engine Switchover System Requirements ...........................47
Graceful Routing Engine Switchover Platform Support ............................47
Graceful Routing Engine Switchover Feature Support .............................47
Graceful Routing Engine Switchover DPC Support ..................................48
Graceful Routing Engine Switchover PIC Support ....................................49
Graceful Routing Engine Switchover Configuration Guidelines 51
Configuring Graceful Routing Engine Switchover ...........................................51
Enabling Graceful Routing Engine Switchover .........................................51
Synchronizing the Routing Engine Configuration ....................................52
Verifying Graceful Routing Engine Switchover Operation ........................52
Requirements for Routers with a Backup Router Configuration .....................52
Summary of Graceful Routing Engine Switchover Configuration
Nonstop Bridging
Nonstop Bridging System Requirements .......................................................61
Nonstop Bridging Configuration Guidelines 63
Enabling Nonstop Bridging .....................................................................63
Synchronizing the Routing Engine Configuration ....................................63
Verifying Nonstop Bridging Operation ....................................................64
Table of Contents
■ ix
JUNOS 9.1 High Availability Configuration Guide
Part 5
Part 6
Nonstop Active Routing
Nonstop Active Routing Overview 69
Nonstop Active Routing Concepts .................................................................69
Nonstop Active Routing System Requirements ..............................................71
Nonstop Active Routing Platform Support ...............................................72
Nonstop Active Routing Protocol Support ...............................................72
Nonstop Active Routing BFD Support ......................................................73
Nonstop Active Routing Configuration Guidelines 75
Configuring Nonstop Active Routing ..............................................................75
Enabling Nonstop Active Routing ............................................................75
Synchronizing the Routing Engine Configuration ....................................76
Verifying Nonstop Active Routing Operation ...........................................76
Tracing Nonstop Active Routing Synchronization Events ...............................77
Example: Configuring Nonstop Active Routing ..............................................78
Summary of Nonstop Active Routing Configuration Statements 81
Graceful Restart
Graceful Restart System Requirements ..........................................................90
OSPF and OSPFv3 ..................................................................................92
x ■
Table of Contents
Table of Contents
Graceful Restart Configuration Guidelines 97
Configuring Aggregate and Static Route Graceful Restart ...............................97
Configuring Routing Protocols Graceful Restart .............................................97
Configuring Graceful Restart Globally ......................................................98
Configuring Graceful Restart Options for BGP .........................................98
Configuring Graceful Restart Options for ES-IS ........................................99
Configuring Graceful Restart Options for IS-IS .........................................99
Configuring Graceful Restart Options for OSPF and OSPFv3 .................100
Configuring Graceful Restart Options for RIP and RIPng .......................101
Configuring Graceful Restart Options for PIM Sparse Mode ..................101
Tracking Graceful Restart Events ..........................................................102
Configuring Graceful Restart for MPLS-Related Protocols .............................102
Configuring Graceful Restart Globally ....................................................103
Configuring Graceful Restart Options for RSVP, CCC, and TCC .............103
Configuring Graceful Restart Options for LDP .......................................104
Configuring VPN Graceful Restart ................................................................104
Configuring Graceful Restart Globally ....................................................105
Configuring Graceful Restart for the Routing Instance ...........................105
Configuring Logical Router Graceful Restart ................................................105
Configuring Graceful Restart Globally ....................................................106
Configuring Graceful Restart for a Routing Instance ..............................106
Verifying Graceful Restart Operation ...........................................................107
Graceful Restart Operational Mode Commands ....................................107
Verifying BGP Graceful Restart ..............................................................107
Verifying IS-IS and OSPF Graceful Restart .............................................108
Verifying CCC and TCC Graceful Restart ...............................................108
Example: Configuring Graceful Restart ........................................................109
maximum-helper-recovery-time ..................................................................137
maximum-helper-restart-time .....................................................................138
maximum-neighbor-reconnect-time ............................................................138
maximum-neighbor-recovery-time ..............................................................139
Table of Contents
■ xi
JUNOS 9.1 High Availability Configuration Guide
Part 7
xii ■
Table of Contents
Virtual Router Redundancy Protocol
VRRP Configuration Guidelines 151
VRRP Configuration Hierarchy ....................................................................151
VRRP for IPv6 Configuration Hierarchy .......................................................152
VRRP Trace and Startup Configuration Statements .....................................153
Configuring Basic VRRP Support .................................................................153
Configuring VRRP Authentication (IPv4 Only) .............................................155
Configuring the Advertisement Interval for the VRRP Master Router ...........156
Modifying the Advertisement Interval in Seconds .................................157
Modifying the Advertisement Interval in Milliseconds ...........................157
Configuring a Backup Router to Preempt the Master Router ........................158
Modifying the Preemption Hold-Time Value .........................................158
Configuring an Interface to Accept Packets Destined for the Virtual IP
Configuring a Logical Interface to Be Tracked ..............................................159
Configuring a Route to Be Tracked ..............................................................161
Configuring Passive ARP Learning for Backup VRRP Routers ......................162
Example: Configuring VRRP for IPv6 ...........................................................165
Example: Configuring VRRP Route Tracking ...............................................166
Table of Contents
Part 8
Unified ISSU
Unified ISSU System Requirements .............................................................198
Unified ISSU JUNOS Software Release Support .....................................198
Unified ISSU Platform Support ..............................................................199
Unified ISSU Protocol Support ...............................................................199
Unified ISSU Feature Support ................................................................199
Unified ISSU PIC Support ......................................................................200
PIC Considerations .........................................................................200
SONET/SDH PICs ............................................................................201
Fast Ethernet and Gigabit Ethernet PICs .........................................202
Channelized PICs ............................................................................203
Tunnel Services PICs ......................................................................203
ATM PICs ........................................................................................203
Unified ISSU Configuration Guidelines 205
Verify That the Master and Backup Routing Engines Are Running the
Same Software Version ..................................................................206
Back Up the Router's Software ..............................................................206
Verify That Graceful Routing Engine Switchover and Nonstop Active
Routing Are Configured ..................................................................207
Upgrading and Rebooting Both Routing Engines Automatically ............208
Upgrading Both Routing Engines and Rebooting the New Backup Routing
Engine Manually .............................................................................213
Upgrading and Rebooting Only One Routing Engine ............................218
Troubleshooting Unified ISSU Problems ......................................................221
Managing and Tracing BFD Sessions During Unified ISSU Procedures .........222
Unified ISSU Configuration Statements Summary 223
Table of Contents
■ xiii
JUNOS 9.1 High Availability Configuration Guide
Part 9 Index
Index of Statements and Commands ..........................................................235
xiv ■
Table of Contents
List of Figures
Figure 1: Preparing for a Graceful Routing Engine Switchover .......................45
Figure 2: Graceful Routing Engine Switchover Process ..................................46
Figure 3: Nonstop Bridging Architecture and the Switchover Preparation
Figure 4: Nonstop Bridging Architecture During a Switchover .......................61
Figure 5: Nonstop Active Routing and the Switchover Preparation
Figure 6: Nonstop Active Routing During a Switchover ..................................71
Figure 7: Layer 3 VPN Graceful Restart Topology ........................................109
List of Figures
■ xv
JUNOS 9.1 High Availability Configuration Guide xvi ■
List of Figures
List of Tables
Table 2: Text and Syntax Conventions ........................................................xxiii
Table 3: Technical Documentation for Supported Routing Platforms ..........xxiv
Table 4: JUNOS Software Network Operations Guides ................................xxix
Table 5: JUNOS Software with Enhanced Services Documentation .............xxix
Table 7: Comparison of High Availability Features ..........................................7
Table 8: Routing Engine Mastership Log ........................................................27
Table 9: Graceful Routing Engine Switchover Feature Support ......................47
Table 10: Interface State and Priority Cost Usage ........................................160
Table 11: Unified ISSU Supported SONET/SDH PICs ....................................201
Table 12: Unified ISSU Supported Fast Ethernet and Gigabit Ethernet
Table 13: Unified ISSU Supported Channelized PICs ....................................203
Table 14: Unified ISSU Supported Tunnel Services PICs ..............................203
Table 15: Unified ISSU Supported ATM PICs ................................................203
List of Tables
■ xvii
JUNOS 9.1 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:
■
■
■
■
■
■
■
■
■
Supported Routing Platforms on page xx
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 xxxii
Requesting Technical Support on page xxxii
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 9.1 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 9.1 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
EX-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 9.1 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
Informational note
Caution
Warning
Laser warning
Description
Indicates important features or instructions.
Indicates a situation that might result in loss of data or hardware damage.
Alerts you to the risk of personal injury or death.
Alerts you to the risk of personal injury from a laser.
Table 2 on page xxiii defines the text and syntax conventions used in this guide.
Table 2: Text and Syntax Conventions
Convention
Bold text like this
Fixed-width text like this
Italic text like this
Italic text like this
Plain text like this
< > (angle brackets)
Description
Represents text that you type.
Examples
To enter configuration mode, type the configure
command: user@host> configure
Represents output that appears on the terminal screen.
■
■
■
Introduces important new terms.
Identifies book names.
Identifies RFC and Internet draft titles.
user@host> show chassis alarms
No alarms currently active
■
■
■
A policy term is a named structure that defines match conditions and actions.
JUNOS System Basics Configuration
Guide
RFC 1997, BGP Communities
Attribute
Represents variables (options for which you substitute a value) in commands or configuration statements.
Configure the machine’s domain name:
[edit] root@# set system domain-name
domain-name
Represents names of configuration statements, commands, files, and directories; IP addresses; configuration hierarchy levels; or labels on routing platform components.
■
■
To configure a stub area, include the stub statement at the [edit protocols ospf area area-id] hierarchy level.
The console port is labeled
CONSOLE .
Enclose optional keywords or variables.
stub <default-metric metric>;
Documentation Conventions
■ xxiii
JUNOS 9.1 High Availability Configuration Guide
Table 2: Text and Syntax Conventions (continued)
Convention
| (pipe symbol)
# (pound sign)
[ ] (square brackets)
Indention and braces ( { } )
; (semicolon)
Description
Enclose a variable for which you can substitute one or more values.
Examples
Indicates a choice between the mutually exclusive keywords or variables on either side of the symbol. The set of choices is often enclosed in parentheses for clarity.
broadcast | multicast
(string1 | string2 | string3
)
Indicates a comment specified on the same line as the configuration statement to which it applies.
rsvp { # Required for dynamic MPLS only community name members [
community-ids ]
Identify a level in the configuration hierarchy.
Identifies a leaf statement at a configuration hierarchy level.
}
[edit] routing-options { static { route default { nexthop address; retain;
}
}
J-Web GUI Conventions
Bold text like this
> (bold right angle bracket)
Represents J-Web graphical user interface (GUI) items you click or select.
■
■
In the Logical Interfaces box, select
All Interfaces.
To cancel the configuration, click
Cancel.
Separates levels in a hierarchy of J-Web selections.
In the configuration editor hierarchy, 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
release notes supporting JUNOS software with enhanced services. All documents are available at http://www.juniper.net/techpubs/
.
Table 6 on page xxxi 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 xxiv ■
List of Technical Publications
About This Guide
Table 3: Technical Documentation for Supported Routing Platforms (continued)
Book
Access Privilege
Class of Service
CLI User Guide
Feature Guide
High Availability
MPLS Applications
Multicast Protocols
Multiplay Solutions
MX-series Solutions Guide
Network Interfaces
Network Management
Policy Framework
Description
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.
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.
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.
Provides a detailed explanation and configuration examples for several of the most complex features in the JUNOS software.
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 active routing (NSR) and graceful Routing Engine switchover (GRES).
Provides an overview of traffic engineering concepts and describes how to configure traffic engineering protocols.
Provides an overview of multicast concepts and describes how to configure multicast routing protocols.
Describes how you can deploy IPTV and voice over IP (VoIP) services in your network.
Describes common configuration scenarios for the Layer 2 features supported on the MX-series routers, including basic bridged VLANs with normalized VLAN tags, aggregated Ethernet links, bridge domains, Multiple Spanning Tree Protocol (MSTP), and integrated routing and bridging (IRB).
Provides an overview of the network interface functions of the
JUNOS software and describes how to configure the network interfaces on the routing platform.
Provides an overview of network management concepts and describes how to configure various network management features, such as SNMP and accounting options.
Provides an overview of policy concepts and describes how to configure routing policy, firewall filters, and forwarding options.
List of Technical Publications
■ xxv
JUNOS 9.1 High Availability Configuration Guide
Table 3: Technical Documentation for Supported Routing Platforms (continued)
Book
Protected System Domain
Routing Protocols
Secure Configuration Guide for Common Criteria and JUNOS-FIPS
Provides an overview of secure Common Criteria 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.
Software Installation and Upgrade Guide
System Basics
VPNs
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.
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.
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
Description
Provides an overview of the JCS 1200 platform and the concept of
Protected System Domains (PSDs). The JCS 1200 platform, which contains up to six redundant pairs of Routing Engines running
JUNOS software, is connected to a T320 router or to a T640 or
T1600 routing node. To configure a PSD, you assign any number of Flexible PIC concentrators (FPCs) in the T-series routing platform to a pair of Routing Engines on the JCS 1200 platform. Each PSD has the same capabilities and functionality as a physical router, with its own control plane, forwarding plane, and administration.
Provides an overview of routing concepts and describes how to configure routing, routing instances, and unicast routing protocols.
Interfaces Command Reference
Routing Protocols and Policies Command
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.
Describes the JUNOS software operational mode commands you use to monitor and troubleshoot interfaces.
Describes the JUNOS software operational mode commands you use to monitor and troubleshoot routing policies and protocols, including firewall filters.
xxvi ■
List of Technical Publications
About This Guide
Table 3: Technical Documentation for Supported Routing Platforms (continued)
Book Description
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
JUNOS XML API Configuration Reference
Describes how to use the JUNOScript application programming interface (API) to monitor and configure Juniper Networks routing platforms.
Provides reference pages for the configuration tag elements in the
JUNOS XML API.
JUNOS XML API Operational Reference
NETCONF API Guide
Provides reference pages for the operational tag elements in the
JUNOS XML API.
Describes how to use the NETCONF API to monitor and configure
Juniper Networks routing platforms.
JUNOS Configuration and Diagnostic Automation
Guide
Describes how to use the commit script and self-diagnosis features 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
PIC Guide
DPC Guide
Describes how to install, maintain, and troubleshoot routing platforms and components. Each platform has its own hardware guide.
Describes the routing platform's Physical Interface Cards (PICs).
Each platform has its own PIC 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.
List of Technical Publications
■ xxvii
JUNOS 9.1 High Availability Configuration Guide
Table 3: Technical Documentation for Supported Routing Platforms (continued)
Book Description
Advanced Insight Solutions (AIS) Documentation
Advanced Insight Solutions Guide
Describes the Advanced Insight Manager (AIM) application, which provides a gateway between JUNOS devices and Juniper Support
Systems (JSS) for case management and intelligence updates.
Explains how to run AI scripts on Juniper Networks devices.
J-series Routing Platform Documentation
Getting Started Guide
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
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.
Shows how to manage users and operations, monitor network performance, upgrade software, and diagnose common problems on J-series Services Routers.
Release Notes
JUNOS Release Notes
Hardware Release Notes
JUNOScope Release Notes
AIS Release Notes
AIS AI Script 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.
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.
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.
Summarize AIS new features and guidelines, identify known and resolved problems, provide information that might have been omitted from the manuals, and provide initial setup, upgrade, and downgrade procedures.
Summarize AI Scripts new features, identify known and resolved problems, provide information that might have been omitted from the manuals, and provide instructions for automatic and manual installation, including deleting and rolling back.
xxviii ■
List of Technical Publications
About This Guide
Table 3: Technical Documentation for Supported Routing Platforms (continued)
Book
J-series Services Router Release Notes
Description
Briefly describe Services Router features, identify known hardware problems, and provide upgrade and downgrade instructions.
Table 4: JUNOS Software Network Operations Guides
Book
Baseline
Interfaces
MPLS
MPLS Log Reference
MPLS Fast Reroute
Hardware
Description
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.
Describes tasks for monitoring interfaces. Tasks include using loopback testing and locating alarms.
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.
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.
Describes operational information helpful in monitoring and troubleshooting an MPLS network configured with fast reroute
(FRR) and load balancing.
Describes tasks for monitoring M-series and T-series routing platforms.
To configure and operate a J-series Services Router running JUNOS software with enhanced services, you must also use the configuration statements and operational mode commands documented in JUNOS configuration guides and command references. To configure and operate a WX Integrated Services Module, you must also use WX documentation.
Table 5: JUNOS Software with Enhanced Services Documentation
Book Description
JUNOS Software with Enhanced Services Design and Implementation Guide
Provides guidelines and examples for designing and implementing IP Security (IPSec) virtual private networks
(VPNs), firewalls, and routing on J-series routers running
JUNOS software with enhanced services.
List of Technical Publications
■ xxix
JUNOS 9.1 High Availability Configuration Guide
Table 5: JUNOS Software with Enhanced Services Documentation (continued)
Book Description
JUNOS Software with Enhanced Services J-series
Services Router Quick Start
Explains how to quickly set up a J-series router. This document contains router declarations of conformity.
JUNOS Software with Enhanced Services J-series
Services Router Getting Started Guide
Provides an overview, basic instructions, and specifications for J-series Services Routers. This guide explains how to prepare a site, unpack and install the router, replace router hardware, and establish basic router connectivity. This guide contains hardware descriptions and specifications.
JUNOS Software with Enhanced Services
Migration Guide
JUNOS Software with Enhanced Services
Interfaces and Routing Configuration Guide
Provides instructions for migrating an SSG device running
ScreenOS software or a J-series router running the JUNOS software to JUNOS software with enhanced services.
Explains how to configure J-series router interfaces for basic
IP routing with standard routing protocols, ISDN service, firewall filters (access control lists), and class-of-service (CoS) traffic classification.
JUNOS Software with Enhanced Services Security
Configuration Guide
Explains how to configure and manage security services such as stateful firewall policies, IPSec VPNs, firewall screens,
Network Address translation (NAT) and Router interface modes, Public Key Cryptography, and Application Layer
Gateways (ALGs).
JUNOS Software with Enhanced Services
Administration Guide
Shows how to monitor the router and routing operations, firewall and security services, system alarms and events, and network performance. This guide also shows how to administer user authentication and access, upgrade software, and diagnose common problems.
JUNOS Software with Enhanced Services CLI
Reference
Provides the complete JUNOS software with enhanced services configuration hierarchy and describes the configuration statements and operational mode commands not documented in the standard JUNOS manuals.
WXC Integrated Services Module Installation and
Configuration Guide
Explains how to install and initially configure a WXC
Integrated Services Module in a J-series router for application acceleration.
JUNOS Software with Enhanced Services Release
Notes
Summarize new features and known problems for a particular release of JUNOS software with enhanced services on J-series routers, including J-Web interface features and problems. The release notes also contain corrections and updates to the manuals and software upgrade and downgrade instructions for JUNOS software with enhanced services.
xxx ■
List of Technical Publications
About This Guide
Table 6: Additional Books Available Through http://www.juniper.net/books
Book Description
Interdomain Multicast
Routing
JUNOS Cookbook
Provides background and in-depth analysis of multicast routing using Protocol Independent
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.
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
IGP for Large-Scale Networks
Explores the full range of characteristics and capabilities for the two major link-state routing 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 for Multivendor IP Networks
Provides a brief history of the Internet, explains IP addressing and routing (Routing Information
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
■ xxxi
JUNOS 9.1 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 [email protected]
, 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 (not required for Network Operations Guides [NOGs])
Requesting Technical Support
Technical product support is available through the Juniper Networks Technical
Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC support contract, or are covered under warranty, and need postsales technical support, you can access our tools and resources online or open a case with JTAC.
■
■
JTAC policies—For a complete understanding of our JTAC procedures and policies, review the JTAC User Guide located at http://www.juniper.net/customers/support/downloads/710059.pdf
.
Product warranties—For product warranty information, visit http://www.juniper.net/support/warranty/
.
■
JTAC Hours of Operation —The JTAC centers have resources available 24 hours a day, 7 days a week, 365 days a year.
Self-Help Online Tools and Resources
For quick and easy problem resolution, Juniper Networks has designed an online self-service portal called the Customer Support Center (CSC) that provides you with the following features:
■
Find CSC offerings: http://www.juniper.net/customers/support/
■
■
■
Search for known bugs: http://www2.juniper.net/kb/
Find product documentation: http://www.juniper.net/techpubs/
Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/
■
■
Download the latest versions of software and review release notes: http://www.juniper.net/customers/csc/software/
Search technical bulletins for relevant hardware and software notifications: https://www.juniper.net/alerts/
■
■
Join and participate in the Juniper Networks Community Forum: http://www.juniper.net/company/communities/
Open a case online in the CSC Case Manager: http://www.juniper.net/cm/ xxxii ■
Documentation Feedback
About This Guide
To verify service entitlement by product serial number, use our Serial Number
Entitlement (SNE) Tool located at https://tools.juniper.net/SerialNumberEntitlementSearch/
.
Opening a Case with JTAC
You can open a case with JTAC on the Web or by telephone.
■
Use the Case Manager tool in the CSC at http://www.juniper.net/cm/
.
■
Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).
For international or direct-dial options in countries without toll-free numbers, visit us at
http://www.juniper.net/support/requesting-support.html
.
Requesting Technical Support
■ xxxiii
JUNOS 9.1 High Availability Configuration Guide xxxiv ■
Requesting Technical Support
Part 1
Overview
■
High Availability Overview on page 3
Overview
■ 1
JUNOS 9.1 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 Active Routing on page 4
Comparison of High Availability Features on page 6
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 active routing. For more information, see “Graceful Routing Engine
Switchover Overview” on page 43.
Routing Engine Redundancy
■ 3
JUNOS 9.1 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 Active Routing
Nonstop active 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 active routing uses the same infrastructure as graceful Routing Engine switchover to preserve interface and kernel information. However, nonstop active routing also preserves routing information and protocol sessions by running the routing protocol process (rpd) on both Routing
Engines. In addition, nonstop active routing preserves TCP connections maintained in the kernel.
NOTE: To use nonstop active routing, you must also configure graceful Routing Engine switchover.
Nonstop active routing is supported 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
Routing Information Protocol (RIP) and RIP next generation (RIPng)
Routing protocols use bidirectional forwarding detection (BFD) for fast liveliness detection of their neighbors. With nonstop active routing enabled, BFD session state is saved on both the master Routing Engine and the backup Routing Engine. When
4 ■
Nonstop Bridging
Chapter 1: High Availability Overview 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.
For more information, see “Nonstop Active 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 89.
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 9.1 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 149.
Unified ISSU
A unified in-service software upgrade (unified ISSU) enables you to upgrade between two different JUNOS software releases with no disruption on the control plane and with minimal disruption of traffic. Unified ISSUs are only supported by dual Routing
Engine platforms. In addition, the graceful Routing Engine switchover (GRES) and nonstop active routing (NSR) must be enabled.
With a unified ISSU, you can eliminate network downtime, reduce operating costs,
and deliver higher services levels. For more information, see “Unified ISSU
Comparison of High Availability Features
Table 7 on page 7 provides a comparison of high availability features. Remember
that:
■
■
Graceful Routing Engine switchover, nonstop bridging, nonstop active routing, and unified ISSUs require dual Routing Engines.
Nonstop bridging, nonstop active routing, and unified ISSUs require graceful
Routing Engine switchover to be configured.
NOTE: Graceful restart helper mode is enabled by default, except for BGP. In helper mode, a neighboring router assists in a restart. Helper mode is not sustained during a graceful Routing Engine switchover (GRES) event.
A router can both act as a graceful restart helper and be configured to support nonstop active routing. However, you cannot configure graceful restart and nonstop active routing at the same time at the [edit routing-options] hierarchy level (with the graceful-restart statement and the nonstop-routing statement, respectively).
To configure BGP helper mode support, you must include the graceful-restart statement at the [edit routing-options] hierarchy level. Again, you cannot configure the router to undergo a graceful restart and to support nonstop active routing at the same time.
Therefore, when nonstop active routing is enabled, BGP cannot provide graceful restart helper support.
6 ■
Unified ISSU
Chapter 1: High Availability Overview
Table 7: Comparison of High Availability Features
Feature
Dual Routing Engines without graceful
Routing Engine switchover
Graceful Routing Engine switchover
Nonstop bridging
Nonstop active routing
Graceful restart
VRRP
Unified ISSUs
Benefits Considerations
When the switchover to the new master
Routing Engine is complete, routing convergence takes place and traffic is resumed.
Traffic is interrupted while the Packet
Forwarding Engine is reinitialized. All kernel and forwarding processes are restarted.
Traffic is not interrupted during the switchover. Interface and kernel information is preserved.
Graceful restart or nonstop active routing must be configured in order to quickly restore or to preserve routing information, respectively.
Traffic is not interrupted during the switchover. Interface, kernel, and Layer
2 control protocol information is preserved.
Nonstop bridging can be used in conjunction with nonstop active routing.
Traffic is not interrupted during the switchover. Interface, kernel, and routing protocol information is preserved.
Neighbors are not required to have any special configuration.
Unsupported protocols must be refreshed using the normal recovery mechanisms inherent in each protocol.
Traffic is not interrupted during the switchover. Interface and kernel information is preserved. Graceful restart protocol extensions quickly collect and restore routing information from the neighboring routers.
Neighbors are required to support graceful restart. The routing protocol process (rpd) restarts. A graceful restart interval is required. For certain protocols, a significant change in the network can cause graceful restart to stop.
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.
—
Upgrade between two different JUNOS software releases with no disruption on the control plane and with minimal disruption of traffic.
—
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
Related Features
■ 7
JUNOS 9.1 High Availability Configuration Guide
■
■
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.
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
Summary of Routing Engine and Control Board Switching Redundancy
Routing Engine and Switching Control Board Redundancy
■ 9
JUNOS 9.1 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 15
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: 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.
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.
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 master, it resets the switch plane and downloads its own version of the microkernel
Routing Engine Redundancy
■ 11
JUNOS 9.1 High Availability Configuration Guide to the Packet Forwarding Engine components. For more information about graceful
Routing Engine switchover, see “Graceful Routing Engine Switchover
If nonstop active routing is configured, the backup Routing Engine receives routing messages, but does not send them to the network. If nonstop active routing is not configured, the backup Routing Engine does not maintain routing tables. For more
information about nonstop active routing, see “Nonstop Active Routing
For more information about Routing Engine redundancy, see the following sections:
■
■
■
■
■
Conditions That Trigger a Routing Engine Failover on page 12
Default Routing Engine Redundancy Behavior on page 13
Routing Engine Redundancy on a TX Matrix Platform on page 14
Situations That Require You to Halt Routing Engines on page 15
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, M320, and T320 routers and T640 and T1600 routing nodes—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.
Conditions That Trigger a Routing Engine Failover
The following events can result in an automatic change in Routing Engine mastership, depending on your configuration:
12 ■
Routing Engine Redundancy
Chapter 2: Routing Engine and Switching Control Board Redundancy Overview
■
■
■
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 failover on-disk-failure
statement at the [edit chassis redundancy] 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 failover on-loss-of-keepalives
statement at the
[edit chassis redundancy] 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 other-routing-engine 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. By default, 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.
2.
Ensure that re0 is the master Routing Engine.
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.
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 .
Routing Engine Redundancy
■ 13
JUNOS 9.1 High Availability Configuration Guide
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.
Routing Engine Redundancy 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 failover on-loss-of-keepalives
statement is included at the
[edit chassis redundancy]
hierarchy level:
■
■
■
When the failover on-loss-of-keepalives
statement is included at the
[edit chassis redundancy] 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 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 failover on-loss-of-keepalives
statement is not included at the
[edit chassis redundancy]
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.
14 ■
Routing Engine Redundancy
Chapter 2: Routing Engine and Switching Control Board Redundancy Overview
■
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.
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 16
Redundant FEBs on the M120 Router on page 16
Redundant SSBs on the M20 Router on page 18
Redundant SFMs on the M40e and M160 Routers on page 19
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.
Switching Control Board Redundancy
■ 15
JUNOS 9.1 High Availability Configuration Guide
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.
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.
16 ■
Switching Control Board Redundancy
Chapter 2: Routing Engine and Switching Control Board Redundancy Overview
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.
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.
Switching Control Board Redundancy
■ 17
JUNOS 9.1 High Availability Configuration Guide
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.
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.
18 ■
Switching Control Board Redundancy
Chapter 2: Routing Engine and Switching Control Board Redundancy Overview
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.
Switching Control Board Redundancy
■ 19
JUNOS 9.1 High Availability Configuration Guide
20 ■
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 21
Initial Routing Engine Configuration on page 22
Copying a Configuration File from One Routing Engine to the Other on page 23
Loading a Software Package from the Other Routing Engine on page 24
Configuring Routing Engine Redundancy on page 24
Configuring CFEB Redundancy on the M10i Router on page 28
Configuring FEB Redundancy on the M120 Router on page 30
Configuring SFM Redundancy on M40e and M160 Routers on page 31
Configuring SSB Redundancy on the M20 Router on page 32
Chassis Redundancy Hierarchy
To configure chassis redundancy, include the following statements at the
[edit chassis] hierarchy level:
}
cfeb slot (always | preferred);
failover on-loss-of-keepalives;
feb slot-number (backup | primary);
description description;
}
}
routing-engine slot-number (master | backup | disabled);
sfm slot-number (always | preferred); ssb slot-number (always | preferred);
Chassis Redundancy Hierarchy
■ 21
JUNOS 9.1 High Availability Configuration Guide
Initial Routing Engine Configuration
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.
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;
}
}
}
NOTE: You can assign an additional IP address to the fxp0 (management) interface on both Routing Engines. The assigned address uses the master-only
keyword and is identical for both Routing Engines, ensuring that the IP address for the master Routing
Engine can be accessed at any time. The address is active only on the master Routing
Engine's fxp0 (management) interface. During a Routing Engine switchover, the address moves over to the new master Routing Engine.
For example, on re0
, the configuration would be:
[edit groups re0 interfaces fxp0]
22 ■
Initial Routing Engine Configuration
Chapter 3: Routing Engine and Switching Control Board Redundancy Configuration Guidelines
} unit 0 { family inet { address 10.17.40.131/25 { master-only;
} address 10.17.40.132/25;
}
On re1 , the configuration would be:
}
[edit groups re1 interfaces fxp0] unit 0 { family inet { address 10.17.40.131/25 { master-only;
} address 10.17.40.133/25;
}
For more information about the initial configuration of dual Routing Engines, see the JUNOS Software Installation and Upgrade Guide. For more information about assigning an additional IP address to the fxp0 (management) interface with the master-only keyword on both Routing Engines, see the JUNOS CLI User Guide.
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
Copying a Configuration File from One Routing Engine to the Other
■ 23
JUNOS 9.1 High Availability Configuration Guide 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.
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
.
Configuring Routing Engine Redundancy
The following sections describe how to configure Routing Engine redundancy:
■
■
■
■
Modifying the Default Routing Engine Mastership on page 25
Configuring Automatic Failover to the Backup Routing Engine on page 25
Manually Switching Routing Engine Mastership on page 27
Verifying Routing Engine Redundancy Status on page 27
NOTE: To complete the tasks in the following sections, re0
and re1
configuration groups must be defined. For more information about configuration groups, see the
JUNOS CLI User Guide.
24 ■
Loading a Software Package from the Other Routing Engine
Chapter 3: Routing Engine and Switching Control Board Redundancy Configuration Guidelines
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.
Configuring Automatic Failover to the Backup Routing Engine
The following sections describe how to configure automatic failover to the backup
Routing Engine when certain failures occur on the master 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. For information about
how to configure graceful Routing Engine switchover, see “Graceful Routing Engine
Switchover Configuration Guidelines” on page 51.
On Detection of 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 failover on-disk-failure
statement at the
[edit chassis redundancy] hierarchy level.
[edit chassis redundancy]
Configuring Routing Engine Redundancy
■ 25
JUNOS 9.1 High Availability Configuration Guide
On Detection of a Loss of Keepalive Signal from the Master Routing Engine
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.
To enable failover on receiving a loss of keepalive signal, include the failover on-loss-of-keepalives statement at the [edit chassis redundancy] hierarchy level:
[edit chassis redundancy]
failover on-loss-of-keepalives;
When graceful Routing Engine switchover is not configured, 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]
The range for keepalive-time is 2 through 10,000 seconds.
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.
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.
2.
Manually configure a keepalive-time of 25 seconds.
After the Packet Forwarding Engine connection to the primary Routing Engine is lost and the keepalive timer expires, packet forwarding is interrupted.
3.
4.
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.
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.
When A Software Process Fails
To configure automatic switchover to the backup Routing Engine if a software process fails, include the failover other-routing-engine statement at the [edit system processes
process-name]
hierarchy level:
26 ■
Configuring Routing Engine Redundancy
Chapter 3: Routing Engine and Switching Control Board Redundancy Configuration Guidelines
[edit system processes] process-name
failover other-routing-engine;
process-name is one of the valid process names. If this statement is configured for a process, and that process fails four times within 30 seconds, the router reboots from the other Routing Engine. Another statement available at the
[edit system processes] hierarchy level is failover alternate-media
. For information about the alternate media option, see the JUNOS System Basics Configuration Guide.
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
lists the mastership log event codes and descriptions.
Event Code
E_NULL = 0
E_CFG_M
E_CFG_B
E_CFG_D
E_MAXTRY
E_REQ_C
E_ACK_C
E_NAK_C
E_REQ_Y
E_ACK_Y
E_NAK_Y
Table 8: Routing Engine Mastership Log
Description
The event is a null event.
The Routing Engine is configured as master.
The Routing Engine is configured as backup.
The Routing Engine is configured as disabled.
The maximum number of tries to acquire or release mastership was exceeded.
A claim mastership request was sent.
A claim mastership acknowledgement was received.
A claim mastership request was not acknowledged.
Confirmation of mastership is requested.
Mastership is acknowledged.
Mastership is not acknowledged.
Configuring Routing Engine Redundancy
■ 27
JUNOS 9.1 High Availability Configuration Guide
Table 8: Routing Engine Mastership Log (continued)
Event Code
E_REQ_G
E_ACK_G
E_CMD_A
E_CMD_F
E_CMD_R
E_CMD_S
E_NO_ORE
E_TMOUT
E_NO_IPC
E_ORE_M
E_ORE_B
E_ORE_D
Description
A release mastership request was sent by a Routing Engine.
The Routing Engine acknowledged release of mastership.
The command request chassis routing-engine master acquire was issued from the backup
Routing Engine.
The command request chassis routing-engine master acquire force was issued from the backup Routing Engine.
The command request chassis routing-engine master release was issued from the master
Routing Engine.
The command request chassis routing-engine master switch was issued from a Routing
Engine.
No other Routing Engine is detected.
A request timed out.
Routing Engine connection was lost.
Other Routing Engine state was changed to master.
Other Routing Engine state was changed to backup.
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 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.
28 ■
Configuring CFEB Redundancy on the M10i Router
Chapter 3: Routing Engine and Switching Control Board Redundancy Configuration Guidelines
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
■ 29
JUNOS 9.1 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:
}
feb slot-number (backup | primary);
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:
30 ■
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
■ 31
JUNOS 9.1 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.
32 ■
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
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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 28.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
cfeb
■ 33
JUNOS 9.1 High Availability Configuration Guide
description
Syntax description description;
Hierarchy Level [edit chassis redundancy feb redundancy redundancy-group name]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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 30
Required Privilege Level view-level—To view this statement in the configuration.
control-level—To add this statement to the configuration.
failover on-disk-failure
Syntax failover on-disk-failure;
Hierarchy Level
[edit chassis redundancy]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
Instruct the backup router to take mastership if it detects hard disk errors on the master Routing Engine.
Usage Guidelines
See “On Detection of a Hard Disk Error on the Master Routing Engine” on page 25.
Required Privilege Level view-level—To view this statement in the configuration.
control-level—To add this statement to the configuration.
34 ■ description
Chapter 4: Summary of Routing Engine and Control Board Switching Redundancy Statements
failover on-loss-of-keepalives
Syntax failover on-loss-of-keepalives;
Hierarchy Level [edit chassis redundancy]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
Instruct the backup router to take mastership if it detects a loss of keepalive signal from the master Routing Engine.
Default
If the failover on-loss-of-keepalives statement at the [edit chassis redundancy] hierarchy level is not included and graceful Routing Engine switchover (GRES) is not enabled, failover cannot occur.
When the failover on-loss-of-keepalives statement is included and graceful Routing
Engine switchover is not configured, failover occurs after 300 seconds (5 minutes).
When the failover 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 “On Detection of a Loss of Keepalive Signal from the Master Routing
Required Privilege Level
Related Topics view-level—To view this statement in the configuration.
control-level—To add this statement to the configuration.
failover on-loss-of-keepalives
■ 35
JUNOS 9.1 High Availability Configuration Guide
failover other-routing-engine
Syntax failover other-routing-engine;
Hierarchy Level [edit system processes process-name]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
Configure automatic switchover to the backup Routing Engine if a software process fails. If this statement is configured for a process, and that process fails four times within 30 seconds, the router reboots from the backup Routing Engine.
Options
process-name
—One of the valid software process names. A few examples are disk-monitoring , ethernet-link-fault-management , kernel-replication , redundancy-interface-process , and vrrp .
Usage Guidelines
See “When A Software Process Fails” on page 26.
Required Privilege Level
Related Topics view-level—To view this statement in the configuration.
control-level—To add this statement to the configuration.
For information about the failover alternate-media configuration statement at the [edit system processes process-name] hierarchy level, see the JUNOS System Basics
Configuration Guide.
feb
Syntax
} feb { redundancy-group group-name { description description; feb slot-number (backup | primary); no-auto-failover;
}
Hierarchy Level
Release Information
Description
Statement introduced in JUNOS Release 8.2.
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 30.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
36 ■ failover other-routing-engine
Chapter 4: Summary of Routing Engine and Control Board Switching Redundancy Statements
keepalive-time
Syntax keepalive-time seconds;
Hierarchy Level
Release Information
Description
Statement introduced before JUNOS Release 7.4.
Configure the time period that must elapse before the backup router takes mastership when it detects loss of the keepalive signal.
Default
If the failover on-loss-of-keepalives statement at the [edit chassis redundancy] hierarchy level is not included and graceful Routing Engine switchover (GRES) is not enabled, failover cannot occur.
When the failover on-loss-of-keepalives statement is included and graceful Routing
Engine switchover is not configured, failover occurs after 300 seconds (5 minutes).
When the failover 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 “On Detection of a Loss of Keepalive Signal from the Master Routing
Required Privilege Level
Related Topics interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
failover on-loss-of-keepalives
no-auto-failover
Syntax no-auto-failover;
Hierarchy Level
[edit chassis redundancy feb redundancy-group group-name]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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 30.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
keepalive-time
■ 37
JUNOS 9.1 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-loss-of-keepalives;
routing-engine slot-number (backup | disabled | master);
sfm slot-number (always | preferred); ssb slot-number (always | preferred);
Hierarchy Level [edit chassis]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
38 ■ 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
Release Information
Description
Statement introduced in JUNOS Release 8.2.
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 30.
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
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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 24.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
redundancy-group
■ 39
JUNOS 9.1 High Availability Configuration Guide
sfm
Syntax sfm slot-number (always | preferred);
Hierarchy Level
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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 31.
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
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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 32.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
40 ■ sfm
Part 3
Graceful Routing Engine Switchover
■
■
■
Graceful Routing Engine Switchover Overview on page 43
Graceful Routing Engine Switchover Configuration Guidelines on page 51
Summary of Graceful Routing Engine Switchover Configuration
Graceful Routing Engine Switchover
■ 41
JUNOS 9.1 High Availability Configuration Guide
42 ■
Graceful Routing Engine Switchover
Chapter 5
Graceful Routing Engine Switchover
Overview
This chapter contains the following sections:
■
■
Graceful Routing Engine Switchover Concepts on page 43
Graceful Routing Engine Switchover System Requirements on page 47
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 active routing (NSR), respectively. For more information about
graceful restart, see “Graceful Restart Overview” on page 89. For more information
about nonstop active routing, see “Nonstop Active 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.
Graceful Routing Engine Switchover Concepts
■ 43
JUNOS 9.1 High Availability Configuration Guide
NOTE: Successive graceful Routing Engine switchover events must be a minimum of 5 minutes apart after both Routing Engines have come up.
If the router displays a warning message similar to “Standby Routing Engine is not ready for graceful switchover. Packet Forwarding Engines that are not ready for graceful switchover might be reset,” do not attempt switchover. If you choose to proceed with switchover, only the Packet Forwarding Engines that were not ready for graceful switchover are reset. None of the FPCs should spontaneously restart. We recommend that you wait until the warning no longer appears and then proceed with the switchover.
44 ■
Graceful Routing Engine Switchover Concepts
Chapter 5: Graceful Routing Engine Switchover Overview
Figure 1 on page 45 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
5.
6.
3.
4.
1.
2.
The switchover preparation process for graceful Routing Engine switchover follows these steps:
The master Routing Engine starts.
The routing platform processes (such as the chassis process [chassisd]) start.
The Packet Forwarding Engine starts and connects to the master Routing Engine.
All state information is updated in the system.
7.
8.
The backup Routing Engine starts.
The system determines whether graceful Routing Engine switchover has been enabled.
The kernel synchronization process (ksyncd) synchronizes the backup Routing
Engine with the master Routing Engine.
All state information is updated in the system.
Graceful Routing Engine Switchover Concepts
■ 45
JUNOS 9.1 High Availability Configuration Guide
Figure 2 on page 46 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.
2.
When keepalives from the master Routing Engine are lost, the system switches over gracefully to the backup Routing Engine.
The Packet Forwarding Engine connects to the backup Routing Engine, which becomes the new master.
3.
4.
5.
Routing platform processes that are not part of graceful Routing Engine switchover
(such as the routing protocol process [rpd]) restart.
State information learned from the point of the switchover is updated in the system.
If configured, graceful restart protocol extensions collect and restore routing information from neighboring peer helper routers.
46 ■
Graceful Routing Engine Switchover Concepts
Chapter 5: Graceful Routing Engine Switchover Overview
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 47
Graceful Routing Engine Switchover Feature Support on page 47
Graceful Routing Engine Switchover DPC Support on page 48
Graceful Routing Engine Switchover PIC Support on page 49
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
T320 router, T640 routing node, and TX Matrix platform—JUNOS Release 7.0
or later
M120 router—JUNOS Release 8.2 or later
MX960 Ethernet Services router—JUNOS Release 8.3 or later
MX480 Ethernet Services router—JUNOS Release 8.4 or later (8.4R2
recommended)
MX240 Ethernet Services router—JUNOS Release 9.0 or later
T1600 routing node—JUNOS Release 8.5 or later
For more information about support for graceful Routing Engine switchover, see the sections that follow.
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 9 on page 47.
Table 9: Graceful Routing Engine Switchover Feature Support
Application
Aggregated Ethernet interfaces with Link Aggregation Control Protocol
(LACP) and aggregated SONET interfaces
Asynchronous Transfer Mode (ATM) virtual circuits (VCs)
JUNOS Release
6.2
6.2
Graceful Routing Engine Switchover System Requirements
■ 47
JUNOS 9.1 High Availability Configuration Guide
Table 9: Graceful Routing Engine Switchover Feature Support (continued)
Application
Logical routers
Multicast
Multilink Point-to-Point Protocol (MLPPP) and Multilink Frame Relay (MLFR) 7.0
Automatic Protection Switching (APS)—The current active interface (either the designated working or the designated protect interface) remains the active interface during a Routing Engine switchover.
7.4
Point-to-multipoint Multiprotocol Label Switching MPLS LSPs (transit only) 7.4
Compressed Real-Time Transport Protocol (CRTP) 7.6
JUNOS Release
6.3
6.4 (7.0 for TX
Matrix)
Virtual private LAN service (VPLS) 8.2
Ethernet Operation, Administration, and Management (OAM) as defined by IEEE 802.3ah
Extended DHCP relay agent
8.5
8.5
Ethernet OAM as defined by IEEE 802.1ag
9.0
Packet Gateway Control Protocol (PGCP) process (pgcpd) on MultiServices
500 PICs on T640 routers.
9.0
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.
VRRP changes mastership when a Routing Engine switchover occurs, even when graceful Routing Engine switchover is configured.
■
The extended DHCP local server does not support graceful Routing Engine switchover. Address-assignment pools do not support graceful Routing Engine switchover. For more information, see the JUNOS System Basics Configuration
Guide.
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.
For more information about DPCs, see the MX-series Ethernet Services Router DPC
Guide.
48 ■
Graceful Routing Engine Switchover System Requirements
Chapter 5: Graceful Routing Engine Switchover Overview
Graceful Routing Engine Switchover PIC Support
Graceful Routing Engine switchover is supported on most PICs, except for the services
PICs listed in this section. The PIC must be on a supported routing platform running the appropriate version of JUNOS software. For information about FPC types, FPC/PIC compatibility, and the initial JUNOS software release in which an FPC supported a particular PIC, see the PIC guide for your router platform.
The following constraints apply to graceful Routing Engine switchover support for services PICs:
■
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 does 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.
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.
Graceful Routing Engine Switchover System Requirements
■ 49
JUNOS 9.1 High Availability Configuration Guide
50 ■
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 51
Requirements for Routers with a Backup Router Configuration on page 52
Resetting Local Statistics on page 53
Configuring Graceful Routing Engine Switchover
This section contains the following topics:
■
■
■
Enabling Graceful Routing Engine Switchover on page 51
Synchronizing the Routing Engine Configuration on page 52
Verifying Graceful Routing Engine Switchover Operation on page 52
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]
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
■ 51
JUNOS 9.1 High Availability Configuration Guide
Synchronizing the Routing Engine Configuration
NOTE: 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, on the backup
Routing Engine, 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. The status of the kernel database and configuration database synchronization between Routing Engines is also provided. For example:
Graceful switchover: On
Configuration database: Ready
Kernel database: Ready
Peer state: Synchronization completed
NOTE: You must issue the show system switchover command on the backup Routing
Engine. This command is not supported on the master Routing Engine.
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.
52 ■
Requirements for Routers with a Backup Router Configuration
Chapter 6: Graceful Routing Engine Switchover Configuration Guidelines
NOTE: If you have a configuration in which multiple static routes point to a gateway from fxp0
, you must either configure prefixes that are more specific than the static routes or include the retain
flag at the
[edit routing-options static route]
hierarchy level.
For example, if you configure the static route 172.16.0.0/12 from fxp0
for management purposes, you must specify the backup router configuration as follows: backup-router 172.29.201.62 destination [172.16.0.0/13 172.16.128.0/13]
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.
Resetting Local Statistics
■ 53
JUNOS 9.1 High Availability Configuration Guide
54 ■
Resetting Local Statistics
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
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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 51.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
graceful-switchover
■ 55
JUNOS 9.1 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 9.1 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 43.
Nonstop Bridging Concepts
■ 59
JUNOS 9.1 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.
4.
5.
6.
7.
8.
The Packet Forwarding Engine starts and connects to the master Routing Engine.
All state information is updated in the system.
The backup Routing Engine starts, including the chassis process (chassisd) and the Layer 2 Control Protocol process (l2cpd).
The system determines whether graceful Routing Engine switchover and nonstop bridging have been enabled.
The kernel synchronization process (ksyncd) synchronizes the backup Routing
Engine with the master Routing Engine.
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.
3.
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.
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
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 9.1 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]
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]
To disable nonstop active 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 9.1 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
Description
Statement introduced in JUNOS Release 8.4.
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 9.1 High Availability Configuration Guide
66 ■ nonstop-bridging
Part 5
Nonstop Active Routing
■
■
■
Nonstop Active Routing Overview on page 69
Nonstop Active Routing Configuration Guidelines on page 75
Summary of Nonstop Active Routing Configuration Statements on page 81
Nonstop Active Routing
■ 67
JUNOS 9.1 High Availability Configuration Guide
68 ■
Nonstop Active Routing
Chapter 11
Nonstop Active Routing Overview
This chapter contains the following information:
■
■
Nonstop Active Routing Concepts on page 69
Nonstop Active Routing System Requirements on page 71
Nonstop Active Routing Concepts
Nonstop active routing (NSR) uses the same infrastructure as graceful Routing Engine switchover (GRES) to preserve interface and kernel information. However, nonstop active routing also saves routing protocol information by running the routing protocol process (rpd) on the backup Routing Engine. By saving this additional information, nonstop active routing is self-contained and does not rely on helper routers to assist the routing platform in restoring routing protocol information. Nonstop active routing is advantageous in networks where neighbor routers do not support graceful restart protocol extensions. As a result of this enhanced functionality, nonstop active routing is a natural replacement for graceful restart.
NOTE: Graceful restart helper mode is enabled by default, except for BGP. In helper mode, a neighboring router assists in a restart. Helper mode is not sustained during a graceful Routing Engine switchover (GRES) event.
A router can both act as a graceful restart helper and be configured to support nonstop active routing. However, you cannot configure graceful restart and nonstop active routing at the same time at the
[edit routing-options]
hierarchy level (with the graceful-restart statement and the nonstop-routing statement, respectively).
To configure BGP helper mode support, you must include the graceful-restart
statement at the [edit routing-options] hierarchy level. Again, you cannot configure the router to undergo a graceful restart and to support nonstop active routing at the same time.
Therefore, when nonstop active routing is enabled, BGP cannot provide graceful restart helper support.
NOTE: To use nonstop active 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 43.
Nonstop Active Routing Concepts
■ 69
JUNOS 9.1 High Availability Configuration Guide
Figure 5 on page 70 shows the system architecture of nonstop active routing and
the process a routing platform follows to prepare for a switchover.
Figure 5: Nonstop Active Routing and the Switchover Preparation Process
The switchover preparation process for nonstop active 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.
4.
5.
6.
7.
8.
The Packet Forwarding Engine starts and connects to the master Routing Engine.
All state information is updated in the system.
The backup Routing Engine starts, including the chassis process (chassisd) and the routing protocol process (rpd).
The system determines whether graceful Routing Engine switchover and nonstop active routing have been enabled.
The kernel synchronization process (ksyncd) synchronizes the backup Routing
Engine with the master Routing Engine.
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 Active Routing Concepts
Chapter 11: Nonstop Active Routing Overview
Figure 6: Nonstop Active Routing 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.
3.
4.
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.
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.
Peer routers continue to interact with the routing platform as if no change had occurred. Routing adjacencies and session state relying on underlying routing information are preserved and not reset.
Nonstop Active Routing System Requirements
This section contains the following topics:
■
■
■
Nonstop Active Routing Platform Support on page 72
Nonstop Active Routing Protocol Support on page 72
Nonstop Active Routing BFD Support on page 73
Nonstop Active Routing System Requirements
■ 71
JUNOS 9.1 High Availability Configuration Guide
Nonstop Active Routing Platform Support
Nonstop active 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
■
■
■
■
■
M120 router—JUNOS 9.0 or later
M320 router—JUNOS 8.4 or later
MX-series Ethernet Services routers—JUNOS 9.0 or later
T320 router, T640 routing node, and TX Matrix platform—JUNOS 8.4 or later
T1600 routing node—JUNOS 8.5 or later
NOTE: All Routing Engines configured for nonstop active routing must be running the same JUNOS software release.
Nonstop Active Routing Protocol Support
Nonstop active routing is supported for aggregate and static routes and for the following protocols:
■
Border Gateway Protocol (BGP), for unicast IPv4 and IPv6 address families only.
If you configure any other address family, the BGP session will not come up on the backup router.
■
■
Intermediate System-to-Intermediate System (IS-IS)
Label Distribution Protocol (LDP)
■
■
Open Shortest Path First (OSPF)/OSPFv3
Routing Information Protocol (RIP) and RIP next generation (RIPng)
Nonstop active routing is also supported for Layer 2 VPN and VPLS functionality.
NOTE: If you configure a protocol that is not supported by nonstop active 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 active routing is not supported on logical routers.
72 ■
Nonstop Active Routing System Requirements
Chapter 11: Nonstop Active Routing Overview
Nonstop Active Routing BFD Support
Routing protocols use bidirectional forwarding detection (BFD) for fast liveliness detection of their neighbors. With nonstop active 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.
NOTE: BFD session states are saved only for clients using aggregate or static routes or for BGP, IS-IS, or OSPF/OSPFv3. Nonstop active 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 active 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 Active Routing System Requirements
■ 73
JUNOS 9.1 High Availability Configuration Guide
74 ■
Nonstop Active Routing System Requirements
Chapter 12
Nonstop Active Routing Configuration
Guidelines
This chapter contains the following sections:
■
■
■
■
Configuring Nonstop Active Routing on page 75
Tracing Nonstop Active Routing Synchronization Events on page 77
Resetting Local Statistics on page 78
Example: Configuring Nonstop Active Routing on page 78
Configuring Nonstop Active Routing
This section includes the following topics:
■
■
■
Enabling Nonstop Active Routing on page 75
Synchronizing the Routing Engine Configuration on page 76
Verifying Nonstop Active Routing Operation on page 76
Enabling Nonstop Active Routing
Nonstop active 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]
By default, nonstop active routing is disabled. To enable nonstop active routing, include the nonstop-routing
statement at the
[edit routing-options]
hierarchy level:
[edit routing-options]
To disable nonstop active routing, remove the nonstop-routing
statement from the
[edit routing-options]
hierarchy level.
Configuring Nonstop Active Routing
■ 75
JUNOS 9.1 High Availability Configuration Guide
NOTE: When you enable nonstop active routing, you cannot enable automatic route distinguishers for multicast VPN routing instances. Automatic route distinguishers are enabled by configuring the route-distinguisher-id statement at the [edit routing-instances instance-name]
hierarchy level; for more information, see the JUNOS
VPNs Configuration Guide.
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.
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 active 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]
If you try to commit the nonstop active routing configuration without including the commit synchronize statement, the commit fails.
If you configure the commit synchronize statement at the [edit system] hierarchy level and issue a commit in the master Routing Engine, the master configuration is automatically synchronized with the backup.
However, if the backup Routing Engine is down when you issue the commit, the
JUNOS system software displays a warning and commits the candidate configuration in the master Routing Engine. When the backup Routing Engine comes up, its configuration will automatically be synchronized with the master.
NOTE: A newly inserted backup Routing Engine automatically synchronizes its configuration with the master Routing Engine configuration.
When you configure nonstop active 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 Active Routing Operation
To see whether or not nonstop active routing is enabled, issue the show task replication command. For BGP nonstop active routing, you can also issue the show bgp replication command.
76 ■
Configuring Nonstop Active Routing
Chapter 12: Nonstop Active Routing Configuration Guidelines
NOTE: You must issue the show task replication command on the master Routing
Engine. This command is not supported on the backup Routing Engine.
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 active 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.
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.
Tracing Nonstop Active Routing Synchronization Events
To track the progress of nonstop active routing synchronization between Routing
Engines, you can configure nonstop active routing trace options flags for each supported protocol and for BFD sessions and record these operations to a log file.
To configure nonstop active 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 {
flag nsr-synchronization [detail | disable | receive | send];
}
}
} isis {
}
flag nsr-synchronization [detail | disable | receive | send]; ldp {
flag nsr-synchronization [detail | disable | receive | send];
}
}
}
(ospf | ospf3) {
}
flag nsr-synchronization [detail | disable | receive | send]; pim {
flag nsr-synchronization detail;
}
Tracing Nonstop Active Routing Synchronization Events
■ 77
JUNOS 9.1 High Availability Configuration Guide
}
}
(rip | ripng) {
flag nsr-synchronization [detail | disable | receive | send];
}
To configure nonstop active 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 {
flag nsr-synchronization; flag nsr-packet;
}
To trace the Layer 2 VPN signaling state replicated from routes advertised by BGP, include the nsr-synchronization statement at the [edit routing-options traceoptions flag] hierarchy level. This flag also traces the label and logical interface association that
VPLS receives from the kernel replication state.
}
[edit routing-options]
flag nsr-synchronization;
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.
Example: Configuring Nonstop Active Routing
The following example enables graceful Routing Engine switchover, nonstop active routing, and nonstop active 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 {
78 ■
Resetting Local Statistics
Chapter 12: Nonstop Active Routing Configuration Guidelines
} 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 {
}
} lo0 { address 10.3.1.1/30;
} family iso; unit 0 { family inet { address 192.168.2.1/32;
}
} family iso { address 49.0004.1921.6800.2001.00;
}
}
} routing-options {
nonstop-routing; # This enables nonstop active routing on the routing platform.
router-id 192.168.2.1; autonomous-system 65432;
} protocols { bgp {
flag nsr-synchronization detail; # This logs nonstop active routing events for
BGP.
} local-address 192.168.2.1; group external-group { type external; export BGP_export;
Example: Configuring Nonstop Active Routing
■ 79
JUNOS 9.1 High Availability Configuration Guide neighbor 192.168.1.1 { family inet { unicast;
} peer-as 65103;
}
} group internal-group { type internal;
}
} isis { neighbor 192.168.10.1; neighbor 192.168.11.1; neighbor 192.168.12.1;
flag nsr-synchronization detail; # This logs nonstop active routing events for
IS-IS.
} interface all; interface fxp0.0 { disable;
}
} interface lo0.0 { passive;
} ospf {
flag nsr-synchronization detail; # This logs nonstop active routing events for
OSPF.
}
} area 0.0.0.0 { interface all; interface fxp0.0 { disable;
}
} interface lo0.0 { passive;
}
}
} policy-options { policy-statement BGP_export { term direct { from { protocol direct;
}
} then accept;
} term final { then reject;
}
80 ■
Example: Configuring Nonstop Active Routing
Chapter 13
Summary of Nonstop Active Routing
Configuration Statements
This chapter provides a reference for each of the nonstop active routing configuration statements. The statements are organized alphabetically.
■ 81
JUNOS 9.1 High Availability Configuration Guide
commit synchronize
Syntax commit synchronize;
<and-quit>
<comment>
<and-force>
Hierarchy Level
[edit system]
Release Information
Description
Statement introduced in JUNOS Release 7.4.
and-quit , comment , and and-force options added in JUNOS Release 8.5.
Configure a commit command to automatically result in a commit synchronize between dual Routing Engines within the same chassis. The Routing Engine on which you execute the commit command (requesting Routing Engine) copies and loads its candidate configuration to the other (responding) Routing Engine. Each Routing
Engine then performs 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 both Routing Engines.
Synchronization only occurs between the Routing Engines within the same chassis.
On the TX Matrix platform, when synchronization is complete, the new configuration is then distributed to the Routing Engines on the T640 routing nodes. That is, the master Routing Engine on the TX Matrix platform distributes the configuration to the master Routing Engine on each T640 routing node. Likewise, the backup Routing
Engine on the TX Matrix platform distributes the configuration to the backup Routing
Engine on each T640 routing node.
NOTE: When you configure nonstop active routing (NSR), you must include the commit synchronize statement. Otherwise, the commit fails.
Options and-quit —(Optional) Quit configuration mode if the commit synchronization succeeds.
comment —(Optional) Write a message to the commit log.
and-force
—(Optional) Force a commit synchronization on the other Routing Engine
(ignore warnings).
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.
82 ■ commit synchronize
Chapter 13: Summary of Nonstop Active Routing Configuration Statements
nonstop-routing
Syntax nonstop-routing;
Hierarchy Level [edit routing-options]
Release Information
Description
Statement introduced in JUNOS Release 8.4.
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 Active Routing” on page 75.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
nonstop-routing
■ 83
JUNOS 9.1 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 bfd],
[edit protocols bgp],
[edit protocols isis],
[edit protocols ldp],
[edit protocols ospf]
[edit protocols ospf3]
[edit protocols rip]
[edit protocols ripng]
[edit routing-options]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
nsr-synchronization
flag for BGP, IS-IS, LDP, and OSPF added in JUNOS Release 8.4.
nsr-synchronization
and nsr-packet
flags for BFD sessions added in JUNOS Release
8.5.
nsr-synchronization
flag for RIP and RIPng added in JUNOS Release 9.0.
nsr-synchronization flag for Layer 2 VPNs and VPLS added in JUNOS Release 9.1.
Define tracing operations that track nonstop active 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.
84 ■ traceoptions
Chapter 13: Summary of Nonstop Active Routing Configuration Statements flag flag
—Tracing operation to perform. To specify more than one tracing operation, include multiple flag statements. The nonstop active routing tracing options are:
■
■ nsr-packet —Detailed trace information for BFD nonstop active routing only nsr-synchronization
—Tracing operations for nonstop active routing
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 Active 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.
traceoptions
■ 85
JUNOS 9.1 High Availability Configuration Guide
86 ■ traceoptions
Part 6
Graceful Restart
■
■
■
Graceful Restart Overview on page 89
Graceful Restart Configuration Guidelines on page 97
Summary of Graceful Restart Configuration Statements on page 135
Graceful Restart
■ 87
JUNOS 9.1 High Availability Configuration Guide
88 ■
Graceful Restart
Chapter 14
Graceful Restart Overview
This chapter contains the following sections:
■
■
■
■
■
■
■
Graceful Restart Concepts on page 89
Graceful Restart System Requirements on page 90
Aggregate and Static Routes on page 91
MPLS-Related Protocols on page 93
Layer 2 and Layer 3 VPNs on page 94
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 for virtual private networks (VPNs)—Provides protection for
Layer 2 and Layer 3 VPNs.
Graceful Restart Concepts
■ 89
JUNOS 9.1 High Availability Configuration Guide
NOTE: Graceful restart helper mode is enabled by default, except for BGP. In helper mode, a neighboring router assists in a restart. Helper mode is not sustained during a graceful Routing Engine switchover (GRES) event.
A router can both act as a graceful restart helper and be configured to support nonstop active routing. However, you cannot configure graceful restart and nonstop active routing at the same time at the [edit routing-options] hierarchy level (with the graceful-restart statement and the nonstop-routing statement, respectively).
To configure BGP helper mode support, you must include the graceful-restart statement at the [edit routing-options] hierarchy level. Again, you cannot configure the router to undergo a graceful restart and to support nonstop active routing at the same time.
Therefore, when nonstop active routing is enabled, BGP cannot provide graceful restart helper support.
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.
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:
90 ■
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 Services Routers)
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
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 retains the routes received and marks the routes as stale. After the session is
Aggregate and Static Routes
■ 91
JUNOS 9.1 High Availability Configuration Guide 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.
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
92 ■
Routing Protocols
Chapter 14: Graceful Restart Overview 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
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.
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
MPLS-Related Protocols
■ 93
JUNOS 9.1 High Availability Configuration Guide 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.
3.
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.
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.
94 ■
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
■ 95
JUNOS 9.1 High Availability Configuration Guide
96 ■
Logical Routers
Chapter 15
Graceful Restart Configuration Guidelines
To implement graceful restart, you must perform the configuration tasks described in the following sections:
■
■
■
■
■
■
■
Configuring Aggregate and Static Route Graceful Restart on page 97
Configuring Routing Protocols Graceful Restart on page 97
Configuring Graceful Restart for MPLS-Related Protocols on page 102
Configuring VPN Graceful Restart on page 104
Configuring Logical Router Graceful Restart on page 105
Verifying Graceful Restart Operation on page 107
Example: Configuring Graceful Restart on page 109
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 98
Configuring Graceful Restart Options for BGP on page 98
Configuring Graceful Restart Options for ES-IS on page 99
Configuring Graceful Restart Options for IS-IS on page 99
Configuring Graceful Restart Options for OSPF and OSPFv3 on page 100
Configuring Graceful Restart Options for RIP and RIPng on page 101
Configuring Graceful Restart Options for PIM Sparse Mode on page 101
Tracking Graceful Restart Events on page 102
Configuring Aggregate and Static Route Graceful Restart
■ 97
JUNOS 9.1 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.
NOTE: Helper mode (the ability to assist a neighboring router attempting a graceful restart) is enabled by default when you start the routing platform, even if graceful restart is not enabled. You can disable helper mode on a per-protocol basis.
}
[edit] routing-options {
}
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 {
}
}
98 ■
Configuring Routing Protocols Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines
To disable BGP graceful restart capability for all BGP sessions, include the disable statement at the [edit protocols bgp graceful-restart] hierarchy level.
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 {
}
}
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 {
}
}
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
■ 99
JUNOS 9.1 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
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 {
}
}
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 102.
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.
100 ■
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) {
}
}
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
■ 101
JUNOS 9.1 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 {
}
}
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 {
flag graceful-restart;
}
}
}
(ospf | ospf3) {
}
flag graceful-restart;
Configuring Graceful Restart for MPLS-Related Protocols
This section contains the following topics:
■
■
■
Configuring Graceful Restart Globally on page 103
Configuring Graceful Restart Options for RSVP, CCC, and TCC on page 103
Configuring Graceful Restart Options for LDP on page 104
102 ■
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 {
}
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 { rsvp {
}
helper-disable; maximum-helper-recovery-time;
}
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 for MPLS-Related Protocols
■ 103
JUNOS 9.1 High Availability Configuration Guide
Configuring Graceful Restart Options for LDP
You can configure the following optional statements at the [edit protocols ldp graceful-restart] hierarchy level:
}
[edit] protocols { ldp {
maximum-neighbor-reconnect-time seconds;
maximum-neighbor-recovery-time seconds;
}
}
The statements have the following effects on the graceful restart process:
■
■
To configure the amount of time required to reestablish a session after a graceful restart, include the reconnect-time
statement; the range is 30 through 120 seconds.
To limit the maximum reconnect time allowed from a restarting neighbor router, include the maximum-neighbor-reconnect-time
statement; the range is 30 through
300 seconds.
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; the range is 120 through 1800 seconds. 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-neighbor-recovery-time statement; the range is 140 through 1900 seconds.
NOTE: The value for the recovery-time and maximum-neighbor-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. To disable LDP graceful restart helper capability, include the helper-disable statement.
Configuring VPN Graceful Restart
To implement graceful restart for a Layer 2 VPN or Layer 3 VPN, perform the configuration tasks described in the following sections:
■
■
Configuring Graceful Restart Globally on page 105
Configuring Graceful Restart for the Routing Instance on page 105
104 ■
Configuring VPN Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines
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 {
}
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] .
}
[edit] routing-instances {
instance-name { routing-options {
}
}
}
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 106
Configuring Graceful Restart for a Routing Instance on page 106
Configuring Logical Router Graceful Restart
■ 105
JUNOS 9.1 High Availability Configuration Guide
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 {
}
}
}
To disable graceful restart globally, include the disable
statement at the
[edit logical-routers logical-router-name routing-options graceful-restart] hierarchy level.
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 {
}
}
}
}
}
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.
106 ■
Configuring Logical Router Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines
Verifying Graceful Restart Operation
This section contains the following topics:
■
■
■
■
Graceful Restart Operational Mode Commands on page 107
Verifying BGP Graceful Restart on page 107
Verifying IS-IS and OSPF Graceful Restart on page 108
Verifying CCC and TCC Graceful Restart on page 108
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)
For more information about these commands and a description of their output fields, see the JUNOS Routing Protocols and Policies Command Reference.
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
Verifying Graceful Restart Operation
■ 107
JUNOS 9.1 High Availability Configuration Guide
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
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 102).
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
108 ■
Verifying Graceful Restart Operation
Chapter 15: Graceful Restart Configuration Guidelines
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
PE1-PE2-3 tlsp Up
PE2-PE1-3 rlsp Up
Example: Configuring Graceful Restart
Figure 7 on page 109 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;
Example: Configuring Graceful Restart
■ 109
JUNOS 9.1 High Availability Configuration Guide
} 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;
}
} 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;
}
110 ■
Example: Configuring Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines
}
} 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 { 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 {
Example: Configuring Graceful Restart
■ 111
JUNOS 9.1 High Availability Configuration Guide
}
} 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;
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;
112 ■
Example: Configuring Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines
}
} family mpls;
} unit 512 { encapsulation frame-relay-ccc; dlci 512;
} t1-0/1/0 { unit 0 { family inet {
}
} lo0 { address 10.96.0.2/30;
} family mpls; 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;
Example: Configuring Graceful Restart
■ 113
JUNOS 9.1 High Availability Configuration Guide
} 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 { 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 {
114 ■
Example: Configuring Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines 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; 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 {
}
Example: Configuring Graceful Restart
■ 115
JUNOS 9.1 High Availability Configuration Guide
} 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;
}
}
}
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 {
116 ■
Example: Configuring Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines
} t3-0/1/3 { unit 0 { family inet { address 10.96.0.5/30;
} family mpls;
}
} t1-0/2/0 { unit 0 { family inet {
}
} lo0 { address 10.96.0.1/30;
} family mpls; 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
Example: Configuring Graceful Restart
■ 117
JUNOS 9.1 High Availability Configuration Guide 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;
}
} 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;
118 ■
Example: Configuring Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines
} family iso { address 47.0005.80ff.f800.0000.0108.0001.0102.4501.4182.00;
}
}
} routing-options {
} protocols { mpls { interface all;
} graceful-restart; router-id 10.245.14.182; autonomous-system 69; 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;
Example: Configuring Graceful Restart
■ 119
JUNOS 9.1 High Availability Configuration Guide 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 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 {
120 ■
Example: Configuring Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines 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;
}
}
}
}
}
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;
Example: Configuring Graceful Restart
■ 121
JUNOS 9.1 High Availability Configuration Guide
}
}
} vrf-export RIP-export; routing-options { graceful-restart;
} protocols { rip { group RIP { export RIP-import; neighbor t1-0/1/3.202;
}
}
}
}
STATIC { 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;
122 ■
Example: Configuring Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines
}
} unit 203 {
} dlci 203; family inet { address 10.96.203.2/30;
} unit 512 { dlci 512; family inet { address 10.96.252.2/30;
}
}
} 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 {
Example: Configuring Graceful Restart
■ 123
JUNOS 9.1 High Availability Configuration Guide
} 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 { 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;
124 ■
Example: Configuring Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines
}
} route-filter 10.96.216.1/32 exact;
} then accept;
}
} term final { then reject;
Router PE1 Status
Before a Restart
The following example displays neighbor relationships on Router PE1 before a restart happens: 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
Example: Configuring Graceful Restart
■ 125
JUNOS 9.1 High Availability Configuration Guide
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
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
126 ■
Example: Configuring Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines
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
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:
Example: Configuring Graceful Restart
■ 127
JUNOS 9.1 High Availability Configuration Guide
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
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
128 ■
Example: Configuring Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines 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
Router PE1 Status
During a Restart bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Restart Complete
Before you can verify that graceful restart is working, you must simulate a router 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
Example: Configuring Graceful Restart
■ 129
JUNOS 9.1 High Availability Configuration Guide
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
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
130 ■
Example: Configuring Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines 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)
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
Example: Configuring Graceful Restart
■ 131
JUNOS 9.1 High Availability Configuration Guide
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 ]
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)
132 ■
Example: Configuring Graceful Restart
Chapter 15: Graceful Restart Configuration Guidelines
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
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
Example: Configuring Graceful Restart
■ 133
JUNOS 9.1 High Availability Configuration Guide
134 ■
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 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)
[edit routing-instances routing-instance-name routing-options graceful-restart],
[edit routing-options graceful-restart]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
Disable graceful restart.
Usage Guidelines
See “Graceful Restart Configuration Guidelines” on page 97.
Required Privilege Level routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
disable
■ 135
JUNOS 9.1 High Availability Configuration Guide
graceful-restart
Syntax
} graceful-restart {
helper-disable; maximum-helper-recovery-time seconds;
maximum-helper-restart-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
Description
Statement introduced before JUNOS Release 7.4.
Enable graceful restart.
Options
The statements are explained separately.
Usage Guidelines
See “Graceful Restart Configuration Guidelines” on page 97.
Required Privilege Level routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
136 ■ 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)
[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
Description
Statement introduced before JUNOS Release 7.4.
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 97.
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
Description
Statement introduced before JUNOS Release 7.4.
Specify the amount of time the router retains the state of its Resource Reservation
Protocol (RSVP) neighbors while they undergo a graceful restart.
Options
Usage Guidelines
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
Default: 180
See “Configuring Graceful Restart Options for RSVP, CCC, and TCC” on page 103.
Required Privilege Level
Related Topics routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
helper-disable
■ 137
JUNOS 9.1 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
Description
Statement introduced in JUNOS Release 8.3.
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
Usage Guidelines
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
Default: 60
See “Configuring Graceful Restart Options for RSVP, CCC, and TCC” on page 103.
Required Privilege Level
Related Topics view-level—To view this statement in the configuration.
control-level—To add this statement to the configuration.
maximum-neighbor-reconnect-time
Syntax maximum-neighbor-reconnect-time seconds;
Hierarchy Level [edit protocols ldp graceful-restart],
[edit logical-routers logical-router-name protocols ldp graceful-restart],
[edit routing-instances routing-instance-name protocols ldp graceful-restart]
Release Information
Description
Statement introduced in JUNOS Release 9.1.
Specify the maximum amount of time allowed to reestablish connection from a restarting neighbor.
Options
Usage Guidelines
seconds
—Maximum time, in seconds, allowed for reconnection.
Range: 30 through 300
See “Configuring Graceful Restart Options for LDP” on page 104
Required Privilege Level view-level—To view this statement in the configuration.
control-level—To add this statement to the configuration.
138 ■ maximum-helper-restart-time
Chapter 16: Summary of Graceful Restart Configuration Statements
maximum-neighbor-recovery-time
Syntax maximum-neighbor-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
Description
Statement introduced in JUNOS Release 8.3.
Statement name changed from maximum-recovery-time
to maximum-neighbor-recovery-time
in JUNOS Release 9.1.
Specify the amount of time the router retains the state of its Label Distribution Protocol
(LDP) neighbors while they undergo a graceful restart.
Options
Usage Guidelines
seconds
—Time, in seconds, the router retains the state of its LDP neighbors while they undergo a graceful restart.
Range: 140 through 1900
Default: 240
See “Configuring Graceful Restart Options for LDP” on page 104.
Required Privilege Level
Related Topics view-level—To view this statement in the configuration.
control-level—To add this statement to the configuration.
no-strict-lsa-checking
Syntax no-strict-lsa-checking;
Hierarchy Level
[edit protocols (ospf | ospf3) graceful-restart]
Release Information
Description
Statement introduced in JUNOS Release 8.5.
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 100.
Required Privilege Level
Related Topics view-level—To view this statement in the configuration.
control-level—To add this statement to the configuration.
maximum-neighbor-recovery-time
maximum-neighbor-recovery-time
■ 139
JUNOS 9.1 High Availability Configuration Guide
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
[edit routing-instances instance-name protocols (ospf | ospf3) graceful-restart]
Release Information
Description
Statement introduced in JUNOS Release 8.3.
Specify the length of time the router notifies helper OSPF routers that it has completed graceful restart.
Options
Usage Guidelines
seconds
—Amount of time in seconds, the router notifies helper OSPF routers that it has completed graceful restart.
Range: 1 through 3600
Default: 30
See “Configuring Graceful Restart Options for OSPF and OSPFv3” on page 100.
Required Privilege Level
Related Topics view-level—To view this statement in the configuration.
control-level—To add this statement to the configuration.
reconnect-time
Syntax reconnect-time seconds;
Hierarchy Level
[edit protocols ldp graceful-restart],
[edit logical-routers logical-router-name protocols ldp graceful-restart],
[edit routing-instances routing-instance-name protocols ldp graceful-restart]
Release Information
Description
Statement introduced in JUNOS Release 9.1.
Specify the amount of time required to reestablish a Label Distribution Protocol (LDP) session after graceful restart.
Options
Usage Guidelines
seconds
—Time, in seconds, required for reconnection.
Range: 30 through 120
See “Configuring Graceful Restart Options for LDP” on page 104
Required Privilege Level view-level—To view this statement in the configuration.
control-level—To add this statement to the configuration.
140 ■ notify-duration
Chapter 16: Summary of Graceful Restart Configuration Statements
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
[edit protocols ldp graceful-restart],
[edit routing-instances routing-instance-name protocols ldp graceful-restart]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
Specify the amount of time a router waits for Label Distribution Protocol (LDP) neighbors to assist it with a graceful restart.
Options
Usage Guidelines
seconds
—Time, in seconds, the router waits for LDP to restart gracefully.
Range: 120 through 1800
Default: 160
See “Configuring Graceful Restart Options for LDP” on page 104.
Required Privilege Level
Related Topics interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
maximum-neighbor-recovery-time no-strict-lsa-checking
recovery-time
■ 141
JUNOS 9.1 High Availability Configuration Guide
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)
[edit routing-options graceful-restart]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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.
Range: The range of values varies according to whether the graceful restart period is being set globally or for a particular protocol:
■
[edit routing-options graceful-restart]
(global setting)—120 through 900
■
■
■
■
ES-IS—30 through 300
IS-IS—30 through 300
OSPF/OSPFv3—1 through 3600
PIM—30 through 300
Default: The default value varies according to whether the graceful restart period is being set globally or for a particular protocol:
■
[edit routing-options graceful-restart] (global setting)—300
■
■
■
ES-IS—180
IS-IS—210
OSPF/OSPFv3—180
■
PIM—60
Usage Guidelines
See “Graceful Restart Configuration Guidelines” on page 97.
Required Privilege Level routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
142 ■ restart-duration
Chapter 16: Summary of Graceful Restart Configuration Statements
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
[edit routing-instances routing-instance-name protocols bgp graceful-restart]
Release Information
Description
Statement introduced in JUNOS Release 8.3.
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: The range of values varies according the protocol:
■
BGP—120
■
RIP/RIPng—60
Usage Guidelines
See “Configuring Graceful Restart Options for BGP” on page 98 and “Configuring
Graceful Restart Options for RIP and RIPng” on page 101.
Required Privilege Level
Related Topics view-level—To view this statement in the configuration.
control-level—To add this statement to the configuration.
restart-time
■ 143
JUNOS 9.1 High Availability Configuration Guide
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
[edit protocols bgp graceful-restart],
[edit routing-instances routing-instance-name protocols bgp graceful-restart]
Release Information
Description
Statement introduced in JUNOS Release 8.3.
Configure amount of time the router waits to receive restart messages from restarting
Border Gateway Protocol (BGP) neighbors before declaring them down.
Options
Usage Guidelines
seconds
—Time, in seconds, the router waits to receive messages from restarting neighbors before declaring them down.
Range: 1 through 600
Default: 300
See “Configuring Graceful Restart Options for BGP” on page 98.
Required Privilege Level
Related Topics view-level—To view this statement in the configuration.
control-level—To add this statement to the configuration.
144 ■ stale-routes-time
Chapter 16: Summary of Graceful Restart 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 isis]
[edit protocols (ospf | ospf3)]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
graceful-restart flag for IS-IS and OSPF/OSPFv3 added in JUNOS Release 8.4.
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 active routing tracing option is:
■ graceful-restart —Tracing operations for nonstop active 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.
traceoptions
■ 145
JUNOS 9.1 High Availability Configuration Guide
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 102.
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.
146 ■ traceoptions
Part 7
Virtual Router Redundancy Protocol
■
■
■
VRRP Configuration Guidelines on page 151
Summary of VRRP Configuration Statements on page 169
Virtual Router Redundancy Protocol
■ 147
JUNOS 9.1 High Availability Configuration Guide
148 ■
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 150 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).
■ 149
JUNOS 9.1 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 draft-ietf-vrrp-ipv6-spec-08.txt, Virtual Router Redundancy Protocol for IPv6.
See also draft-ietf-vrrp-unified-mib-06.txt, Definitions of Managed Objects for the VRRP
over IPv4 and IPv6.
150 ■
Chapter 18
VRRP Configuration Guidelines
This chapter contains the following topics:
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
VRRP Configuration Hierarchy on page 151
VRRP for IPv6 Configuration Hierarchy on page 152
VRRP Trace and Startup Configuration Statements on page 153
Configuring Basic VRRP Support on page 153
Configuring VRRP Authentication (IPv4 Only) on page 155
Configuring the Advertisement Interval for the VRRP Master Router on page 156
Configuring a Backup Router to Preempt the Master Router on page 158
Configuring an Interface to Accept Packets Destined for the Virtual IP
Configuring a Logical Interface to Be Tracked on page 159
Configuring a Route to Be Tracked on page 161
Tracing VRRP Operations on page 161
Configuring the Silent Period on page 162
Configuring Passive ARP Learning for Backup VRRP Routers on page 162
Example: Configuring VRRP on page 163
Example: Configuring VRRP for IPv6 on page 165
Example: Configuring VRRP Route Tracking on page 166
VRRP Configuration Hierarchy
To configure VRRP, include the following statements at either of these hierarchy levels:
■
[edit interfaces interface-name unit logical-unit-number family inet address address]
■
[edit logical-router logical-router-name interfaces interface-name unit
logical-unit-number family inet address address]
(accept-data | no-accept-data);
authentication-type authentication;
VRRP Configuration Hierarchy
■ 151
JUNOS 9.1 High Availability Configuration Guide
}
}
track {
bandwidth-threshold bits-per-second {
}
}
}
route prefix routing-instance instance-name {
}
virtual-address [ addresses ];
VRRP for IPv6 Configuration Hierarchy
To configure VRRP for IPv6, include the following statements at either of these hierarchy levels:
■
[edit interfaces interface-name unit logical-unit-number family inet6 address address]
■
[edit logical-router logical-router-name interfaces interface-name unit
logical-unit-number family inet6 address address]
}
(accept-data | no-accept-data);
inet6-advertise-interval seconds;
}
track {
bandwidth-threshold bits-per-second {
}
}
}
route prefix routing-instance instance-name {
priority-cost priority;
}
virtual-inet6-address [ addresses ];
virtual-link-local-address ipv6-address
152 ■
VRRP for IPv6 Configuration Hierarchy
Chapter 18: VRRP Configuration Guidelines
VRRP Trace and Startup Configuration Statements
To trace VRRP operations, include the traceoptions
statement at the
[edit protocols vrrp] hierarchy level:
} traceoptions { file { filename filename; files number; match regex; microsecond-stamp; 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 either of these hierarchy levels:
■
[edit interfaces interface-name unit logical-unit-number family inet address address]
■
[edit logical-router logical-router-name interfaces interface-name unit
logical-unit-number family inet address address]
}
virtual-address [ addresses ];
To configure basic VRRP for IPv6 support, configure VRRP group support on interfaces by including the following statements at the either of these hierarchy levels:
■
[edit interfaces interface-name unit logical-unit-number family inet6 address address]
■
[edit logical-router logical-router-name interfaces interface-name unit
logical-unit-number family inet6 address address]
}
virtual-inet6-address [ addresses ];
virtual-link-local-address ipv6-address
VRRP Trace and Startup Configuration Statements
■ 153
JUNOS 9.1 High Availability Configuration Guide
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
.
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
154 ■
Configuring Basic VRRP Support
Chapter 18: VRRP Configuration Guidelines
■
■ 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.
■
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 either of the following hierarchy levels:
■
[edit interfaces interface-name unit logical-unit-number family inet address address vrrp-group group-id]
■
[edit logical-router logical-router-name interfaces interface-name unit
logical-unit-number family inet address address vrrp-group group-id]
authentication-type authentication;
authentication
can be simple or md5 . The authentication type must be the same for all routing platforms in the VRRP group.
Configuring VRRP Authentication (IPv4 Only)
■ 155
JUNOS 9.1 High Availability Configuration Guide
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 either of the following hierarchy levels:
■
[edit interfaces interface-name unit logical-unit-number family inet address address vrrp-group group-id]
■
[edit logical-router logical-router-name interfaces interface-name unit
logical-unit-number family inet address address vrrp-group group-id]
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 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 IPv6 router advertisements for the interface on which VRRP is configured to send IPv6 router advertisements for the VRRP group.
To do so, include the interface interface-name
statement at the
[edit protocols router-advertisement] hierarchy level. (For information on this statement and guidelines, see the JUNOS Routing Protocols Configuration Guide.) 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.
NOTE: The master VRRP for IPv6 router must respond to a Neighbor Solicitation message with the virtual IP address of the router. However, when the interface
interface-name
statement is included at the [edit protocols router-advertisement] hierarchy level, the backup VRRP for IPv6 router might send a response before the
VRRP master responds so that the default route of the client is not set to the master
VRRP router's virtual IP address. To avoid this situation, include the virtual-router-only statement at the [edit protocols router-advertisement] interface interface-name hierarchy level. When this statement is included, router advertisements are sent only for VRRP
IPv6 groups configured on the interface (if the groups are in the master state). You must include this statement on both the master and backup VRRP for IPv6 routers.
156 ■
Configuring the Advertisement Interval for the VRRP Master Router
Chapter 18: VRRP Configuration Guidelines
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 either of the following hierarchy levels:
■
[edit interfaces interface-name unit logical-unit-number family inet address address vrrp-group group-id]
■
[edit logical-router logical-router-name interfaces interface-name unit
logical-unit-number family inet address address vrrp-group group-id]
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 either of the following hierarchy levels:
■
[edit interfaces interface-name unit logical-unit-number family inet6 address address vrrp-inet6-group group-id]
■
[edit logical-router logical-router-name interfaces interface-name unit
logical-unit-number family inet6 address addressvrrp-inet6-group group-id]
inet6-advertise-interval seconds;
The interval can be from 1 through 255 seconds.
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 either of the following hierarchy levels:
■
■
[edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-id]
[edit logical-router logical-router-name interfaces interface-name unit
logical-unit-number family (inet | inet6) address address (vrrp-group | vrrp-inet6-group)
group-id]
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.
Configuring the Advertisement Interval for the VRRP Master Router
■ 157
JUNOS 9.1 High Availability Configuration Guide
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 either of the following hierarchy levels:
■
[edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-id]
■
[edit logical-router logical-router-name interfaces interface-name unit
logical-unit-number family (Inet | inet6) address address (vrrp-group | vrrp-inet6-group)
group-id]
To prohibit a higher-priority backup router from preempting a lower priority master router, include the no-preempt
statement:
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 either of the following hierarchy levels:
■
[edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-id] preempt
■
[edit logical-router logical-router-name interfaces interface-name unit
logical-unit-number family (Inet | inet6) address address (vrrp-group | vrrp-inet6-group)
group-id] preempt
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 either of the following hierarchy levels:
■
[edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group)] group-id
158 ■
Configuring a Backup Router to Preempt the Master Router
Chapter 18: VRRP Configuration Guidelines
■
[edit logical-router logical-router-name interfaces interface-name unit
logical-unit-number family (Inet | inet6) address address (vrrp-group | vrrp-inet6-group)]
group-id
To prohibit the interface from accepting packets destined for the virtual IP address, include the no-accept-data statement:
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 following statements at either of the these hierarchy levels:
■
■
[edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-id]
[edit logical-router logical-router-name interfaces interface-name unit
logical-unit-number family (Inet | inet6) address address (vrrp-group | vrrp-inet6-group)
group-id]
Configuring a Logical Interface to Be Tracked
■ 159
JUNOS 9.1 High Availability Configuration Guide
}
}
bandwidth-threshold bits-per-second {
}
The interface specified is the interface to be tracked for the VRRP group. 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.
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: Interface State and Priority Cost Usage
Tracked Interface State
Down
Not down; media speed below one or more bandwidth thresholds
Priority Cost Usage priority-cost priority
Priority-cost of the lowest applicable bandwidth 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.
160 ■
Configuring a Logical Interface to Be Tracked
Chapter 18: VRRP Configuration Guidelines
Configuring a Route to Be Tracked
VRRP can track whether a route is reachable (that is, the route exists in the routing table of the routing instance included in the configuration) and dynamically change the priority of the VRRP group based on the reachability of the tracked route, which might trigger a new master router election.
To configure a route to be tracked, include the following statements at either of these hierarchy levels:
■
[edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-id]
■
[edit logical-router logical-router-name interfaces interface-name unit
logical-unit-number family (Inet | inet6) address address (vrrp-group | vrrp-inet6-group)
group-id]
}
route prefix routing-instance instance-name {
}
The route prefix specified is the route to be tracked for the VRRP group. 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.
The routing instance is the routing instance in which the route is to be tracked. If the route is in the default, or global, routing instance, specify the instance name as default
.
NOTE: Tracking a route that belongs to a routing instance from a different logical router is not supported.
The priority cost is the value to be subtracted from the configured VRRP priority when the tracked route 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.
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
Configuring a Route to Be Tracked
■ 161
JUNOS 9.1 High Availability Configuration Guide
/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; microsecond-stamp size size;
(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
162 ■
Configuring the Silent Period
Chapter 18: VRRP Configuration Guidelines 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;
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
On Router A
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.
}
[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 {
Example: Configuring VRRP
■ 163
JUNOS 9.1 High Availability Configuration Guide
}
}
}
}
}
} vrrp-group 27 { virtual-address 192.168.1.15; priority 200; authentication-type simple; authentication-key booJUM;
Configuring One Router to be the Master Virtual
Router for the Group
}
[edit] interfaces { 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
MAC Source Address
Filtering
The VRRP group number is the decimal equivalent of the last byte of the virtual MAC address.
[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;
164 ■
Example: Configuring VRRP
Chapter 18: VRRP Configuration Guidelines
}
}
}
} priority 255; preempt;
Example: Configuring VRRP for IPv6
On Router A
Configure VRRP properties for IPv6 in one master (Router A) and one backup (Router
B).
}
[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;
}
}
}
On Router B
[edit protocols] router-advertisement { interface ge-1/0/0.0 {
} prefix fec0::/64; max-advertisement-interval 4;
}
}
[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]
Example: Configuring VRRP for IPv6
■ 165
JUNOS 9.1 High Availability Configuration Guide router-advertisement { interface ge-1/0/0.0 { prefix fec0::/64;
} max-advertisement-interval 4;
}
Example: Configuring VRRP Route Tracking
R1 Configuration
Configure routers R1 and R2 to run VRRP. Configure static routes and a policy for exporting the static routes on R3. The VRRP routing instances on R2 track the routes that are advertised by R3.
}
[edit interfaces] ge-1/0/3 { unit 0 { vlan-id1; family inet { address 200.100.50.2/24 { vrrp-group 0 { virtual-address 200.100.50.101; priority 195;
}
}
}
}
R2 Configuration
}
[edit interfaces] ge-1/0/1 { unit 0 { vlan-id 1; family inet { address 200.100.50.1/24 { vrrp-group 0 {
} virtual-address 200.100.50.101; priority 200; track { route 59.0.58.153/22 routing-instance default priority-cost 5 route 59.0.58.154/32 routing-instance default priority-cost 5 route 59.0.58.155/32 routing-instance default priority-cost 5
}
}
}
}
R3 Configuration [edit] policy-options { policy-statement static-policy { term term1 { then accept;
}
166 ■
Example: Configuring VRRP Route Tracking
Chapter 18: VRRP Configuration Guidelines
}
}
} protocols { ospf { export static-policy; reference-bandwidth 4g; area 0.0.0.0 {
} interface all; interface fxp0.0 { disable;
}
}
} routing-options {
} static { route 59.0.0.153/32 next-hop 45.45.45.46; route 59.0.0.154/32 next-hop 45.45.45.46; route 59.0.0.155/32 next-hop 45.45.45.46;
Example: Configuring VRRP Route Tracking
■ 167
JUNOS 9.1 High Availability Configuration Guide
168 ■
Example: Configuring VRRP Route Tracking
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-id],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-id]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
accept-data
■ 169
JUNOS 9.1 High Availability Configuration Guide
advertise-interval
Syntax advertise-interval seconds;
Hierarchy Level [edit interfaces interface-name unit logical-unit-number family inet address address
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family inet address address vrrp-group group-id]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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
Usage Guidelines
seconds
—Interval between advertisement packets.
Range: 1 through 255 seconds
Default: 1 second
See “Configuring the Advertisement Interval for the VRRP Master Router” on page 156.
Required Privilege Level
Related Topics interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
170 ■ 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
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family inet address address vrrp-group group-id]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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 155.
Required Privilege Level
Related Topics interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
authentication-key
■ 171
JUNOS 9.1 High Availability Configuration Guide
authentication-type
Syntax authentication-type authentication;
Hierarchy Level [edit interfaces interface-name unit logical-unit-number family inet address address
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family inet address address vrrp-group group-id]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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.
Usage Guidelines
■ 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)
See “Configuring VRRP Authentication (IPv4 Only)” on page 155.
Required Privilege Level
Related Topics interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
172 ■ authentication-type
Chapter 19: Summary of VRRP Configuration Statements
bandwidth-threshold
Syntax
} bandwidth-threshold bits-per-second {
Hierarchy Level [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-id 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-id track
Release Information
Description
Statement introduced in JUNOS Release 8.1.
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 159.
Required Privilege Level
Related Topics interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
bandwidth-threshold
■ 173
JUNOS 9.1 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 | vrrp-inet6-group) group-id],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-id]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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
Usage Guidelines
milliseconds
—Interval between advertisement packets.
Range: 100 through 999 milliseconds
Default: 1 second
See “Configuring the Advertisement Interval for the VRRP Master Router” on page 156.
Required Privilege Level
Related Topics interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
174 ■ 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-id preempt],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp | vrrp-inet6-group) group-id preempt]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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
Usage Guidelines
seconds
—Hold-time period.
Range: 0 through 3600 seconds
Default: 0 seconds (VRRP preemption is not timed.)
See “Configuring a Backup Router to Preempt the Master Router” on page 158.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
hold-time
■ 175
JUNOS 9.1 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
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family inet6 address address vrrp-inet6-group group-id]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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
Usage Guidelines
seconds
—Interval between advertisement packets.
Range: 1 through 255 seconds
Default: 1 second
See “Configuring the Advertisement Interval for the VRRP Master Router” on page 156.
Required Privilege Level
Related Topics interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
176 ■ inet6-advertise-interval
Chapter 19: Summary of VRRP Configuration Statements
interface
Syntax
} interface interface-name {
}
bandwidth-threshold bits-per-second {
Hierarchy Level [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-id track],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-id track]
Release Information
Description
Statement introduced in JUNOS Release 7.5.
bandwidth-threshold statement added in JUNOS Release 8.1.
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 159.
Required Privilege Level
Related Topics interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
JUNOS Services Interfaces Configuration Guide
no-accept-data
See
no-preempt
See
interface
■ 177
JUNOS 9.1 High Availability Configuration Guide
preempt
Syntax
}
Hierarchy Level [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-id],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-id]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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 158.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
178 ■ 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-id],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-id]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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
Usage Guidelines
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)
See “Configuring Basic VRRP Support” on page 153.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
priority
■ 179
JUNOS 9.1 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-id track 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-id track interface
interface-name],
[edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp | vrrp-inet6-group) group-id track 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-id track interface
interface-name bandwidth-threshold bits-per-second],
[edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-id track route prefix routing-instance
instance-name],
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number family (inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-id track route
prefix routing-instance instance-name]
Release Information
Description
Statement introduced in JUNOS Release 8.1.
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
Usage Guidelines
priority
—The value subtracted from the configured VRRP priority when the tracked interface or route 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
See “Configuring a Logical Interface to Be Tracked” on page 159.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
180 ■ 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-id track],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp | vrrp-inet6-group) group-id track]
Release Information
Description
Statement introduced in JUNOS Release 8.1.
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
Usage Guidelines
seconds
—The minimum length of time that must elapse between dynamic priority changes.
Range: 1 through 3600 seconds
See “Configuring a Logical Interface to Be Tracked” on page 159.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
priority-hold-time
■ 181
JUNOS 9.1 High Availability Configuration Guide
route
Syntax
} route prefix routing-instance instance-name priority-cost priority;
Hierarchy Level [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-id track],
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number family (inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-id track]
Release Information
Description
Statement introduced in JUNOS Release 9.0.
Enable route tracking for a Virtual Router Redundancy Protocol (VRRP) group.
Options
prefix
—Route to be tracked for this VRRP group.
routing-instance instance-name —Routing instance in which the route is to be tracked.
If the route is in the default, or global, routing instance, the value for
instance-name must be default .
The remaining statement is described separately.
Usage Guidelines
See “Configuring a Route to Be Tracked” on page 161.
Required Privilege Level view-level—To view this statement in the configuration.
control-level—To add this statement to the configuration.
startup-silent-period
Syntax startup-silent-period seconds;
Hierarchy Level
[edit protocols vrrp]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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
Usage Guidelines
seconds
—Number of seconds.
Default: 4 seconds
Range: 1 through 2000 seconds
See “Configuring the Silent Period” on page 162.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
182 ■ route
Chapter 19: Summary of VRRP Configuration Statements
traceoptions
Syntax
} traceoptions { file { filename filename; files number; match regex; microsecond-stamp size size;
(world-readable | no-world-readable);
} flag flag;
Hierarchy Level
[edit protocols vrrp]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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 traceoptions
■ 183
JUNOS 9.1 High Availability Configuration Guide
■ 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 161.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
184 ■ traceoptions
Chapter 19: Summary of VRRP Configuration Statements
track
Syntax
} track {
bandwidth-threshold bits-per-second {
}
}
}
route prefix routing-instance instance-name {
priority-cost priority;
Hierarchy Level
[edit interfaces interface-name unit logical-unit-number family (inet | inet6) address
address (vrrp-group | vrrp-inet6-group) group-id],
[edit logical-router logical-router-name interfaces interface-name unit logical-unit-number
family (inet | inet6) address address (vrrp-group | vrrp-inet6-group) group-id]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
bandwidth-threshold option added in JUNOS Release 8.1.
route option added in JUNOS Release 9.0.
Enable logical interface tracking, route tracking, or both, 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 159 and “Configuring a
Route to Be Tracked” on page 161.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
track
■ 185
JUNOS 9.1 High Availability Configuration Guide
virtual-address
Syntax 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 vrrp-group group-id]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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 153.
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
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number
family inet6 address address vrrp-inet6-group group-id]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
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 153.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
186 ■ virtual-address
Chapter 19: Summary of VRRP Configuration Statements
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
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number
family inet6 address address vrrp-inet6-group group-id]
Release Information
Description
Statement introduced in JUNOS Release 8.4.
Configure a virtual link local address for 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 153.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
virtual-link-local-address
■ 187
JUNOS 9.1 High Availability Configuration Guide
vrrp-group
Syntax
}
(accept-data | no-accept-data);
authentication-type authentication;
}
track {
bandwidth-threshold bits-per-second {
}
}
}
route prefix routing-instance instance-name {
priority-cost priority;
}
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
Description
Statement introduced before JUNOS Release 7.4.
bandwidth-threshold option added in JUNOS Release 8.1.
route option added in JUNOS Release 9.0.
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-id
—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
3768. 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 151.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
188 ■ vrrp-group
Chapter 19: Summary of VRRP Configuration Statements
vrrp-inet6-group
Syntax
}
(accept-data | no-accept-data);
inet6-advertise-interval seconds;
}
track {
bandwidth-threshold bits-per-second {
}
}
}
route prefix routing-instance instance-name {
priority-cost priority;
}
virtual-inet6-address [ addresses ];
virtual-link-local-address ipv6-address
Hierarchy Level [edit interfaces interface-name unit logical-unit-number family inet6 address address],
[edit logical-routers logical-router-name interfaces interface-name unit logical-unit-number family inet6 address address]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
bandwidth-threshold option added in JUNOS Release 8.1.
route option added in JUNOS Release 9.0.
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-id
—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 151.
Required Privilege Level interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
vrrp-inet6-group
■ 189
JUNOS 9.1 High Availability Configuration Guide
190 ■ vrrp-inet6-group
Part 8
Unified ISSU
■
■
■
Unified ISSU Overview on page 193
Unified ISSU Configuration Guidelines on page 205
Unified ISSU Configuration Statements Summary on page 223
Unified ISSU
■ 191
JUNOS 9.1 High Availability Configuration Guide
192 ■
Unified ISSU
Chapter 20
Unified ISSU Overview
This chapter includes the following sections:
■
■
Unified ISSU Concepts on page 193
Unified ISSU System Requirements on page 198
Unified ISSU Concepts
A unified in-service software upgrade (unified ISSU) enables you to upgrade between two different JUNOS software releases with no disruption on the control plane and with minimal disruption of traffic. Unified ISSU is only supported on dual Routing
Engine platforms. In addition, the graceful Routing Engine switchover (GRES) and nonstop active routing (NSR) must be enabled.
A unified ISSU provides the following benefits:
■
Eliminates network downtime during software image upgrades
■
■
Reduces operating costs, while delivering higher service levels
Allows fast implementation of new features
NOTE: The master Routing Engine and backup Routing Engine must be running the same software version before you can perform a unified ISSU.
You cannot take any PICs online or offline during a unified ISSU.
To perform a unified ISSU, complete the following steps:
1.
Enable Graceful Routing Engine switchover and nonstop active routing. Verify that the Routing Engines and protocols are synchronized.
2.
3.
Download the new software package from the Juniper Networks Support Web site and then copy the package to the router.
Issue the request system software in-service-upgrade
command on the master
Routing Engine.
Unified ISSU Concepts
■ 193
JUNOS 9.1 High Availability Configuration Guide
A JUNOS release package comprises three distinct systems:
■
Juniper Networks Operating System, which provides system control and all the features and functions of the Juniper Networks router that executes in the Routing
Engines.
■
■
Juniper Networks Packet Forwarding Engine, which supports the high performance traffic forwarding and packet handling capabilities.
Interface control.
After the request system software in-service-upgrade command is issued, the following process occurs.
NOTE: In the illustrations, a solid line indicates the high-speed internal link between a Routing Engine and a Packet Forwarding Engine. A dotted line indicates the chassis process (chassisd), another method of communication between a Routing Engine and a Packet Forwarding Engine. RE0m and RE1s indicate master and backup (or standby) Routing Engines, respectively.
1.
The master Routing Engine validates the router configuration to ensure that it can be committed using the new software version. Checks are made for unsupported configurations and for unsupported Physical Interface Cards (PICs) and Flexible PIC Concentrators (FPCs). Unsupported PICs do not prevent a unified
ISSU. The software issues a warning to indicate that these PICs will restart during the upgrade. Similarly, an unsupported protocol configuration does not prevent a unified ISSU. The software issues a warning that packet loss may occur for the protocol during the upgrade.
2.
3.
When the validation succeeds, the kernel state synchronization daemon (ksyncd) synchronizes the kernel on the backup Routing Engine with the master Routing
Engine.
The backup Routing Engine is upgraded with the new software image. Before being upgraded, the backup Routing Engine gets the configuration file from the master Routing Engine and validates the configuration to ensure that it can be committed using the new software version. After being upgraded, it is
194 ■
Unified ISSU Concepts
Chapter 20: Unified ISSU Overview resynchronized with the master Routing Engine. In the illustration, an apostrophe
( ' ) indicates the device is running the new version of software.
4.
5.
The chassis process (chassisd) on the master Routing Engine prepares other software processes for the unified ISSU. When all the processes are ready, chassisd sends an ISSU_PREPARE message to the Flexible PIC Concentrators
(FPCs) installed in the router.
The Packet Forwarding Engine on each FPC saves its state and downloads the new software image from the backup Routing Engine. Next, each Packet
Forwarding Engine sends an ISSU_READY message to the chassis process
(chassisd).
6.
After receiving an ISSU_READY message from a Packet Forwarding Engine, the chassis process (chassisd) sends an ISSU_REBOOT message to the FPC on which the Packet Forwarding Engine resides. The FPC reboots with the new software image. After the FPC is rebooted, the Packet Forwarding Engine restores the FPC state and a high-speed internal link is established with the backup Routing Engine
Unified ISSU Concepts
■ 195
JUNOS 9.1 High Availability Configuration Guide
7.
running the new software. The chassis process (chassisd) is also re-established with the master Routing Engine.
After all Packet Forwarding Engines have sent a READY message via the chassis process (chassisd) on the master Routing Engine, other software processes are
196 ■
Unified ISSU Concepts
Chapter 20: Unified ISSU Overview prepared for a Routing Engine switchover. The system is ready for a switchover at this point.
8.
The Routing Engine switchover occurs and the backup Routing Engine becomes the new master Routing Engine.
9.
The new backup Routing Engine is now upgraded to the new software image.
(This step is skipped if the no-old-master-upgrade option is specified.)
Unified ISSU Concepts
■ 197
JUNOS 9.1 High Availability Configuration Guide
10.
When the backup Routing Engine has been successfully upgraded, the unified
ISSU is complete.
Unified ISSU System Requirements
This section contains the following topics:
■
■
■
■
■
Unified ISSU JUNOS Software Release Support on page 198
Unified ISSU Platform Support on page 199
Unified ISSU Protocol Support on page 199
Unified ISSU Feature Support on page 199
Unified ISSU PIC Support on page 200
Unified ISSU JUNOS Software Release Support
In order to perform a unified ISSU, your router must be running a JUNOS software
release that is ISSU capable for the specific platform. See “Unified ISSU Platform
Support” on page 199. You can use unified ISSU to upgrade from an ISSU-capable
software release to a newer software release. To downgrade from an ISSU-capable release to a previous software release (ISSU-capable or not), use the request system add command. See the JUNOS Software Installation and Upgrade Guide for details.
NOTE: Unified ISSU does not support extension application packages developed using the Juniper Partner Solution Development Platform (PSDP) SDK.
198 ■
Unified ISSU System Requirements
Chapter 20: Unified ISSU Overview
Unified ISSU Platform Support
Unified ISSU is supported on the following routing platforms:
■
■
■
■
M320 router
T320 router
T640 routing node
T1600 routing node
Unified ISSU Protocol Support
Unified ISSU is dependent on nonstop active routing. As with nonstop active routing, unified ISSU is supported for the following protocols:
■
■
Border Gateway Protocol (BGP), except for BGP VPN services
Intermediate System-to-Intermediate System (IS-IS)
■
■
Label Distribution Protocol (LDP)
Open Shortest Path First (OSPF)/OSPFv3
NOTE: Although Routing Information Protocol (RIP) and next generation RIP (RIPng) are supported for nonstop active routing, these protocols are not yet supported for unified ISSU.
NOTE: For routing protocols using bidirectional forwarding detection (BFD), when a
Routing Engine switchover occurs, the BFD session state is not saved.
Unified ISSU Feature Support
Unified ISSU supports most JUNOS software features. However, the following constraints apply:
■
Link Aggregation Control Protocol (LACP)—Link changes are not processed until after the unified ISSU is complete.
■
■
■
■
Automatic Protection Switching (APS)—Network changes are not processed until after the unified ISSU is complete.
Ethernet Operation, Administration, and Management (OAM) as defined by IEEE
802.3ah and by IEEE 802.1ag—When a Routing Engine switchover occurs, the
OAM hello times out, triggering protocol convergence.
Ethernet circuit cross-connect (CCC) encapsulation—Circuit changes are not processed until after the unified ISSU is complete.
Logical routers—Logical router configurations are not supported by unified ISSU.
Unified ISSU System Requirements
■ 199
JUNOS 9.1 High Availability Configuration Guide
Unified ISSU PIC Support
The following sections list the Physical Interface Cards (PICs) that are supported during a unified ISSU.
■
■
■
■
■
■
■
■
PIC Considerations on page 200
Fast Ethernet and Gigabit Ethernet PICs on page 202
Tunnel Services PICs on page 203
NOTE: For information about FPC types, FPC/PIC compatibility, and the initial JUNOS software release in which an FPC supported a particular PIC, see the PIC guide for your router platform.
PIC Considerations
Take the following PIC restrictions into consideration before performing a unified
ISSU:
■
Unsupported PICs—If a PIC is not supported by unified ISSU, at the beginning of the upgrade the software issues a warning that the PIC will be brought offline.
After the PIC is brought offline and the ISSU is complete, the PIC is brought back online with the new firmware.
■
PIC combinations—For some PICs, newer JUNOS services can require significant
Internet Processor ASIC memory, and some configuration rules might limit certain combinations of PICs on particular platforms. With a unified ISSU:
■
If a PIC combination is not supported by the software version that the router is being upgraded from, the upgrade will be aborted.
■
If a PIC combination is not supported by the software version to which the router is being upgraded, the in-service software upgrade will abort, even if the PIC combination is supported by the software version from which the router is being upgraded.
■
Interface statistics—Interface statistics might be incorrect because:
■
During bootup of the new microkernel on the Packet Forwarding Engine
(PFE), host-bound traffic is not handled and might be dropped, causing packet loss.
■
During the hardware update of the Packet Forwarding Engine and its interfaces, traffic is halted and discarded. (The duration of the hardware update depends on the number and type of interfaces and on the router configuration.)
200 ■
Unified ISSU System Requirements
Chapter 20: Unified ISSU Overview
■
■
During a unified ISSU, periodic statistics collection is halted. If hardware counters saturate or wrap around, the software does not display accurate interface statistics.
CIR oversubscription—If oversubscription of committed rate information (CIR) is configured on logical interfaces:
■
■
And the sum of the CIR exceeds the physical interface's bandwidth, after a unified in-service software upgrade is performed, each logical interface might not be given its original CIR.
And the sum of the delay buffer rate configured on logical interfaces exceeds the physical interface's bandwidth, after a unified in-service software upgrade is performed, each logical interface might not receive its original delay-buffer-rate calculation.
SONET/SDH PICs
Table 11 on page 201 lists the SONET/SDH PICs that are supported during a unified
ISSU.
Table 11: Unified ISSU Supported SONET/SDH PICs
PIC Type
OC3c/STM1
Number of Ports Model Number
4-port PB-4OC3-SON-MM
PB-4OC3-SON-SMIR
PB-4OC3-0C12-SON-SFP OC3c/STM1, SFP (Multi-Rate) 4 OC3 ports, 4
OC12 ports
4 OC3 ports, 1
OC12 port
OC12c/STM4 1-port
OC12c/STM4, SFP
OC48c/STM16, SFP
OC192/STM64, XFP
4-port
1-port
1-port
4-port
1
PB-4OC3-0C12-SON2-SFP
PB-1OC12-SON-MM
PB-1OC12-SON-SMIR
PB-4OC12-SON-MM
PB-4OC12-SON-SMIR
PB-1OC12-SON-SFP
PB-1OC48-SON-SFP
PB-1OC48-SON-B-SFP
PC-4OC48-SON-SFP
PC-1OC192-SON-LR,
PC-1OC192-SON-SR2
PC-1OC192-VSR
Router
M320, T320, T640
M320, T320, T640
M320, T320, T640
M320, T320, T640
M320, T320, T640
M320, T320, T640
Unified ISSU System Requirements
■ 201
JUNOS 9.1 High Availability Configuration Guide
Table 11: Unified ISSU Supported SONET/SDH PICs (continued)
PIC Type
OC192/STM64, XFP
Number of Ports Model Number
4 PD-4OC192-SON-XFP
Router
T640, T1600
Fast Ethernet and Gigabit Ethernet PICs
Table 12 on page 202 lists the Fast Ethernet and Gigabit Ethernet PICs that are
supported during a unified ISSU.
Table 12: Unified ISSU Supported Fast Ethernet and Gigabit Ethernet PICs
PIC Type
Fast Ethernet
Fast Ethernet
Fast Ethernet
Fast Ethernet
Gigabit Ethernet, SFP
Gigabit Ethernet IQ, SFP
Gigabit Ethernet IQ2, SFP
Gigabit Ethernet IQ2, XFP
10-Gigabit Ethernet, XENPAK 1
10-Gigabit Ethernet, DWDM 1
8
8
1
10
1
2
4
Number of Ports
4
8
12
48
1
2 or 4
Model Number
PB-4FE-TX
PB-8FE-FX
PB-12FE-TX-MDI
PB-12FE-TX-MDIX
PB-48FE-TX-MDI
PB-48FE-TX-MDIX
PB-1GE-SFP
PB-2GE-SFP
PB-4GE-SFP
PC-10GE-SFP
PB-1GE-SFP-QPP
PB-2GE-SFP-QPP
PB-4GE-TYPE1-SFP-IQ2
PB-8GE-TYPE2-SFP-IQ2
PC-8GE-TYPE3-XFP-IQ2
PC-1XGE-TYPE3-XFP-IQ2
PC-1XGE-XENPAK
PC-1XGE-DWDM-CBAND
Router
M320, T320, T640
M320
M320, T320
M320, T320
M320, T320, T640
M320, T320, T640
M320, T320, T640
M320, T320, T640
M320, T320, T640
M320, T320, T640
202 ■
Unified ISSU System Requirements
Chapter 20: Unified ISSU Overview
Channelized PICs
Table 13 on page 203 lists the channelized PICs that are supported during a unified
ISSU.
Table 13: Unified ISSU Supported Channelized PICs
PIC Type
Channelized E1 IQ
Channelized T1 IQ
Channelized OC IQ
Number of Ports
10
10
1
Channelized DS3 to DS0 IQ 4
Model Number
PB-10CHE1-RJ48-QPP
PB-10CHT1-RJ48-QPP
PB-1CHOC12SMIR-QPP
PB-1CHSTM1-SMIR-QPP
PB-1CHOC3-SMIR-QPP
PB-4CHDS3-QPP
Platform
M320, T320, T640
M320, T320, T640
M320, T320, T640
M320, T320, T640
Tunnel Services PICs
Table 14 on page 203 lists the tunnel services PICs that are supported during a unified
ISSU.
Table 14: Unified ISSU Supported Tunnel Services PICs
PIC Type
1-Gbps Tunnel
4-Gbps Tunnel
10-Gbps Tunnel
Model Number
PB-TUNNEL-1
PB-TUNNEL
PC-TUNNEL
Platform
M320, T320, T640
ATM PICs
Table 15 on page 203 lists the ATM PICs that are supported during a unified ISSU.
This includes support on Enhanced III FPCs.
Table 15: Unified ISSU Supported ATM PICs
PIC Type
OC3/STM1
Number of Ports
2
Model Number
PB-2OC3-ATM2-MM
PB-2OC3-ATM2-SMIR
Platform
M320, T320, T640, T1600
Unified ISSU System Requirements
■ 203
JUNOS 9.1 High Availability Configuration Guide
Table 15: Unified ISSU Supported ATM PICs (continued)
PIC Type
OC12/STM4
Number of Ports
1
OC12/STM4 2
Model Number
PB-1OC12-ATM2-MM
PB-1OC12-ATM2-SMIR
PB-2OC12-ATM2-MM
PB-2OC12-ATM2-SMIR
Platform
M320, T320, T640, T1600
M320, T320, T640, T1600
Serial PICs
The 2–port EIA–530 serial PIC (Model Number PB-2EIA530) is supported during a unified ISSU only on Enhanced III FPCs in M320 routers.
E3 PICs
The 4–port E3 IQ PIC (Model Number PB-4E3-QPP) is supported during a unified
ISSU on M320, T320, and T640 routers.
204 ■
Unified ISSU System Requirements
Chapter 21
Unified ISSU Configuration Guidelines
■
■
■
■
■
■
Performing a Unified ISSU on page 208
Verifying a Unified ISSU on page 221
Troubleshooting Unified ISSU Problems on page 221
Managing and Tracing BFD Sessions During Unified ISSU Procedures on page 222
Best Practices
When you are planning to perform a unified in-service software upgrade (unified
ISSU), choose a time when your network is as stable as possible. As with a normal upgrade, Telnet sessions, SNMP, and CLI access are briefly interrupted. In addition, the following restrictions apply:
■
■
The master Routing Engine and backup Routing Engine must be running the same software version before you can perform a unified ISSU.
During a unified ISSU, you cannot bring any PICs online or offline.
Before You Begin
Before you begin a unified ISSU, complete the tasks in the following sections:
■
■
■
Verify That the Master and Backup Routing Engines Are Running the Same
Back Up the Router's Software on page 206
Verify That Graceful Routing Engine Switchover and Nonstop Active Routing Are
Best Practices
■ 205
JUNOS 9.1 High Availability Configuration Guide
Verify That the Master and Backup Routing Engines Are Running the Same Software
Version
To verify that both Routing Engines are running the same version of software, issue the following command:
{master} user@host> show version invoke-on all-routing-engines re0:
--------------------------------------------------------------------------
Hostname: host
Model: m320
JUNOS Base OS boot [9.0-20071210.0]
JUNOS Base OS Software Suite [9.0-20071210.0]
JUNOS Kernel Software Suite [9.0-20071210.0]
JUNOS Crypto Software Suite [9.0-20071210.0]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.0-20071210.0]
JUNOS Packet Forwarding Engine Support (M320) [9.0-20071210.0]
JUNOS Online Documentation [9.0-20071210.0]
JUNOS Routing Software Suite [9.0-20071210.0] re1:
--------------------------------------------------------------------------
Hostname: host
Model: m320
JUNOS Base OS boot [9.0-20071210.0]
JUNOS Base OS Software Suite [9.0-20071210.0]
JUNOS Kernel Software Suite [9.0-20071210.0]
JUNOS Crypto Software Suite [9.0-20071210.0]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.0-20071210.0]
JUNOS Packet Forwarding Engine Support (M320) [9.0-20071210.0]
JUNOS Online Documentation [9.0-20071210.0]
JUNOS Routing Software Suite [9.0-20071210.0]
If both Routing Engines are not running the same software version, issue the request system software add command on the desired Routing Engine so that the software version is the same. For more information, see the JUNOS Software Installation and
Upgrade Guide.
Back Up the Router's Software
As a preventive measure in case any problems occur during an upgrade, issue the request system snapshot command on each Routing Engine to back up the system software to the router’s hard disk. The following is an example of issuing the command on the master Routing Engine:
{master} user@host> request system snapshot
Verifying compatibility of destination media partitions...
Running newfs (220MB) on hard-disk media / partition (ad1s1a)...
Running newfs (24MB) on hard-disk media /config partition (ad1s1e)...
Copying '/dev/ad0s1a' to '/dev/ad1s1a' .. (this may take a few minutes)
Copying '/dev/ad0s1e' to '/dev/ad1s1e' .. (this may take a few minutes)
The following filesystems were archived: / /config
206 ■
Before You Begin
Chapter 21: Unified ISSU Configuration Guidelines
NOTE: The root file system is backed up to /altroot , and /config is backed up to
/altconfig
. After you issue the request system snapshot
command, the router’s flash and hard disks are identical. You can return to the previous version of the software only by booting the router from removable media. For more information about the request system snapshot command, see the JUNOS System Basics Configuration Guide.
Verify That Graceful Routing Engine Switchover and Nonstop Active Routing Are Configured
Before you begin a unified ISSU, ensure that graceful Routing Engine switchover and nonstop active routing are configured on your router.
1.
To verify graceful Routing Engine switchover is configured, on the backup Routing
Engine ( re1
) issue the show system switchover
command. The output should be similar to the following example. The
Graceful switchover
field state must be
On
.
{backup} user@host> show system switchover
Graceful switchover: On
Configuration database: Ready
Kernel database: Ready
Peer state: Steady State
2.
To verify nonstop active routing is configured, on the master Routing Engine
( re0 ) issue the show task replication command. The output should be similar to the following example.
{master} user@host> show task replication
Stateful Replication: Enabled
RE mode: Master
Protocol Synchronization Status
OSPF Complete
IS-IS Complete
If graceful Routing Engine switchover and nonstop active routing are not configured, complete the following steps:
1.
2.
3.
On the master Routing Engine ( re0 ), enable graceful Routing Engine switchover.
Include the graceful-switchover
statement at the
[edit chassis redundancy]
hierarchy level.
On the master Routing Engine, enable nonstop active routing. Include the commit synchronize statement at the [edit system] hierarchy level and the nonstop-routing statement at the [edit routing-options] hierarchy level.
On the master Router Engine, issue the commit
command.
Before You Begin
■ 207
JUNOS 9.1 High Availability Configuration Guide
The system provides the following confirmation that the master and backup
Routing Engines are synchronized: re0: configuration check succeeds re1: commit complete re0: commit complete
Performing a Unified ISSU
You can perform a unified ISSU in one of three ways:
■
■
■
Upgrading and Rebooting Both Routing Engines Automatically on page 208
Upgrading Both Routing Engines and Rebooting the New Backup Routing Engine
Upgrading and Rebooting Only One Routing Engine on page 218
Upgrading and Rebooting Both Routing Engines Automatically
When you issue the request system software in-service-upgrade command with the reboot option, the system automatically upgrades both Routing Engines to the newer software and reboots both Routing Engines. This option enables you to complete the unified ISSU with a single command.
To perform a unified ISSU using the request system software in-service-upgrade
package-name reboot
command, complete the following steps:
1.
2.
Download the software package from the Juniper Networks Support Web site, http://www.juniper.net/support/
. Choose the Canada and U.S., Worldwide, or
JUNOS-FIPS edition. Place the package on a local server. To download the package, you must have a service contract and an access account. If you do not have an access account, complete the registration form at the Juniper Networks
Web site: https://www.juniper.net/registration/Register.jsp
.
Copy the package to the router. We recommend that you copy it to the
/var/tmp directory, which is a large file system on the hard disk.
user@host>file copy
ftp://username:prompt@ftp.hostname.net/filename/var/tmp/filename
3.
To verify the current software version running on both Routing Engines, on the master Routing Engine issue the show version invoke-on all-routing-engines command. The following example shows that both Routing Engines are running an image of JUNOS 9.0 software that was built on December 11, 2007:
{backup} user@host> show version invoke-on all-routing-engines
208 ■
Performing a Unified ISSU
Chapter 21: Unified ISSU Configuration Guidelines re0:
--------------------------------------------------------------------------
Hostname: host
Model: m320
JUNOS Base OS boot [9.0-20071211.2]
JUNOS Base OS Software Suite 9.0-20071211.2]
JUNOS Kernel Software Suite [9.0-20071211.2]
JUNOS Crypto Software Suite [9.0-20071211.2]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.0-20071211.2]
JUNOS Packet Forwarding Engine Support (M320) [9.0-20071211.2]
JUNOS Online Documentation [9.0-20071211.2]
JUNOS Routing Software Suite [9.0-20071211.2] re1:
--------------------------------------------------------------------------
Hostname: host1
Model: m320
JUNOS Base OS boot [9.0-20071211.2]
JUNOS Base OS Software Suite [9.0-20071211.2]
JUNOS Kernel Software Suite [9.0-20071211.20]
JUNOS Crypto Software Suite [9.0-20071211.2]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.0-20071211.2]
JUNOS Packet Forwarding Engine Support (M320) [9.0-20071211.2]
JUNOS Online Documentation [9.0-20071211.2]
JUNOS Routing Software Suite [9.0-20071211.2]
4.
On the master Routing Engine, issue the request system software in-service-upgrade
package-name reboot
command. The following example upgrades the current version to an image of JUNOS 9.0 software that was built on January 14, 2008:
{master} user@host> request system software in-service-upgrade
/var/tmp/jinstall-9.0-20080114.2-domestic-signed.tgz reboot
ISSU: Validating Image
PIC 0/3 will be offlined (In-Service-Upgrade not supported)
Do you want to continue with these actions being taken ? [yes,no] (no) yes
ISSU: Preparing Backup RE
Pushing bundle to re1
Checking compatibility with configuration
Initializing...
Using jbase-9.0-20080114.2
Verified manifest signed by PackageProduction_9_0_0
Using /var/tmp/jinstall-9.0-20080114.2-domestic-signed.tgz
Verified jinstall-9.0-20080114.2-domestic.tgz signed by
PackageProduction_9_0_0
Using jinstall-9.0-20080114.2-domestic.tgz
Using jbundle-9.0-20080114.2-domestic.tgz
Checking jbundle requirements on /
Using jbase-9.0-20080114.2.tgz
Verified manifest signed by PackageProduction_9_0_0
Using jkernel-9.0-20080114.2.tgz
Verified manifest signed by PackageProduction_9_0_0
Using jcrypto-9.0-20080114.2.tgz
Verified manifest signed by PackageProduction_9_0_0
Using jpfe-9.0-20080114.2.tgz
Performing a Unified ISSU
■ 209
JUNOS 9.1 High Availability Configuration Guide
210 ■
Performing a Unified ISSU
Using jdocs-9.0-20080114.2.tgz
Verified manifest signed by PackageProduction_9_0_0
Using jroute-9.0-20080114.2.tgz
Verified manifest signed by PackageProduction_9_0_0
Hardware Database regeneration succeeded
Validating against /config/juniper.conf.gz
mgd: commit complete
Validation succeeded
Installing package '/var/tmp/jinstall-9.0-20080114.2-domestic-signed.tgz'
...
Verified jinstall-9.0-20080114.2-domestic.tgz signed by
PackageProduction_9_0_0
Adding jinstall...
Verified manifest signed by PackageProduction_9_0_0
WARNING: This package will load JUNOS 9.0-20080114.2 software.
WARNING: It will save JUNOS configuration files, and SSH keys
WARNING: (if configured), but erase all other files and information
WARNING: stored on this machine. It will attempt to preserve dumps
WARNING: and log files, but this can not be guaranteed. This is the
WARNING: pre-installation stage and all the software is loaded when
WARNING: you reboot the system.
Saving the config files ...
NOTICE: uncommitted changes have been saved in
/var/db/config/juniper.conf.pre-install
Installing the bootstrap installer ...
WARNING: A REBOOT IS REQUIRED TO LOAD THIS SOFTWARE CORRECTLY. Use the
WARNING: 'request system reboot' command when software installation is
WARNING: complete. To abort the installation, do not reboot your system,
WARNING: instead use the 'request system software delete jinstall'
WARNING: command as soon as this operation completes.
Saving package file in
/var/sw/pkg/jinstall-9.0-20080114.2-domestic-signed.tgz ...
Saving state for rollback ...
Backup upgrade done
Rebooting Backup RE
Rebooting re1
ISSU: Backup RE Prepare Done
Waiting for Backup RE reboot
GRES operational
Initiating Chassis In-Service-Upgrade
Chassis ISSU started
ISSU: Backup RE Prepare Done
ISSU: Preparing Daemons
ISSU: Daemons Ready for ISSU
ISSU: Starting Upgrade for FRUs
ISSU: Preparing for Switchover
ISSU: Ready for Switchover
Checking In-Service-Upgrade status
Item Status Reason
FPC 0 Online (ISSU)
FPC 1 Online (ISSU)
FPC 2 Online (ISSU)
FPC 6 Online (ISSU)
Chapter 21: Unified ISSU Configuration Guidelines
FPC 7 Online (ISSU)
Resolving mastership...
Complete. The other routing engine becomes the master.
ISSU: RE switchover Done
ISSU: Upgrading Old Master RE
Installing package '/var/tmp/paKEuy' ...
Verified jinstall-9.0-20080114.2-domestic.tgz signed by
PackageProduction_9_0_0
Adding jinstall...
Verified manifest signed by PackageProduction_9_0_0
WARNING: This package will load JUNOS 9.0-20080114.2 software.
WARNING: It will save JUNOS configuration files, and SSH keys
WARNING: (if configured), but erase all other files and information
WARNING: stored on this machine. It will attempt to preserve dumps
WARNING: and log files, but this can not be guaranteed. This is the
WARNING: pre-installation stage and all the software is loaded when
WARNING: you reboot the system.
Saving the config files ...
NOTICE: uncommitted changes have been saved in
/var/db/config/juniper.conf.pre-install
Installing the bootstrap installer ...
WARNING: A REBOOT IS REQUIRED TO LOAD THIS SOFTWARE CORRECTLY. Use the
WARNING: 'request system reboot' command when software installation is
WARNING: complete. To abort the installation, do not reboot your system,
WARNING: instead use the 'request system software delete jinstall'
WARNING: command as soon as this operation completes.
Saving package file in
/var/sw/pkg/jinstall-9.0-20080114.2-domestic-signed.tgz ...
cp: /var/tmp/paKEuy is a directory (not copied).
Saving state for rollback ...
ISSU: Old Master Upgrade Done
ISSU: IDLE
Shutdown NOW!
Reboot consistency check bypassed - jinstall 9.0-20080114.2 will complete
installation upon reboot
[pid 30227]
*** FINAL System shutdown message from root@host ***
System going down IMMEDIATELY
Connection to host closed.
5.
When the new backup (old master) Routing Engine is rebooted, you are logged off the router.
After waiting a few minutes, log in to the router again. You are logged in to the new backup Routing Engine ( re0 ). To verify that both Routing Engines have been upgraded, issue the following command:
{backup}
Performing a Unified ISSU
■ 211
JUNOS 9.1 High Availability Configuration Guide user@host> show version invoke-on all-routing-engines re0:
--------------------------------------------------------------------------
Hostname: host
Model: m320
JUNOS Base OS boot [9.0-20080114.2]
JUNOS Base OS Software Suite 9.0-20080114.2]
JUNOS Kernel Software Suite [9.0-20080114.2]
JUNOS Crypto Software Suite [9.0-20080114.2]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.0-20080114.2]
JUNOS Packet Forwarding Engine Support (M320) [9.0-20080114.2]
JUNOS Online Documentation [9.0-20080114.2]
JUNOS Routing Software Suite [9.0-20080114.2] re1:
--------------------------------------------------------------------------
Hostname: host1
Model: m320
JUNOS Base OS boot [9.0-20080114.2]
JUNOS Base OS Software Suite [9.0-20080114.2]
JUNOS Kernel Software Suite [9.0-20080114.2]
JUNOS Crypto Software Suite [9.0-20080114.2]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.0-20080114.2]
JUNOS Packet Forwarding Engine Support (M320) [9.0-20080114.2]
JUNOS Online Documentation [9.0-20080114.2]
JUNOS Routing Software Suite [9.0-20080114.2]
6.
To make re0
the master Routing Engine, issue the following command:
{backup} user@host> request chassis routing-engine master acquire
Attempt to become the master routing engine ? [yes,no] (no) yes
Resolving mastership...
Complete. The local routing engine becomes the master.
{master} user@host>
7.
Issue the request system snapshot command on each Routing Engine to back up the system software to the router’s hard disk.
NOTE: The root file system is backed up to
/altroot
, and
/config
is backed up to
/altconfig
. After you issue the request system snapshot
command, the router’s flash and hard disks are identical. You can return to the previous version of the software only by booting the router from removable media.
212 ■
Performing a Unified ISSU
Chapter 21: Unified ISSU Configuration Guidelines
Upgrading Both Routing Engines and Rebooting the New Backup Routing Engine Manually
When you issue the request system software in-service-upgrade command without any options, the system upgrades and reboots the new master Routing Engine to the newer software. The new software is placed on the new backup (old master)
Routing Engine; however, to complete the upgrade, you must issue the request system reboot command on the new backup Routing Engine.
To perform a unified ISSU using the request system software in-service-upgrade
package-name
command without any options, complete the following steps:
1.
Download the software package from the Juniper Networks Support Web site, http://www.juniper.net/support/
. Choose the Canada and U.S., Worldwide, or
JUNOS-FIPS edition. Place the package on a local server. To download the package, you must have a service contract and an access account. If you do not have an access account, complete the registration form at the Juniper Networks
Web site: https://www.juniper.net/registration/Register.jsp
.
2.
Copy the package to the router. We recommend that you copy it to the /var/tmp directory, which is a large file system on the hard disk.
user@host>file copy
ftp://username:prompt@ftp.hostname.net/filename/var/tmp/filename
3.
To verify the current software version running on both Routing Engines, on the master Routing Engine issue the show version invoke-on all-routing-engines command. The following example shows that both Routing Engines are running
JUNOS Release 9.0R1:
{master} user@host> show version invoke-on all-routing-engines re0:
--------------------------------------------------------------------------
Hostname: host
Model: m320
JUNOS Base OS boot [9.0R1]
JUNOS Base OS Software Suite [9.0R1]
JUNOS Kernel Software Suite [9.0R1]
JUNOS Crypto Software Suite [9.0R1]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.0R1]
JUNOS Packet Forwarding Engine Support (M320) [9.0R1]
JUNOS Online Documentation [9.0R1]
JUNOS Routing Software Suite [9.0R1] re1:
--------------------------------------------------------------------------
Hostname: host1
Model: m320
JUNOS Base OS boot [9.0R1]
JUNOS Base OS Software Suite [9.0R1]
JUNOS Kernel Software Suite [9.0R1]
JUNOS Crypto Software Suite [9.0R1]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.0R1]
JUNOS Packet Forwarding Engine Support (M320) [9.0R1]
Performing a Unified ISSU
■ 213
JUNOS 9.1 High Availability Configuration Guide
JUNOS Online Documentation [9.0R1]
JUNOS Routing Software Suite [9.0R1]
4.
On the master Routing Engine, issue the request system software in-service-upgrade
package-name
command. The following example upgrades the current version to JUNOS Release 9.0R1.2: user@host> request system software in-service-upgrade
/var/tmp/jinstall-9.0R1.2-domestic-signed.tgz
ISSU: Validating Image
FPC 4 will be offlined (In-Service-Upgrade not supported)
Do you want to continue with these actions being taken ? [yes,no] (no) yes
ISSU: Preparing Backup RE
Pushing bundle to re1
Checking compatibility with configuration
Initializing...
Using jbase-9.0-20080117.0
Verified manifest signed by PackageProduction_9_0_0
Using /var/tmp/jinstall-9.0R1.2-domestic-signed.tgz
Verified jinstall-9.0R1.2-domestic.tgz signed by PackageProduction_9_0_0
Using jinstall-9.0R1.2-domestic.tgz
Using jbundle-9.0R1.2-domestic.tgz
Checking jbundle requirements on /
Using jbase-9.0R1.2.tgz
Verified manifest signed by PackageProduction_9_0_0
Using jkernel-9.0R1.2.tgz
Verified manifest signed by PackageProduction_9_0_0
Using jcrypto-9.0R1.2.tgz
Verified manifest signed by PackageProduction_9_0_0
Using jpfe-9.0R1.2.tgz
Using jdocs-9.0R1.2.tgz
Verified manifest signed by PackageProduction_9_0_0
Using jroute-9.0R1.2.tgz
Verified manifest signed by PackageProduction_9_0_0
Hardware Database regeneration succeeded
Validating against /config/juniper.conf.gz
mgd: commit complete
Validation succeeded
Installing package '/var/tmp/jinstall-9.0R1.2-domestic-signed.tgz' ...
Verified jinstall-9.0R1.2-domestic.tgz signed by PackageProduction_9_0_0
Adding jinstall...
Verified manifest signed by PackageProduction_9_0_0
WARNING: This package will load JUNOS 9.0R1.2 software.
WARNING: It will save JUNOS configuration files, and SSH keys
WARNING: (if configured), but erase all other files and information
WARNING: stored on this machine. It will attempt to preserve dumps
WARNING: and log files, but this can not be guaranteed. This is the
WARNING: pre-installation stage and all the software is loaded when
WARNING: you reboot the system.
Saving the config files ...
NOTICE: uncommitted changes have been saved in
/var/db/config/juniper.conf.pre-install
Installing the bootstrap installer ...
214 ■
Performing a Unified ISSU
Chapter 21: Unified ISSU Configuration Guidelines
WARNING: A REBOOT IS REQUIRED TO LOAD THIS SOFTWARE CORRECTLY. Use the
WARNING: 'request system reboot' command when software installation is
WARNING: complete. To abort the installation, do not reboot your system,
WARNING: instead use the 'request system software delete jinstall'
WARNING: command as soon as this operation completes.
Saving package file in /var/sw/pkg/jinstall-9.0R1.2-domestic-signed.tgz
...
Saving state for rollback ...
Backup upgrade done
Rebooting Backup RE
Rebooting re1
ISSU: Backup RE Prepare Done
Waiting for Backup RE reboot
GRES operational
Initiating Chassis In-Service-Upgrade
Chassis ISSU started
ISSU: Backup RE Prepare Done
ISSU: Preparing Daemons
ISSU: Daemons Ready for ISSU
ISSU: Starting Upgrade for FRUs
ISSU: Preparing for Switchover
ISSU: Ready for Switchover
Checking In-Service-Upgrade status
Item Status Reason
FPC 0 Online (ISSU)
FPC 1 Online (ISSU)
FPC 2 Online (ISSU)
FPC 3 Online (ISSU)
FPC 4 Offline Offlined by cli command
FPC 5 Online (ISSU)
Resolving mastership...
Complete. The other routing engine becomes the master.
ISSU: RE switchover Done
ISSU: Upgrading Old Master RE
Installing package '/var/tmp/paeBi5' ...
Verified jinstall-9.0R1.2-domestic.tgz signed by PackageProduction_9_0_0
Adding jinstall...
Verified manifest signed by PackageProduction_9_0_0
WARNING: This package will load JUNOS 9.0R1.2 software.
WARNING: It will save JUNOS configuration files, and SSH keys
WARNING: (if configured), but erase all other files and information
WARNING: stored on this machine. It will attempt to preserve dumps
WARNING: and log files, but this can not be guaranteed. This is the
WARNING: pre-installation stage and all the software is loaded when
WARNING: you reboot the system.
Saving the config files ...
NOTICE: uncommitted changes have been saved in
/var/db/config/juniper.conf.pre-install
Installing the bootstrap installer ...
WARNING: A REBOOT IS REQUIRED TO LOAD THIS SOFTWARE CORRECTLY. Use the
WARNING: 'request system reboot' command when software installation is
Performing a Unified ISSU
■ 215
JUNOS 9.1 High Availability Configuration Guide
WARNING: complete. To abort the installation, do not reboot your system,
WARNING: instead use the 'request system software delete jinstall'
WARNING: command as soon as this operation completes.
Saving package file in /var/sw/pkg/jinstall-9.0R1.2-domestic-signed.tgz
...
cp: /var/tmp/paeBi5 is a directory (not copied).
Saving state for rollback ...
ISSU: Old Master Upgrade Done
ISSU: IDLE
5.
Issue the show version invoke-on all-routing-engines command to verify that the new backup (old master) Routing Engine ( re0
), is still running the previous software image, while the new master Routing Engine ( re1 ) is running the new software image:
{backup} user@host> show version re0:
--------------------------------------------------------------------------
Hostname: user
Model: m320
JUNOS Base OS boot [9.0R1]
JUNOS Base OS Software Suite [9.0R1]
JUNOS Kernel Software Suite [9.0R1]
JUNOS Crypto Software Suite [9.0R1]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.0R1]
JUNOS Packet Forwarding Engine Support (M320) [9.0R1]
JUNOS Online Documentation [9.0R1]
JUNOS Routing Software Suite [9.0R1] labpkg [7.0]
JUNOS Installation Software [9.0R1.2] re1:
--------------------------------------------------------------------------
Hostname: user1
Model: m320
JUNOS Base OS boot [9.0R1.2]
JUNOS Base OS Software Suite [9.0R1.2]
JUNOS Kernel Software Suite [9.0R1.2]
JUNOS Crypto Software Suite [9.0R1.2]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.0R1.2]
JUNOS Packet Forwarding Engine Support (M320) [9.0R1.2]
JUNOS Online Documentation [9.0R1.2]
JUNOS Routing Software Suite [9.0R1.2]
6.
7.
At this point, if you choose not to install the newer software version on the new backup Routing Engine ( re1 ), you can issue the request system software delete jinstall command on it. Otherwise, to complete the upgrade, go to the next step.
Reboot the new backup Routing Engine ( re0
) by issuing the request system reboot command:
{backup}
216 ■
Performing a Unified ISSU
Chapter 21: Unified ISSU Configuration Guidelines user@host> request system reboot
Reboot the system ? [yes,no] (no) yes
Shutdown NOW!
Reboot consistency check bypassed - jinstall 9.0R1.2 will complete installation upon reboot
[pid 6170]
{backup} user@host>
System going down IMMEDIATELY
Connection to host closed by remote host.
Connection to host closed.
8.
If you are not on the console port, you are disconnected from the router session.
After waiting a few minutes, log in to the router again. You are logged in to the new backup Routing Engine ( re0 ). To verify that both Routing Engines have been upgraded, issue the following command:
{backup} user@host> show version invoke-on all-routing-engines re0:
--------------------------------------------------------------------------
Hostname: host
Model: m320
JUNOS Base OS boot [9.0R1.2]
JUNOS Base OS Software Suite [9.0R1.2]
JUNOS Kernel Software Suite [9.0R1.2]
JUNOS Crypto Software Suite [9.0R1.2]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.0R1.2]
JUNOS Packet Forwarding Engine Support (M320) [9.0R1.2]
JUNOS Online Documentation [9.0R1.2]
JUNOS Routing Software Suite [9.0R1.2] re1:
--------------------------------------------------------------------------
Hostname: host1
Model: m320
JUNOS Base OS boot [9.0R1.2]
JUNOS Base OS Software Suite [9.0R1.2]
JUNOS Kernel Software Suite [9.0R1.2]
JUNOS Crypto Software Suite [9.0R1.2]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.0R1.2]
JUNOS Packet Forwarding Engine Support (M320) [9.0R1.2]
JUNOS Online Documentation [9.0R1.2]
JUNOS Routing Software Suite [9.0R1.2]
9.
To make re0 the master Routing Engine, issue the following command:
{backup}
Performing a Unified ISSU
■ 217
JUNOS 9.1 High Availability Configuration Guide user@host> request chassis routing-engine master acquire
Attempt to become the master routing engine ? [yes,no] (no) yes
Resolving mastership...
Complete. The local routing engine becomes the master.
{master} user@host>
10.
Issue the request system snapshot
command on each Routing Engine to back up the system software to the router’s hard disk.
NOTE: The root file system is backed up to /altroot , and /config is backed up to
/altconfig . After you issue the request system snapshot command, the router’s flash and hard disks are identical. You can return to the previous version of the software only by booting the router from removable media.
Upgrading and Rebooting Only One Routing Engine
When you issue the request system software in-service-upgrade
command with the no-old-master-upgrade option, the system upgrades and reboots only the new master
Routing Engine. To upgrade the new backup (former master) Routing Engine, you must issue the request system software add command.
To perform a unified ISSU using the request system software in-service-upgrade
package-name no-old-master-upgrade commands, complete the following steps:
1.
Download the software package from the Juniper Networks Support Web site, http://www.juniper.net/support/
. Choose the Canada and U.S., Worldwide, or
JUNOS-FIPS edition. Place the package on a local server. To download the package, you must have a service contract and an access account. If you do not have an access account, complete the registration form at the Juniper Networks
Web site: https://www.juniper.net/registration/Register.jsp
.
2.
Copy the package to the router. We recommend that you copy it to the
/var/tmp directory, which is a large file system on the hard disk.
user@host>file copy
ftp://username:prompt@ftp.hostname.net/filename/var/tmp/filename
3.
To verify the current software version running on both Routing Engines, on the master Routing Engine issue the show version invoke-on all-routing-engines command. The following example shows that both Routing Engines are running an image of JUNOS 9.0 software that was built on December 11, 2007:
{backup} user@host> show version invoke-on all-routing-engines
218 ■
Performing a Unified ISSU
Chapter 21: Unified ISSU Configuration Guidelines re0:
--------------------------------------------------------------------------
Hostname: host
Model: m320
JUNOS Base OS boot [9.0-20071211.2]
JUNOS Base OS Software Suite 9.0-20071211.2]
JUNOS Kernel Software Suite [9.0-20071211.2]
JUNOS Crypto Software Suite [9.0-20071211.2]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.0-20071211.2]
JUNOS Packet Forwarding Engine Support (M320) [9.0-20071211.2]
JUNOS Online Documentation [9.0-20071211.2]
JUNOS Routing Software Suite [9.0-20071211.2] re1:
--------------------------------------------------------------------------
Hostname: host1
Model: m320
JUNOS Base OS boot [9.0-20071211.2]
JUNOS Base OS Software Suite [9.0-20071211.2]
JUNOS Kernel Software Suite [9.0-20071211.20]
JUNOS Crypto Software Suite [9.0-20071211.2]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.0-20071211.2]
JUNOS Packet Forwarding Engine Support (M320) [9.0-20071211.2]
JUNOS Online Documentation [9.0-20071211.2]
JUNOS Routing Software Suite [9.0-20071211.2]
4.
On the master Routing Engine, issue the request system software in-service-upgrade
package-name no-old-master-upgrade
command. The following example upgrades the current version to an image of JUNOS 9.0 software that was built on January
16, 2008:
{master} user@host> request system software in-service-upgrade
/var/tmp/jinstall-9.0-20080116.2-domestic-signed.tgz no-old-master-upgrade
ISSU: Validating Image
ISSU: Preparing Backup RE
Pushing bundle to re1
Checking compatibility with configuration
Initializing...
Using jbase-9.0-20080116.2
Verified manifest signed by PackageProduction_9_0_0
Using /var/tmp/jinstall-9.0-20080116.2-domestic-signed.tgz
Verified jinstall-9.0-20080116.2-domestic.tgz signed by
PackageProduction_9_0_0
Using jinstall-9.0-20080116.2-domestic.tgz
Using jbundle-9.0-20080116.2-domestic.tgz
Checking jbundle requirements on /
Using jbase-9.0-20080116.2.tgz
Verified manifest signed by PackageProduction_9_0_0
Using jkernel-9.0-20080116.2.tgz
Verified manifest signed by PackageProduction_9_0_0
Using jcrypto-9.0-20080116.2.tgz
Verified manifest signed by PackageProduction_9_0_0
Using jpfe-9.0-20080116.2.tgz
Using jdocs-9.0-20080116.2.tgz
Verified manifest signed by PackageProduction_9_0_0
Using jroute-9.0-20080116.2.tgz
Performing a Unified ISSU
■ 219
JUNOS 9.1 High Availability Configuration Guide
220 ■
Performing a Unified ISSU
Verified manifest signed by PackageProduction_9_0_0
Hardware Database regeneration succeeded
Validating against /config/juniper.conf.gz
mgd: commit complete
Validation succeeded
Installing package '/var/tmp/jinstall-9.0-20080116.2-domestic-signed.tgz'
...
Verified jinstall-9.0-20080116.2-domestic.tgz signed by
PackageProduction_9_0_0
Adding jinstall...
Verified manifest signed by PackageProduction_9_0_0
WARNING: This package will load JUNOS 9.0-20080116.2 software.
WARNING: It will save JUNOS configuration files, and SSH keys
WARNING: (if configured), but erase all other files and information
WARNING: stored on this machine. It will attempt to preserve dumps
WARNING: and log files, but this can not be guaranteed. This is the
WARNING: pre-installation stage and all the software is loaded when
WARNING: you reboot the system.
Saving the config files ...
NOTICE: uncommitted changes have been saved in
/var/db/config/juniper.conf.pre-install
Installing the bootstrap installer ...
WARNING: A REBOOT IS REQUIRED TO LOAD THIS SOFTWARE CORRECTLY. Use the
WARNING: 'request system reboot' command when software installation is
WARNING: complete. To abort the installation, do not reboot your system,
WARNING: instead use the 'request system software delete jinstall'
WARNING: command as soon as this operation completes.
Saving package file in
/var/sw/pkg/jinstall-9.0-20080116.2-domestic-signed.tgz ...
Saving state for rollback ...
Backup upgrade done
Rebooting Backup RE
Rebooting re1
ISSU: Backup RE Prepare Done
Waiting for Backup RE reboot
GRES operational
Initiating Chassis In-Service-Upgrade
Chassis ISSU started
ISSU: Backup RE Prepare Done
ISSU: Preparing Daemons
ISSU: Daemons Ready for ISSU
ISSU: Starting Upgrade for FRUs
ISSU: Preparing for Switchover
ISSU: Ready for Switchover
Checking In-Service-Upgrade status
Item Status Reason
FPC 0 Online (ISSU)
FPC 1 Online (ISSU)
FPC 2 Online (ISSU)
FPC 3 Online (ISSU)
FPC 5 Online (ISSU)
Resolving mastership...
Complete. The other routing engine becomes the master.
Chapter 21: Unified ISSU Configuration Guidelines
ISSU: RE switchover Done
Skipping Old Master Upgrade
ISSU: IDLE
{backup} user@host
5.
You are now logged into the new backup (old master Routing Engine). If you want to install the new software version on the new backup Routing Engine, issue the request system software add
/var/tmp/jinstall-9.0-20080116.2-domestic-signed.tgz
command.
Verifying a Unified ISSU
To verify the status of FPCs and their corresponding PICs after the most recent unified
ISSU, issue the show chassis in-service-upgrade command on the master Routing
Engine: user@host> show chassis in-service-upgrade
Item Status Reason
FPC 0 Online
FPC 1 Online
FPC 2 Online
PIC 0 Online
PIC 1 Online
FPC 3 Offline Offlined by CLI command
FPC 4 Online
PIC 1 Online
FPC 5 Online
PIC 0 Online
FPC 6 Online
PIC 3 Online
FPC 7 Online
For more information about the show chassis in-service-upgrade
command, see the
JUNOS System Basics and Services Command Reference.
Troubleshooting Unified ISSU Problems
If the unified ISSU procedure stops progressing, complete the following steps:
1.
2.
Open a new session on the master Routing Engine and issue the request system software abort in-service-upgrade
command.
Check the existing router session to verify that the upgrade has been aborted.
An “ISSU: aborted!” message is provided. Additional system messages provide you with information about where the upgrade stopped and recommendations for the next step to take.
For more information about the request system software abort in-service-upgrade command, see the JUNOS System Basics and Services Command Reference.
Verifying a Unified ISSU
■ 221
JUNOS 9.1 High Availability Configuration Guide
Managing and Tracing BFD Sessions During Unified ISSU Procedures
Bidirectional Forwarding Detection (BFD) sessions temporarily increase their detection and transmission timers during unified ISSU procedures. After the upgrade, these timers revert to the values in use before the unified ISSU started. The BFD process replicates the unified ISSU state and timer values to the backup Routing Engine for each session.
No additional configuration is necessary to enable unified ISSU for BFD. However, you can disable the BFD timer negotiation during the unified ISSU by including the no-issu-timer-negotiation statement at the [edit protocols bfd] hierarchy level:
[edit protocols bfd]
If you configure this statement, the BFD timers maintain their original values during unified ISSU.
CAUTION: The sessions might flap during unified ISSU or Routing Engine switchover, depending on the detection intervals.
For more information about BFD, see the JUNOS Routing Protocols Configuration
Guide.
To configure unified ISSU trace options for BFD sessions, include the issu statement at the [edit protocols bfd traceoptions flag] hierarchy level.
}
[edit protocols] bfd {
flag issu;
}
222 ■
Managing and Tracing BFD Sessions During Unified ISSU Procedures
Chapter 22
Unified ISSU Configuration Statements
Summary
To perform a unified in-service software upgrade (ISSU), you must include the following statements in your router's configuration. The first two statements are
described in “Summary of Graceful Routing Engine Switchover Configuration
Statements” on page 55. The third statement is described in “Summary of Nonstop
Active Routing Configuration Statements” on page 81.
■
■
■
■ 223
JUNOS 9.1 High Availability Configuration Guide
This chapter also provides summaries for two optional statements related to unified
ISSU.
no-issu-timer-negotiation
Syntax no-issu-timer-negotiation;
Hierarchy Level
[edit protocols bfd],
[edit logical-routers logical-router-name protocols bfd],
[edit routing-instances routing-instance-name protocols bfd]
Release Information
Description
Statement introduced in JUNOS Release 9.1.
Disable unified ISSU timer negotiation for Bidirectional Forwarding Detection (BFD) sessions.
CAUTION: The sessions might flap during unified ISSU or Routing Engine switchover, depending on the detection intervals.
Usage Guidelines
See “Managing and Tracing BFD Sessions During Unified ISSU
Required Privilege Level
Related Topics view-level—To view this statement in the configuration.
control-level—To add this statement to the configuration.
For details on BFD, see the JUNOS Routing Protocols Configuration Guide.
224 ■ no-issu-timer-negotiation
Chapter 22: Unified ISSU Configuration Statements Summary
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]
Release Information
Description
Statement introduced before JUNOS Release 7.4.
issu
flag for BFD added in JUNOS Release 9.1.
Define tracing operations that track unified in-service software upgrade (ISSU) 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. There is only one unified ISSU tracing option:
■ issu —Trace BFD unified ISSU operations.
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 traceoptions
■ 225
JUNOS 9.1 High Availability Configuration Guide
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 “Managing and Tracing BFD Sessions During Unified ISSU
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.
226 ■ traceoptions
Part 9
Index
■
■
Index of Statements and Commands on page 235
Index
■ 227
JUNOS 9.1 High Availability Configuration Guide
228 ■
Index
Index
Symbols
#, comments in configuration statements.................xxiv
( ), in syntax descriptions..........................................xxiv
< >, in syntax descriptions......................................xxiii
[ ], in configuration statements..................................xxiv
{ }, in configuration statements................................xxiv
| (pipe), in syntax descriptions..................................xxiv
A
accept-data statement................................................169
usage guidelines..................................................158
advertise-interval statement.......................................170
usage guidelines..................................................156
advertisement intervals, VRRP...................................156
aggregate routes
graceful restart......................................................89
nonstop active routing..........................................72
authentication, VRRP.................................................155
authentication-key statement.....................................171
usage guidelines..................................................155
authentication-type statement....................................172
usage guidelines..................................................155
B
backup routers, VRRP................................................149
bandwidth-threshold statement.................................173
usage guidelines..................................................159
BFD, nonstop active routing.........................................73
BGP
graceful restart......................................................89
nonstop active routing..........................................72
unified ISSU........................................................199
bidirectional forwarding detection See BFD
Border Gateway Protocol See BGP
braces, in configuration statements...........................xxiv
brackets
angle, in syntax descriptions..............................xxiii
square, in configuration statements...................xxiv
C
CCC, graceful restart....................................................89
CFEB redundancy
configuring............................................................28
overview...............................................................16
cfeb statement.............................................................33
usage guidelines....................................................28
circuit cross-connect See CCC
comments, in configuration statements....................xxiv
commit synchronize statement....................................82
usage guidelines....................................................76
Compact Forwarding Engine Board See CFEB redundancy configuration files, copying between Routing
Engines....................................................................23
conventions
text and syntax..................................................xxiii
curly braces, in configuration statements..................xxiv
customer support.....................................................xxxii
contacting JTAC.................................................xxxii
D
description statement..................................................34
usage guidelines....................................................30
disable statement.......................................................135
usage guidelines
aggregate routes............................................97
BGP...............................................................98
ES-IS..............................................................99
global.....................................98, 103, 105, 106
IS-IS...............................................................99
OSPF ..........................................................100
OSPFv3........................................................100
PIM..............................................................101
RIP..............................................................101
RIPng...........................................................101
routing instances.........................................105
routing instances inside a logical router.......106
RSVP...........................................................103
static routes...................................................97
documentation set
comments on....................................................xxxii
E
ES-IS
graceful restart......................................................89
Index
■ 229
JUNOS 9.1 High Availability Configuration Guide
F
failover on-disk-failure statement.................................34
usage guidelines....................................................25
failover on-loss-of-keepalives statement.......................35
usage guidelines....................................................26
failover other-routing-engine statement.......................36
usage guidelines....................................................26
fast-interval statement...............................................174
usage guidelines..................................................157
FEB redundancy
configuration example..........................................30
configuring............................................................30
overview...............................................................16
feb statement...............................................................36
usage guidelines....................................................30
file copy command
usage guidelines....................................................23
font conventions.......................................................xxiii
Forwarding Engine Board See FEB redundancy
G
graceful restart
commands, operational mode............................107
concepts...............................................................89
configuration procedure
aggregate routes............................................97
MPLS protocols............................................102
routing protocols...........................................97
static routes...................................................97
VPNs............................................................104
example configuration........................................109
overview...............................................................89
aggregate routes............................................91
MPLS protocols..............................................93
routing protocols...........................................91
static routes...................................................91
VPNs..............................................................94
protocol support...................................................89
system requirements............................................90
trace options.......................................................102
verifying operation of.........................................107
graceful Routing Engine switchover
concepts...............................................................43
DPC support.........................................................48
enabling................................................................51
feature support.....................................................47
PIC support...........................................................49
platform support...................................................47
system architecture...............................................45
system requirements............................................47
verifying status of.................................................52
graceful-restart statement..........................................136
usage guidelines
aggregate routes............................................97
BGP...............................................................98
global.....................................98, 103, 105, 106
IS-IS...............................................................99
LDP.............................................................104
OSPF ..........................................................100
OSPFv3........................................................100
PIM..............................................................101
RIP..............................................................101
RIPng...........................................................101
routing instances.........................................105
routing instances inside a logical router.......106
RSVP...........................................................103
static routes...................................................97
graceful-switchover statement......................................55
usage guidelines....................................................51
GRES See graceful Routing Engine switchover
H
helper-disable statement............................................137
usage guidelines
IS-IS...............................................................99
LDP.............................................................104
OSPF ..........................................................100
OSPFv3........................................................100
RSVP...........................................................103
high availability features
comparison of.........................................................6
graceful restart......................................................89
graceful Routing Engine switchover......................43
nonstop active routing..........................................69
nonstop bridging...................................................59
overview.................................................................3
unified ISSU........................................................193
VRRP..................................................................149
hold-time statement...................................................175
I
icons defined, notice..................................................xxii
in-service software upgrade See unified ISSU
inet6-advertise-interval statement..............................176
usage guidelines..................................................157
initial configuration, redundant Routing Engines..........22
interface statement....................................................177
usage guidelines..................................................159
Intermediate System-to-Intermediate System See IS-IS
IS-IS
graceful restart......................................................89
nonstop active routing..........................................72
unified ISSU........................................................199
ISSU See unified ISSU
K
keepalive-time statement.............................................37
usage guidelines....................................................26
230 ■
Index
Index
L
Label Distribution Protocol See LDP
Layer 2 VPNs
nonstop active routing..........................................72
LDP
graceful restart......................................................89
nonstop active routing..........................................72
unified ISSU........................................................199
M
manuals
comments on....................................................xxxii
master router, VRRP..................................................149
maximum-helper-recovery-time statement................137
usage guidelines..................................................103
maximum-helper-restart-time statement....................138
usage guidelines..................................................103
maximum-neighbor-reconnect-time
usage guidelines..................................................104
maximum-neighbor-reconnect-time statement..........138
maximum-neighbor-recovery-time statement............139
usage guidelines..................................................104
MPLS, graceful restart..................................................89
MSTP, nonstop bridging...............................................62
Multiple Spanning Tree Protocol See MSTP
N
next-generation RIP See RIPng
no-accept-data statement...........................................177
usage guidelines..................................................158
no-auto-failover statement...........................................37
usage guidelines....................................................30
no-issu-timer-negotiation statement...........................224
usage guidelines..................................................222
no-preempt statement...............................................177
usage guidelines..................................................158
no-strict-lsa-checking statement.................................139
usage guidelines
OSPF...........................................................100
OSPFv3........................................................100
nonstop active routing
concepts...............................................................69
enabling................................................................75
example configuration..........................................78
platform support...................................................72
protocol support...................................................72
system architecture...............................................70
system requirements............................................71
trace options.........................................................77
verifying status of ................................................76
nonstop bridging
concepts...............................................................59
enabling................................................................63
platform support...................................................61
protocol support...................................................62
system architecture...............................................60
system requirements............................................61
verifying status of ................................................64
nonstop-bridging statement.........................................65
usage guidelines....................................................63
nonstop-routing statement...........................................83
usage guidelines....................................................75
notice icons defined...................................................xxii
notify-duration statement...........................................140
usage guidelines..................................................100
NSR See nonstop active routing
O
Open Shortest Path First See OSPF
OSPF
graceful restart......................................................89
nonstop active routing..........................................72
unified ISSU........................................................199
OSPFv3
nonstop active routing..........................................72
unified ISSU........................................................199
P
parentheses, in syntax descriptions...........................xxiv
passive ARP learning, VRRP.......................................162
PIM, graceful restart.....................................................89
preempt statement....................................................178
usage guidelines..................................................158
preempting master router, VRRP...............................158
priority statement......................................................179
usage guidelines..................................................153
priority-cost statement...............................................180
usage guidelines..................................................159
priority-hold-time statement......................................181
usage guidelines..................................................159
Protocol Independent Multicast See PIM
R
Rapid Spanning Tree Protocol See RSTP
reconnect-time statement..........................................140
usage guidelines..................................................104
recovery-time statement............................................141
usage guidelines..................................................104
redundancy feb statement
usage guidelines....................................................30
redundancy statement.................................................38
usage guidelines....................................................21
redundancy-group statement.......................................39
usage guidelines....................................................30
request chassis cfeb master switch command
usage guidelines....................................................29
Index
■ 231
JUNOS 9.1 High Availability Configuration Guide request chassis redundancy feb command
usage guidelines....................................................30
request chassis routing-engine master acquire command
usage guidelines....................................................27
request chassis routing-engine master release command
usage guidelines....................................................27
request chassis routing-engine master switch command
usage guidelines....................................................27
request chassis sfm master switch command
usage guidelines....................................................32
request chassis ssb master switch command
usage guidelines....................................................32
request routing-engine login command
usage guidelines....................................................23
request system software add command
usage guidelines....................................................24
Resource Reservation Protocol See RSVP
restart-duration statement..........................................142
usage guidelines
ES-IS..............................................................99
global.....................................98, 103, 105, 106
IS-IS...............................................................99
OSPF ..........................................................100
OSPFv3........................................................100
PIM..............................................................101
routing instances.........................................105
routing instances inside a logical router.......106
restart-time statement................................................143
usage guidelines
BGP...............................................................98
RIP..............................................................101
RIPng...........................................................101
RIP
graceful restart......................................................89
nonstop active routing..........................................72
RIPng
graceful restart......................................................89
nonstop active routing..........................................72
route statement..........................................................182
Routing Engine redundancy
copying configuration files....................................23
default behavior....................................................13
failover
conditions......................................................12
on loss of keepalive signal.............................26
graceful Routing Engine switchover......................25
halting Routing Engines........................................15
initial configuration...............................................22
log file, viewing.....................................................27
mastership
default setup, modifying................................25
switching, manually.......................................27
overview...............................................................11
platform support...................................................12
software packages, loading ..................................24
TX Matrix, running the same JUNOS release.........14
Routing Information Protocol See RIP
Routing Information Protocol next generation See
RIPng
routing-engine statement.............................................39
usage guidelines....................................................25
RSTP, nonstop bridging................................................62
RSVP
graceful restart......................................................89
S
SFM redundancy
configuring............................................................31
overview...............................................................19
sfm statement..............................................................40
usage guidelines....................................................31
show bgp replication command
usage guidelines....................................................76
show chassis cfeb command
usage guidelines....................................................29
show chassis feb command
usage guidelines....................................................30
show chassis sfm command
usage guidelines....................................................32
show chassis ssb command
usage guidelines....................................................32
show task replication command
usage guidelines....................................................76
software packages
transferring between Routing Engines..................24
Spanning Tree Protocol See STP
SSB redundancy
configuring............................................................32
overview...............................................................18
ssb statement...............................................................40
usage guidelines....................................................32
stale-routes-time statement........................................144
usage guidelines....................................................98
startup period, VRRP..................................................153
startup-silent-period statement...................................182
usage guidelines..................................................153
static routes
graceful restart......................................................89
nonstop active routing..........................................72
STP, nonstop bridging..................................................62
support, technical See technical support
Switching and Forwarding Module See SFM redundancy switching control board redundancy See CFEB redundancy, FEB redundancy, SFM redundancy, SSB redundancy synchronizing Routing Engines
graceful Routing Engine switchover......................52
nonstop active routing..........................................76
Routing Engine redundancy..................................63
232 ■
Index
Index
syntax conventions...................................................xxiii
System and Switch Board See SSB redundancy system requirements
graceful restart......................................................90
graceful Routing Engine switchover......................47
nonstop active routing..........................................71
nonstop bridging...................................................61
unified ISSU........................................................198
T
TCC, graceful restart.....................................................89
technical support
contacting JTAC.................................................xxxii
traceoptions statement
graceful restart ...................................................145
usage guidelines..........................................102
nonstop active routing..........................................84
usage guidelines............................................77
unified ISSU........................................................225
VRRP..................................................................183
usage guidelines..........................................161
track statement..........................................................185
usage guidelines..................................................159
translational cross-connect See TCC
TX Matrix platform
Routing Engine redundancy..................................14
U
unified in-service software upgrade See unified ISSU unified ISSU
concepts.............................................................193
configuration procedure
best practices...............................................205
performing an..............................................208
preparing for...............................................205
PIC support
ATM.............................................................203
channelized.................................................203
E3 IQ...........................................................204
Fast Ethernet...............................................202
FPC/PIC compatibility..................................200
Gigabit Ethernet...........................................202
restrictions...................................................200
serial............................................................204
SONET/SDH.................................................201
tunnel services.............................................203
platform support.................................................199
protocol support.................................................199
system requirements..........................................198
troubleshooting...................................................221
verifying status of...............................................221
V
Virtual Router Redundancy Protocol See VRRP
virtual-address statement...........................................186
usage guidelines..................................................153
virtual-inet6-address statement..................................186
usage guidelines..................................................153
virtual-link-local-address statement............................187
usage guidelines..................................................153
VPLS
nonstop active routing..........................................72
VPNs, graceful restart...................................................89
VRRP
advertisement interval........................................156
authentication.....................................................155
basic configuration..............................................153
example configuration........................................163
overview.............................................................149
passive ARP learning..........................................162
preempting master router...................................158
trace operations..................................................161
tracking logical interface status...........................159
vrrp-group statement.................................................188
usage guidelines..................................................153
vrrp-inet6-group statement........................................189
usage guidelines..................................................153
Index
■ 233
JUNOS 9.1 High Availability Configuration Guide
234 ■
Index
Index of Statements and Commands
A
accept-data statement................................................169
advertise-interval statement.......................................170
authentication-key statement.....................................171
authentication-type statement....................................172
B
bandwidth-threshold statement.................................173
C
cfeb statement.............................................................33
commit synchronize statement....................................82
D
description statement..................................................34
disable statement.......................................................135
F
failover on-disk-failure statement.................................34
failover on-loss-of-keepalives statement ......................35
failover other-routing-engine statement.......................36
fast-interval statement...............................................174
feb statement...............................................................36
G
graceful-restart statement..........................................136
graceful-switchover statement......................................55
H
helper-disable statement............................................137
hold-time statement...................................................175
I
inet6-advertise-interval statement..............................176
interface statement....................................................177
K
keepalive-time statement.............................................37
M
maximum-helper-recovery-time statement................137
maximum-helper-restart-time statement....................138
maximum-neighbor-reconnect-time statement..........138
maximum-neighbor-recovery-time statement............139
N
no-accept-data statement...........................................177
no-auto-failover statement...........................................37
no-issu-timer-negotiation statement...........................224
no-preempt statement...............................................177
no-strict-lsa-checking statement.................................139
nonstop-bridging statement.........................................65
nonstop-routing statement...........................................83
notify-duration statement...........................................140
P
preempt statement....................................................178
priority statement......................................................179
priority-cost statement...............................................180
priority-hold-time statement......................................181
R
reconnect-time statement..........................................140
recovery-time statement............................................141
redundancy statement.................................................38
redundancy-group statement.......................................39
restart-duration statement..........................................142
restart-time statement................................................143
route statement..........................................................182
routing-engine statement.............................................39
S
sfm statement..............................................................40
ssb statement...............................................................40
stale-routes-time statement........................................144
Index of Statements and Commands
■ 235
JUNOS 9.1 High Availability Configuration Guide
startup-silent-period statement...................................182
T
traceoptions statement
graceful restart....................................................145
nonstop active routing..........................................84
unified ISSU........................................................225
VRRP..................................................................183
track statement..........................................................185
V
virtual-address statement...........................................186
virtual-inet6-address statement..................................186
virtual-link-local-address statement............................187
vrrp-group statement.................................................188
vrrp-inet6-group statement........................................189
236 ■
Index of Statements and Commands
Télécharger
Lien public mis à jour
Le lien public vers votre chat a été mis à jour. Vous pouvez afficher et gérer vos liens de chat après inscription ici.
Lien public du document
Publicité