Juniper SERVICE AVAILABILITY - CONFIGURATION GUIDE V 11.1.X, JUNOSe 11.1 Configuration Manual

JUNOSe™ Software for E Series™ Broadband Services Routers

Service Availability Configuration Guide

Release 11.1.x

Juniper Networks, Inc.

1194 North Mathilda Avenue

Sunnyvale, California 94089

USA

408-745-2000

www.juniper.net

Published: 2010-04-08

Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, ScreenOS, and Steel-Belted Radius are registered trademarks of Juniper Networks, Inc. in
the United States and other countries. JUNOSe is a trademark 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.

JUNOSe™ Software for E Series™ Broadband Services Routers Service Availability Configuration Guide

Release 11.1.x
Copyright © 2010, Juniper Networks, Inc.
All rights reserved. Printed in USA.

Writing: Krupa Chandrashekar, Sairam Venugopalan
Editing: Benjamin Mann
Illustration: Nathaniel Woodward
Cover Design: Edmonds Design

Revision History
April 2010— FRS JUNOSe 11.1.x

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 (i) Juniper Networks, Inc. (if the Customer’s principal office is located in the Americas) or Juniper Networks
(Cayman) Limited (if the Customer’s principal office is located outside the Americas) (such applicable entity being referred to herein as “Juniper”), and (ii)
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, for which Customer
has paid the applicable license or support fees to Juniper or an authorized Juniper reseller, or which was embedded by Juniper in equipment which Customer
purchased from Juniper or an authorized Juniper reseller. “Software” also includes updates, upgrades and new releases of such software. “Embedded
Software” means Software which Juniper has embedded in or loaded onto the Juniper equipment and any updates, upgrades, additions or replacements
which are subsequently embedded in or loaded onto the 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 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 or IMS AAA software on multiple computers or virtual machines (e.g., Solaris zones) requires multiple licenses, regardless of whether
such computers or virtualizations 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 Embedded Software on non-Juniper equipment; (j) use Embedded 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.

■ iii

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.

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 payable under this agreement are exclusive of tax. Customer shall be responsible for paying Taxes arising from the purchase of
the license, or importation or use of the Software. If applicable, valid exemption documentation for each taxing jurisdiction shall be provided to Juniper prior
to invoicing, and Customer shall promptly notify Juniper if their exemption is revoked or modified. All payments made by Customer shall be net of any
applicable withholding tax. Customer will provide reasonable assistance to Juniper in connection with such withholding taxes by promptly: providing Juniper
with valid tax receipts and other required documentation showing Customer’s payment of any withholding taxes; completing appropriate applications that
would reduce the amount of withholding tax to be paid; and notifying and assisting Juniper in any audit or tax proceeding related to transactions hereunder.
Customer shall comply with all applicable tax laws and regulations, and Customer will promptly pay or reimburse Juniper for all costs and damages related
to any liability incurred by Juniper as a result of Customer’s non-compliance or delay with its responsibilities herein. Customer’s obligations under this
Section shall survive termination or expiration of this Agreement.

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

iv ■

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)).

■ v

vi ■

Abbreviated Table of Contents

About the Documentation xix

Part 1 Chapters

Chapter 1 Service Availability 3

Chapter 2 Managing Module Redundancy 7

Chapter 3 Managing Stateful SRP Switchover 25

Chapter 4 Configuring a Unified In-Service Software Upgrade 57

Chapter 5 Configuring VRRP 105

Chapter 6 Managing Interchassis Redundancy 127

Part 2 Index

Index 149

Abbreviated Table of Contents ■ vii

JUNOSe 11.1.x Service Availability Configuration Guide

viii ■

Table of Contents

About the Documentation xix

E Series and JUNOSe Documentation and Release Notes ..............................xix

Audience ......................................................................................................xix

E Series and JUNOSe Text and Syntax Conventions .....................................xix

Obtaining Documentation ............................................................................xxi

Documentation Feedback .............................................................................xxi

Requesting Technical Support ......................................................................xxi

Self-Help Online Tools and Resources ...................................................xxii

Opening a Case with JTAC .....................................................................xxii

Part 1 Chapters

Chapter 1 Service Availability 3

Service Availability Overview ..........................................................................3

Service Availability Versus High Availability ..............................................4

Understanding Service Availability Features ....................................................5

Module Redundancy .................................................................................5

Stateful SRP Switchover ............................................................................5

Unified ISSU ..............................................................................................5

VRRP ........................................................................................................6

Interchassis Redundancy ..........................................................................6

Chapter 2 Managing Module Redundancy 7

Line Module Redundancy Overview ................................................................7

Module Requirements ...............................................................................7

ERX7xx Models and ERX14xx Models ................................................7

E120 and E320 Routers ......................................................................8

Automatic Switchover ...............................................................................9

Limitations of Automatic Switchover ..................................................9

Reversion After Switchover .......................................................................9

Configuring Line Module Redundancy ....................................................10

Managing Line Module Redundancy .......................................................10

SRP Module Redundancy ........................................................................11

SRP Module Behavior ..............................................................................11

Specifying the Configuration for Redundant SRP Modules ......................14

Installing a Redundant SRP Module ........................................................15

Table of Contents ■ ix

JUNOSe 11.1.x Service Availability Configuration Guide

Managing SRP Module Redundancy ........................................................16

Switching to the Redundant SRP Module ................................................18

Upgrading Software on a Redundant SRP Module ...................................19

Monitoring the Status LEDs .....................................................................19

Monitoring Line Module and SRP Module Redundancy .................................19

Managing Port Redundancy ..........................................................................23

Chapter 3 Managing Stateful SRP Switchover 25

Stateful SRP Switchover Overview .................................................................25

Stateful SRP Switchover Platform Considerations ..........................................26

Module Requirements .............................................................................26

Stateful SRP Switchover Redundancy Modes .................................................27

File System Synchronization Mode .........................................................27

High Availability Mode ............................................................................27

Stateful SRP Switchover States ......................................................................29

Disabled State .........................................................................................29

Initializing State ......................................................................................30

Active State .............................................................................................30

Pending State ..........................................................................................31

Application Support for Stateful SRP Switchover ...........................................32

Application Support ................................................................................32

Guidelines for Activating High Availability .....................................................41

Activating High Availability ............................................................................42

Guidelines for Deactivating High Availability .................................................42

Deactivating High Availability ........................................................................43

Guidelines for Setting the IP Interface Priority ...............................................43

Setting the IP Interface Priority .....................................................................44

Guidelines for Upgrading Software ................................................................44

Monitoring the Redundancy Status ................................................................45

Monitoring the Redundancy Status of Applications ........................................48

Monitoring the Redundancy History ..............................................................50

Monitoring the Redundancy Status of Line Modules ......................................51

Monitoring the Redundancy Status of SRP Modules ......................................52

Monitoring the Redundancy Switchover History ............................................54

Clearing the Redundancy History ..................................................................55

Chapter 4 Configuring a Unified In-Service Software Upgrade 57

Unified ISSU Overview ..................................................................................58

Unified ISSU Platform Considerations ...........................................................59

Hardware and Software Requirements Before Beginning a Unified ISSU .......60

Hardware Requirements for Unified ISSU ......................................................60

Software Requirements for Unified ISSU .......................................................61

Unified ISSU Terms .......................................................................................62

Unified ISSU References ................................................................................62

Unified ISSU Phases Overview ......................................................................63

x ■ Table of Contents

Router Behavior During a Unified In-Service Software Upgrade ..............59

Table of Contents

Unified ISSU Initialization Phase Overview ....................................................63

Application Data Upgrade on the Standby SRP Module ...........................64

SNMP Traps ............................................................................................65

Unified ISSU Upgrade Phase Overview ..........................................................66

Exceptions During the Upgrade Phase ....................................................67

Verifications of Requirements .................................................................68

Upgrade Setup ........................................................................................68

Line Module Arming .........................................................................69

Line Module Control Plane Upgrade .................................................69

SRP Module Switchover ....................................................................69

Line Module Forwarding Plane Upgrade ...........................................70

Unified ISSU Service Restoration Phase Overview .........................................71

Application Support for Unified ISSU .............................................................71

Unexpected AAA Authentication and Authorization Behavior During Unified

ISSU ........................................................................................................80

Unexpected ATM Behavior During Unified ISSU ............................................80

ILMI Sessions Not Maintained .................................................................80

OAM CC Effects on VCC ..........................................................................80

OAM VC Integrity Verification Cessation .................................................81

Port Data Rate Monitoring Cessation ......................................................81

VC and VP Statistics Monitoring Halts Unified ISSU Progress ..................81

Unexpected DHCP Behavior During Unified ISSU ..........................................81

DHCP Packet Capture Halted on Line Modules .......................................81

Unexpected Denial-of-Service Protection Behavior During Unified ISSU ........81

Unexpected Ethernet Behavior During Unified ISSU ......................................82

ARP Packets Briefly Not Sent or Received ...............................................82

Link Aggregation Interruption .................................................................82

Port Data Rate Monitoring Halted ...........................................................83

VLAN Statistics Monitoring Halts Unified ISSU Progress ..........................83

Unexpected File Transfer Protocol Server Behavior During Unified ISSU .......83

IS-IS Effects on Graceful Restart and Network Stability During Unified

ISSU ........................................................................................................86

Configuring Graceful Restart Before Unified ISSU Begins ........................86

Configuring Graceful Restart When BGP and LDP Are Configured ...........86

Routing Around the Restarting Router to Minimize Network

Instability .........................................................................................87

Unexpected L2TP Failover of Established Tunnels During Unified ISSU .........87

OSPF Effects on Graceful Restart and Network Stability During Unified

ISSU ........................................................................................................88

Configuring Graceful Restart Before Unified ISSU Begins ........................88

Configuring Graceful Restart When BGP and LDP Are Configured ...........89

Configuring a Longer Dead Interval Than Normal ...................................89

Routing Around the Restarting Router to Minimize Network

Instability .........................................................................................89

Unexpected Suspension of PIM During Unified ISSU .....................................90

Unexpected Suspension of Subscriber Login and Logouts During Unified

ISSU ........................................................................................................90

Subscriber Statistics Accumulation or Deletion .......................................90

Unexpected SONET and SDH Behavior During Unified ISSU .........................91

Unexpected T3 Behavior During Unified ISSU ...............................................91

Unavailability of TACACS+ Services During Unified ISSU .............................92

Table of Contents ■ xi

JUNOSe 11.1.x Service Availability Configuration Guide

Interruption in Traffic Forwarding for Layer 3 Routing Protocols During

Unified ISSU ............................................................................................92

Recommended Settings for Routing Protocol Timers During Unified

ISSU ........................................................................................................94

Upgrading Router Software with Unified ISSU ...............................................96

Halt of Unified ISSU During Initialization Phase Overview .............................99

Halting Unified ISSU During Initialization Phase ............................................99

Halt of Unified ISSU During Upgrade Phase Overview .................................100

Halting Unified ISSU During Upgrade Phase ................................................100

Monitoring the Status of the Router During Unified ISSU .............................101

Chapter 5 Configuring VRRP 105

VRRP Overview ...........................................................................................105

VRRP Terms .........................................................................................105

Platform Considerations ..............................................................................106

References ..................................................................................................106

How VRRP Works .......................................................................................107

Configuration Examples ........................................................................107

Basic VRRP Configuration ...............................................................107

Commonly Used VRRP Configuration .............................................108

VRRP Configuration Without the Real Address Owner ...................109

How VRRP Is Implemented in E Series Routers ...........................................110

Router Election Rules ............................................................................111

Configuring VRRP ........................................................................................112

Configuring the IP Interface ..................................................................112

Creating VRIDs .....................................................................................112

Configuration Steps ...............................................................................113

Changing Object Priority .............................................................................117

Monitoring VRRP .........................................................................................117

Chapter 6 Managing Interchassis Redundancy 127

ICR Overview ..............................................................................................127

ICR Platform Considerations .......................................................................129

ICR Terms ...................................................................................................130

ICR References ............................................................................................130

ICR Scaling Considerations ..........................................................................131

Interaction with RADIUS for ICR .................................................................132

Configuring an ICR Partition ........................................................................134

Configuring the Interface on Which the ICR Partition Resides .....................135

Configuring VRRP Instances to Match ICR Requirements ............................135

Naming ICR Partitions .................................................................................136

Grouping ICR Subscribers Based on S-VLAN IDs ..........................................137

Grouping ICR Subscribers Based on VLAN IDs .............................................138

Example: Configuring ICR Partitions That Group Subscribers by S-VLAN

xii ■ Table of Contents

Interface Specifiers ...............................................................................129

1:1 Subscriber Redundancy in a 4–Node ICR Cluster ............................131

ICR Partition Accounting Overview .......................................................133

ID .........................................................................................................139

Using RADIUS to Manage Subscribers Logging In to ICR Partitions ..............141

Monitoring the Configuration of an ICR Partition Attached to an

Interface ...............................................................................................141

Monitoring the Configuration of ICR Partitions ............................................143

Part 2 Index

Index ...........................................................................................................149

Table of Contents

Table of Contents ■ xiii

JUNOSe 11.1.x Service Availability Configuration Guide

xiv ■ Table of Contents

List of Figures

Part 1 Chapters

Chapter 2 Managing Module Redundancy 7

Figure 1: SRP Module on ERX7xx Models and ERX14xx Models ...................13

Figure 2: SRP Module on the E120 and E320 Routers ...................................14

Chapter 3 Managing Stateful SRP Switchover 25

Figure 3: High Availability States ...................................................................29

Chapter 5 Configuring VRRP 105

Figure 4: Basic VRRP Configuration .............................................................108

Figure 5: Commonly Used VRRP Configuration ...........................................109

Figure 6: VRRP Configuration Without the Real Address Owner ..................110

Chapter 6 Managing Interchassis Redundancy 127

Figure 7: ICR Deployment ...........................................................................128

Figure 8: Sample 1:1 Subscriber Redundancy in a 4–Node ICR Cluster .......131

List of Figures ■ xv

JUNOSe 11.1.x Service Availability Configuration Guide

xvi ■ List of Figures

List of Tables

About the Documentation xix

Table 1: Notice Icons .....................................................................................xx

Table 2: Text and Syntax Conventions ..........................................................xx

Part 1 Chapters

Chapter 2 Managing Module Redundancy 7

Table 3: Commands That Can Cause Automatic Switchover ............................9

Table 4: Function of the Online and Redundant LEDs ...................................19

Chapter 3 Managing Stateful SRP Switchover 25

Table 5: Application Support for Stateful SRP Switchover ..............................32

Table 6: show redundancy Output Fields ......................................................47

Table 7: show redundancy clients Output Fields ...........................................50

Table 8: show redundancy history Output Fields ...........................................51

Table 9: show redundancy line-card Output Fields ........................................52

Table 10: show redundancy srp Output Fields ...............................................53

Table 11: show redundancy switchover-history Output Fields .......................55

Chapter 4 Configuring a Unified In-Service Software Upgrade 57

Table 12: Unified ISSU-Related Terms ...........................................................62

Table 13: Router Response to Undesirable Events During the Upgrade

Phase ......................................................................................................67

Table 14: Application Support for Unified In-Service Software Upgrades .......72

Table 15: Behavior of Routing Protocols During a Unified In-Service Software

Upgrade ..................................................................................................93

Table 16: Recommended Routing Protocol Timer Settings ............................95

Table 17: show issu Output Fields ...............................................................103

Chapter 5 Configuring VRRP 105

Table 18: VRRP Definitions .........................................................................106

Chapter 6 Managing Interchassis Redundancy 127

Table 19: ICR Terminology ..........................................................................130

Table 20: show icr-partition Output Fields ...................................................142

Table 21: show icr-partitions Output Fields .................................................144

List of Tables ■ xvii

JUNOSe 11.1.x Service Availability Configuration Guide

xviii ■ List of Tables

About the Documentation

■ E Series and JUNOSe Documentation and Release Notes on page xix

■ Audience on page xix

■ E Series and JUNOSe Text and Syntax Conventions on page xix

■ Obtaining Documentation on page xxi

■ Documentation Feedback on page xxi

■ Requesting Technical Support on page xxi

E Series and JUNOSe Documentation and Release Notes

For a list of related JUNOSe documentation, see

http://www.juniper.net/techpubs/software/index.html .

If the information in the latest release notes differs from the information in the
documentation, follow the JUNOSe Release Notes.

To obtain the most current version of all Juniper Networks® technical documentation,
see the product documentation page on the Juniper Networks website at

http://www.juniper.net/techpubs/.

Audience

This guide is intended for experienced system and network specialists working with
Juniper Networks E Series Broadband Services Routers in an Internet access
environment.

E Series and JUNOSe Text and Syntax Conventions

Table 1 on page xx defines notice icons used in this documentation.

E Series and JUNOSe Documentation and Release Notes ■ xix

JUNOSe 11.1.x Service Availability Configuration Guide

Table 1: Notice Icons

Table 2 on page xx defines text and syntax conventions that we use throughout the
E Series and JUNOSe documentation.

DescriptionMeaningIcon

Indicates important features or instructions.Informational note

Indicates a situation that might result in loss of data or hardware damage.Caution

Alerts you to the risk of personal injury or death.Warning

Alerts you to the risk of personal injury from a laser.Laser warning

Table 2: Text and Syntax Conventions

Represents commands and keywords in text.Bold text like this

Bold text like this

Fixed-width text like this

Represents text that the user must type.

Represents information as displayed on your
terminal’s screen.

Italic text like this

Emphasizes words.

■

Identifies variables.

■

Identifies chapter, appendix, and book

■

names.

Plus sign (+) linking key names

keys simultaneously.

Syntax Conventions in the Command Reference Guide

ExamplesDescriptionConvention

Issue the clock source command.

■

Specify the keyword exp-msg.

■

host1(config)#traffic class low-loss1

host1#show ip ospf 2

Routing Process OSPF 2 with Router
ID 5.5.0.250
Router is an Area Border Router
(ABR)

There are two levels of access: user and

■

privileged.

clusterId, ipAddress.

■

Appendix A, System Specifications

■

Press Ctrl + b.Indicates that you must press two or more

terminal lengthRepresents keywords.Plain text like this

| (pipe symbol)

xx ■ E Series and JUNOSe Text and Syntax Conventions

mask, accessListNameRepresents variables.Italic text like this

diagnostic | lineRepresents a choice to select one keyword
or variable to the left or to the right of this
symbol. (The keyword or variable can be
either optional or required.)

Table 2: Text and Syntax Conventions (continued)

About the Documentation

ExamplesDescriptionConvention

[ internal | external ]Represent optional keywords or variables.[ ] (brackets)

[ ]* (brackets and asterisk)

that can be entered more than once.

Represent required keywords or variables.{ } (braces)

Obtaining Documentation

To obtain the most current version of all Juniper Networks technical documentation,
see the Technical Documentation page on the Juniper Networks Web site at

http://www.juniper.net/.

To download complete sets of technical documentation to create your own
documentation CD-ROMs or DVD-ROMs, see the Offline Documentation page at

http://www.juniper.net/techpubs/resources/cdrom.html

Copies of the Management Information Bases (MIBs) for a particular software release
are available for download in the software image bundle from the Juniper Networks
Web site athttp://www.juniper.net/.

Documentation Feedback

[ level1 | level2 | l1 ]*Represent optional keywords or variables

{ permit | deny } { in | out }

{ clusterId | ipAddress }

We encourage you to provide feedback, comments, and suggestions so that we can
improve the documentation to better meet your needs. Send your comments to

[e-mail], or fill out the documentation feedback form at

https://www.juniper.net/cgi-bin/docbugreport/. If you are using e-mail, be sure to include

the following information with your comments:

■ Document or topic name

■ URL or page number

■ Software release version

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 post-sales 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/7100059-EN.pdf .

Obtaining Documentation ■ xxi

JUNOSe 11.1.x Service Availability Configuration Guide

■ 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 Management tool: http://www.juniper.net/cm/

To verify service entitlement by product serial number, use our Serial Number
Entitlement (SNE) Tool: 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 Management 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, see

http://www.juniper.net/support/requesting support.html .

xxii ■ Requesting Technical Support

Part 1

Chapters

■ Service Availability on page 3

■ Managing Module Redundancy on page 7

■ Managing Stateful SRP Switchover on page 25

■ Configuring a Unified In-Service Software Upgrade on page 57

■ Configuring VRRP on page 105

■ Managing Interchassis Redundancy on page 127

Chapters ■ 1

JUNOSe 11.1.x Service Availability Configuration Guide

2 ■ Chapters

Chapter 1

Service Availability

This chapter explains what service availability is and discusses the features of service
availability. It also discusses Juniper Networks multi-layered service availability
approach for uninterrupted delivery of services.

■ Service Availability Overview on page 3

■ Understanding Service Availability Features on page 5

Service Availability Overview

In a conventional network, router outages can occur because of denial of service
(DoS) attacks, line module failure, switch route processor module failure, software
defects, feature upgrades, or complete router failure. These outages result in subscriber
downtime.

To reduce subscriber downtime, a network must have the following capabilities:

■ Reliability—A network that does not crash often and recovers from failure very

rapidly. During recovery, the network maintains user sessions and forwards data
with little or no impact on the delivery of services.

■ Resiliency—A network component or network that responds to failure, resists

failure, and handles failure with little or no impact on the delivery of services.

■ Redundancy—A network whose reliability is enhanced by the addition of a backup

component.

■ High Availability—A network that is both reliable and resilient.

JUNOSe Software uses a multi-layered service availability approach that enables you
to provide uninterrupted delivery of services with the help of reliable, highly available,
and redundant hardware and software components.

Service Availability Overview ■ 3

Security

Protects infrastructure against DoS attacks

Network Resiliency

Protects against port, link (fiber cuts), and network node failures

Software Availability

Protects against software crashes and minimizes downtime from software upgrades

Hardware Redundancy and Design

1:1 or N:1 component-level protection

g016518

99.999%

JUNOSe 11.1.x Service Availability Configuration Guide

Figure 1 illustrates the multiple layers of JUNOSe Software service availability

The security layer protects the network from DoS attacks.

The network resiliency layer protects against port, link, and node failures. You can
configure IEEE 802.3 ad link aggregation for Ethernet, and Virtual Router Redundancy
Protocol (VRRP) to improve network resiliency.

The software availability layer protects against software failures by using hot-fixes
or installing a higher-numbered software release. You can perform a unified in-service
software upgrade (ISSU) instead of the conventional software upgrade to reduce
outage. You can eliminate or reduce single points of failure by configuring stateful
SRP switchover (high availability). Any network component with an uptime of 99.999
percent is considered highly available with a downtime of less than 5 minutes in a
year.

The hardware redundancy and design layer introduces redundancy in the network
in the form of multiple power supplies, cooling devices, line modules, and sometimes
even a router. For instance, you can install a backup line module in your router to
protect against line module failure. You can also configure a router as a backup router
that accepts subscriber login requests when the master router fails.

Service Availability Versus High Availability

High availability is a measure of the uptime of a network or network component. A
network component that has a downtime of 5 minutes is accessible or available 99
percent of the time. If a failure occurs, a backup component is available within 5
minutes. A highly available network is a network that has components that either
have high reliability or have the ability to recover very quickly from a failure, or both.

Service availability refers to the ability to provide uninterrupted delivery of services.
For example, from the time when a component fails to the time when the backup
component is accessible, the delivery of services is interrupted. To provide
uninterrupted delivery of services, highly available components must maintain session
details and other data across failures. Service availability can thus be defined as the
ability to provide uninterrupted delivery of services using a highly available network.

4 ■ Service Availability Overview

Related Topics ■ Understanding Service Availability Features on page 5

Understanding Service Availability Features

Service availability refers to ability of a network or a network component to provide
uninterrupted delivery of services using highly available, redundant, and reliable
components. This topic provides brief overviews of the benefits of using the following
service availability features:

■ Module Redundancy on page 5

■ Stateful SRP Switchover on page 5

■ Unified ISSU on page 5

■ VRRP on page 6

■ Interchassis Redundancy on page 6

Chapter 1: Service Availability

Module Redundancy

For hardware components, Juniper Networks provides redundancy solutions to ensure
that the router continues to operate in the event of a hardware fault. Redundancy
also enables you to hot-swap various components within your E Series router.

Stateful SRP Switchover

Stateful SRP switchover (high availability) enables you to reduce or eliminate single
points of failure in your network. Stateful SRP switchover provides both
hardware-specific and software-specific methods to ensure minimal downtime and
ultimately improve the performance of your network.

Stateful SRP switchover minimizes the impact to the router of a stateful switchover
from the active SRP module to the standby SRP module. Stateful SRP switchover
maintains user sessions and data forwarding through the router during the switchover,
thus improving the overall availability of the router.

Unified ISSU

A conventional software upgrade—one that does not use the unified in-service
software upgrade (ISSU) process—causes a router-wide outage for all users. Only
static configurations (stored on the flash card) are maintained across the upgrade;
all dynamic configurations are lost. A conventional upgrade can take 30-40 minutes
to complete, with additional time required to bring all users back online.

Unified ISSU enables you to upgrade the router to a higher-numbered software release
without disconnecting user sessions or disrupting forwarding through the chassis.

When an application supports unified ISSU, you can configure the application on the
router and proceed with the unified in-service software upgrade with no adverse
effect on the upgrade.

Understanding Service Availability Features ■ 5

JUNOSe 11.1.x Service Availability Configuration Guide

When you perform a unified ISSU on a router that has one or more modules that do
not support unified ISSU, these modules are upgraded by means of the legacy,
conventional upgrade process. The unsupported modules undergo a cold reboot at
the beginning of the unified ISSU process, and are held down until the ISSU process
is completed.

VRRP

Virtual Router Redundancy Protocol (VRRP) prevents loss of network connectivity
to end hosts when the static default IP gateway fails. By implementing VRRP, you
can designate a number of routers as backup routers in the event that the default
master router fails. In case of a failure, VRRP dynamically shifts the packet-forwarding
responsibility to a backup router. VRRP creates a redundancy scheme that enables
hosts to keep a single IP address for the default gateway but maps the IP address to
a well-known virtual MAC address. You can take advantage of the redundancy
provided by VRRP without performing any special configuration on the end host
systems.

Routers running VRRP dynamically elect master and backup routers. You can also
force assignment of master and backup routers using priorities in the range 1–255,
with 255 being the highest priority.

VRRP supports virtual local area networks (VLANs), stacked VLANs (S-VLANs), and
creation of interchassis redundancy (ICR) partitions.

Interchassis Redundancy

ICR enables you to minimize subscriber downtime when the router or access interface
on the edge router fails. ICR accomplishes this by re-creating subscriber sessions on
the backup router that were originally terminated on the failed router. It also enables
you to track the failure of uplink interfaces. In this way, ICR enables you to completely
recover from router failure. ICR uses Virtual Router Redundancy Protocol (VRRP) to
detect failures. ICR also enables you to track the failure of uplink interfaces. ICR
currently supports only PPPoE subscribers.

Related Topics ■ Managing Module Redundancy on page 7

■ Managing Stateful SRP Switchover on page 25

■ Configuring a Unified In-Service Software Upgrade on page 57

■ Configuring VRRP on page 105

■ Managing Interchassis Redundancy on page 127

■ Service Availability Overview on page 3

6 ■ Understanding Service Availability Features

Chapter 2

Managing Module Redundancy

This chapter describes how to manage redundancy in line modules, switch route
processor (SRP) modules, switch fabric modules (SFMs), I/O modules, and I/O adapters
(IOAs) in E Series routers.

This chapter contains the following sections:

■ Line Module Redundancy Overview on page 7

■ Monitoring Line Module and SRP Module Redundancy on page 19

■ Managing Port Redundancy on page 23

Line Module Redundancy Overview

You can install an extra line module in a group of identical line modules to provide
redundancy if one of the modules fails.

The process by which the router switches to the spare line module is called
switchover. During switchover, the line, circuit, and IP interfaces on the I/O module
or one or more IOAs appear to go down temporarily. The duration of the downtime
depends on the number of interfaces and the size of the routing table, because the
router must reload the interface configuration and the routing table from the SRP
module.

If the line module software is not compatible with the running SRP module software
release, a warning message appears on the console.

Module Requirements

The requirements for line module redundancy depend on the type of router that you
have.

NOTE: The information in this section does not apply to the ERX310 Broadband
Services Router, which does not support line module redundancy.

ERX7xx Models and ERX14xx Models

To use this feature on ERX7xx models and ERX14xx models, you must also install
a redundancy midplane and a redundancy I/O module. For a detailed explanation

Line Module Redundancy Overview ■ 7

JUNOSe 11.1.x Service Availability Configuration Guide

of how the router provides redundancy for line modules and procedures for installing
the modules, see the ERX Hardware Guide.

E120 and E320 Routers

To configure line module redundancy on the E120 or E320 Broadband Services
router, you must also install an ES2-S1 Redund IOA in either slot 0 or slot 11. The
ES2-S1 Redund IOA is a full-height IOA. For a detailed explanation of how the router
provides redundancy for line modules and procedures for installing the modules, see
the E120 and E320 Hardware Guide.

On E120 and E320 routers, each side of the chassis is treated as a redundancy group.
The lowest numbered slot for each side acts as the spare line module, providing
backup functionality when an ES2-S1 Redund IOA is located directly behind it. When
the line module does not contain an ES2-S1 Redund IOA, it is considered a primary
line module.

The router accepts the following redundancy groups:

■ ES2 4G LM as backup and ES2 4G LM as primary

■ ES2 10G Uplink LM and ES2 10G Uplink LM as primary

■ ES2 10G LM as backup and ES2 10G LM

■ ES2 10G ADV LM as backup and ES2 10G ADV LM as primary

■ ES2 10G ADV LM as backup and ES2 10G LM as primary

Also, you cannot configure redundancy for the ES2-S1 Service IOA.

IOA Behavior When the Router Reboots

On E120 and E320 routers, switchover is based on the combined states of the line
module and the IOAs that are installed in the affected slot.

When the router reboots and the formerly configured primary line module is not
present, or is present and fails diagnostics, it switches to a spare line module and
takes inventory of the IOAs. If the IOA is present and new, the router reverts back
to the primary line module so that the spare line module can service other active
primary line modules.

When the router reboots and a slot contains a line module and one active and one
inactive IOA, the inactive IOA remains in that state.

Line Module Behavior When Disabling or Enabling IOAs

On E120 and E320 routers, a line module reboots when you issue the adapter
disable or adapter enable commands for an associated IOA.

When you issue the adapter disable or adapter enable commands, the line module
(primary or spare) currently associated with that IOA reboots. If the IOA is protected
by a line module redundancy group, an automatic line module redundancy switchover
or revert can be triggered by the line module reboot. To prevent undesired line

8 ■ Line Module Redundancy Overview

module redundancy actions, issue the redundancy lockout command for the primary
line module slot before issuing the adapter disable or adapter enable commands.

Automatic Switchover

Provided you have not issued the redundancy lockout command for the primary
line module, the router switches over to the spare line module automatically if it
detects any of the following failures on the primary line module:

■ Power-on self-test (POST) failure

■ Software-detected unrecoverable error

■ Software watchdog timer expiration

■ Primary line module failure to respond to keepalive polling from the SRP module

■ Removal, disabling, or reloading of the primary line module

■ Missing or disabled primary line modules when the router reboots

Chapter 2: Managing Module Redundancy

■ Resetting the primary line module using the concealed push button

Limitations of Automatic Switchover

If automatic switchover is enabled on a slot (the default configuration) and a spare
line module is available, issuing some CLI commands for the primary line module
causes a switchover (Table 3 on page 9).

You can also disable automatic switchover on individual slots. For more information,
see “Configuring Line Module Redundancy” on page 10.

Table 3: Commands That Can Cause Automatic Switchover

slot disable primary-line-module-slot

reload slot primary-line-module-slot

Reversion After Switchover

Reason for Automatic SwitchoverCommand

The command disables the primary line module
but not the primary I/O module or IOAs.

The command is equivalent to pushing the reset
button on the primary line module.

You can install only one spare line module in the group of slots covered by the
redundancy midplane or redundancy group. If the router is using the spare line
module, no redundancy is available. Reverting to the primary module as soon as
possible is desirable. By default, the router does not automatically revert to the
primary module after switchover; however, you can configure it to do so.
(See “Configuring Line Module Redundancy” on page 10.) Before reversion can take
place, the primary line module must complete the POST diagnostics.

Line Module Redundancy Overview ■ 9

JUNOSe 11.1.x Service Availability Configuration Guide

Configuring Line Module Redundancy

You can modify the default redundancy operations on the router
as follows:

■ Disable automatic switchover on a slot.

■ Enable automatic reversion after switchover.

redundancy lockout

■ Use to prevent the router from switching automatically to a spare line module

if the primary module in the specified slot fails.

■ The redundancy force-switchover command overrides the redundancy lockout

command.

■ Example

host1(config)#redundancy lockout 5

■ Use the no version to restart redundancy protection for the slot.

■ See redundancy lockout.

redundancy revertive

■ Use to enable the router to revert from all spare line modules to the associated

primary line modules automatically.

■ Reversion takes place when the primary line module is again available unless

you specify a time of day. In that case, reversion takes place only when the
primary module is available and after the specified time.

■ Example

host1(config)#redundancy revertive 23:00:00

■ Use the no version to disable automatic reversion.

■ See redundancy revertive.

Managing Line Module Redundancy

When the router is running and a redundancy group is installed, you can manage
the redundancy situation as follows:

■ Force switchover manually.

■ Force reversion manually.

redundancy force-switchover

10 ■ Line Module Redundancy Overview

redundancy revert

Chapter 2: Managing Module Redundancy

■ Use to force the router to switch from the primary line module in the specified

slot or the primary SRP module to the spare line module or SRP module.

■ The command causes a single switchover. When you reboot, the router reverts

to the configured setting for this slot.

■ The redundancy force-switchover command overrides the redundancy lockout

command.

■ Example

host1#redundancy force-switchover 5

■ There is no no version.

■ See redundancy force-switchover.

■ Use to force the router to revert to the primary line module in the specified slot.

■ The router acts on this command immediately unless you specify a time or a

■ The command causes a single reversion. When you reboot, the router uses the

■ Example

■ There is no no version.

■ See redundancy revert.

SRP Module Redundancy

This section covers general issues of SRP module redundancy. It does not cover NVS
cards or the behavior on systems running high availability features such as hitless
SRP switchover. For information about managing NVS in a router that contains two
SRP modules, see Managing Flash Cards on SRP Modules in the JUNOSe System Basics
Configuration Guide. For information about managing high availability in a router,
see “Managing Module Redundancy” on page 7.

The information in this section does not apply to the ERX310 router, which does not
support SRP module redundancy. For this reason, any references to synchronization
that may appear in command output or system messages do not apply to the ERX310
router.

time and date that the action is to take place.

configured setting for this slot.

host1#redundancy revert 4 23:00:00 5 September 200X

SRP Module Behavior

The SRP module uses a 1:1 redundancy scheme. When two SRP modules are installed
in the router, one acts as a primary and the second as a redundant module. On
ERX7xx models, ERX14xx models, and the ERX310 router, both SRP modules share
a single SRP I/O module located in the rear of the chassis. On the E120 and E320
routers, both SRP modules share an SRP IOA located in the rear of the chassis.

Line Module Redundancy Overview ■ 11

JUNOSe 11.1.x Service Availability Configuration Guide

After you install two SRP modules, the modules negotiate for the primary role. A
number of factors determine which module becomes the primary; however,
preference is given to the module in the lower slot. The SRP modules record their
latest roles and retain them the next time you switch on the router.

With the default software settings, if the primary SRP module fails, the redundant
SRP module assumes control without rebooting itself. For information about
preventing the redundant SRP module from assuming control, see “Managing SRP
Module Redundancy” on page 16.

On E120 and E320 routers, the switch fabric is distributed between the SFMs and
the SRP modules. If the primary SRP module fails a diagnostic test on its resident
slice of switch fabric, then it abdicates control to the redundant SRP module if both
of the following are true:

■ The standby SRP module does not indicate any error.

■ The standby SRP module passes diagnostics on its attached fabric slice.

When the redundant SRP module assumes control, the following sequence of events
occurs:

1. The original primary SRP module reboots and assumes the redundant role.

2. The redundant SRP module restarts and assumes the primary role without

reloading new code. (When upgrading software, you must reload the software
on the redundant SRP module. See Installing JUNOSe Software in the JUNOSe
System Basics Configuration Guide.)

3. All line modules reboot.

The following actions activate the redundant SRP module:

■ Failure of the primary SRP module (hardware or software)

■ Pushing the recessed reset button on the primary SRP module (See Figure 1 on

page 13 and Figure 2 on page 14.)

■ Issuing the srp switch command

■ Issuing the redundancy force-switchover command

12 ■ Line Module Redundancy Overview

Chapter 2: Managing Module Redundancy

Figure 1: SRP Module on ERX7xx Models and ERX14xx Models

Line Module Redundancy Overview ■ 13

JUNOSe 11.1.x Service Availability Configuration Guide

Figure 2: SRP Module on the E120 and E320 Routers

Specifying the Configuration for Redundant SRP Modules

On a router with redundant SRP modules, you can specify the configuration that
both the primary and redundant modules load in the event of a reload or switchover.
A switchover can result from an error on the primary SRP module or from an srp
switch command. The following behavior takes place only in the event of a cold
restart; it does not take place in the event of a warm restart.

When you arm a configuration (.cnf) file by issuing the boot config cnfFilename
command, a subsequent SRP switchover causes the redundant SRP module to take
the role of primary SRP module with the configuration specified by the .cnf file. The
new primary SRP module does not use the running configuration.

If you want the redundant SRP module to instead use the running configuration when
it takes the primary role, then you must first arm a configuration file with the boot
config cnfFilename once command. To exhaust the once option, you must then
cause the redundant SRP module to reload for some reason, such as by issuing a
reload command or by arming a new JUNOSe Software release or a hotfix file.

14 ■ Line Module Redundancy Overview

When a switchover subsequently occurs, the redundant SRP module reloads with
the running configuration and takes the primary role. For more information about
the boot config command, see Booting the System in the JUNOSe System Basics
Configuration Guide.

Installing a Redundant SRP Module

You can install a redundant SRP module into a running router, provided that the
redundant SRP module has a valid, armed software release on its NVS card. Access
to a software release in NVS ensures that the redundant SRP module can boot; the
release need not be the same as that on the primary SRP module.

WARNING: Do not insert any metal object, such as a screwdriver, or place your hand
into an open slot or the backplane when the router is on. Remove jewelry (including
rings, necklaces, and watches) before working on equipment that is connected to
power lines. These actions prevent electric shock and serious burns.

Chapter 2: Managing Module Redundancy

CAUTION: When handling modules, use an antistatic wrist strap connected to the
router’s ESD grounding jack, and hold modules by their edges. Do not touch the
components, pins, leads, or solder connections. These actions help to protect modules
from damage by electrostatic discharge.

To install a redundant SRP module into a running router, follow these steps:

1. Install the redundant SRP module into the open SRP slot (slot 6 or 7 for ERX14xx

models, the E120 router, and the E320 router; slot 0 or 1 for ERX7xx models).

For detailed information about installing the SRP module, see the ERX Hardware
Guide or the E120 and E320 Hardware Guide.

2. Wait for the redundant SRP module to boot, initialize, and reach the standby

state.

When the module is in standby state, the REDUNDANT LED is on and the ONLINE
LED is off. If you issue the show version command, the state field for the slot
that contains the redundant SRP module is standby.

3. Synchronize the NVS file system of the redundant SRP module to that of the

primary SRP module.

NOTE: The SRP module reboots after synchronization is complete.

reload slot

■ Use to reboot a selected slot on the router.

■ If you specify a slot on the E120 or E320 router that contains an SRP module,

you reboot the SC subsystem on that slot by default. You do not, however, reboot
the fabric slice that resides on the slot.

Line Module Redundancy Overview ■ 15

JUNOSe 11.1.x Service Availability Configuration Guide

■ Use the srp keyword to reboot the portion of the SC subsystem that resides

on a specified SRP module.

■ Use the fabric keyword to reboot the fabric slice that resides on the specified

SRP module.

■ Example 1—Reboots the module in slot 7

host1#reload slot 7

■ Example 2—Reboots the SC on the SRP module in slot 7 (applies only to E120

and E320 routers)

host1#reload slot 7 srp

■ There is no no version.

■ See reload slot.

synchronize

■ Use to force the file system of the redundant SRP module to synchronize with

the NVS file system of the primary SRP module.

■ If you synchronize the redundant SRP module with the primary SRP module and

the redundant module is armed with a release different from the one it is currently
running, the redundant SRP module is automatically rebooted to load the armed
release.

■ Optionally, you can use the low-level-check keyword to force the router to

validate all files or only configuration files in NVS, and to synchronize all files
that failed the checksum test during the flash-disk-compare command as well
as any other files that are unsynchronized. See Managing Flash Cards on SRP
Modules in the JUNOSe System Basics Configuration Guide for details.

■ Examples

host1#synchronize
host1#synchronize low-level-check all
host1#synchronize low-level-check configuration

■ There is no no version.

■ See synchronize.

Managing SRP Module Redundancy

You can prevent the redundant SRP module from taking over when:

■ The primary SRP module experiences a software failure.

■ You push the reset button on the primary SRP module.

16 ■ Line Module Redundancy Overview

disable-switch-on-error

Chapter 2: Managing Module Redundancy

NOTE: If you do not configure this option, when troubleshooting an SRP module,
disconnect the other SRP module from the router. This action prevents the redundant
SRP module from taking over if you push the reset button on the primary SRP module.

To configure this option:

1. Issue the disable-switch-on-error command.

2. Synchronize the NVS file system of the redundant SRP module to that of the

primary SRP module.

■ Use to prevent the redundant SRP module from taking over if the primary SRP

module experiences a software failure or if you push the reset button on the
primary SRP module.

synchronize

■ Issue the synchronize command immediately before you issue this command.

■ If you issue the disable-switch-on-error command, and later issue the srp

switch command, the redundant SRP module waits about 30 seconds before it
takes over from the primary SRP module.

■ Example

host1(config)#disable-switch-on-error

■ Use the no version to revert to the default situation, in which the redundant SRP

module takes over if the primary SRP module experiences a software failure.

■ See disable-switch-on-error.

■ Use to force the NVS file system of the redundant SRP module to synchronize

with the NVS file system of the primary SRP module.

■ If you synchronize the redundant SRP module with the primary SRP module and

the redundant module is armed with a release different from the one it is currently
running, the redundant SRP module is automatically rebooted to load the armed
release.

■ Optionally, you can use the low-level-check keyword to force the router to

validate all files or only configuration files in NVS, and to synchronize all files
that failed the checksum test during the flash-disk-compare command as well
as any other files that are unsynchronized. See Managing Flash Cards on SRP
Modules in the JUNOSe System Basics Configuration Guide for details.

■ Examples

host1#synchronize
host1#synchronize low-level-check all
host1#synchronize low-level-check configuration

Line Module Redundancy Overview ■ 17

JUNOSe 11.1.x Service Availability Configuration Guide

■ There is no no version.

■ See synchronize.

Switching to the Redundant SRP Module

To switch immediately from the primary SRP module to the redundant SRP module,
issue the redundancy force-switchover command or the srp switch command. You
can configure the router to prompt you if the modules are in a state that could lead
to loss of configuration data or NVS corruption.

redundancy force-switchover

■ Use to force the router to switch from the primary line module in the specified

slot or the primary SRP module to the spare line module or SRP module.

■ The command causes a single switchover. When you reboot, the router reverts

to the configured setting for this slot.

srp switch

■ With the srp option, the command is equivalent to the srp switch command.

■ The redundancy force-switchover command overrides the redundancy lockout

command.

■ Example

host1#redundancy force-switchover 5

■ There is no no version.

■ See redundancy force-switchover.

■ Use to switch from the primary SRP module to the redundant SRP module.

■ When the high availability state is active, this command delays until all transaction

data, up to when you issue the command, has been mirrored to the standby SRP
module. This preserves legacy behavior requiring that SRP modules be
synchronized before the switchover.

■ If you specify the force keyword, the procedure fails if the SRP modules are in

certain states, such as during a synchronization. In these cases, the router displays
a message that indicates that the procedure cannot currently be performed and
the reason why. However, if the SRP modules are in other states that could lead
to a loss of configuration data or an NVS corruption, the router displays a message
that explains the state of the SRP modules, and prompts you to confirm (enter
yes or no) whether you want to proceed.

■ If you do not specify the force keyword, the procedure fails if the SRP modules

are in any state that could lead to a loss of configuration data or an NVS
corruption, and the router displays a message explaining the command failure.

■ When you issue this command, the router prompts you for a confirmation before

the command takes effect.

18 ■ Line Module Redundancy Overview

■ If you issue the disable-switch-on-error command and later issue the srp switch

command, the redundant SRP module waits about 30 seconds before it takes
over from the primary SRP module.

■ If the router does not contain a redundant SRP module, this command has no

effect.

■ Example

host1#srp switch
host1#srp switch force

■ There is no no version.

■ See srp switch.

Upgrading Software on a Redundant SRP Module

For information about upgrading software on SRP modules on ERX7xx models,
ERX14xx models, or the ERX310 router, see Installing JUNOSe Software in the JUNOSe
System Basics Configuration Guide.

Chapter 2: Managing Module Redundancy

Monitoring the Status LEDs

You can determine the redundancy state of line modules and SRP modules by
examining their status LEDs. See Table 4 on page 19 for a description of the LEDs
functions. In addition, if you issue the show version command, the state field for
the slot that contains the redundant SRP module indicates standby.

Table 4: Function of the Online and Redundant LEDs

State of the ModuleRedundant LEDOnline LED

Module is booting or is an inactive primary line module.OffOff

Module is active, but no redundant module is available.OffOn

Module is in standby state.OnOff

Module is active, and a redundant module is available.OnOn

Monitoring Line Module and SRP Module Redundancy

You can use show commands to monitor the status of redundancy groups, line
modules, and SRP modules.

NOTE: For more information about monitoring high availability, see “Managing
Module Redundancy” on page 7.

show environment

Monitoring Line Module and SRP Module Redundancy ■ 19

JUNOSe 11.1.x Service Availability Configuration Guide

Use to display information about the hardware installed for redundancy.■

■ See Managing the System in the JUNOSe System Basics Configuration Guide for

details and examples.

■ See show environment.

show hardware

Use to display detailed information about the line modules and SRP modules.■

■ See Monitoring Modules in the JUNOSe System Basics Configuration Guide for

details and examples.

■ See show hardware.

show redundancy

■ Use to display the configuration for line module redundancy and SRP redundancy.

■ Field descriptions

■ SRP

■ high-availability state—State of the high availability mode (disabled,

active, or pending)

■ current redundancy mode—Redundancy mode currently being used by

this router (high-availability or file-system-synchronization)

■ last activation type—Last type of activation that occurred on this router

(that is, the method by which the SRP last booted [cold-start or
warm-start])

■ Criteria Preventing High Availability from being Active—Criteria required

for high availability to be active.

■ slot—Slot in which the line module resides

■ hardware role—Function of the line module: primary or spare

■ lockout config—Status of redundancy on this line module

■ protected—Line module redundancy is enabled

■ locked out—Line module redundancy is disabled

■ backed up by slot—Slot that contains the line module that is a spare for this

primary line module

■ sparing for slot—Slot that contains the primary line module for which this

line module is a spare

■ revert at—Time at which you want the line module to revert

■ midplane type—Identifier for the type of midplane

20 ■ Monitoring Line Module and SRP Module Redundancy

Chapter 2: Managing Module Redundancy

■ midplane rev—Hardware revision number of the redundancy midplane

■ fabric slice redundancy—Status of the fabric slice on the SRP modules or

SFMs on the E120 and E320 routers

■ slot—Slot in which the fabric slice resides

■ state—State of the fabric slice (online, not present)

■ type—Identifier for the type of hardware (SRP module or SFM)

■ Example 1

In the following example, the user issues a show redundancy command, and
then a redundancy force switchover command. Finally, the user issues the
show redundancy line-card command to display information specific to the
line modules. The two displays show how the states of the primary and spare
line modules change.

host1#show redundancy

SRP

---

high-availability state: disabled
current redundancy mode: file-system-synchronization
last activation type: cold-start

Criteria Preventing High Availability from being Active

------------------------------------------------------­ criterion met

---------------------------------- --­High Availability mode configured? No
Mirroring Subsystem present? No

Line Card

---------

automatic reverting is off

backed
up sparing
hardware lockout by for revert
slot role config slot slot at

---- -------- --------- ------ ------- -----­ 0 spare --- --- --- --­ 2 primary protected --- --- --­ 12 --- --- --- --- ---

midplane midplane
slots type rev

----- -------- -------­0 - 5 6 0

host1#redundancy force-switchover 2
host1#show redundancy line-card

automatic reverting is off

backed
up sparing

Monitoring Line Module and SRP Module Redundancy ■ 21

JUNOSe 11.1.x Service Availability Configuration Guide

hardware lockout by for revert
slot role config slot slot at

---- -------- --------- ------ ------- -----­ 0 spare --- --- 2 --­ 2 primary protected 0 --- --­ 12 --- --- --- --- ---

midplane midplane
slots type rev

----- -------- -------­0 - 5 6 0

■ Example 2—Displays the redundancy status on an E320 router

host1#show redundancy

SRP

---

high-availability state: active
current redundancy mode: high-availability
last activation type: cold-start

show version

Line Card

---------

automatic reverting is off

backed
up sparing
hardware lockout by for revert
slot role config slot slot at

---- -------- --------- ------ ------- -----­ 0 spare --- --- --- ---
2 primary protected --- --- ---
4 primary protected --- --- ---

fabric slice redundancy: none
slot state type

---- ------ ------­6 online SFM-100
7 online SFM-100
8 --- ---
9 --- ---
10 --- ---

■ See show redundancy.

Use to display information about each module in the router.■

See Managing the System in the JUNOSe System Basics Configuration Guide, for
details and examples.

■ See show version.

22 ■ Monitoring Line Module and SRP Module Redundancy

Managing Port Redundancy

For information on port redundancy, see the JUNOSe Physical Layer Configuration
Guide. For information on managing port redundancy on Gigabit Ethernet I/O modules,
see Managing Port Redundancy on Gigabit Ethernet I/O Modules in the JUNOSe Physical
Layer Configuration Guide.

For information on redundancy and interface distribution of tunnel-service interfaces
see Redundancy and Interface Distribution of Tunnel-Service Interfaces in the JUNOSe
Physical Layer Configuration Guide.

Chapter 2: Managing Module Redundancy

Managing Port Redundancy ■ 23

JUNOSe 11.1.x Service Availability Configuration Guide

24 ■ Managing Port Redundancy

Chapter 3

Managing Stateful SRP Switchover

This chapter describes how to manage Juniper Networks Stateful SRP Switchover
(also referred to as high availability or HA) software features for the E Series router.
Use this chapter with “Managing Module Redundancy” on page 7 to fully manage
the SRP features.

This chapter contains the following sections:

■ Stateful SRP Switchover Overview on page 25

■ Stateful SRP Switchover Platform Considerations on page 26

■ Stateful SRP Switchover Redundancy Modes on page 27

■ Stateful SRP Switchover States on page 29

■ Application Support for Stateful SRP Switchover on page 32

■ Guidelines for Activating High Availability on page 41

■ Activating High Availability on page 42

■ Guidelines for Deactivating High Availability on page 42

■ Deactivating High Availability on page 43

■ Guidelines for Setting the IP Interface Priority on page 43

■ Setting the IP Interface Priority on page 44

■ Guidelines for Upgrading Software on page 44

■ Monitoring the Redundancy Status on page 45

■ Monitoring the Redundancy Status of Applications on page 48

■ Monitoring the Redundancy History on page 50

■ Monitoring the Redundancy Status of Line Modules on page 51

■ Monitoring the Redundancy Status of SRP Modules on page 52

■ Monitoring the Redundancy Switchover History on page 54

■ Clearing the Redundancy History on page 55

Stateful SRP Switchover Overview

Stateful SRP switchover is the idea of reducing or eliminating single points of failure.
When applied to the E Series router, stateful SRP switchover provides both
hardware-specific and software-specific methods to ensure minimal downtime and
ultimately improve the performance of your network.

Stateful SRP Switchover Overview ■ 25

JUNOSe 11.1.x Service Availability Configuration Guide

For hardware components, Juniper Networks provides redundancy solutions to ensure
that the router continues to operate in the event of a hardware fault. This redundancy
can exist on various router models in the form of multiple power supplies, cooling
fans, switching planes, routing engines and, in some cases, interfaces. Redundancy
also allows for hot-swapping various components within your Juniper Networks
router.

NOTE: For information about E Series hardware redundancy features, see the ERX
Hardware Guide or the E120 and E320 Hardware Guide.

Related Topics Stateful SRP Switchover Redundancy Modes on page 27■

■ Stateful SRP Switchover States on page 29

■ Application Support for Stateful SRP Switchover on page 32

Stateful SRP Switchover Platform Considerations

Stateful SRP switchover is supported on all E Series routers except for the ERX310
Broadband Services Router.

For information about the modules supported on E Series routers:

■ See the ERX Module Guide for modules supported on ERX7xx models and

ERX14xx models.

■ See the E120 and E320 Module Guide for modules supported on the E120 and

E320 Broadband Services Routers.

Module Requirements

The following table lists which SRPs support or do not support the high availability
mode (stateful SRP switchover) feature.

SupportedSRP Model

NoSRP-5G

YesSRP-5G+

YesSRP-10G

26 ■ Stateful SRP Switchover Platform Considerations

NoSRP-40G

YesSRP-40G PLUS

YesSRP-100

NOTE: Stateful SRP switchover requires two SRP modules with 1 GB of memory or
more.

Related Topics ■ Monitoring the Redundancy Status on page 45

■ Monitoring the Redundancy Status of SRP Modules on page 52

■ show redundancy

■ show redundancy srp

Stateful SRP Switchover Redundancy Modes

The switch route processor (SRP) modules can operate in one of two redundancy
modes—file system synchronization and high availability.

Chapter 3: Managing Stateful SRP Switchover

File System Synchronization Mode

File system synchronization is the default behavior mode for E Series routers that
contain redundant SRPs. Available only to SRP modules, this mode has been available
since the JUNOSe Software 2.x release. In this mode:

■ Files and data (for example, configuration files and releases) in nonvolatile storage

(NVS) remain synchronized between the primary and standby SRP modules.

■ SRP modules reload all line modules and restart from saved configuration files.

■ If the active SRP module switches over to the standby SRP, the router cold-restarts

as follows:

■ All line modules are reloaded.

■ User connections are lost, and forwarding through the chassis stops until

the router SRP module recovers.

■ The standby SRP module boots from the last known good configuration from

NVS.

For additional information about the default SRP functionality, see “Managing Module
Redundancy” on page 7.

High Availability Mode

Currently applicable to the SRP module, Juniper Networks high availability mode
uses an initial bulk file transfer and subsequent, transaction-based mirroring to ensure
rapid SRP module recovery after a switchover. This process is referred to in this
chapter as stateful SRP switchover.

In addition to keeping the contents of NVS, high availability mode keeps state and
dynamic configuration data from the SRP memory synchronized between the primary
and standby SRP modules.

Stateful SRP Switchover Redundancy Modes ■ 27

JUNOSe 11.1.x Service Availability Configuration Guide

When stateful SRP switchover is enabled, an SRP switchover keeps line modules up
and forwarding data, and the newly active SRP module continues from the point of
switchover.

By using transaction-based mirroring instead of file synchronization, high availability
mode keeps the standby SRP module synchronized with the active SRP module.
Mirroring occurs from memory on the active SRP module to memory on the standby
SRP module by way of transactions. When a transaction is committed on the active
SRP module, the data associated with the transaction is sent to the standby SRP
module.

In high availability mode:

■ The contents of the NVS in the primary and standby SRP modules remain

synchronized.

NOTE: Configuration files are always synchronized. Nonconfiguration files are
synchronized when the disable-autosync command has not been configured; this
is the default case. When the disable-autosync command has been configured,
nonconfiguration files are not synchronized.

■ If a switchover occurs:

■ The standby SRP module warm-restarts using the mirrored data to restore

itself to the state of the system before the switchover.

■ During the warm restart:

■ User connections remain active, and forwarding continues through the

chassis.

■ New user connection attempts during switchover are denied until

switchover is complete.

■ New configuration changes are prevented until switchover is complete

(or after 5 minutes).

NOTE: If the switchover does not finish within 5 minutes, the SRP module cancels
the operation and reenables CLI configuration.

Related Topics ■ Stateful SRP Switchover States on page 29

■ disable-autosync

■ redundancy

■ mode

28 ■ Stateful SRP Switchover Redundancy Modes

Stateful SRP Switchover States

The SRP progresses through various high availability states. These states are illustrated
in Figure 3 on page 29.

Figure 3: High Availability States

Chapter 3: Managing Stateful SRP Switchover

Disabled State

The initial, default state for high availability mode is disabled. While in this state, the
router continues to use file system synchronization. If a switchover occurs while the
router is in this state, the standby SRP module performs a cold restart.

The router enters this state when you power up the router or when the router
warm-restarts from an SRP switchover.

After you enable high availability, the system must meet the following criteria before
it can enter the initializing state:

■ High availability mode is configured.

■ Active SRP hardware supports high availability.

■ Network core dump feature is disabled.

■ Running configuration allows high availability to operate (that is, no unsupported

applications are configured).

■ Standby SRP hardware supports high availability.

■ Standby SRP module is online and capable of mirroring.

■ Standby SRP module is running the same release.

Stateful SRP Switchover States ■ 29

JUNOSe 11.1.x Service Availability Configuration Guide

During the disabled state:

■ If any one criterion is not met, the system remains in the disabled state, until

the criterion is met.

■ If a switchover occurs while the system is in the disabled state, the system

cold-restarts.

While in the disabled state, the system operates as if it were configured for file system
synchronization (for example, NVS is synchronized every 5 minutes, if
autosynchronization is enabled).

If all criteria are met, high availability mode transitions to the initialization state.

Initializing State

After the SRP module transitions into the initializing state, bulk synchronization of
the memory and NVS occurs. This includes the following:

Active State

■ File synchronization of the primary NVS with the standby NVS

■ Mirroring of appropriate state and dynamic configuration information from the

active SRP (memory) to the standby SRP (memory)

NOTE: Depending on the size of the configuration, this process can take several
minutes.

During the initializing state:

■ If an unsupported application is configured during initialization, the system

completes initializing and enters the pending state.

■ If any other criterion becomes false (or is no longer met), the system enters the

disabled state.

■ If a switchover occurs while the system is in this state, the system cold-restarts.

After initialization is completed, the system enters the active state.

During the active state, the data that was synchronized from the active SRP module
to the standby SRP module during initialization remains synchronized through
mirroring updates.

Mirroring updates occur as follows:

1. When making changes or updates, applications create individual transactions,

perform the updates on the active SRP module, and post the transactions.

2. Following the updates, the active SRP module sends the changes to the standby

SRP module.

30 ■ Stateful SRP Switchover States

Chapter 3: Managing Stateful SRP Switchover

3. The standby SRP module replays the updates (in the order in which they were

committed on the active SRP module) and makes the appropriate changes for
each changed application.

4. Updates that need to be stored in NVS (that is, for static configurations) are

updated in NVS.

NOTE: While in the active and pending states, the CLI synchronize command does
not update configuration files; these files are updated by the mirroring process.

During the active state:

■ If a switchover occurs while the router is in the active state, the standby SRP

module performs a warm restart (that is, stateful SRP switchover is in effect);
the standby SRP module uses the configuration located in NVS.

■ If an unsupported application is configured, the system transitions to the pending

state.

Pending State

■ If any other criterion changes (is no longer met), the system transitions to the

disabled state.

NOTE: Changes made in manual commit mode are maintained, uncommitted, in
the standby SRP memory until a trigger to commit occurs; if a switchover occurs
while in this mode, the standby SRP module uses the configuration in memory.

The system transitions to the pending state if an unsupported application is
configured. When a transition to the pending state occurs, the system generates
SNMP traps and log messages.

How the router behaves depends on which HA state the application is in when it
shifts to a pending state:

■ From disabled state—The router remains in the disabled state.

■ From initializing state—The router completes the initializing state and transitions

to the pending state after initialization is complete.

■ Active State—The router transitions to the pending state.

The system remains in the pending state until the configuration of the unsupported
application is removed. However, even though it is in the pending state, the system
continues mirroring updates from the primary SRP module to the standby SRP
module.

Stateful SRP Switchover States ■ 31

JUNOSe 11.1.x Service Availability Configuration Guide

NOTE: You can use the show redundancy srp command to display the name of any
unsupported applications that are configured.

If a switchover occurs while the system is in the pending state, the system
cold-restarts.

Related Topics ■ Monitoring the Redundancy Status on page 45

■ Monitoring the Redundancy Status of SRP Modules on page 52

■ show redundancy

■ show redundancy srp

■ synchronize

Application Support for Stateful SRP Switchover

Applications are either supported or unsupported by stateful SRP switchover.

■ Supported—You can configure supported applications without having any adverse

impact to stateful SRP switchover. When a switchover occurs, supported
applications can react to switchovers in one of two different ways:

■ Gracefully recover using mirrored static and dynamic information (for

example, IP, PPP, and PPPoE)

■ Recover using static configuration only; that is, no runtime state is restored

after a switchover. Dynamic configuration and state information are lost.
(For example, CLI sessions are restarted, telnet sessions are dropped,
multicast routes must be rebuilt, and so on.)

■ Unsupported—We recommend that you not configure unsupported applications

on a chassis running in high availability mode. Although configured unsupported
applications suspend high availability or prevent high availability from becoming
active, they do not cause any problems with the function of the router.

Table 5 on page 32 indicates which applications support or do not support stateful
SRP switchover.

Application Support

Table 5: Application Support for Stateful SRP Switchover

Physical Layer
Protocols

32 ■ Application Support for Stateful SRP Switchover

NotesUnsupportedSupportedApplication

––✓DS1

––✓DS3

Chapter 3: Managing Stateful SRP Switchover

Table 5: Application Support for Stateful SRP Switchover (continued)

NotesUnsupportedSupportedApplication

––✓HDLC

––✓SONET/SDH

––✓SONET/SDH VT

Link-Layer
Protocols

–✓ATM

Static and dynamic interfaces, with the
exception of ATM subscribers, are
supported.

In this case, ATM subscribers refers to a
technology on the E Series router where
the ATM layer does authentication (that
is, not PPP or IP subscriber manager).

configuration of
dynamic interfaces

without VLANs)

bridging

Unicast Routing

––✓ATM 1483 bulk

––✓Bridged Ethernet

––✓Cisco HDLC

––✓Ethernet (with and

––✓Frame Relay

––✓PPP

––✓PPPoE

––✓Transparent

––✓Access Routes

–✓BFD

During a stateful SRP switchover, the
BFD transmit interval is set to 1000 ms
with a detection multiplier of 3. These
values result in a liveness detection
interval of 3000 ms. This longer interval
helps prevent a BFD timeout during the
switchover. BFD negotiates the interval
with the remote peer before applying
the temporary change. The BFD timers
revert back to the configured values after
15 minutes (the maximum duration for
graceful restart completion).

Application Support for Stateful SRP Switchover ■ 33

JUNOSe 11.1.x Service Availability Configuration Guide

Table 5: Application Support for Stateful SRP Switchover (continued)

NotesUnsupportedSupportedApplication

discovery

–✓BGP

Supported for IPv4 only when the
graceful restart extension is enabled.
Does not support graceful restart for
IPv6 address families.

Static recovery support only.–✓FTP

––✓IP

––✓IPv6

–✓IPv6 neighbor

IPv6 neighbor discovery characteristics
are replayed during switchover. Line
modules do not flush neighbor discovery
information during the switchover.

–✓–IPSec Transport

–✓IPSec Tunnels

Completed IKE phase 1 and phase 2
negotiations supported only.

–✓IS-IS

Supported only when the graceful restart
extension is enabled.

–✓IS-ISv6

Supported only when the graceful restart
extension is enabled.

–OSPFv2

Supported only when the graceful restart
extension is enabled.

and IPv6)

IPv4 Multicast
Routing

–✓OSPFv3

Supported only when the graceful restart
extension is enabled.

Static recovery support only.–✓RIP

–✓Static Routes (IP

After all high-priority interfaces have
been replayed from NVS and mirrored
storage, static routes are replayed from
NVS, followed by replay of low-priority
interfaces from NVS and mirrored
storage. This behavior enables static
routes that are dependent on
high-priority interfaces to be resolved
quickly and installed in the IP routing
table.

Static recovery support only.–✓Telnet

–✓Multicast Routing

Static recovery support only. During
switchover, the system mirrors the
multicast queue so that IP can use the
same queue without needing to re-create
a different connection.

34 ■ Application Support for Stateful SRP Switchover

Chapter 3: Managing Stateful SRP Switchover

Table 5: Application Support for Stateful SRP Switchover (continued)

NotesUnsupportedSupportedApplication

–✓DVMRP

Static recovery support only. DVMRP
gives the restart complete indication to
the IP routing table after getting a peer
update (60-second timeout).

–✓IGMP

IC IGMP deletes its interface and
membership state on SRP failover
(controller down). As part of SRP warm
start, IGMP interfaces are reconfigured
from NVS and dynamic IGMP interfaces
are reconfigured from mirrored storage.
IGMP hosts are queried as IP interfaces
come back up, the join state is
re-established, and SC IGMP state is
created.

After the maximum query response time
(across all interfaces) expires to allow
hosts to re-establish join state, IGMP
notifies MGTM that graceful restart is
complete.

–✓MGTM

On SRP failover, old mroutes are
retained on the line module to preserve
multicast forwarding; cache-misses to
the SRP are disabled. When MGTM
warm starts on the SRP, it reads the NVS
configuration and enables multicast
routing. When IGMP, DVMRP, and PIM
have completed graceful restart and the
IP route table multicast-view has
completed graceful restart, old mroutes
are deleted from the line module and
cache-misses to the SRP are enabled.
This triggers re-creation of mroutes and
establishes the current multicast
forwarding state.

Although cache-misses to the SRP
module are disabled, forwarding is
preserved for old multicast joins to
downstream routers and hosts.
However, forwarding for new multicast
joins requested by downstream routers
and hosts after SRP module switchover
is not provided until cache-misses are
re-enabled.

Application Support for Stateful SRP Switchover ■ 35

JUNOSe 11.1.x Service Availability Configuration Guide

Table 5: Application Support for Stateful SRP Switchover (continued)

NotesUnsupportedSupportedApplication

IPv6 Multicast
Routing

–✓PIM

Static recovery support only. For warm
start, PIM interfaces are reconfigured
from NVS. A Hello message with a new
Generation ID is issued as IP interfaces
come up. A neighbor that receives this
Hello determines that the upstream
neighbor has lost state and needs to be
refreshed. A VR-global configurable
graceful restart timer is required for PIM
to time out the re-establishment of the
join state for sparse-mode interfaces.
After this timer expires, PIM notifies
MGTM that graceful restart is complete.

–✓Multicast Routing

Static recovery support only. During
switchover, the system mirrors the
multicast queue so that IPv6 can use the
same queue without needing to re-create
a different connection.

–✓MGTM

On SRP failover, old mroutes are
retained on the line module to preserve
multicast forwarding; cache-misses to
the SRP are disabled. When MGTM
warm starts on the SRP, it reads the NVS
configuration and enables multicast
routing. When MLD and PIM have
completed graceful restart and the IPv6
route table multicast-view has completed
graceful restart, old mroutes are deleted
from the line module and cache-misses
to the SRP are enabled. This triggers
re-creation of mroutes and establishes
the current multicast forwarding state.

36 ■ Application Support for Stateful SRP Switchover

Although cache-misses to the SRP
module are disabled, forwarding is
preserved for old multicast joins to
downstream routers and hosts.
However, forwarding for new multicast
joins requested by downstream routers
and hosts after SRP module switchover
is not provided until cache-misses are
re-enabled.

Chapter 3: Managing Stateful SRP Switchover

Table 5: Application Support for Stateful SRP Switchover (continued)

NotesUnsupportedSupportedApplication

–✓MLD

IC MLD deletes its interface and
membership state on SRP failover
(controller down). As part of SRP warm
start, MLD interfaces are reconfigured
from NVS and dynamic IMLD interfaces
are reconfigured from mirrored storage.
MLD hosts are queried as IPv6 interfaces
come back, the join state is
re-established, and SC MLD state is
created. After the maximum query
response time (across all interfaces)
expires to allow hosts to re-establish join
state, MLD notifies MGTMv6 that
graceful restart is complete.

–✓PIM

Static recovery support only. For warm
start, PIM interfaces are reconfigured
from NVS and a Hello message with a
new Generation ID is issued as IPv6
interfaces come up. A neighbor that
receives this Hello determines that the
upstream neighbor has lost state and
needs to be refreshed. A VR-global
configurable graceful restart timer is
required for PIM to time out the
re-establishment of the join state for
sparse-mode interfaces. After this timer
expires, PIM notifies MGTM that graceful
restart is complete.

Multiprotocol
Label Switching

–✓MPLS

MPLS is HA-unsafe during a graceful
restart. It is HA-unsafe until all the
configured MPLS signaling protocols
have completed their graceful restart
procedures and any stale forwarding
elements have been flushed from the
line modules.

If you force an SRP switchover while
MPLS is HA-unsafe, the SRP module
switches but the SRP module and the
line modules undergo a cold restart.

If the primary SRP module resets while
MPLS is HA-unsafe, the router undergoes
a cold restart.

MPLS over IPv6 supports HA. This
functionality enables BGP to support
graceful restart for IPv6 labeled
addresses.

—–✓BGP signaling

Application Support for Stateful SRP Switchover ■ 37

JUNOSe 11.1.x Service Availability Configuration Guide

Table 5: Application Support for Stateful SRP Switchover (continued)

NotesUnsupportedSupportedApplication

cross-connects
between layer 2
interfaces using
MPLS

Policies and QoS

–✓LDP signaling

To provide uninterrupted service during
an SRP switchover in a scaled
configuration, such as one with 32,000
Martini circuits, set the LDP graceful
restart reconnect time to the maximum
300 seconds and set the LDP graceful
restart recovery timer to the maximum
600 seconds. This requirement is true
for all SRP switchovers, including those
in the context of a unified in-service
software upgrade.

LDP signaling does not support HA for
IPv6.

—–✓RSVP signaling

––✓Local

––✓Policies

Static recovery support only.–✓QoS

Remote Access

Server and Packet
Trigger

Capture

––✓AAA

–✓DHCP External

Following a switchover, the DHCP lease
(that is, time remaining) is recalculated
based on when the lease started. When
the release timer for a client expires, the
client is deleted and the access route is
removed, along with the dynamic
subscriber interface if it was created. If
the client requests a new lease, DHCP
external server resynchronizes with the
new lease time.

––✓DHCP Packet

–✓–DHCP Proxy Client

––DHCP Relay Proxy

38 ■ Application Support for Stateful SRP Switchover

Chapter 3: Managing Stateful SRP Switchover

Table 5: Application Support for Stateful SRP Switchover (continued)

NotesUnsupportedSupportedApplication

Server

Server

–✓DHCP Relay Server

Before HA support, clients identified by
the DHCP relay server were maintained
on a switchover (their state was stored
to NVS); DHCP relay server always had
some level of HA support.

Currently, following a switchover, the
DHCP lease (that is, time remaining) is
reset. When the release timer for a client
expires, the client requests a new lease.
The E Series router DHCP relay server
then synchronizes with the new state.

––✓DHCPv4 Local

–✓DHCPv6 Local

DHCPv6 now supports stateful SRP
switchover (high availability).

After SRP warm switchover, the router
restores the client bindings from the
mirrored DHCPv6 information as it does
for other applications that support
stateful SRP switchover.

—–✓L2TP

–✓–L2TP Dialout

Pools

Pools

Dynamic-Request
Server

–✓IPv4 Local Address

The internal local address server state
supports only static recovery. However,
the AAA application reallocates active
addresses on a switchover. The resulting
effect is the IPv4 local address server
having full HA support.

–✓IPv6 Local Address

When the IPv6 local pools are
configured, you can perform an HA
switchover without cold booting the
router because the configuration is now
HA safe. The prefix assigned to the
subscriber, before and after the warm
restart, remains the same. The In Use
prefix count also remains the same
before and after the warm restart.

–✓RADIUS Client

Similar to local address server, AAA
recovers disrupted RADIUS
communication on a switchover. The
resulting effect is the RADIUS client
having full HA support.

Static recovery support only.–✓RADIUS

Application Support for Stateful SRP Switchover ■ 39

JUNOSe 11.1.x Service Availability Configuration Guide

Table 5: Application Support for Stateful SRP Switchover (continued)

NotesUnsupportedSupportedApplication

Disconnect

Server

Route-Download
Server

Miscellaneous

statistics)

Redundancy

–✓RADIUS Initiated

––✓RADIUS Relay

––✓RADIUS

––✓Service Manager

––✓SRC Client

Static recovery support only.–✓TACACS+

—–✓DNS

✓–DNSv6

If DNSv6 is configured, no warning or
error is displayed during a warm start.
DNSv6 is subsequently configured from
NVS as it is after a cold reboot.

––✓J-Flow (IP flow

––✓Line Module

Translation

Threshold Monitor

Reporter

Interfaces

DVMRP)

––✓Network Address

––✓NTP

––✓Resource

––✓Response Time

Static recovery support only.–✓Route Policy

–✓Subscriber

IPv4 only. Subscriber interfaces are not
applicable to IPv6.

––✓Tunnels (GRE and

Static recovery support only.–✓VRRP

40 ■ Application Support for Stateful SRP Switchover

CAUTION: When IP tunnels are configured on an HA-enabled router and the Service
Module (SM) carrying these tunnels is reloaded, HA transitions to the pending state.
HA remains in the pending state for 5 minutes after the successful reloading of the
SM. This amount of time allows for IP tunnel relocation and for the tunnels to become
operational again on the SM. If an SRP switchover occurs while HA is in the pending
state, the router performs a cold restart.

Related Topics Monitoring the Redundancy Status of Applications on page 48■

■ show redundancy clients

Guidelines for Activating High Availability

Before you activate high availability on the SRP modules, you must be aware of any
high availability–related changes to SRP management commands. For information
on high availability-related changes to SRP, see “Managing Module Redundancy” on
page 7.

Chapter 3: Managing Stateful SRP Switchover

You activate high availability (stateful SRP switchover) by launching Redundancy
Configuration mode and issuing the mode high-availability command. The
high-availability keyword enables high availability mode for stateful SRP switchover.
In this mode, the router uses mirroring to keep the configuration and state of the
standby SRP module coordinated with the configuration and state of the active SRP
module.

When activating high availability, keep the following in mind:

■ In an E Series router that supports stateful SRP switchover, both SRP modules

must be running the same software release version in order to activate high
availability mode.

■ If high availability mode cannot become active because of different releases on

the active and standby SRP modules, the system reverts to its default mode (file
system synchronization).

■ When active or pending, the router configuration files are mirrored from the

active SRP module to the standby SRP module. All other files shared between
the active and standby SRP modules are automatically synchronized using legacy
synchronization methods.

Related Topics ■ Stateful SRP Switchover Redundancy Modes on page 27

■ Activating High Availability on page 42

■ redundancy

■ mode

Guidelines for Activating High Availability ■ 41

JUNOSe 11.1.x Service Availability Configuration Guide

Activating High Availability

The switch route processor (SRP) module can operate in one of the two redundancy
modes—file system synchronization and high availability. When you activate high
availability, the router uses mirroring to keep the configuration and state of the
standby SRP module coordinated with the configuration and state of the active SRP
module.

To activate high availability:

1. From Global Configuration mode, launch Redundancy Configuration mode.

host1(config)#redundancy

2. In Redundancy Configuration mode, specify high availability as the redundancy

mode.

host1(config-redundancy)#mode high-availability

Related Topics ■ Stateful SRP Switchover Redundancy Modes on page 27

■ Guidelines for Activating High Availability on page 41

■ redundancy

■ mode

Guidelines for Deactivating High Availability

You can disable high availability (stateful SRP switchover) by launching Redundancy
Configuration mode and issuing the mode file-system-synchronization command
or specifying the no mode command.

In the file-system-synchronization mode, the router synchronizes the files and data
such as configuration files and releases that are stored in NVS (nonvolatile storage)
between the primary and standby SRP modules. This is the default behavior mode
for E Series routers that contain redundant SRPs.

Because this mode uses file synchronization instead of transaction-based mirroring,
when the active SRP module switches to the standby SRP, the router cold-starts.

Related Topics ■ Stateful SRP Switchover Redundancy Modes on page 27

■ Deactivating High Availability on page 43

■ redundancy

■ mode

42 ■ Activating High Availability

Deactivating High Availability

The switch route processor (SRP) module can operate in one of the two redundancy
modes—file system synchronization and high availability. When you disable high
availability, the router uses file system synchronization mode which is the default
behavior mode for E Series routers that use redundant SRPs. The router synchronizes
the contents of the NVS (nonvolatile storage) in the primary and standby SRP modules.

To disable high availability support:

1. From Global Configuration mode, launch Redundancy Configuration mode.

host1(config)#redundancy

2. In Redundancy Configuration mode, you can disable high availability by doing

one of the following:

■ Specify file system synchronization mode as the redundancy mode.

Chapter 3: Managing Stateful SRP Switchover

host1(config-redundancy)#mode file-system-synchronization

■ Specify the no version to disable high availability.

host1(config-redundancy)#no mode

Related Topics ■ Stateful SRP Switchover Redundancy Modes on page 27

■ Guidelines for Deactivating High Availability on page 42

■ redundancy

■ mode

Guidelines for Setting the IP Interface Priority

During the warm restart after an SRP switchover, IP and IPv6 interfaces are replayed
from NVS and from mirrored storage. High-priority IP and IPv6 interfaces are replayed
first, followed by static routes, and then by low-priority IP and IPv6 interfaces. This
scheme enables static routes that are dependent on high-priority interfaces to be
resolved and routing protocols to exchange information with peers over high-priority
interfaces before the low-priority interfaces are replayed.

You can designate an IP or IPv6 interface as high priority either implicitly or explicitly:

■ Implicit designation—Configure an IGP or PIM protocol on the interface.

■ Explicit designation—Issue the ip initial-sequence-preference 1 command on

the IP subinterface, or the ipv6 initial-sequence-preference 1 command on the
IPv6 subinterface.

Deactivating High Availability ■ 43

JUNOSe 11.1.x Service Availability Configuration Guide

An IP or IPv6 interface can be designated as high priority by more than one protocol,
the CLI command, or both. You can change an IP or IPv6 interface from high priority
to low priority only by one of the following methods:

■ Delete the IP or IPv6 interface.

■ Remove all high-priority configuration from the IP or IPv6 interface, then reload

the router.

Related Topics Setting the IP Interface Priority on page 44■

■ ip initial-sequence-preference

■ ipv6 initial-sequence-preference

Setting the IP Interface Priority

Use the ip initial-sequence-preference command to set the preference value on an
IP or IPv6 interface at the subinterface level. To configure the interface as high-priority,
specify the value of the initial sequence preference as 1. To configure the interface
as low-priority, specify the value as 0.

To set the priority for the IPv4 or IPv6 interface, you can do one of the following:

■ From Subinterface Configuration mode, explicitly configure the IPv4 interface

as high-priority:

host1(config-subif)#ip initial-sequence-preference 1

■ From Subinterface Configuration mode, explicitly configure the IPv6 interface

as low-priority:

host1(config-subif)#ipv6 initial-sequence-preference 0

Related Topics Guidelines for Setting the IP Interface Priority on page 43■

■ ip initial-sequence-preference

■ ipv6 initial-sequence-preference

Guidelines for Upgrading Software

You cannot activate stateful SRP switchover when a different release of software is
running on the standby SRP module. The router determines whether a release is the
same by viewing the build date, the release filename, and the internal version number
for the software on each SRP module.

The most efficient way to upgrade the software is to ensure that the standby SRP
module is armed with the new release and then reload the standby SRP module.
This reload occurs automatically after you download and arm a new release onto the

44 ■ Setting the IP Interface Priority

Chapter 3: Managing Stateful SRP Switchover

active SRP module and the active SRP module subsequently synchronizes with the
standby SRP module.

After reloading, and even though high availability mode is configured, the active SRP
module reverts to using the file-system-synchronization operational mode for
synchronizing updates. To complete the upgrade and place the system back in
high-availability operational mode, you must execute the srp switch command to
force the standby SRP module to take over as the active SRP module.

NOTE: Executing the srp switch command results in a cold restart of the router.

After the switchover is initiated, the formerly active SRP module reloads the software
and starts running the same release as the newly active SRP module. When the
formerly active SRP module becomes operational as the standby SRP module, the
newly active SRP module detects that the release it is running is the same as that on
the standby SRP module and allows the originally active SRP module to resume the
high-availability operational mode.

If a fault occurs when the active SRP module is in file-system-synchronization
operational mode, the standby SRP module detects the fault and takes over, and the
router cold-restarts. For this reason, you must arm the new release only when you
can accept the resulting window of vulnerability where high availability is disabled
(that is, until the active and standby SRP modules are again running the same release).

Related Topics Stateful SRP Switchover Redundancy Modes on page 27■

■ Stateful SRP Switchover States on page 29

■ srp switch

Monitoring the Redundancy Status

Purpose Display the redundancy modes and other information about stateful SRP switchover.

Action To display summary redundancy status information.

host1#show redundancy
SRP

---

high-availability state: disabled
current redundancy mode: high-availability
last activation type: cold-switch

Criteria Preventing High Availability from being Active

------------------------------------------------------­ criterion met

----------------------------------------------- --­Standby SRP is online and capable of mirroring? No

Line Card

Monitoring the Redundancy Status ■ 45

JUNOSe 11.1.x Service Availability Configuration Guide

---------

automatic reverting is off

backed
up sparing
hardware lockout by for revert
slot role config slot slot at

---- -------- --------- ------ ------- -----­ 3 --- --- --- --- --­ 8 spare --- --- --- --­ 12 primary protected --- --- ---

midplane midplane
slots type rev

------ -------- -------­8 - 13 6 0

To display detailed redundancy status information:

host1#show redundancy detail
SRP

--­high-availability state: disabled
current redundancy mode: file-system-synchronization
last activation type: cold-start
Criteria Required for High Availability to be Active

---------------------------------------------------­ criterion met

---------------------------------------------------- --­Active SRP hardware supports High Availability? Yes
High Availability mode configured? No
Mirroring Subsystem present? Yes
Mirroring activity levels within limits? Yes
Network Core Dumps disabled? Yes
Running configuration is safe for High Availability? Yes
Standby SRP hardware supports High Availability? Yes
Standby SRP is online and capable of mirroring? Yes
Standby SRP is running the same release? Yes
Line Card

--------­automatic reverting is off
backed
up sparing
hardware lockout by for revert
slot role config slot slot at

---- -------- --------- ------ ------- -----­ 3 --- --- --- --- --­ 8 spare --- --- --- --­ 12 primary protected --- --- --­ midplane midplane
slots type rev

------ -------- -------­8 - 13 6 0

Meaning Table 6 on page 47 lists the show redundancy command output fields.

46 ■ Monitoring the Redundancy Status

Table 6: show redundancy Output Fields

Field DescriptionField Name

SRP

Chapter 3: Managing Stateful SRP Switchover

high-availability state

current redundancy mode

last activation type

State of high availability mode:

■ disabled—Initial, default state for

high-availability mode. The router continues to
use file system synchronization.

■ active—Data synchronized from the active SRP

module to the standby SRP module during
initialization remains synchronized through
mirroring updates.

■ pending—If an unsupported application is

configured, the router transitions to this state.

■ initializing—If SRP module is in initializing state,

bulk synchronization of memory and NVS
occurs.

Redundancy mode currently used by the router:

■ high-availability—Ensures rapid SRP module

recovery after a switchover by using initial bulk
file transfer and subsequent, transaction-based
mirroring.

■ file-system-synchronization—Default

redundancy mode of the router. SRP modules
reload all line modules and restart form saved
configuration files.

Last type of activation that occurred on the router.
The method using which the SRP last booted:

■ cold-switch—When the router is in pending state

and switchover occurs, the router undergoes a
cold-switch or cold re-start.

■ warm-switch—When the router is in active state

and switchover occurs, the router undergoes a
warm-switch or warm re-start.

Criteria Preventing High
Availability from being Active

Criteria Required for High
Availability to be Active

Line Card

automatic reverting

Criteria preventing the router from being in the active
state of high availability mode.

NOTE: For the router to be in the Active state, all
criteria for this option must be “yes”.

Criteria required for the router to be in the active
state of high availability mode.

NOTE: For the router to be in the Active state, all
criteria for this option must be “yes”.

State of automatic reverting. Possible states: on or
off.

Monitoring the Redundancy Status ■ 47

JUNOSe 11.1.x Service Availability Configuration Guide

Table 6: show redundancy Output Fields (continued)

Field DescriptionField Name

Slots in which the line modules reside.slots

hardware role

lockout config

backed up by slot

sparing for slot

midplane rev

fabric slice redundancy

slice state

Function of the line module. Possible values: primary
or spare.

Status of redundancy on the line module:

■ protected—Line module redundancy is enabled

■ locked out—Line module redundancy is disabled

Slot that contains the line module that is a spare for
this primary line module.

Slot that contains the primary line module for which
this module is a spare.

Time at which you want the line module to revert.revert at

Identifier for the type of midplane.midplane type

Hardware revision number of the redundancy
midplane.

Status of the fabric slice on the SRP modules or SFMs
on the E120 and E320 routers.

Slot in which the fabric slice resides.slot

State of the fabric slice. Possible values: online or not
present.

type

Identifier for the type of hardware. Possible values:
SRP modules or SFM modules.

Related Topics ■ show redundancy

Monitoring the Redundancy Status of Applications

Purpose Display the redundancy status of the applications.

Action To display the applications that do not support high availability.

host1#show redundancy clients

Unsupported High Availability Clients

------------------------------------­ client configuration

--------------------- -------------

48 ■ Monitoring the Redundancy Status of Applications

Chapter 3: Managing Stateful SRP Switchover

DHCP Proxy Client safe
Global Ipv6 safe
IPsec Transport (ITM) safe
l2tpDialoutGenerator safe
DHCPv6 Local Server safe
Radius Relay Server safe

You can also display the redundancy status information of all clients. Specifies whether
the client supports high availability and also the safety level of configuration. For
instance, if an unsupported client is configured on a router with high availability
enabled, the configuration reads “unsafe”.

host1#show redundancy clients all
High Availability Client Information

-----------------------------------­ client mode configuration

--------------------- ----------- ------------­atm1483DataService supported safe
AA83 supported safe
aaaServer supported safe
atmAal5 supported safe
AAQS supported safe
atm supported safe
Bridged Ethernet supported safe
Transparent Bridging supported safe
dcm supported safe
dhcpExternal supported safe
DHCP Proxy Client unsupported safe
DS1 supported safe
DS3 supported safe
ethernet supported safe
Flow Inspection supported safe
frameRelay supported safe
FT1 supported safe
Global Ipv6 unsupported safe
Global Ip supported safe
HDLC supported safe
IKEP supported safe
ipflowstats supported safe
IpSubscriberManager supported safe
IPTU supported safe
IPVR supported safe
IPsec Transport (ITM) unsupported safe
l2tpDialoutGenerator unsupported safe
l2tp supported safe
LMGR supported safe
DHCPv4 Local Server supported safe
DHCPv6 Local Server unsupported safe
MPLS supported safe
PMGR supported safe
pppoe supported safe
ppp supported safe
qos supported safe
Radius Relay Server unsupported safe
RSVP supported safe
SCM supported safe
slotHelper supported safe
Cisco HDLC supported safe
ServiceManager supported safe
Sonet supported safe
SonetPath supported safe

Monitoring the Redundancy Status of Applications ■ 49

JUNOSe 11.1.x Service Availability Configuration Guide

SonetVT supported safe
IPsec Tunnel (ST) supported safe

Meaning Table 7 on page 50 lists the show redundancy clients command output fields.

Table 7: show redundancy clients Output Fields

Field DescriptionField Name

High availability client.client

mode

Configuration

Related Topics ■ show redundancy clients

Monitoring the Redundancy History

Purpose Display information about dates, times, and the number of occurrences for starts

and switchovers.

Action To display information about the number of occurrences for starts and switchovers.

host1#show redundancy history
system up time: 0 00:08:01
last cold start: 2004-07-26 10:44:25
last cold switchover: 2004-07-25 18:51:56
last warm switchover: 2004-07-25 20:58:57
activation statistics:
cold starts: 92
switchovers:
cold: 21
warm: 147
consecutive warm: 0

High availability status of the client. Possible values:
supported or unsupported.

Safety level of the configuration based on whether
or not the client is supported or unsupported and in
case of those unsupported, whether or not the client
has been configured. For example, if an unsupported
client has been configured on a router with high
availability enabled, the configuration reads “unsafe”.

To display the additional redundancy history information:

host1#show redundancy history detail
system up time: 0 00:08:01
last cold start: 2004-07-26 10:44:25
last cold switchover: 2004-07-25 18:51:56
last warm switchover: 2004-07-25 20:58:57

50 ■ Monitoring the Redundancy History

Chapter 3: Managing Stateful SRP Switchover

activation statistics:
cold starts: 92
switchovers:
cold: 21
warm: 147
consecutive warm: 0
system
SRP activation time type slot uptime running release

------------------- ---------- ---- ------ ----------------­2004-09-08 15:10:40 cold-start 00 --- erx_6-0-0b1-8.rel
2004-09-08 14:39:10 cold-start 00 --- erx_6-0-0b1-1.rel

Meaning Table 8 on page 51 lists the show redundancy history command output fields.

Table 8: show redundancy history Output Fields

Field DescriptionField Name

Amount of time elapsed since the last cold boot.system up time

last cold start

last cold switchover

last warm switchover

cold starts

switchovers

Date and time the router experienced the last cold
start.

Date and time the router experienced the last cold
switchover.

Date and time the router experienced the last warm
switchover.

Total number of cold starts the router has
experienced.

Number of cold, warm, and consecutive warm
switchovers the router has experienced.

Amount of time the SRP module has been active.SRP activation time

Last type of activation that occurred on this router.type

Slot in which the line module resides.slot

Amount of time the chassis has been operational.system uptime

Release running on the SRP module at the time.running release

Related Topics ■ show redundancy history

Monitoring the Redundancy Status of Line Modules

Purpose Display redundancy information specific to line modules.

Monitoring the Redundancy Status of Line Modules ■ 51

JUNOSe 11.1.x Service Availability Configuration Guide

Action To display the redundancy status of the line modules.

host1#show redundancy line-card
automatic reverting is off
backed
up sparing
hardware lockout by for revert
slot role config slot slot at

---- -------- --------- ------ ------- -----­ 3 --- --- --- --- --­ 8 spare --- --- --- --­ 12 primary protected --- --- --­ midplane midplane
slots type rev

------ -------- -------­8 - 13 6 0

Meaning Table 9 on page 52 lists the show redundancy line-card command output fields.

Table 9: show redundancy line-card Output Fields

lockout config

backed up by slot

sparing for slot

midplane rev

Field DescriptionField Name

State of automatic reverting (on or off).automatic reverting

Slots in which the line modules reside.slots

Function of the line module: primary or spare.hardware role

Status of redundancy on this line module:

■ protected—Line module redundancy is enabled

■ locked out—Line module redundancy is disabled

Slot that contains the line module that is a spare for
this primary line module.

Slot that contains the primary line module for which
this line module is a spare.

Time at which you want line module to revert.revert at

Identifier for the type of midplane.midplane type

Hardware revision number of the redundancy
midplane.

Related Topics ■ show redundancy line-card

Monitoring the Redundancy Status of SRP Modules

Purpose Display redundancy information specific to SRP modules.

52 ■ Monitoring the Redundancy Status of SRP Modules

Chapter 3: Managing Stateful SRP Switchover

Action To display the redundancy status of the SRP modules.

host1#show redundancy srp
high-availability state: active
current redundancy mode: high-availability
last activation type: warm-switch

To display the redundancy status of the SRP modules in detail.

host1#show redundancy srp detail
high-availability state: disabled
current redundancy mode: file-system-synchronization
last activation type: cold-start
Criteria Required for High Availability to be Active

---------------------------------------------------­ criterion met

---------------------------------------------------- --­Active SRP hardware supports High Availability? Yes
High Availability mode configured? No
Mirroring Subsystem present? Yes
Mirroring activity levels within limits? Yes
Network Core Dumps disabled? Yes
Running configuration is safe for High Availability? Yes
Standby SRP hardware supports High Availability? Yes
Standby SRP is online and capable of mirroring? Yes
Standby SRP is running the same release? Yes

Meaning Table 10 on page 53 lists the show redundancy srp command output fields.

Table 10: show redundancy srp Output Fields

Field DescriptionField Name

high-availability state

State of high availability mode:

■ disabled—Initial, default state for

high-availability mode. The router continues to
use file system synchronization.

■ active—Data synchronized from the active SRP

module to the standby SRP module during
initialization remains synchronized through
mirroring updates.

■ pending—If an unsupported application is

configured, the router transitions to this state.

■ initializing—If SRP module is in initializing state,

bulk synchronization of memory and NVS
occurs.

Monitoring the Redundancy Status of SRP Modules ■ 53

JUNOSe 11.1.x Service Availability Configuration Guide

Table 10: show redundancy srp Output Fields (continued)

Field DescriptionField Name

current redundancy mode

last activation type

Criteria Required for High
Availability to be Active

Redundancy mode currently being used by this
router:

■ high-availability—Ensures rapid SRP module

recovery after a switchover by using initial bulk
file transfer and subsequent, transaction-based
mirroring.

■ file-system-synchronization—Default

redundancy mode of the router. SRP modules
reload all line modules and restart form saved
configuration files.

Last type of activation that occurred on the router.
The method using which the SRP last booted:

■ cold-switch—When the router is in pending state

and switchover occurs, the router undergoes a
cold-switch or cold re-start.

■ warm-switch—When the router is in active state

and switchover occurs, the router undergoes a
warm-switch or warm re-start.

Criteria required for high availability to be active.

NOTE: All criteria must be “yes” for high availability
to be active.

Related Topics ■ show redundancy srp

Monitoring the Redundancy Switchover History

Purpose Display information about stateful SRP switchover history for the chassis.

Action host1# show redundancy switchover-history

system
SRP activation time type slot uptime running release

------------------- ----------- ---- ---------- ------------------------­2004-07-26 10:44:25 cold-start 07 --- L-07-25-60b1mrg-e.rel
2004-07-25 20:58:57 warm-switch 06 0 00:15:08 L-07-25-60b1mrg-e.rel
2004-07-25 20:53:41 warm-switch 07 0 00:09:51 L-07-25-60b1mrg-e.rel
2004-07-25 20:44:43 cold-start 06 --- L-07-25-60b1mrg-e.rel
2004-07-25 19:32:01 cold-start 06 --- L-07-25-60b1mrg-d.rel
2004-07-25 18:58:01 warm-switch 06 0 00:12:01 L-07-25-60b1mrg-c.rel
2004-07-25 18:51:56 cold-switch 07 0 00:05:56 L-07-25-60b1mrg-c.rel
2004-07-25 18:46:54 cold-start 06 --- L-07-25-60b1mrg-c.rel
2004-07-25 17:44:48 warm-switch 06 0 00:14:32 L-07-25-60b1mrg-b.rel
2004-07-25 17:31:07 cold-start 07 --- L-07-25-60b1mrg-b.rel
2004-07-25 16:05:08 cold-start 07 --- L-07-25-60b1mrg-a.rel

54 ■ Monitoring the Redundancy Switchover History

Chapter 3: Managing Stateful SRP Switchover

2004-07-24 23:25:09 warm-switch 07 0 16:27:03 L-07-24-60b1mrg-b.rel
2004-07-24 23:18:23 cold-switch 06 0 16:20:17 L-07-24-60b1mrg-b.rel

Meaning Table 11 on page 55 lists the show redundancy switchover-history command output

fields.

Table 11: show redundancy switchover-history Output Fields

Field DescriptionField Name

Amount of time the SRP module has been active.SRP activation time

Type of switchover.type

Slot in which the SRP module resides.slot

Amount of time the chassis has been operational.system uptime

running release

Related Topics ■ show redundancy switchover-history

Clearing the Redundancy History

To clear the stateful SRP switchover history for the router:

■ Issue the clear redundancy history command:

host1#clear redundancy history

There is no no version.

Related Topics ■ Monitoring the Redundancy History on page 50

■ Monitoring the Redundancy Switchover History on page 54

■ clear redundancy history

Release running on the SRP module at the time of
the switchover.

■ show redundancy history

■ show redundancy switchover-history

Clearing the Redundancy History ■ 55

JUNOSe 11.1.x Service Availability Configuration Guide

56 ■ Clearing the Redundancy History

Chapter 4

Configuring a Unified In-Service Software
Upgrade

This chapter describes how to prepare for and perform a unified in-service software
upgrade (unified ISSU) of JUNOSe Software on E120 and E320 Broadband Services
Routers. A unified in-service software upgrade provides a way to upgrade to a
higher-numbered release while minimizing the effect of the upgrade on traffic
forwarded through the router.

■ Unified ISSU Overview on page 58

■ Unified ISSU Platform Considerations on page 59

■ Hardware and Software Requirements Before Beginning a Unified

ISSU on page 60

■ Unified ISSU Terms on page 62

■ Unified ISSU References on page 62

■ Unified ISSU Phases Overview on page 63

■ Unified ISSU Initialization Phase Overview on page 63

■ Unified ISSU Upgrade Phase Overview on page 66

■ Unified ISSU Service Restoration Phase Overview on page 71

■ Application Support for Unified ISSU on page 71

■ Unexpected AAA Authentication and Authorization Behavior During Unified

ISSU on page 80

■ Unexpected ATM Behavior During Unified ISSU on page 80

■ Unexpected DHCP Behavior During Unified ISSU on page 81

■ Unexpected Denial-of-Service Protection Behavior During Unified ISSU on page 81

■ Unexpected Ethernet Behavior During Unified ISSU on page 82

■ Unexpected File Transfer Protocol Server Behavior During Unified

ISSU on page 83

■ IS-IS Effects on Graceful Restart and Network Stability During Unified

ISSU on page 86

■ Unexpected L2TP Failover of Established Tunnels During Unified ISSU on page 87

■ OSPF Effects on Graceful Restart and Network Stability During Unified

ISSU on page 88

■ Unexpected Suspension of PIM During Unified ISSU on page 90

■ 57

JUNOSe 11.1.x Service Availability Configuration Guide

■ Unexpected Suspension of Subscriber Login and Logouts During Unified

ISSU on page 90

■ Unexpected SONET and SDH Behavior During Unified ISSU on page 91

■ Unexpected T3 Behavior During Unified ISSU on page 91

■ Unavailability of TACACS+ Services During Unified ISSU on page 92

■ Interruption in Traffic Forwarding for Layer 3 Routing Protocols During Unified

ISSU on page 92

■ Recommended Settings for Routing Protocol Timers During Unified

ISSU on page 94

■ Upgrading Router Software with Unified ISSU on page 96

■ Halt of Unified ISSU During Initialization Phase Overview on page 99

■ Halting Unified ISSU During Initialization Phase on page 99

■ Halt of Unified ISSU During Upgrade Phase Overview on page 100

■ Halting Unified ISSU During Upgrade Phase on page 100

■ Monitoring the Status of the Router During Unified ISSU on page 101

Unified ISSU Overview

In software releases numbered lower than Release 6.0, all line modules are reloaded
when an SRP switchover occurs. This reload disconnects user sessions and disrupts
forwarding through the chassis. Stateful SRP switchover was introduced in JUNOSe
Release 6.0 to minimize the impact to the router of a stateful switchover from the
active SRP module to the standby SRP module. Stateful SRP switchover (high
availability) maintains user sessions during the switchover and data forwarding
through the router continues to flow with little impact, thus improving the overall
availability of the router.

The unified in-service software upgrade (unified ISSU) feature further extends router
availability. Unified ISSU enables you to upgrade the router to a higher-numbered
software release without disconnecting user sessions or disrupting forwarding through
the chassis.

A conventional software upgrade—one that does not use the unified ISSU
process—causes a router-wide outage for all users. Only static configurations (stored
on the flash card) are maintained across the upgrade; all dynamic configurations are
lost. A conventional upgrade takes 30-40 minutes to complete, with additional time
required to bring all users back online.

When you perform a unified in-service software upgrade on a router that has one or
more modules that do not support unified ISSU, these modules alone are upgraded
by means of the legacy, conventional upgrade process. The unsupported modules
undergo a cold reboot at the beginning of the unified ISSU process, and are held
down until the in-service software upgrade is completed. Connections that pass
through the unsupported modules are lost. The interfaces on these modules pass
into a down state, which causes the physical layer and link layer to go down during
the unified in-service software upgrade for those modules.

58 ■ Unified ISSU Overview

Chapter 4: Configuring a Unified In-Service Software Upgrade

Applications that do not support unified ISSU applications cannot maintain state and
configuration with minimal traffic loss across the upgrade to a higher-numbered
release. When you attempt a unified in-service software upgrade on a router on
which a unified ISSU-challenged application is configured, the unified in-service
software upgrade cannot proceed. You must unconfigure the unified ISSU-challenged
application to successfully perform the unified ISSU.

Router Behavior During a Unified In-Service Software Upgrade

The following behaviors are characteristic of a unified in-service software upgrade.

■ Connections that were established before you begin the unified ISSU are

maintained across the upgrade. Any such connection that was forwarding data
continues to do so during and after the upgrade.

■ New connections are denied until the upgrade is completed.

■ Packet loss during the upgrade is limited. Bandwidth through the modules is

reduced, but the impact is minimal.

■ Graceful restart protocols do not time out during the unified ISSU.

■ The unified in-service software upgrade has a minimal effect on the control and

data planes. During the SRP module upgrade phase, forwarding through the
fabric is interrupted for about 1 second on the E120 and E320 routers and about
4 seconds on the ERX1440 Broadband Services Router. During the line module
upgrade phase, forwarding through the chassis is interrupted for about 15 seconds
on the E120 and E320 routers and for about 50 seconds on the ERX1440 router.

■ Diagnostic software is not run on any modules during a unified in-service software

upgrade.

■ The router undergoes a cold restart if you attempt to upgrade the software to a

lower-numbered version with unified ISSU. The unified in-service software
upgrade must be to a higher-numbered release than the running release.

■ Additional memory is consumed during a unified in-service software upgrade.

Available memory on a line module might not be sufficient due to the module’s
configuration. Unified ISSU can detect this limitation during the upgrade procedure
and exit the process, gracefully.

Related Topics ■ Unified ISSU Phases Overview on page 63

■ Application Support for Unified ISSU on page 71

■ Hardware and Software Requirements Before Beginning a Unified ISSU on

page 60

■ Upgrading Router Software with Unified ISSU on page 96

Unified ISSU Platform Considerations

Unified ISSU is supported on E120 and E320 routers. Unified ISSU is also supported
on the ERX1440 router with the SRP-40G PLUS with 2GB of memory. Unified ISSU
on the ERX1440 requires a license key.

Unified ISSU Platform Considerations ■ 59

JUNOSe 11.1.x Service Availability Configuration Guide

For information about modules supported on E120 and E320 routers:

■ See E120 and E320 Module Guide, Table 1, Modules and IOAs for detailed module

specifications.

■ See E120 and E320 Module Guide, Appendix A, IOA Protocol Support for information

about the modules that support unified ISSU.

For information about modules supported on the ERX1440 router:

■ See ERX Module Guide, Table 1, ERX Module Combinations for detailed module

specifications.

■ See ERX Module Guide, Appendix A, Module Protocol Support for information about

the modules that support unified ISSU.

Redundant SRP modules are required for unified ISSU support.

Unified ISSU is not supported on the ERX7xx models, the ERX1410 router, and the
ERX310 router.

Hardware and Software Requirements Before Beginning a Unified ISSU

The following hardware and software prerequisites must be met for the successful
completion of unified ISSU. You can issue the show issu command to determine
whether the routers meets these requirements.

Hardware Requirements for Unified ISSU

■ The router must support unified ISSU. Therefore the router must be an E120,

E320, or ERX1440 router.

■ Two SRP modules must be installed in the router.

■ All installed combinations of line modules and IOAs must support unified ISSU.

Unsupported modules that are online are reloaded during the unified ISSU, with
consequent loss of connections and traffic forwarding.

Do not install IOAs in the chassis while the unified ISSU operation is in process.

■ The redundant SRP module must have at least 300 MB of free memory.

Depending on their configuration, line modules require up to 75 MB of free
memory.

On the ERX1440 router, certain hardware updates might require a module to be cold
restarted. Unified ISSU cannot be successfully accomplished with such modules. In
this case, the behavior is the same as for unsupported line modules. The unified ISSU
process reboots these modules and holds them down until the supported modules
on the router complete the unified ISSU process.

When hardware updates are required for modules that you have installed in an
ERX1440 router, contact your Juniper Networks representative to determine whether
the update affects unified ISSU.

60 ■ Hardware and Software Requirements Before Beginning a Unified ISSU

Software Requirements for Unified ISSU

■ The running JUNOSe Software release must support unified ISSU.

You can upgrade to a software version that supports unified ISSU from a software
version that does not support unified ISSU only by means of a conventional
upgrade. During the conventional upgrade, all line modules are reloaded, all
subscribers are dropped, and traffic forwarding is interrupted until the upgrade
is completed.

■ The armed (upgrade) release must be capable of being upgraded to from the

currently running release; it must be higher-numbered than the running release.

■ All applications that are configured on the router must support unified ISSU and

stateful SRP switchover.

If one or more unified ISSU-challenged applications are configured and you
proceed with a unified in-service software upgrade, the unified ISSU process
forces a conventional upgrade on the router. All line modules are reloaded, all
subscribers are dropped, and traffic forwarding is interrupted until the upgrade
is completed.

Chapter 4: Configuring a Unified In-Service Software Upgrade

You can avoid this circumstance by removing the configuration for the unified
ISSU-challenged applications from the router before you begin the in-service
software upgrade.

■ Stateful SRP switchover must be configured on the router. Use the following

commands to configure high availability:

host1(config)#redundancy
host1(config-redundancy)#mode high-availability

See “Managing Stateful SRP Switchover” on page 25 for information about high
availability.

The following requirements must be met for traffic forwarding to continue. However,
failing to meet these requirements does not halt the unified ISSU operation. The
unified ISSU process offers the option to override or ignore these forwarding
requirements.

■ Graceful restart must be enabled for all configured routing protocols. The unified

ISSU operation relies on graceful restart to keep the routing protocols alive through
the various stages of the upgrade.

■ All connected peers must be configured with graceful restart. Because some

protocols cannot themselves confirm peer configuration for graceful restart, you
must ensure that the peers are properly configured.

■ For applications that exchange keepalive messages with peers, you must ensure

that the poll times are adequate to maintain the peering session across any
forwarding interruption caused by the unified ISSU operation.

■ On the ERX1440 router, you must enter the key provided with your license in

order to make the unified ISSU CLI commands available. Unified ISSU is licensed
on only the ERX1440 router; no license is required or available on the E120 and
E320 routers.

Software Requirements for Unified ISSU ■ 61

JUNOSe 11.1.x Service Availability Configuration Guide

The license issu command is available only on the ERX1440 CLI.

Related Topics ■ Application Support for Unified ISSU on page 71

■ Application Support for Stateful SRP Switchover on page 32

■ Activating High Availability on page 42

■ license issu

■ show issu

Unified ISSU Terms

Table 12 on page 62 defines terms relevant to module behavior during a unified
in-service software upgrade.

Table 12: Unified ISSU-Related Terms

MeaningTerm

Cold boot

Cold start

Cold restart

Warm restart

The SRP module or line module loads diagnostics from the flash file
system and runs them. When the diagnostics successfully complete,
the operational image is loaded from the flash file system and then
cold started.

The SRP module or line module is initialized from the loaded
operational image. The line modules are reloaded and the configuration
is read from flash memory. When the line modules are operational,
their configuration data is bulk downloaded and their interfaces become
operational.

If the active SRP module fails, the standby SRP module takes the role
of active SRP module. When high availability is not configured, the
cold restart is similar to the cold start, except that the applications are
already loaded into memory on the standby SRP module and ready
to be started. The line modules are reloaded.

If the active SRP module fails, the standby SRP module takes the role
of active SRP module. Mirrored configuration data as well as any
mirrored volatile data are already resident in memory. The line
modules continue to forward data (with a small loss of packets when
the fabric is switched from the formerly active SRP module to the
newly active SRP module). The protocols and other applications
re-initialize from the mirrored data and resynchronize communications
with the line modules. When resynchronization is completed, the
router resumes normal operations, including updates of any routing
tables that result from changes that occurred during the warm restart.

Unified ISSU References

For more information about stateful SRP switchovers, see “Managing Stateful SRP
Switchover” on page 25.

62 ■ Unified ISSU Terms

For more information about SRP module redundancy, see “Managing Module
Redundancy” on page 7.

Unified ISSU Phases Overview

The JUNOSe Software includes software modules that operate the following hardware
components:

■ SRP module

■ Line module control plane

■ Line module forwarding plane

A unified in-service software upgrade replaces the currently operating software on
each of these components with a higher-numbered release. The unified ISSU also
upgrades or re-creates the state and configuration data of the configured applications.

Before you begin the unified in-service software upgrade, you must first prepare the
router for the upgrade. See “Hardware and Software Requirements Before Beginning
a Unified ISSU” on page 60 for more information.

Chapter 4: Configuring a Unified In-Service Software Upgrade

The unified in-service software upgrade takes place in three phases:

1. Initialization Phase—When you issue the issu initialize command, unified ISSU

verifies whether all prerequisites for the upgrade have been met. The router is
prepared for the upgrade. The configuration that has been mirrored to the standby
SRP module is upgraded according to the upgrade release. This phase can last
from a few minutes up to 40 minutes depending on the number of software
releases across which the router is being upgraded.

2. Upgrade Phase—When you issue the issu start command, unified ISSU again

verifies whether all prerequisites for the upgrade have been met. During this
phase the line module control plane and forwarding plane are upgraded and all
three hardware components are resynchronized.

3. Service Restoration Phase—This phase automatically begins without user

intervention when the upgrade phase has completed. During this final phase,
the router is returned to a normal, runtime state.

Related Topics ■ Unified ISSU Initialization Phase Overview on page 63

■ Unified ISSU Upgrade Phase Overview on page 66

■ Unified ISSU Service Restoration Phase Overview on page 71

■ Halting Unified ISSU During Initialization Phase on page 99

■ Halting Unified ISSU During Upgrade Phase on page 100

Unified ISSU Initialization Phase Overview

When you issue the issu initialize command, unified ISSU first verifies whether all
requirements for the upgrade are met. The verification process examines the running

Unified ISSU Phases Overview ■ 63

JUNOSe 11.1.x Service Availability Configuration Guide

release, the SRP modules, the line modules, line module redundancy, and the router
configuration.

The issu initialize command does not interrupt or disrupt any of the runtime
operations of the router. The command has no effect on changes of authorization,
forwarding, or subscribers (except perhaps, rate of logins). You cannot manually
change the file system redundancy mode from high availability to file synchronization
until the unified in-service software upgrade is completed.

NOTE: We recommend that you make no configuration changes after you have issued
the issu initialization command. As a best practice, ensure that your configuration
is complete before you start the software upgrade.

During the initialization phase, you can halt the unified in-service software upgrade
at any time and revert either to a normal SRP module switchover or to the previous
state of the router. To stop the unified ISSU process, you must issue the issu stop
command. If instead you simply exit the CLI session, the unified ISSU initialization
phase continues.

The action taken when a requirement is not met depends on the requirement. For
some failed verifications, the CLI warns you of the issue and prompts you to proceed
or quit the upgrade process. More serious failures cause the CLI to exit the command
and provide a message describing the issue.

NOTE: We recommend that you issue the show issu command before beginning the
unified in-service software upgrade. The output of the command lists any necessary
conditions that are not currently met on the router. You can therefore correct these
failures before entering into the upgrade. You can issue the show issu command at
any time.

NOTE: On E120 and E320 routers, you can hot swap an IOA during the initialization
phase without affecting the in-service software upgrade. However, we strongly
recommend that you perform any necessary hot swaps before you issue the issu
initialize command.

If the standby SRP module reloads during the initialization phase, unified ISSU is
halted. You must begin again by issuing the issu initialize command.

Application Data Upgrade on the Standby SRP Module

Synchronized modules can become unsynchronized because you can change the
router configuration at any time until you issue the issu start command. When the
verification process is completed, unified ISSU starts up the stateful SRP switchover
process to maintain synchronization between the active SRP module and the standby
SRP module during the SRP module upgrade phase.

64 ■ Unified ISSU Initialization Phase Overview

Chapter 4: Configuring a Unified In-Service Software Upgrade

NOTE: An SRP switchover from the active SRP module to the standby SRP module
at this point in the unified in-service software upgrade causes a cold restart of the
router because the SRP modules are running two different releases. The current
release is on the active SRP module and the upgrade release is on the standby SRP
module.

The application and configuration data that has been mirrored to the standby SRP
module is upgraded as required by the new software release. The CLI displays the
progress of the SRP module upgrade.

While data on the standby SRP module is upgraded, any new changes that are
mirrored from the primary SRP module to the standby SRP module are also upgraded
to the version required by the armed release.

NOTE: This process consumes significant CPU resources on the redundant SRP
module and can take a considerable amount of time to complete. Performance of
the active SRP module might be affected during the SRP module upgrade.

SNMP Traps

Related Topics ■ Unified ISSU Phases Overview on page 63

When the upgrade release has been synchronized to the standby SRP module, stateful
SRP switchover is disabled until the unified in-service software upgrade is completed.

If you configure an application that does not support unified ISSU during the
initialization phase, the initialization phase completes, but the issu start command
subsequently fails.

When you issue the issu initialization command, the SNMP agent generates a
juniSystemIssuStateChange trap with juniSystemIssuState set to initializing. When
the unified ISSU initialization is completed, the SNMP agent generates a
juniSystemIssuStateChange trap with juniSystemIssuState set to initialized.

■ Halt of Unified ISSU During Initialization Phase Overview on page 99

■ Halting Unified ISSU During Initialization Phase on page 99

■ issu initialize

■ issu start

■ issu stop

■ show issu

Unified ISSU Initialization Phase Overview ■ 65

JUNOSe 11.1.x Service Availability Configuration Guide

Unified ISSU Upgrade Phase Overview

During the upgrade phase, the CLI supports only a reduced set of administrative
commands. You cannot interrupt the upgrade phase. The upgrade phase cannot
commence if any CLI commands outside of this set are executing when you issue
the issu start command.

NOTE: Although you can use any CLI session to issue the issu start command, we
recommend that you issue the command from a session to the management console
port. When the standby SRP module switchover takes place, all management network
connections through the Ethernet management port are dropped, and you can access
the router only through a console port until the service restoration phase is completed.

When you issue the issu start command, unified ISSU performs the following
operations:

1. Verifies that the unified ISSU requirements on the router are still met.

2. Verifies that the active and standby SRP modules are synchronized. If they are

not synchronized, forces a synchronization to ensure that all configuration and
file system changes are propagated to the standby SRP module before proceeding
with the upgrade.

3. Copies the NVS configuration from a backup memory area to the flash card on

the standby SRP module. During the initialization phase, this configuration data
was mirrored from NVS on the active SRP module and upgraded as required by
the armed release.

4. Upgrades the control plane on each line module at the same time.

5. Switches control from the primary SRP module (running the current release) to

the standby SRP module (running the armed upgrade release).

6. Upgrades the forwarding plane on each line module at the same time. The fabric

is switched and upgraded.

You can view the status of the router and the progress of the upgrade at any time
by issuing the show issu command from another terminal session to the router.

66 ■ Unified ISSU Upgrade Phase Overview

NOTE: While a unified ISSU operation is in progress, do not remove the SRP modules
or attempt to reset them. Removing the SRP modules anytime during unified ISSU
has an adverse impact.

After the unified ISSU operation is completed, issue the show version command.
The output from a successful upgrade indicates the following:

■ The formerly active SRP module has rebooted and come up as the new standby

SRP module.

■ The newly active SRP module indicates that the formerly active SRP has rebooted

and has come up as standby SRP module

You can then remove an SRP module after issuing the halt command.

Exceptions During the Upgrade Phase

Chapter 4: Configuring a Unified In-Service Software Upgrade

Table 13 on page 67 describes the behavior of the router during the upgrade phase
when certain exceptional events take place outside the context of the unified in-service
software upgrade.

Table 13: Router Response to Undesirable Events During the Upgrade Phase

Router ActionEvent

The router reloads.

The primary SRP
module switches
over to the standby
SRP module.

The standby SRP
module reloads.

A line module
reloads.

The unified ISSU operation halts.

■

The router undergoes a cold restart.

■

The router boots with the armed upgrade release.

■

The line modules reboot.

■

The unified ISSU operation halts.

■

The router undergoes a cold restart.

■

The router boots with the armed upgrade release.

■

The line modules reboot.

■

The unified ISSU operation halts.

■

The router undergoes a cold restart.

■

The router boots with the armed upgrade release.

■

The line modules reboot.

■

The line module is held down and prevented from rebooting until the

■

service restoration phase is completed. The line module then
undergoes a cold reboot to the running (post-upgrade) release.

An IOA is
hotswapped.

Hot swapping is disabled during the upgrade phase. The line module

■

undergoes a cold reboot and hot swapping is reenabled when the
service restoration phase is completed,

Unified ISSU Upgrade Phase Overview ■ 67

JUNOSe 11.1.x Service Availability Configuration Guide

Table 13: Router Response to Undesirable Events During the Upgrade
Phase (continued)

Router ActionEvent

An application that
does not support
unified ISSU is
configured.

Verifications of Requirements

Because some time may have passed since unified ISSU verified the requirements
for the upgrade during the initialization phase, unified ISSU reverifies all the same
conditions.

Unified ISSU also verifies that no CLI configuration sessions are open, that no scripts
or macros are running, and that any SNMP requests or CLI commands in progress
complete within 5 seconds.

If any of the required conditions are not met, the CLI either exits the command with
an error message or provides an informative message and prompts you to proceed
or halt.

When all the conditions are met, the CLI prompts you to proceed. If you continue,
then you can subsequently halt the upgrade only by reloading the router. If you exit
the command, the router remains in the unified ISSU initialized state.

Upgrade Setup

This event can take place only before the issu start command is

■

issued, because that command disables CLI configuration commands.
When you issue the issu start command, after configuring such an
application, the command exits and generates an error message.

At this stage all the preconditions have been met. The unified ISSU process shuts
down all management interfaces to the router in order to prevent changes in the
configuration.

Final preparation for the upgrade phase includes the following actions:

■ SNMP—The SNMP agent generates a juniSystemIssuStateChange trap with

juniSystemIssuState set to upgrading to indicate that the final phase of the
operation has begun. When the trap is issued with this state value, the SNMP
agent stops accepting any new SNMP gets or sets and does not issue any further
traps.

■ CLI—Most CLI commands are disabled. Only reload, show issu, and show

version commands are available to you until the service restoration phase

completes. These commands are available on the console and are not available
to Telnet sessions.

■ External events—Externally created events from sources other than the CLI are

ignored. These events typically come from user connections, RADIUS servers,
SRC software and SDX software, and SNMP, and include login requests, COA
requests, multicast join requests, packet mirroring requests, and so on. Logout
requests are cached and processed at a later stage.

68 ■ Unified ISSU Upgrade Phase Overview

Chapter 4: Configuring a Unified In-Service Software Upgrade

■ Routing protocols—The unified ISSU process prompts you to consider raising

the link costs for each routing protocol that is configured on the router. Raising
the link cost for routes through the upgrading router enables neighbors to
recompute better routes to those destinations. If you choose to raise the link
cost, the higher costs can take some time to propagate through the network.
Because the router is unable to determine when this has completed, it waits for
2 minutes before proceeding to the next step in the upgrade.

The reason for raising the link cost is that when the upgrade of the line module
control plane begins, routing protocol updates cannot be installed in the line
modules until that upgrade completes. That period can be in the range 2–15
minutes. During the control plane upgrade, the routing protocols can still accept
new routes and communicate with their neighbors but cannot install the routes.

■ Unsupported line modules—Any unsupported line modules that are present are

held down after the start of this phase when you can no longer gracefully exit
from the unified ISSU process. The modules are held down for the duration of
the unified in-service software upgrade and then undergo a cold boot to the
original running release.

■ IGMP requests—The router cannot handle IGMP requests for channel changing

for IPTV implementations.

Line Module Arming

When the upgrade of the application data on the standby SRP upgrade is completed,
unified ISSU temporarily arms the line modules with the upgrade release in a backup
region of the memory.

Line Module Control Plane Upgrade

At this point, the upgrade release is preserved on each line module in some backup
region. When signaled by the active SRP module, all supported line modules
simultaneously reload and restart with the new release. Forwarding through the
forwarding subsystem on the line modules—through the fabric of the system—is not
affected by the reload.

The line modules then simultaneously recover any application data preserved in
memory on the line module and upgrade that data into a format that the applications
running on the new release can interpret. This operation can take in the range of
1–10 minutes depending on the size of the data and the upgrade path of the data.
Each line module restores its operational state, running the new release with all data
upgraded to a version acceptable to the new software.

If the upgrade process fails for any line module, that module undergoes a cold restart,
but none of the other line modules is affected.

SRP Module Switchover

At this stage the primary SRP module is running the current release, the redundant
SRP module is running the armed release, and the control plane on each supported
line module is running the armed release.

Unified ISSU Upgrade Phase Overview ■ 69

JUNOSe 11.1.x Service Availability Configuration Guide

When the primary SRP module has verified that all line modules are up, the redundant
SRP module takes over control of the router by becoming the active SRP module.
The primary, and formerly active, SRP module reboots to the armed release and
serves as the standby SRP module.

All applications on the newly active SRP module are restarted. Each application
reconstructs itself from the mirrored data, restoring its state and configuration as it
was before the switchover. Forwarding through the fabric is interrupted for about 1
second on the E120 and E320 routers and about 4 seconds on the ERX1440 router.

The SRP switchover restarts the routing protocols and triggers a graceful restart
because the routes need to be recomputed. This recalculation can take up to 90
seconds. Data continues to be forwarded through routes that were learned before
the upgrade of the line module control planes.

Line Module Forwarding Plane Upgrade

While the applications on the SRP module and the line modules reconstruct
themselves, they also begin to build up the new state for the forwarding subsystem.
All applications on the line module signal the system when they are ready to start
the forwarding upgrade.

Because upgrading the forwarding plane affects forwarding through the chassis for
up to 30 seconds on the E120 and E320 routers and about 50 seconds on the
ERX1440 router, unified ISSU does not proceed until the routing protocols have
signaled that route reconvergence has completed. Unified ISSU then instructs all line
modules to simultaneously upgrade their forwarding subsystems.

The line modules then perform the following steps:

1. Halt forwarding through the line modules. Although any links to external devices

remain up, incoming data is dropped.

2. Update any changed programmable hardware devices.

3. Update the forwarding subsystem with the new release and upgraded

configuration data.

4. Update the routing tables with the reconverged routes.

5. Resume forwarding.

Related Topics ■ Unified ISSU Phases Overview on page 63

■ Halt of Unified ISSU During Upgrade Phase Overview on page 100

■ Halting Unified ISSU During Upgrade Phase on page 100

■ issu start

■ show issu

■ halt

■ reload

70 ■ Unified ISSU Upgrade Phase Overview

Chapter 4: Configuring a Unified In-Service Software Upgrade

Unified ISSU Service Restoration Phase Overview

This is the final unified ISSU phase. At this point, all three major components of the
router—the SRP modules, the line module control planes, and the line module
forwarding planes—have been upgraded and forwarding has resumed through the
chassis. The following actions take place during this phase:

■ The CLI is re-enabled. All commands are made available to users.

■ The SNMP agent is restarted and bulk statistics are collected and available for

review. (The first interval of bulk statistics collection starts when unified ISSU is
still in process. Therefore, the system performs bulk statistics collection after the
first interval.)

■ New login requests and logout requests are processed. The router begins to

accept externally created events from sources other than the CLI and SNMP.
These events typically come from user connections, RADIUS servers, and SRC
software and SDX software, and include login requests, COA requests, multicast
join requests, and so on.

■ Logout requests that were cached at the start of the unified in-service software

upgrade are processed.

■ After the flash memory on the newly active SRP module is updated, stateful SRP

switchover is available to the router.

At this point the unified in-service software upgrade is completed, and the router is
restored to normal operation. Any line modules that reloaded during the upgrade
phase and were therefore held down are now rebooted to the original running release.

Related Topics ■ Unified ISSU Phases Overview on page 63

Application Support for Unified ISSU

When an application supports unified ISSU, you can configure the application on the
router and proceed with the unified in-service software upgrade with no adverse
impact to the upgrade.

Applications that do not support unified ISSU cannot maintain state and configuration
with minimal traffic loss across the upgrade. When you attempt the unified in-service
software upgrade on a router that is configured with an ISSU-challenged application,
the unified in-service software upgrade is halted and cannot proceed unless you
remove the configuration. An application that does not support high availability
cannot support unified ISSU.

Table 14 on page 72 indicates which applications support or do not support a unified
in-service software upgrade, as well as limitations on their behavior.

Unified ISSU Service Restoration Phase Overview ■ 71

JUNOSe 11.1.x Service Availability Configuration Guide

Table 14: Application Support for Unified In-Service Software Upgrades

Physical Layer
Protocols

(E120 and E320)

NotesUnsupportedSupportedApplication

–––DS1

(ERX1440)

–––DS1

––✓DS3

––✓HDLC

–✓SONET/SDH

Unified ISSU support
is provided only for
non-channelized APS
IOAs. Also, unified
ISSU can proceed
only if you have not
configured APS on the
OCx/STMx ATM or
OCx/STMx POS line
modules. If you have
configured APS, a
warning message is
displayed and the
router cannot proceed
with the unified ISSU.

The unified ISSU
process for
channelized line
modules remains
unchanged.

Link-Layer Protocols

72 ■ Application Support for Unified ISSU

E120 and E320
routers do not support
APS.

–✓–SONET/SDH VT

–✓ARP

ARP entries in the
ARP cache do not
time out because no
ARP aging occurs
during unified ISSU.
When the unified
ISSU is completed,
the ARP cache
contains the same
entries as it had
before the unified
ISSU began.

––✓ATM

Chapter 4: Configuring a Unified In-Service Software Upgrade

Table 14: Application Support for Unified In-Service Software Upgrades (continued)

NotesUnsupportedSupportedApplication

configuration of
dynamic interfaces

configuration of static
interfaces

without VLANs)

Unicast Routing

––✓ATM 1483 bulk

––✓ATM bulk

––✓Bridged Ethernet

––✓Cisco HDLC

––✓Ethernet (with and

–––Frame Relay

––✓PPP

––✓PPPoE

––✓Transparent bridging

––✓Access Routes

––✓BGP

(E120 and E320)

(ERX1440)

(E120 and E320)

(ERX1440)

–✓FTP

Although unified ISSU
supports FTP in active
state, no file transfer
operation can be in
progress while
performing unified
ISSU.

––✓IP

✓–IPv6

Unified ISSU does not
support IPv6.

✓–IPSec Transport

E120 and E320
routers do not support
IPSec.

–––IPSec Transport

✓–IPSec Tunnels

E120 and E320
routers do not support
IPSec.

–––IPSec Tunnels

Application Support for Unified ISSU ■ 73

JUNOSe 11.1.x Service Availability Configuration Guide

Table 14: Application Support for Unified In-Service Software Upgrades (continued)

NotesUnsupportedSupportedApplication

IPv4 Multicast
Routing

–✓IS-IS

Support only when
graceful restart is
configured.

–✓OSPF

Support only when
graceful restart is
configured.

––✓RIP

––✓Static Routes

–✓Telnet

Authentication and
command
authorizations on
Telnet sessions fail
during the upgrade
phase and Telnet
sessions are dropped.

––✓Multicast Routing

–✓ANCP (L2C)

Unified ISSU can
proceed if ANCP is
configured. However,
ANCP has no graceful
restart extensions and
therefore it cannot
maintain its dynamic
state across the
upgrade.
Consequently, all
ANCP sessions are
brought down and
then restored when
the upgrade is
completed.

(E120 and E320)

(ERX1440)

IPv6 Multicast
Routing

74 ■ Application Support for Unified ISSU

––✓DVMRP

–––DVMRP

––✓IGMP

––✓PIM

✓–Multicast Routing

Unified ISSU does not
support IPv6.

Chapter 4: Configuring a Unified In-Service Software Upgrade

Table 14: Application Support for Unified In-Service Software Upgrades (continued)

NotesUnsupportedSupportedApplication

Multiprotocol Label
Switching

between layer 2
interfaces using MPLS

Policies and QoS

Remote Access

✓–MLD

Unified ISSU does not
support IPv6.

✓–PIM

Unified ISSU does not
support IPv6.

––✓MPLS

––✓BGP signaling

––✓LDP signaling

––✓RSVP-TE signaling

––✓Local cross-connects

––✓Policies

––✓QoS

–✓AAA

The following
configuration is not
supported: The
subscriber username
and password are on
an ATM circuit in
Bridged Ethernet over
ATM or IP over ATM
configurations.

and Packet Trigger

––✓DHCP External Server

Application Support for Unified ISSU ■ 75

JUNOSe 11.1.x Service Availability Configuration Guide

Table 14: Application Support for Unified In-Service Software Upgrades (continued)

NotesUnsupportedSupportedApplication

–✓DHCP Packet Capture

–✓DHCP Relay Proxy

Configuration of
DHCP packet capture
does not prevent
unified ISSU from
proceeding. However,
the capturing of
packets on the line
modules is halted
when the unified ISSU
upgrade phase
commences. Packet
capture resumes
automatically during
the unified ISSU
service restoration
phase.

–✓–DHCP Proxy Client

DHCP relay proxy
continues processing
of DHCP release
requests during the
unified ISSU to
maintain server-client
synchronization. State
is preserved across
the upgrade; statistics
are not preserved.

––✓DHCP Relay Server

–✓DHCPv4 Local Server

✓–DHCPv6 Local Server

Forwarding outages
that take place during
a unified ISSU can
affect DHCP lease
renewal. Before you
begin unified ISSU,
we recommend that
you configure the
DHCP local server
address pools with a
minimum lease time
of 120 minutes to
ensure that leases do
not expire during the
upgrade.

Unified ISSU does not
support IPv6.

76 ■ Application Support for Unified ISSU

Chapter 4: Configuring a Unified In-Service Software Upgrade

Table 14: Application Support for Unified In-Service Software Upgrades (continued)

NotesUnsupportedSupportedApplication

Server

Dynamic-Request
Server

Disconnect

–✓L2TP

Unified ISSU forces an
L2TP failover for all
established tunnels.
L2TP failover
resynchronization is
required for
successful recovery of
a tunnel and its
sessions following the
upgrade.

–✓–L2TP Dialout

––✓Local Address Pools

––✓Local Authentication

––✓RADIUS Client

––✓RADIUS

––✓RADIUS Initiated

–✓–RADIUS Relay Server

Route-Download
Server

Miscellaneous

(DoS) protection

statistics)

––✓RADIUS

––✓SRC Client

––✓Service Manager

––✓Subscriber Manager

––✓TACACS+

––✓Bulk statistics

––✓Denial of Service

––✓HTTP server

–✓–IOA hot swap

––✓J-Flow (IP flow

Application Support for Unified ISSU ■ 77

JUNOSe 11.1.x Service Availability Configuration Guide

Table 14: Application Support for Unified In-Service Software Upgrades (continued)

NotesUnsupportedSupportedApplication

Redundancy

–✓Line Module

You can use the active
spare line module for
unified ISSU
operations. You do
not have to revert to
the primary line
module. The following
sets of line modules
and IOAs are
supported:

ATM: OC3-4A,

■

OC3/OC12/DS3-ATM
POS: OC3-4P

■

Line Modules

■

ES2 4G LM

■

ES2 10G

■

Uplink LM
ES2 10G LM

■

ES2 10G

■

ADV LM

IOAs

■

ES2-S1

■

GE-4 IOA
ES2-S1

■

GE-8 IOA
ES2-S3

■

GE-20 IOA
ES2-S1

■

10GE IOA
ES2-S2

■

10GE PR
IOA

ES2-S1

■

OC3-8
STM1 ATM
IOA

ES2-S1

■

OC12-2
STM4 ATM
IOA

ES2-S1

■

OC12-2
STM4 POS
IOA

ES2-S1

■

OC48
STM16 POS
IOA

Agent

78 ■ Application Support for Unified ISSU

–✓–Mobile IP Home