Juniper JUNOSE SOFTWARE FOR E SERIES 11.3.X - SERVICE AVAILABILITY CONFIGURATION GUIDE 2010-10-08, JUNOSE 11.3 Configuration Manual

Download

Page 1

JunosE™ Software for E Series™ Broadband Services Routers

Service Availability Configuration Guide

Release

11.3.x

Published: 2010-10-08

Page 2

Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, California 94089 USA 408-745-2000 www.juniper.net

Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.

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

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

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

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

Revision History October 2010—FRS JunosE 11.3.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 OS has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.

Page 3

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 BOUNDBY THIS AGREEMENT.IF YOU DO NOT OR CANNOTAGREE TO THE TERMSCONTAINED 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 (ifthe Customer’s principal officeis locatedoutside the Americas) (suchapplicable entitybeing referred to herein as“Juniper”), and (ii)the personor organization that originallypurchased from Juniper or anauthorized Juniper reseller theapplicable 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 paymentof the applicable fees and thelimitations andrestrictions setforth 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 limitsto Customer’s useof the Software. Suchlimits may restrictuse to amaximum numberof 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, toany thirdparty; (d) remove anyproprietary notices, labels,or markson or inany copyof 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 inthe secondhand market; (f)use any ‘locked’ orkey-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

Page 4

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.

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 havinga 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 statementthat accompanies the Software (the“Warranty Statement”).Nothing inthis Agreementshall give riseto 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 ORPROCUREMENT OFSUBSTITUTE GOODSOR SERVICES,OR FORANY SPECIAL, INDIRECT,OR CONSEQUENTIALDAMAGES ARISING OUTOF THIS AGREEMENT,THE SOFTWARE,OR ANY JUNIPEROR JUNIPER-SUPPLIED SOFTWARE. IN NOEVENT SHALLJUNIPER 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.

Page 5

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

at http://www.gnu.org/licenses/lgpl.html .

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

Page 6

Page 7

Abbreviated Table of Contents

About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Part 1 Chapters

Chapter 1 Service Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Chapter 2 Managing Module Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapter 3 Managing Stateful SRP Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter 4 Managing Stateful Line Module Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Chapter 5 Configuring a Unified In-Service Software Upgrade . . . . . . . . . . . . . . . . . . . 101

Chapter 6 Configuring VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Chapter 7 Managing Interchassis Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Part 2 Index

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Page 8

JunosE 11.3.x Service Availability Configuration Guide

Page 9

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

Stateful Line Module Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

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

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

Chapter 2 Managing Module Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Line Module Redundancy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Line Module Redundancy Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

ERX7xx Models and ERX14xx Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

E120 and E320 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

IOA Behavior When the Router Reboots . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Line Module Behavior When Disabling or Enabling IOAs . . . . . . . . . . . . . . 11

Understanding Automatic Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Limitations of Automatic Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Understanding Reversion After Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Configuring Line Module Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Managing Line Module Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Example: Forcing the Router to Switch from Primary Line Module to Spare Line

Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Interoperation of Redundancy and Stateful Switchover for Line Modules . . . . . . . 15

Understanding SRP Module Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Understanding Configuration of SRP Modules for Redundancy . . . . . . . . . . . . . . . 19

Installing a Redundant SRP Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Page 10

JunosE 11.3.x Service Availability Configuration Guide

Managing SRP Module Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Switching to the Redundant SRP Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Determination of Redundancy Status for Line Modules and SRP Modules Using

Status LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Monitoring Redundancy in Installed Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Monitoring Redundancy in Line Module and SRP Modules . . . . . . . . . . . . . . . . . . 27

Monitoring Redundancy Status on E320 Router . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Chapter 3 Managing Stateful SRP Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Stateful SRP Switchover Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Stateful SRP Switchover Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . 36

Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Stateful SRP Switchover Redundancy Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

File System Synchronization Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

High Availability Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Stateful SRP Switchover States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Disabled State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Initializing State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Active State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Pending State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Application Support for Stateful SRP Switchover . . . . . . . . . . . . . . . . . . . . . . . . . 42

Application Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Guidelines for Activating High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Activating High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Guidelines for Deactivating High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Deactivating High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

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

Setting the IP Interface Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Guidelines for Upgrading Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Monitoring the Redundancy Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Monitoring the Redundancy Status of Applications . . . . . . . . . . . . . . . . . . . . . . . . 59

Monitoring the Redundancy History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

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

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

Monitoring the Redundancy Switchover History . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Clearing the Redundancy History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Chapter 4 Managing Stateful Line Module Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Stateful Line Module Switchover Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Benefits of Stateful Line Module Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

1:1 Redundancy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Seamless Preservation of Subscriber Sessions . . . . . . . . . . . . . . . . . . . . . . . . 69

Stateful Line Module Switchover Platform Considerations . . . . . . . . . . . . . . . . . . 70

Guidelines for Configuring Stateful Line Module Switchover . . . . . . . . . . . . . . . . . 70

System Operations When Stateful Line Module Switchover Is Enabled . . . . . . . . 74

Stateful Line Module Configuration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

High Availability Configured and Enabled on the Line Module . . . . . . . . . . . . 75

High Availability Configured and Disabled on the Line Module . . . . . . . . . . . . 76

High Availability Configured and the Switchover State Is Active or

Disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Page 11

Table of Contents

Rebooting of the System When Line Module High Availability Is

Configured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Stateful SRP Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Line Module Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Replacement of Line Modules When Stateful Line Module Switchover Is

Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Reloading the Primary Line Module in Response to Failures . . . . . . . . . . . . . . 77

Reloading the Secondary Line Module in Response to Failures . . . . . . . . . . . 78

Disabling the Primary and Secondary Line Module Slots . . . . . . . . . . . . . . . . 78

Reloading the Router When Line Modules Enabled for HA Are Installed . . . . 78

Removing IOAs Without Powering Down from Line Modules . . . . . . . . . . . . . 78

Cold and Warm Switchovers of Line Modules In a High Availability Pair . . . . 78

Application Support for Stateful Line Module Switchover . . . . . . . . . . . . . . . . . . . 79

Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Connection Manager and Queue Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Forwarding Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Mirroring Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

ICCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Stateful Line Module Switchover Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Stateless Switchover Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

High Availability Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Stateful Line Module Switchover States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Disabled State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Initializing State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Active State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Guidelines for Activating High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Activating High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Guidelines for Deactivating High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Deactivating High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Switching Over from a Primary Line Module to Secondary Line Module . . . . . . . . 90

Log Messages Generated for Stateful LM Switchover . . . . . . . . . . . . . . . . . . . . . . . 91

Log Messages Displayed During the Transition from Disabled Stateto Active

State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Log Messages Displayed During the Transition from Active State to Pending

or Disabled State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Log Messages Displayed During the Transition from Pending or Disabled

State to Active State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Log Messages Displayed During the Transition from Active or Pending State

to Disabled State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Log Messages Displayed for Stateful SRP and Line Module Switchover

When HA Is Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Log Messages Displayed for Stateful SRP and Line Module Switchover

When HA Is Disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Page 12

JunosE 11.3.x Service Availability Configuration Guide

Preservation of Statistics During Stateful Line Module Switchover . . . . . . . . . . . . 93

PPP Accounting Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Policy Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Performance Impact and Scalability Considerations . . . . . . . . . . . . . . . . . . . . . . . 94

Use of Status LEDs to Monitor the High Availability States of Line Modules . . . . 95

Monitoring the Redundancy Status of Line Modules in a Specific Slot . . . . . . . . . 95

Monitoring the Redundancy History of Line Modules in a Specific Slot . . . . . . . . . 97

Chapter 5 Configuring a Unified In-Service Software Upgrade . . . . . . . . . . . . . . . . . . . 101

Unified ISSU Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

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

Unified ISSU Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

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

Hardware Requirements for Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Software Requirements for Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Unified ISSU Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Unified ISSU References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Unified ISSU Phases Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Unified ISSU Initialization Phase Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

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

SNMP Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Unified ISSU Upgrade Phase Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Exceptions During the Upgrade Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Verifications of Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Upgrade Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Line Module Arming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Line Module Control Plane Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

SRP Module Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Line Module Forwarding Plane Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 114

Unified ISSU Service Restoration Phase Overview . . . . . . . . . . . . . . . . . . . . . . . . . 115

Application Support for Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Unexpected AAA Authentication and Authorization Behavior During Unified

ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Unexpected ATM Behavior During Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . 124

ILMI Sessions Not Maintained . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

OAM CC Effects on VCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

OAM VC Integrity Verification Cessation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Port Data Rate Monitoring Cessation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

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

Unexpected DHCP Behavior During Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . 125

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

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

Unexpected Ethernet Behavior During Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . 126

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

Link Aggregation Interruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Port Data Rate Monitoring Halted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

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

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

Page 13

Table of Contents

IS-IS Effects on Graceful Restart and Network Stability During Unified ISSU . . . 129

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

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

Routing Around the Restarting Router to Minimize Network Instability . . . . 130

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

OSPF Effects on Graceful Restart and Network Stability During Unified ISSU . . 132

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

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

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

Routing Around the Restarting Router to Minimize Network Instability . . . . 133

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

Unexpected Suspension of Subscriber Login and Logouts During Unified

ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Subscriber Statistics Accumulation or Deletion . . . . . . . . . . . . . . . . . . . . . . . 134

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

Unexpected T3 Behavior During Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

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

Interruption in Traffic Forwarding for Layer 3 Routing Protocols During Unified

ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Recommended Settings for Routing Protocol Timers During Unified ISSU . . . . . 138

Upgrading Router Software with Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

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

Halting Unified ISSU During Initialization Phase . . . . . . . . . . . . . . . . . . . . . . . . . . 142

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

Halting Unified ISSU During Upgrade Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

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

Chapter 6 Configuring VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

VRRP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

VRRP Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

VRRP Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

VRRP References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

VRRP Implementation in E Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

VRRP Router Election Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Example: Basic VRRP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Example: Commonly Used VRRP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Example: VRRP Configuration Without the Real Address Owner . . . . . . . . . . . . . 155

Before You Configure VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Configuring VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Changing the Object Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Monitoring the Configuration of VRIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Monitoring the Configuration of VRRP Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . 162

Monitoring the Statistics of VRRP Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Monitoring the Configuration of VRRP Tracked Objects . . . . . . . . . . . . . . . . . . . . 166

Chapter 7 Managing Interchassis Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

ICR Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

ICR Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

ICR Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Page 14

JunosE 11.3.x Service Availability Configuration Guide

ICR References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

ICR Scaling Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

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

Interaction with RADIUS for ICR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

ICR Partition Accounting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Configuring an ICR Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

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

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

Naming ICR Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

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

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

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

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

Monitoring the Configuration of an ICR Partition Attached to an Interface . . . . . 183

Monitoring the Configuration of ICR Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Part 2 Index

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Page 15

List of Figures

Part 1 Chapters

Chapter 1 Service Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Figure 1: JunosE Software Service Availability Layers . . . . . . . . . . . . . . . . . . . . . . . . 4

Chapter 2 Managing Module Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Figure 2: SRP Module on ERX7xx Models and ERX14xx Models . . . . . . . . . . . . . . . 18

Figure 3: SRP Module on the E120 and E320 Routers . . . . . . . . . . . . . . . . . . . . . . . 19

Chapter 3 Managing Stateful SRP Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Figure 4: High Availability States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 4 Managing Stateful Line Module Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Figure 5: Stateful Line Module Switchover States . . . . . . . . . . . . . . . . . . . . . . . . . 85

Chapter 6 Configuring VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Figure 6: Basic VRRP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Figure 7: Commonly Used VRRP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Figure 8: VRRP Configuration Without the Real Address Owner . . . . . . . . . . . . . 156

Chapter 7 Managing Interchassis Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Figure 9: ICR Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Figure 10: Sample 1:1 Subscriber Redundancy in a 4–Node ICR Cluster . . . . . . . . 173

Page 16

JunosE 11.3.x Service Availability Configuration Guide

Page 17

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

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

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

Table 5: show environment Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Table 6: show hardware Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Table 7: show redundancy Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Chapter 3 Managing Stateful SRP Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Table 8: Application Support for Stateful SRP Switchover . . . . . . . . . . . . . . . . . . 42

Table 9: show redundancy Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Table 10: show redundancy clients Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 60

Table 11: show redundancy history Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Table 12: show redundancy line-card Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 63

Table 13: show redundancy srp Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Table 14: show redundancy switchover-history Output Fields . . . . . . . . . . . . . . . . 65

Chapter 4 Managing Stateful Line Module Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Table 15: Module Configurations Supported for Stateful Switchover of LNS

Table 16: show redundancy line-card slot slotNum Output Fields . . . . . . . . . . . . 96

Table 17: show redundancy history line-card slot slotNum Output Fields . . . . . . . 98

Chapter 5 Configuring a Unified In-Service Software Upgrade . . . . . . . . . . . . . . . . . . . 101

Table 18: Unified ISSU-Related Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Table 19: Router Response to Undesirable Events During the Upgrade Phase . . . 111

Table 20: Application Support for Unified In-Service Software Upgrades . . . . . . 116

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

Table 22: Recommended Routing Protocol Timer Settings . . . . . . . . . . . . . . . . . 138

Table 23: show issu Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Chapter 6 Configuring VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Table 24: VRRP Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Table 25: show ip vrrp and show ip vrrp summary Output Fields . . . . . . . . . . . . . 160

Table 26: show ip vrrp neighbor Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Table 27: show ip vrrp statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Page 18

JunosE 11.3.x Service Availability Configuration Guide

Table 28: show ip vrrp tracked-objects Output Fields . . . . . . . . . . . . . . . . . . . . . 166

Chapter 7 Managing Interchassis Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Table 29: ICR Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Table 30: show icr-partition Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Table 31: show icr-partitions Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Page 19

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 Routersin an Internet accessenvironment.

E Series and JunosE Text and Syntax Conventions

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

Page 20

JunosE 11.3.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

Representscommands andkeywords intext.Bold text like this

Fixed-width text like this

Italic text like this

Plus sign (+) linking key names

Syntax Conventions in the Command Reference Guide

Representsinformation as displayed onyour terminal’s screen.

•

Emphasizes words.

•

Identifies variables.

•

Identifies chapter, appendix, and book names.

keys simultaneously.

ExamplesDescriptionConvention

•

Issue the clock source command.

•

Specify the keyword exp-msg.

host1(config)#traffic class low-loss1Represents text that the user must type.Bold text like this

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

mask, accessListNameRepresents variables.Italic text like this

Page 21

Table 2: Text and Syntax Conventions (continued)

About the Documentation

ExamplesDescriptionConvention

| (pipe symbol)

or variable to the left or to the right of this symbol. (The keyword or variable can be either optional or required.)

[ ]* (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 Portable Libraries page at

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

diagnostic | lineRepresents a choice to select one keyword

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

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

{ permit | deny } { in | out }

{ clusterId | ipAddress }

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

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

techpubs-comments@juniper.net, 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 productsupport is available through the Juniper Networks Technical Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,

Page 22

JunosE 11.3.x Service Availability Configuration Guide

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/us/en/local/pdf/resource-guides/7100059-en.pdf .

•

Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/ .

•

JTAC hours of operation—The JTAC centers have resources available 24 hours a day, 7 days a week, 365 days a year.

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online self-service portal called the Customer Support Center (CSC) that provides you with the following features:

•

Find CSC offerings: http://www.juniper.net/customers/support/

•

Search for known bugs: http://www2.juniper.net/kb/

•

Find product documentation: http://www.juniper.net/techpubs/

•

Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/

•

Download the latest versions of software and review release notes:

http://www.juniper.net/customers/csc/software/

•

Search technical bulletins for relevant hardware and software notifications:

https://www.juniper.net/alerts/

•

Join and participate in the Juniper Networks Community Forum:

http://www.juniper.net/company/communities/

•

Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/

To verify service entitlement by product serialnumber, 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 .

Page 23

PART 1

Chapters

•

Service Availability on page 3

•

Managing Module Redundancy on page 9

•

Managing Stateful SRP Switchover on page 35

•

Managing Stateful Line Module Switchover on page 67

•

Configuring a Unified In-Service Software Upgrade on page 101

•

Configuring VRRP on page 149

•

Managing Interchassis Redundancy on page 169

Page 24

JunosE 11.3.x Service Availability Configuration Guide

Page 25

CHAPTER 1

Service Availability

This chapter explains what service availability is and discusses the features of service availability. It alsodiscusses Juniper Networks multi-layered service availabilityapproach 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, orcompleterouter failure.These outages result insubscriber 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.

Figure 1 illustrates the multiple layers of JunosE Software service availability.

Page 26

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.3.x Service Availability Configuration Guide

Figure 1: JunosE Software Service Availability Layers

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 upgradeto reduce outage. You can eliminateor reduce single points of failureby configuring stateful SRPswitchover (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 ofthe 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 failsto 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.

Documentation

Understanding Service Availability Features on page 5•

Page 27

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

•

Stateful Line Module Switchover on page 5

•

Unified ISSU on page 6

•

VRRP on page 6

•

Interchassis Redundancy on page 6

Module Redundancy

Chapter 1: Service Availability

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 offailure 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 therouter of a stateful switchover from the active SRP module to the standby SRP module. Stateful SRP switchover maintains user sessionsand data forwarding through the router duringthe switchover,thus improving the overall availability of the router.

Stateful Line Module Switchover

High availability of line modules increases the overall availability of the routerby ensuring that all the subscribers who were connected during a line module recovery continue to remain logged in and can access network resources during the switchover from the primary line module to the secondary line module. Forwarding of data through the fabric slice for those subscribers continues with a brief disruption of two minutes. If you configured stateful line module switchover on a router, when a switchover occurs, a message is displayed on the active SRP module after the secondary line module successfully takes over the role of the previously configured primary line module. If the primary line module fails, the secondary line module takes the role of the primary line module. Mirrored configuration data and any mirrored volatile data are already resident in memory. The protocols and other applications re-initialize from the mirrored data and resynchronize communications with the line modules (non-volatile configuration and volatile state). Data forwarding operation continues to function normally with the secondary line module operating on behalf of the primary line module (with a small loss

Page 28

JunosE 11.3.x Service Availability Configuration Guide

of packets when the fabric is switched from the formerly active line module to the newly active line module). When resynchronization is completed, the router resumes normal operations, including updates ofany routingtables that result from changesthat occurred during the warm restart.

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 theupgrade; 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.

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 createsa redundancy scheme that enableshosts 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 youto track thefailure of uplink interfaces.ICR currentlysupports only PPPoE subscribers.

Page 29

Chapter 1: Service Availability

Documentation

• Managing Module Redundancy on page 9

• Managing Stateful SRP Switchover on page 35

• Configuring a Unified In-Service Software Upgrade on page 101

• Configuring VRRP on page 149

• Managing Interchassis Redundancy on page 169

• Service Availability Overview on page 3

Page 30

JunosE 11.3.x Service Availability Configuration Guide

Page 31

CHAPTER 2

Managing Module Redundancy

This chapter describes how tomanage redundancy (stateless switchover)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 9

•

Line Module Redundancy Requirements on page 10

•

Understanding Automatic Switchover on page 12

•

Understanding Reversion After Switchover on page 12

•

Configuring Line Module Redundancy on page 13

•

Managing Line Module Redundancy on page 13

•

Example: Forcing the Router to Switch from Primary Line Module to Spare Line Module on page 14

•

Interoperation of Redundancy and Stateful Switchover for Line Modules on page 15

•

Understanding SRP Module Redundancy on page 16

•

Understanding Configuration of SRP Modules for Redundancy on page 19

•

Installing a Redundant SRP Module on page 20

•

Managing SRP Module Redundancy on page 21

•

Switching to the Redundant SRP Module on page 22

•

Determination of Redundancy Status for Line Modules and SRP Modules Using Status LEDs on page 22

•

Monitoring Redundancy in Installed Hardware on page 23

•

Monitoring Redundancy in Line Module and SRP Modules on page 27

•

Monitoring Redundancy Status on E320 Router on page 30

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.

Page 32

JunosE 11.3.x Service Availability Configuration Guide

The process by which the router switches to the spare line module is called switchover. Line modules can operate in one of the two redundancy modes: stateless switchover or high availability. Stateless switchover is the default redundancy mode. During stateless 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 interfacesand the size of therouting table, because therouter 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.

NOTE: This section does not coverbehavior of line modules in high availability

redundancy mode. For information about stateful line module switchover, see“Managing Stateful Line Module Switchover” on page 67.

Documentation

Line Module Redundancy Requirements on page 10•

• Configuring Line Module Redundancy on page 13

• Managing Line Module Redundancy on page 13

• Stateful Line Module Switchover Overview on page 68

• Guidelines for Configuring Stateful Line Module Switchover on page 70

Line Module Redundancy Requirements

The requirements for linemodule redundancy depend on the type of router that youhave.

NOTE: The information in this section does not apply to the ERX310

Broadband Services Router,which doesnot 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 of how the router provides redundancy forline modulesand 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 ofhow the router providesredundancy 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

Page 33

Chapter 2: Managing Module Redundancy

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 stateless switchover redundancy for the ES2-S1 Service IOA.

IOA Behavior When the Router Reboots

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

Documentation

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 therouter reboots and a slotcontains aline moduleand one active andone 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 module redundancy actions, issuethe redundancy lockout command forthe primaryline module slot before issuing the adapter disable or adapter enable commands.

Line Module Redundancy Overview on page 9•

• Configuring Line Module Redundancy on page 13

• Managing Line Module Redundancy on page 13

• Stateful Line Module Switchover Overview on page 68

• Stateful Line Module Switchover Platform Considerations on page 70

Page 34

JunosE 11.3.x Service Availability Configuration Guide

Understanding 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

•

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

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

Table 3: Commands That Can Cause Automatic Switchover

slot disable primary-line-module-slot

reload slot primary-line-module-slot

Documentation

Line Module Redundancy Overview on page 9•

• Understanding Reversion After Switchover on page 12

• Configuring Line Module Redundancy on page 13

• Managing Line Module Redundancy on page 13

Understanding Reversion After Switchover

Reason for Automatic SwitchoverCommand

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

The command isequivalentto pushingthe reset button on the primary line module.

You can installonly onespare linemodule in the group of slots coveredby theredundancy midplane or redundancygroup. Ifthe router is using thespare line module, no redundancy is available. Reverting to the primary module as soon as possible is desirable. By default, the router does not automaticallyrevert to the primary module after switchover;however,

Page 35

Chapter 2: Managing Module Redundancy

you can configure it to do so. (See “Configuring Line Module Redundancy” on page 13.) Before reversion can take place, the primary line module must complete the POST diagnostics.

Documentation

Understanding Automatic Switchover on page 12•

• Line Module Redundancy Overview on page 9

Configuring Line Module Redundancy

By default, when the primary line module fails, the router automatically switches to the spare line module. Because the router is using the spare line module, no redundancy is available. The router must revert to the primary line module as soon as possible. The router does not automatically revert to the primary line module. To modify the default redundancy operations on the router, perform the following tasks:

•

Disable automatic switchover on a slot.

host1(config)#redundancy lockout 5

•

Enable automatic reversion after switchover.

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

Documentation

Line Module Redundancy Overview on page 9•

• Line Module Redundancy Requirements on page 10

• Managing Line Module Redundancy on page 13

• redundancy lockout

• redundancy revertive

Managing Line Module Redundancy

When the router is running and a redundancy group is installed, to manage stateless switchover redundancy, you must perform the following tasks:

•

Force switchover manually.

host1#redundancy force-switchover 5

•

Force reversion manually.

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

Documentation

Line Module Redundancy Overview on page 9•

• Line Module Redundancy Requirements on page 10

• Configuring Line Module Redundancy on page 13

• Stateful Line Module Switchover Overview on page 68

• Stateful Line Module Switchover Modes on page 83

Page 36

JunosE 11.3.x Service Availability Configuration Guide

• System Operations When Stateful Line Module Switchover Is Enabled on page 74

• redundancy force-switchover

• redundancy revert

Example: Forcing the Router to Switch from Primary Line Module to Spare Line Module

In thefollowing example, theuser forces the router to switchfrom the primary line module to the spare line module by issuing the redundancy force-switchover command. In the example, you first issue the show redundancy command to display redundancy informationspecific toline modules.Youcan thenissue the redundancy force-switchover command to force the router to switch from the primary line module to the spare line module. To view the status of the line modules after the switchover, you can again issue the show redundancy command.

1. Display the redundancy information.

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

2. Force the router to switch from the primary line module to the spare line module.

host1#redundancy force-switchover 2

Page 37

Chapter 2: Managing Module Redundancy

3. Verify the redundancy status of the line module.

host1#show redundancy line-card

automatic reverting is off

backed up sparing 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

Interoperation of Redundancy and Stateful Switchover for Line Modules

Documentation

Line module redundancy and stateful line module switchover cannot coexist and are mutually exclusive processes. Only one of the two operations—line module redundancy or stateful line module switchover—can be enabled on a router at a point of time. You cannot configure line modules installed in a redundancy group to operate in HA mode. If aline moduleis a member of aredundancy group, you cannot configure that line module for stateful switchover using the mode high-availability slot command in Redundancy Configuration mode. Similarly, if a line module is configured for high availability, it cannot be installed in a redundancy group. If you attempt to add a line module configured in a redundancy group to the stateful switchover pair using the mode high-availability slot command, the particular line moduleis removed from theredundancy group andis added to the high availability pair. High availability configuration for a line module takes precedence over its redundancy group setting.

Stateful Line Module Switchover Overview on page 68•

• mode

• line-card switch

• show redundancy line-card

• show redundancy history

Page 38

JunosE 11.3.x Service Availability Configuration Guide

Understanding SRP Module Redundancy

NOTE: This section does not cover NVS cards or the behavior on systems running high availability features such as hitless SRP switchover. For informationabout managing NVSin 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 Stateful SRP Switchover” on page 35.

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.

NOTE: The ERX310 router 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.

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-numbered 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 takes control without rebooting itself. For information about preventing the redundant SRP module from taking control, see “Managing SRP Module Redundancy” on page 21.

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 gives back 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 takes control, the followingsequence of eventsoccurs:

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

2. The redundant SRP module restarts and takes 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.

Page 39

Chapter 2: Managing Module Redundancy

The following actions activate the redundant SRP module:

•

Failure of the primary SRP module (hardware or software)

•

Pushing the recessedreset button onthe primarySRP module. (See Figure2 onpage 18 and Figure 3 on page 19.)

•

Issuing the srp switch command

•

Issuing the redundancy force-switchover command

Page 40

JunosE 11.3.x Service Availability Configuration Guide

Figure 2: SRP Module on ERX7xx Models and ERX14xx Models

Page 41

Chapter 2: Managing Module Redundancy

Figure 3: SRP Module on the E120 and E320 Routers

Documentation

Understanding Configuration of SRP Modules for Redundancy on page 19•

• Installing a Redundant SRP Module on page 20

• Managing SRP Module Redundancy on page 21

Understanding Configuration of SRP Modules for Redundancy

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 arma configuration (.cnf) fileby issuingthe 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.

Page 42

JunosE 11.3.x Service Availability Configuration Guide

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.

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.

Documentation

Understanding SRP Module Redundancy on page 16•

• Installing a Redundant SRP Module on page 20

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.

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 solderconnections. These actions help to protect modules from damage by electrostatic discharge.

To install a redundant SRP module into a running router:

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.

host1#reload slot 7

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

Page 43

Chapter 2: Managing Module Redundancy

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

SRP module.

host1#synchronize low-level-check all

NOTE: The SRP module reboots after synchronization is complete.

Documentation

Understanding SRP Module Redundancy on page 16•

• Managing SRP Module Redundancy on page 21

• Switching to the Redundant SRP Module on page 22

• reload slot

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

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.

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

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

SRP module.

host1#synchronize low-level-check all

Documentation

Understanding SRP Module Redundancy on page 16•

• Installing a Redundant SRP Module on page 20

• disable-switch-on-error

• synchronize

Page 44

JunosE 11.3.x Service Availability Configuration Guide

Switching to the Redundant SRP Module

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

Switch from the primary SRP module to the redundant SRP module by doing either of the following:

•

Issue the redundancy force-switchover command.

host1#redundancy force-switchover 5

•

Issue the srp switch force command.

host1#srp switch force

Documentation

Understanding SRP Module Redundancy on page 16•

• Installing a Redundant SRP Module on page 20

• Managing SRP Module Redundancy on page 21

• redundancy force-switchover

• srp switch

Determination of Redundancy Status for Line Modules and SRP Modules Using Status LEDs

You can determine the redundancy state of line modules and SRP modules by examining their status LEDs. See Table 4 on page 22 for a description of the LEDs functions. In addition, if you issue the show version command, the state fieldfor 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

Documentation

Line Module Redundancy Overview on page 9•

• Understanding SRP Module Redundancy on page 16

Module is in standby state.OnOff

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

Page 45

Monitoring Redundancy in Installed Hardware

Purpose Display redundancy information specific to the hardware installed.

Action To display redundancy information of the hardware installed, system environment

information, and detailed information on the temperature status of an ERX7xx router.

host1#show environment all chassis: 14 slot (id 0x3, rev. 0x0) fabric: 5 Gbps (rev. 1) fans: ok nvs: ok (81MB flash disk, 54% full) power: A ok, B not present AC power: A not present, B not present srp redundancy: none *** slots: cards missing or offline online: 6 9 standby: 8 offline: 2 empty: 0 1 3 4 5 7 10 11 12 13 line redundancy: 1 redundancy group(s) width 6, spare 8, primary 9 temperature: ok timing: primary primary: internal SC oscillator (ok) secondary: internal SC oscillator (ok) tertiary: internal SC oscillator (ok) auto-upgrade enabled *** system operational: no

processor processor IOA IOA temperature temperature temperature temperature slot (10C - 70C) status (10C - 70C) status

---- ----------- ----------- ----------- ----------0 31 normal 30 normal 3 31 normal 30 normal 5 31 normal 30 normal 7 31 normal 30 normal processor temperature ranges below -5C is too cold above 80C is too hot low temperature warning below 10C high temperature warning above 70C IOA temperature ranges below -5C is too cold above 80C is too hot low temperature warning below 10C high temperature warning above 70C

Chapter 2: Managing Module Redundancy

To display redundancy information of the hardware installed, system environment information, and detailed information on the temperature status of an E320 router.

host1#show environment all

chassis: 17 slot (id 0x3, rev. 0x0) fabric: 100 Gbps (rev. 1) fans: fanSubsystemOk nvs: ok (977MB flash disk, 29% full), matches running config power: A ok, B not present srp redundancy: mode is file-system-synchronization auto-sync

Page 46

JunosE 11.3.x Service Availability Configuration Guide

enabled, switch-on-error enabled status unknown *** slots: cards missing or offline online: 0 6 13 offline: 7 empty: 1 2 3 4 5 11 12 14 15 16 fabric slots: ok online: 6 7 8 9 10 line redundancy: none temperature: ok timing: primary primary: internal SC oscillator (ok) secondary: internal SC oscillator (ok) tertiary: internal SC oscillator (ok) auto-upgrade enabled fabric redundancy: ok

*** system operational: no

temperature temperature slot type (10C - 70C) status

---- ------------------ ----------- ----------0 LM-4 42 normal 0/1 GE-4 IOA 23 normal 6 SRP-100 32 normal 6 SFM-100 32 normal 6/0 SRP IOA 25 normal 7 SFM-100 30 normal 8 SFM-100 23 normal 9 SFM-100 25 normal 10 SFM-100 24 normal 13 LM-4 24 normal 13/0 GE-4 IOA 23 normal

fabric temperature ranges below -5C is too cold above 79C is too hot low temperature warning below 10C high temperature warning above 70C processor temperature ranges below -5C is too cold above 79C is too hot low temperature warning below 10C high temperature warning above 70C IOA temperature ranges below -5C is too cold above 79C is too hot low temperature warning below 10C high temperature warning above 70C

Meaning Table 5 on page 25 lists the show environment command output fields.

Page 47

Table 5: show environment Output Fields

Field DescriptionField Name

Chapter 2: Managing Module Redundancy

Chassis

nvs

Number of slots, midplane identifier, and hardware revision number:

• 14Slot—5Gbps, 14 slot midplane

• midplaneId7Slot—5Gbps, 7 slot midplane

• midplaneIdRx1400—10Gbps ASIC compatible, 12

line module slots, 2 SRP module slots for ERX14xx models

• midplaneIdRx700—10Gbps ASIC compatible,5 line

module slots, 2 SRP module slots for ERX7xx models

• 17Slot—100 or 320 Gbps, 17-slot midplane for the

E120 router

• 11Slot—320Gbps,

11-slot midplane for the E120 router

Capacity and hardware revision of the fabric.fabric

Status of fans.fans

Status and capacity of NVS and amount of space used.

Status of power feeds.power

For ERX310 router only; status of power feeds.AC power

slots: cards missing or offline.

line redundancy

fabric redundancy

Availability of a redundant SRP modulesrp redundancy

Status of each slot:

• online

• standby

• offline

• empty

Number of redundancy groups installed:

• width—Number of slots the redundant midplane

covers

• spare—Slot that contains a spare line module

• primary—Slot that contains theprimary line module

Statusof redundancyon the switch fabricon the E120 and E320 routers. Possible values: ok and none.

Status of the system temperaturetemperature

Page 48

JunosE 11.3.x Service Availability Configuration Guide

Table 5: show environment Output Fields (continued)

Field DescriptionField Name

timing

type

temperature

processor temperature status

Source of the timing signal:

• primary—Type and status of the primary timing

signal

• secondary—Type and status of the secondary

timing signal

• tertiary—Type and status of the tertiary timing

signal

• auto-upgrade—Status of the auto-upgrade

parameter, which enables the system to revert to a higher-priority timing source after switching to a lower-priority timing source.

Status of the systemsystem operational

Number of the slot in which the module residesslot

Type of module in the slot on the E120 and E320 routers

Temperature of theline module, SRP module, orSFM on the E120 and E320 routers

Temperature of the line module or SRP moduleprocessor temperature

Temperature condition of the line module:

IOA temperature status

processor temperature ranges

• normal—Temperature is within the normal range

• too hot—Module is too hot; system will go into

thermal protection mode if the temperature ofany module exceeds 80 C

• too cold—Module is too cold; system will go into

thermal protection mode if the temperature ofany module drops below -5 C

Temperature of the corresponding I/O module or IOAIOA temperature

Temperature condition of the corresponding I/O module or IOA:

• normal—Temperature is within the normal range

• too hot—Module is too hot; system will go into

thermal protection mode if the temperature ofany module exceeds 80 C

• too cold—Module is too cold; system will go into

thermal protection mode if the temperature ofany module drops below -5 C

Temperature ranges for the line modules and SRP modules.

Page 49

Chapter 2: Managing Module Redundancy

Table 5: show environment Output Fields (continued)

Field DescriptionField Name

Temperature ranges for the I/O modules on ERX7xx models, ERX14xx models, and the ERX310 router or IOAs on the E120 and E320 routers.

Temperature ranges for the SRP modules and SFMs on the E120 and E320 routers.

IOA temperature ranges

fabric temperature ranges

show environment•

Documentation

Monitoring Redundancy in Line Module and SRP Modules

Purpose Display redundancy information about SRP modules, line modules, and I/O modules in

ERX7xx models, ERX14xx models, and the ERX310 router. Also displays redundancy information about SRP modules, line modules, and IOAs in the E120 router and the E320 router.

Action To displayredundancy informationabout the SRP modules, line modules,and I/Omodules

on an ERX7xx router.

host1#show hardware serial assembly assembly ram slot type number number rev. (MB)

---- ---------------- ---------- ---------- -------- ---0 SRP-10Ge 4305358981 3500005472 A06 2048 1 SRP-10Ge 4305359020 3500005472 A06 2048 2 --- --- --- --- --3 --- --- --- --- --4 CT3-12 4305337201 3500010901 A07 128 5 OC3/OC12/DS3-ATM 4605300290 3500103958 A06 256 6 GE/FE 4605340294 3500104554 A08 256

number of serial assembly assembly MAC slot type number number rev. addresses

---- ------------- ---------- ---------- -------- --------0 --- --- --- --- --1 SRP-10Ge I/O 4605250426 3500003302 A02 1 2 --- --- --- --- --3 --- --- --- --- --4 CT3/T3-12 I/O 4305316605 3500010801 A02 5 OC3(8)-MM I/O 4304443600 4500001501 A03 4 6 GE-SFP I/O 4605310064 4500002001 A05 1 base slot MAC address

---- -------------0 --1 0090.1aa0.577a 2 --3 --4

Page 50

JunosE 11.3.x Service Availability Configuration Guide

5 0090.1a41.7c68 6 0090.1aa0.6216

To display redundancy information about the SRP modules, line modules, and IOAs on the E320 router.

host1#show hardware

Chassis

------ serial assembly assembly Major/Minor type number number rev. rev

------- ---------- ---------- -------- ----------Chassis 5504200687 4400006402 01 0.101

Modules

------ serial assembly assembly ram Major/Min slot type number number rev. (MB) rev

---- ------- ---------- ---------- -------- ---- --------0 --- --- --- --- --- --1 --- --- --- --- --- --2 LM-4 4303470363 4500006301 01 256 1.101 3 --- --- --- --- --- --4 --- --- --- --- --- --5 --- --- --- --- --- --6 --- --- --- --- --- --6 --- --- --- --- --- --7 SRP-100 4304218323 4500006601 03 1024 1.103 7 SFM-100 4304218323 4500006601 03 --- 1.103 8 SFM-100 4304206756 4500006701 04 --- 1.104 9 SFM-100 4304206762 4500006701 04 --- 1.104 10 SFM-100 4304206737 4500006701 04 --- 1.104 11 --- --- --- --- --- --12 --- --- --- --- --- --13 --- --- --- --- --- --14 --- --- --- --- --- --15 --- --- --- --- --- --16 --- --- --- --- --- ---

Adapters

------- number of serial assembly assembly MAC slot type number number rev. addresses

---- -------- ---------- ---------- -------- --------0/0 --- --- --- --- --0/1 --- --- --- --- --1/0 --- --- --- --- --1/1 --- --- --- --- --2/0 GE-4 IOA 4304020462 4500006800 11 4 2/1 --- --- --- --- --3/0 --- --- --- --- --3/1 --- --- --- --- --4/0 --- --- --- --- --4/1 --- --- --- --- --5/0 --- --- --- --- --5/1 --- --- --- --- --7/0 SRP IOA 4303470366 4500006500 02 2 11/0 --- --- --- --- --11/1 --- --- --- --- ---

Page 51

Chapter 2: Managing Module Redundancy

12/0 --- --- --- --- --12/1 --- --- --- --- --13/0 --- --- --- --- --13/1 --- --- --- --- --14/0 --- --- --- --- --14/1 --- --- --- --- --15/0 --- --- --- --- --15/1 --- --- --- --- --16/0 --- --- --- --- --16/1 --- --- --- --- -- base Major/Minor slot MAC address rev

---- -------------- ----------0/0 --- --0/1 --- --1/0 --- --1/1 --- --2/0 0090.1a00.17ec 1.111 2/1 --- --3/0 --- --3/1 --- --4/0 --- --4/1 --- --5/0 --- --5/1 --- --7/0 0090.1a00.17ae 1.102 11/0 --- --11/1 --- --12/0 --- --12/1 --- --13/0 --- --13/1 --- --14/0 --- --14/1 --- --15/0 --- --15/1 --- --16/0 --- --16/1 --- ---

Fan(s)

----- serial assembly assembly Major/Minor Tray type number number rev. rev

---- ----------- ---------- ---------- -------- ----------0 Primary FAN 4303370009 4400007000 01 1.101

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

Meaning Table 6 on page 29 lists the show hardware command output fields.

Table 6: show hardware Output Fields

type

Field DescriptionField Name

Physical slot that contains the module.Slot

Kind ofmodule orchassis and fan tray in the E120and E320 routers; an “e”at theend of anSRP module type (for example, SRP-5Ge) indicates that the module includes error-checking code (ECC) memory.

Page 52

JunosE 11.3.x Service Availability Configuration Guide

Table 6: show hardware Output Fields (continued)

Field DescriptionField Name

Serial number of the module, chassis, or fan tray.serial number

Part number of the module, chassis, or fan tray.assembly number

Hardware revision of the module, chassis, or fan tray.assembly rev.

Memory capacity of the host processor.ram (MB)

Total number ofEthernet addresses onan I/Omodule or an IOA.

Lowest Ethernet address on an I/O module or an IOAbase MAC address

Number of the fan tray in the E120 and E320 routers; 0 indicates the primary fan.

Revisionnumber of the module on the E120 and E320 routers.

number of MAC addresses

Tray

Major/Minor rev

show hardware•

Documentation

Monitoring Redundancy Status on E320 Router

Purpose Display the configuration for line module redundancy and SRP module redundancy on

an E320 router.

Action host1#show redundancy

SRP

---

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

Criteria Preventing High Availability from being Active

------------------------------------------------------ criterion met

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

Line Card

---------

automatic reverting is off

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

Page 53

Chapter 2: Managing Module Redundancy

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

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

Table 7: show redundancy Output Fields

Field DescriptionField Name

SRP

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 restartform saved configurationfiles.

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

• cold-start—When the routeris inpending state and

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

• warm-start—When the router is in active state and

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

Page 54

JunosE 11.3.x Service Availability Configuration Guide

Table 7: show redundancy Output Fields (continued)

Field DescriptionField Name

Criteria Preventing High Availability from being Active

Criteria Required for High Availability to be Active

Line Card

automatic reverting

hardware role

lockout config

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.

Slots in which the line modules reside.slots

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

backed up by slot

sparing for slot

midplane rev

fabric slice redundancy

slice state

type

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.

Statusof thefabric slice onthe SRP modules orSFMs 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.

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

Page 55

Chapter 2: Managing Module Redundancy

Documentation

• show redundancy

• show redundancy line-card

• show redundancy srp

Page 56

JunosE 11.3.x Service Availability Configuration Guide

Page 57

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 E Series routers. Use this chapter with “Managing Module Redundancy” on page 9 to fully manage the SRP features.

This chapter contains the following sections:

•

Stateful SRP Switchover Overview on page 35

•

Stateful SRP Switchover Platform Considerations on page 36

•

Stateful SRP Switchover Redundancy Modes on page 37

•

Stateful SRP Switchover States on page 38

•

Application Support for Stateful SRP Switchover on page 42

•

Guidelines for Activating High Availability on page 51

•

Activating High Availability on page 52

•

Guidelines for Deactivating High Availability on page 53

•

Deactivating High Availability on page 53

•

Guidelines for Setting the IP Interface Priority on page 54

•

Setting the IP Interface Priority on page 54

•

Guidelines for Upgrading Software on page 55

•

Monitoring the Redundancy Status on page 56

•

Monitoring the Redundancy Status of Applications on page 59

•

Monitoring the Redundancy History on page 61

•

Monitoring the Redundancy Status of Line Modules on page 62

•

Monitoring the Redundancy Status of SRP Modules on page 63

•

Monitoring the Redundancy Switchover History on page 65

•

Clearing the Redundancy History on page 65

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

Page 58

JunosE 11.3.x Service Availability Configuration Guide

hardware-specific and software-specific methods to ensure minimal downtime and ultimately improve the performance of your network.

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, routingengines 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.

Documentation

Stateful SRP Switchover Redundancy Modes on page 37•

• Stateful SRP Switchover States on page 38

• Application Support for Stateful SRP Switchover on page 42

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

NoSRP-40G

YesSRP-40G PLUS

YesSRP-100

Page 59

Chapter 3: Managing Stateful SRP Switchover

NOTE: Stateful SRP switchover requires two SRP modules with 1 GB of

memory or more.

Documentation

Monitoring the Redundancy Status on page 56•

• Monitoring the Redundancy Status of SRP Modules on page 63

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

File System Synchronization Mode

File system synchronization is the default behavior mode for E Series routersthat 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:

High Availability Mode

•

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

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 additionto keeping thecontents of NVS,high availability modekeeps state anddynamic configurationdata from the SRP memory synchronized between theprimary and standby SRP modules.

Page 60

JunosE 11.3.x Service Availability Configuration Guide

When stateful SRP switchover is enabled, an SRP switchover keeps line modules up and forwardingdata, andthe newly active SRP module continues from the point ofswitchover.

By using transaction-based mirroring instead of file synchronization, high availability mode keeps the standby SRP module synchronized withthe activeSRP 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 NVSin 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.

Documentation

•

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.

Stateful SRP Switchover States on page 38•

• disable-autosync

• redundancy

• mode

Stateful SRP Switchover States

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

Page 61

Figure 4: 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 touse file system synchronization. If a switchover occurs while therouter 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.

During the disabled state:

•

If anyone criterion is not met,the system remains inthe disabledstate, until the criterion is met.

•

If aswitchover occurs whilethe system isin the disabled state, thesystem cold-restarts.

Page 62

JunosE 11.3.x Service Availability Configuration Guide

While in the disabled state, the system operates as if it were configured for file system synchronization(for example, NVS issynchronized 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:

•

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.

Active State

During the initializing state:

•

If an unsupported application is configured during initialization, the system completes initializing and enters the pending state.

•

If anyother criterionbecomes false (or isno longer met),the system enters thedisabled 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. Whenmaking changesor 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.

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.

Page 63

Chapter 3: Managing Stateful SRP Switchover

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 anunsupported application isconfigured, the systemtransitions tothe 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 tocommit occurs; if a switchover occurs while in this mode, the standby SRP module uses the configuration in memory.

Pending State

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.

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.

Documentation

Monitoring the Redundancy Status on page 56•

• Monitoring the Redundancy Status of SRP Modules on page 63

Page 64

JunosE 11.3.x Service Availability Configuration Guide

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

Application Support

•

Unsupported—We recommend that you not configure unsupported applications on a chassis running in highavailability mode. Althoughconfigured 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 8 on page 42 indicates which applications support or do not support stateful SRP switchover.

Table 8: Application Support for Stateful SRP Switchover

NotesUnsupportedSupportedApplication

Physical Layer Protocols

––✓DS1

––✓DS3

––✓HDLC

––✓SONET/SDH

––✓SONET/SDH VT

Link-Layer Protocols

Page 65

Chapter 3: Managing Stateful SRP Switchover

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

NotesUnsupportedSupportedApplication

configuration of dynamic interfaces

without VLANs)

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

––✓ATM 1483 bulk

––✓Bridged Ethernet

––✓Cisco HDLC

––✓Ethernet (with and

––✓Frame Relay

––✓PPP

––✓PPPoE

bridging

Unicast Routing

––✓Transparent

––✓Access Routes

–✓BFD

–✓BGP

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 theremote peer before applying the temporarychange. TheBFD timers revert back to the configured values after 15 minutes (the maximum duration for graceful restart completion).

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

Page 66

JunosE 11.3.x Service Availability Configuration Guide

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

NotesUnsupportedSupportedApplication

––✓IP

––✓IPv6

discovery

and IPv6)

–✓IPv6 neighbor

–✓IPSec Tunnels

–✓IS-IS

–✓IS-ISv6

–OSPFv2

–✓OSPFv3

–✓Static Routes (IP

IPv6 neighbor discovery characteristics are replayed during switchover. Line modulesdo notflush neighbor discovery information during the switchover.

–✓–IPSec Transport

Completed IKE phase 1 and phase 2 negotiations supported only.

Supported only whenthe graceful restart extension is enabled.

Static recovery support only.–✓RIP

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.

IPv4 Multicast Routing

Static recovery support only.–✓Telnet

Page 67

Chapter 3: Managing Stateful SRP Switchover

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

NotesUnsupportedSupportedApplication

–✓Multicast Routing

–✓DVMRP

–✓IGMP

Stateful SRP switchover. During switchover, the system mirrors the multicast queue so that IP can use the same queuewithout needing to recreate a different connection. The multicast queues are also preserved during the switchover and graceful restart period to ensure that multicast data continues to be forwarded using the previously learned multicast forwarding state.

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

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.

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

Page 68

JunosE 11.3.x Service Availability Configuration Guide

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

NotesUnsupportedSupportedApplication

–✓MGTM

–✓PIM

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 onthe 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 downstreamrouters 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.

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.

IPv6 Multicast Routing

–✓Multicast Routing

Page 69

Chapter 3: Managing Stateful SRP Switchover

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

NotesUnsupportedSupportedApplication

–✓MGTM

–✓MLD

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

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 asIPv6 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 allowhosts 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 notifiesMGTM that graceful restart is complete.

Page 70

JunosE 11.3.x Service Availability Configuration Guide

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

Multiprotocol Label Switching

NotesUnsupportedSupportedApplication

–✓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 isHA-unsafe, therouter undergoes a cold restart.

cross-connects between layer 2 interfaces using MPLS

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

—–✓BGP signaling

–✓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 and QoS

––✓Policies

Static recovery support only.–✓QoS

Page 71

Chapter 3: Managing Stateful SRP Switchover

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

NotesUnsupportedSupportedApplication

Remote Access

––✓AAA

Server and Packet Trigger

Capture

–✓DHCP External

–✓DHCP Relay Server

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

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.

Server

––✓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

Page 72

JunosE 11.3.x Service Availability Configuration Guide

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

NotesUnsupportedSupportedApplication

Pools

Dynamic-Request Server

Disconnect

–✓IPv4 Local Address

–✓IPv6 Local Address

–✓RADIUS Client

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.

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.

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

–✓RADIUS Initiated

Server

Route-Download Server

Miscellaneous

––✓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.

Page 73

Chapter 3: Managing Stateful SRP Switchover

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

NotesUnsupportedSupportedApplication

––✓J-Flow (IP flow

statistics)

––✓Line Module

Redundancy

––✓Network Address

Translation

––✓NTP

––✓Resource

Threshold Monitor

––✓Response Time

Reporter

Documentation

Interfaces

DVMRP)

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.

Monitoring the Redundancy Status of Applications on page 59•

• show redundancy clients

Static recovery support only.–✓Route Policy

–✓Subscriber

IPv4 only. Subscriber interfaces are not applicable to IPv6.

––✓Tunnels (GRE and

Static recovery support only.–✓VRRP

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 Stateful SRP Switchover” onpage 35.

Page 74

JunosE 11.3.x Service Availability Configuration Guide

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 runningthe same software release version in order to activate high availabilitymode.

•

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.

Documentation

Stateful SRP Switchover Redundancy Modes on page 37•

• Activating High Availability on page 52

• redundancy

• mode

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 RedundancyConfiguration mode, specify highavailability as the redundancy mode.

host1(config-redundancy)#mode high-availability

Documentation

Stateful SRP Switchover Redundancy Modes on page 37•

• Guidelines for Activating High Availability on page 51

• redundancy

• mode

Page 75

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 thefile-system-synchronizationmode, therouter synchronizes the filesand 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.

Chapter 3: Managing Stateful SRP Switchover

Documentation

Stateful SRP Switchover Redundancy Modes on page 37•

• Deactivating High Availability on page 53

• redundancy

• mode

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 modewhich is the defaultbehavior mode for E Series routers thatuse 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.

•

Specify the no version to disable high availability.

Documentation

Stateful SRP Switchover Redundancy Modes on page 37•

• Guidelines for Deactivating High Availability on page 53

• redundancy

• mode

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

host1(config-redundancy)#no mode

Page 76

JunosE 11.3.x Service Availability Configuration Guide

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-priorityIP and IPv6interfaces.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.

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.

Documentation

Setting the IP Interface Priority on page 54•

• 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

Page 77

Chapter 3: Managing Stateful SRP Switchover

Documentation

Guidelines for Setting the IP Interface Priority on page 54•

• 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 thesoftware is to ensure thatthe 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 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.

Documentation

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

Stateful SRP Switchover Redundancy Modes on page 37•

• Stateful SRP Switchover States on page 38

• srp switch

Page 78

JunosE 11.3.x Service Availability Configuration Guide

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

---------

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

Page 79

Chapter 3: Managing Stateful SRP Switchover

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 9 on page 57 lists the show redundancy command output fields.

Table 9: show redundancy Output Fields

Field DescriptionField Name

SRP

high-availability state

current redundancy mode

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 restartform saved configurationfiles.

Page 80

JunosE 11.3.x Service Availability Configuration Guide

Table 9: show redundancy Output Fields (continued)

Field DescriptionField Name

last activation type

Criteria Preventing High Availability from being Active

Criteria Required for High Availability to be Active

Line Card

automatic reverting

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

Slots in which the line modules reside.slots

hardware role

lockout config

backed up by slot

sparing for slot

midplane rev

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.

Page 81

Chapter 3: Managing Stateful SRP Switchover

Table 9: show redundancy Output Fields (continued)

Field DescriptionField Name

Statusof thefabric slice onthe SRP modules orSFMs 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.

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

fabric slice redundancy

slice state

type

show redundancy•

Documentation

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

--------------------- ------------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 clientsupports high availability and also the safety level of configuration. Forinstance, 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

Page 82

JunosE 11.3.x Service Availability Configuration Guide

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 SonetVT supported safe IPsec Tunnel (ST) supported safe

Meaning Table 10 on page 60 lists the show redundancy clients command output fields.

Table 10: show redundancy clients Output Fields

Field DescriptionField Name

High availability client.client

mode

Configuration

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

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

Page 83

Chapter 3: Managing Stateful SRP Switchover

show redundancy clients•

Documentation

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

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

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 11 on page 61 lists the show redundancy history command output fields.

Table 11: show redundancy history Output Fields

last cold start

last cold switchover

Field DescriptionField Name

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

Date and time the router experienced the last cold start.

Date and time the router experienced the last cold switchover.

Page 84

JunosE 11.3.x Service Availability Configuration Guide

Table 11: show redundancy history Output Fields (continued)

Field DescriptionField Name

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

last warm switchover

cold starts

switchovers

show redundancy history•

Documentation

Monitoring the Redundancy Status of Line Modules

Purpose Display redundancy information specific to line modules.

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 12 on page 63 lists the show redundancy line-card command output fields.

Page 85

Chapter 3: Managing Stateful SRP Switchover

Table 12: show redundancy line-card Output Fields

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.

lockout config

backed up by slot

sparing for slot

midplane rev

show redundancy line-card•

Documentation

Monitoring the Redundancy Status of SRP Modules

Purpose Display redundancy information specific to SRP modules.

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

Page 86

JunosE 11.3.x Service Availability Configuration Guide

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 13 on page 64 lists the show redundancy srp command output fields.

Table 13: show redundancy srp Output Fields

Field DescriptionField Name

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.

Redundancymode currentlybeing used bythis 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 restartform saved configurationfiles.

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

show redundancy srp•

Documentation

Criteria required for high availability to be active.

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

Page 87

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

Chapter 3: Managing Stateful SRP Switchover

Meaning Table 14 on page 65 lists the show redundancy switchover-history command output

fields.

Table 14: show redundancy switchover-history Output Fields

running release

show redundancy switchover-history•

Documentation

Clearing the Redundancy History

To clear the stateful SRP switchover history for the router:

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

Release runningon theSRP moduleat thetime ofthe switchover.

•

Issue the clear redundancy history command:

host1#clear redundancy history

There is no no version.

Page 88

JunosE 11.3.x Service Availability Configuration Guide

Documentation

• Monitoring the Redundancy History on page 61

• Monitoring the Redundancy Switchover History on page 65

• clear redundancy history

• show redundancy history

• show redundancy switchover-history

Page 89

CHAPTER 4

Managing Stateful Line Module Switchover

This chapter describes how to manage statefulline module switchover (high availability) software features for E120 and E320 routers, and contains the following sections:

•

Stateful Line Module Switchover Overview on page 68

•

Benefits of Stateful Line Module Switchover on page 68

•

Stateful Line Module Switchover Platform Considerations on page 70

•

Guidelines for Configuring Stateful Line Module Switchover on page 70

•

System Operations When Stateful Line Module Switchover Is Enabled on page 74

•

Stateful Line Module Configuration Scenarios on page 75

•

Replacement of Line Modules When Stateful Line Module Switchover Is Enabled on page 77

•

Application Support for Stateful Line Module Switchover on page 79

•

Stateful Line Module Switchover Modes on page 83

•

Stateful Line Module Switchover States on page 84

•

Guidelines for Activating High Availability on page 87

•

Activating High Availability on page 88

•

Guidelines for Deactivating High Availability on page 89

•

Deactivating High Availability on page 89

•

Switching Over from a Primary Line Module to Secondary Line Module on page 90

•

Log Messages Generated for Stateful LM Switchover on page 91

•

Preservation of Statistics During Stateful Line Module Switchover on page 93

•

Performance Impact and Scalability Considerations on page 94

•

Use of Status LEDs to Monitor the High Availability States of Line Modules on page 95

•

Monitoring the Redundancy Status of Line Modules in a Specific Slot on page 95

•

Monitoring the Redundancy History of Line Modules in a Specific Slot on page 97

Page 90

JunosE 11.3.x Service Availability Configuration Guide

Stateful Line Module Switchover Overview

JunosE Software now supports high availability for ES2 4G line modules configured with Service IOAs on E120 and E320 routers. These line modules function in a 1:1 redundancy mode withthe activemodule as the primary linemodule andthe spare or standbymodule as the secondary line module. This functionality of high availability for line modules is also referred to as stateful line module switchover.

In releases in which the stateful line module switchover feature was not supported or in scenarios in which this behavior is disabled, the restart of a line module causes it to be reloaded and all the subscriber sessions that are routed through it to be disconnected. All users connected to the router when the line module is reloading need to log in again and reestablish their connections. Based on the router models deployed in your environment, the configurationsettings appliedin yournetwork, andthe number of active subscriber sessions,reestablishment and resettingof subscriberconnections can consume several minutes.

Stateful linemodule switchoverreduces theimpact onsubscriber traffic duringa stateful switchover from the active line module to the standby line module by ensuring that existing subscriber sessions remain active with a brief disconnection in traffic. Stateful line module switchover maintains user sessions and reduces data traffic outage through the router to a brief duration during the switchover, thereby improving the overall availability of the router. Stateful line module switchover keeps the connections through the module up, with a brief disruption in forwarding on existing interfaces through the fabric slice. When you restart the line module, applications recover to a stable state by synchronizing with their peers on the SRP module swiftly to resume normal operations. This mechanism enables the system to keep user connections up and data forwarding outage minimal through the fabric slice.

Documentation

Benefits of Stateful Line Module Switchover on page 68•

• Stateful Line Module Switchover Platform Considerations on page 70

Benefits of Stateful Line Module Switchover

Line module high availability enhances the overall reliability and resiliency of the router. All subscribers who are connected during line module recovery remain active; their sessions are preserved during switchover and forwarding of data through the fabric slice is disrupted briefly.When a switchover occurs withthe high availability state beingactive, a message is displayed on the active SRP module after the secondary line module has successfully taken over from the previously configured primary line module.

If you configured the ha logging event category (using the log severity notice ha command), log messages are displayed when high availability for linemodules isenabled or disabled, either because of manual settings or in response to system events. For example, the following log message is displayed when a line module event causes high availability to be disabled.

Page 91

1:1 Redundancy Model

Chapter 4: Managing Stateful Line Module Switchover

NOTICE 01/27/2004 19:54:06 ha (): High Availability disabled due to secondary line card

in slot 9 down

The commands used to configure stateful switchover for SRP modulesand line modules are very similar.The configurationmodes arethe same. The keywords to configurestateful switchover for SRP modules and for line modules are different. When redundancy mode is configured for high availability on E120 and E320 routers with dual SRP modules, high availabilityis enabledonly for thecorresponding SRP modules. You must explicitlyspecify high availability for the line modules to enable stateful switchover of the line modules to occur.

Line module highavailability uses a 1:1 redundancy modelto maintainsubscriber sessions, during and after a switchover of the primary line module to the secondary line module. This feature is supported only on E120 and E320 routers installed with ES2 4G LMs and Service IOAs. You can enable line module high availability feature only on the compatible line modules and IOA combinations. On routers in which line module high availability is disabled or not available for configuration (cold-restart support is not present), all subscriber sessions are forcibly terminated when a line module fails or stops responding. This mechanism is known as a cold-restart.

Seamless Preservation of Subscriber Sessions

When thesecondary line module in the HAconfigurationbecomes theprimary linemodule, all the applications on it recover to a stable state to operate normally in the place of the failed line module. The new primary line module maintains existing subscriber sessions and continues to forward subscriber data traffic after the switchover. A brief subscriber data disconnection occurs for two minutes during the switchover. Diagnostic functions are still run on the failed line module to ensure that the hardware on the defective line module is still usable. The exception might have been triggered by a hardware fault that the diagnostic services might discover using its testing mechanism. For the stateful line module switchover to work correctly, the current subscriber information must be made accessible to thenewly configured primaryline module. The statesof subscriber sessions that were on the failed line module are mirrored to the secondary line module, which has taken over as the primary controller.

Only those subscriber sessions whose operational status is up are guaranteed to be retained. Other subscriber connections that are in the process of fluctuating between up and down statesmight not be preserved. Such atechnique ofnot retaining thesubscriber sessions that are constantlyalternating is adopted because of the possibility of occurrence of faults during transitional periods of states. If subscriber sessions in these transitional states are not preserved, the possibility of the same problem occurring on the secondary line module after the switchover is reduced.

Documentation

Stateful Line Module Switchover Overview on page 68•

• Stateful Line Module Switchover Platform Considerations on page 70

• System Operations When Stateful Line Module Switchover Is Enabled on page 74

Page 92

JunosE 11.3.x Service Availability Configuration Guide

Stateful Line Module Switchover Platform Considerations

Stateful SRP switchover is supported on all E120 and E320 routers that contain ES2 4G line modules installed withthe ES2-ES1Service IOA. Seethe E120 and E320 Module Guide for modules supported on the E120 and E320 Broadband Services Routers.

Table 15 on page 70 lists the line module, SRP module, and IOA slot combinations that support stateful switchover of line modules and stateful switchover for LNS sessions, when the router operates as an LNS device on one side of an L2TP tunnel.

Table 15: Module Configurations Supported for Stateful Switchover of LNS Sessions

Support for Stateful Switchover of LNS Sessions

Router Model

SRP and SFM Model

Number of L2TP tunnels and sessions

Number of Active and StandbyES2-ES1 Service IOAs

Downlink and Uplink LMs

SRP-100E320

SRP-320E320

SRP-320E120

Documentation

16,000 tunnels and 16,000 sessions

16,000 tunnels and 32,000 sessions

32,000 tunnels and 32,000 sessions

16,000 tunnels and 16,000 sessions

32,000 tunnels and 32,000 sessions

16,000 tunnels and 16,000 sessions

32,000 tunnels and 32,000 sessions

2 ServiceIOAs (1active and 1 standby)

4 Service IOAs (2active and 2 standby)

2 ServiceIOAs (1active and 1 standby)

4 Service IOAs (2active and 2 standby)

2 ServiceIOAs (1active and 1 standby)

4 Service IOAs (2active and 2 standby)

IOA

GE-8 IOA

SupportedES2 4G LM and GE-4

Not supportedES2 10G LM and

SupportedES2 10G LM and

Stateful Line Module Switchover Overview on page 68•

• System Operations When Stateful Line Module Switchover Is Enabled on page 74

• Replacement of Line Modules When Stateful Line Module Switchover Is Enabled on

page 77

• Application Support for Stateful Line Module Switchover on page 79

Guidelines for Configuring Stateful Line Module Switchover

Keepthe following points inmind when you configurestateful switchover for line modules:

Page 93

Chapter 4: Managing Stateful Line Module Switchover

•

Line module high availability, similar to dual SRP stateful switchover, does not to prevent the root cause of the reload or restart. This functionality is designed to return the system to the online, active state as soon as possible. The secondary line module takes the role of the primary module to preserve subscriber sessions in the up state with minimal subscriber data outage.

•

The architecture of line modules supports switchover simultaneously across multiple 1:1 sets of line modules that participate in line module high availability.

•

Line module high availability is available only on the operational image that runs on the interface controller (IC). The behavior of the forwarding controller (FC) image, and the IC boot and diagnostic images provide the same functionality as the behavior that existed before line module high availability support was implemented.

•

Line module high availability in a 1:1 redundancy model is supported for ES2 4G LMs and Service IOAs on E120 and E320 routers. The architecture of line module high availability ensures that it does not depend on high availability for SRP modules to be enabled and operational for stateful line module switchover to work. Similarly, any modifications made to the dual SRP stateful switchover settings do not require or depend on line module high availability to be enabled and operational.

•

Unified ISSU is supported on the primary line module in a high availability pair of line modules. The secondary line module is disabled during the unified ISSU operation and cold boots after the unified ISSU operation is complete. Line module high availability mode is active after the secondary line module is up, provided that line module HA configuration is enabled.

•

Applications that are configured on the router ensure that their defined settings and memory requirements are handled on E120 and E320 routers. The primary and secondary line modules in a high availability pair are determined using the slot information specified using the mode high-availability slot command in Redundancy Configuration mode.

•

Packets that are transmitted between the FC and IC and between the FC and system controller (SC) are not preserved during a stateful line module recovery.

•

1:N hot standby mode is not supported for stateful line module switchover. Automatic switchoverof the serial connection to the linemodule thatis designated as theprimary module after switchover is also not supported. Similarly, cold switchover is not supported if line module high availability is not configured.

•

Recovery of routers from double failures, such as simultaneous switchover of SRP and line modules, is not supported. Application-specific statistical details are not retained across a stateful line module switchover.

•

Subscriber sessions that constantly move between up and down states are not maintained across a stateful switchover.

•

If the line module that contains a downlink interface (connecting to the LAC device) reloads,owing tohardware or software failures, subscriber sessionsare notmaintained, even if the LM and Service IOA are HA-protected. Also, subscriber sessions are not retained if the line module that connects to the LAC device reloads, when the LM and Service IOA are part of a redundancy group.

Page 94

JunosE 11.3.x Service Availability Configuration Guide

•

ES2 10GLMs cannotbe used as downlink modules in an LNS device. These LMs cannot be used as access modules in a LNS device that contains a Service IOA that is HA-enabled.

•

Certain statistics might be lost during the period of the stateful line module switchover. PPP and policy statistics are polled and collected every 10 minutes and sent to the standby line module. The statistics that were last collected before the switchover occurredare used as the baseline forstatistics onthe newly configured primary module. At a maximum, statistics for around 10 minutes might be lost. This scenario normally happens when polling is about to happen and the primary module switched over.

•

A historical record of informationabout the forwarding anddrop events and forwarding and droprateson egressqueues is not retainedacross astateful line module switchover. The queue statistics for subscriber interfaces are calculated afresh after a stateful switchover of line modules.

•

Sequence number checking for data packets received on all L2TP tunnels in the router is not maintained and supported during a stateful line module switchover. We recommend that you set up the router to ignore sequence numbers in data packets received on L2TP tunnels by entering the l2tp ignore-receive-data-sequencing command on an LNS device to prevent requests from a LAC device to enable insertion of sequence numbers into data packets.

•

Some performance impact might occur when a new secondary module is provisioned or inserted, with the primary module containing maximum tunneled PPP sessions. In this case, data synchronization consumes a portion of the backplane bandwidth,which might have some impact on call setup rate (CSR) during this time. Under peak load conditions, it might take about 20 minutes for the system to become HA-active for Service IOAs.

•

Removal of the Service IOA from the primary ES2 4G LM without powering it down does not trigger stateful line module switchover.

•

The PPP application on ES2 4G LMs with Service IOA supports line module high availability. PPP session data is mirrored to the standby line module to attain high availability. The PPP application replicates the PPP sessions on the standby module and retains them across switchovers, in addition to accounting statistics. During line module switchover, the forwarding controller (FC) in the access module of the router that works as the LNS attempts to prevent timeouts of PPP sessions (due to the lack of PPP echo reply messages to the active subscribers) by sending echo response packets until the switchover is successfully completed.

•

Policy manager is stateful line module switchover safe. Policy manager downloads the policy attachmentsfrom theSRP tothe newly active linemodule after aswitchover operation is detected. Policy statistics are preserved and made available across line module switchovers.

•

The QoS application accomplishes the stateful line module switchover functionality by restoring the queues on subscriber interfaces in the newly active line module when the previously designated primary line module fails.

•

During stateful line module switchover, the forwarding controller (FC) in the access module on the routerfunctioning as the LNS device prevents timeouts of PPP sessions

Page 95

Chapter 4: Managing Stateful Line Module Switchover

owing to the absence of PPP echoreply messages inresponse toecho requests received from clients.

•

Only two pairs of primary and secondary line modules can be configured on a single chassis for stateful switchover. As a result, only two line modules can be HA-safe. If high availability is activated, when the secondary module takes over as the primary module, existing subscribers are retained. If high availability is not activated, when the primary linemodule fails, thestandby linemodule processesthe regularrouter functions, but previously active subscriber sessions are not retained.

•

Stateful line module switchover can be triggered when one of the following actions is performed on the primary line module, with high availability for line modules enabled on the router:

•

Disabling the module in the specified slot using the slot disable command

•

Rebooting a module in a selected slot on the router using the reload slot command

•

Performing a graceful switchover to the secondary line module using the line-card switch command

•

If both the primary and secondary modules are cold booted (for example, when a chassis is cold started), andif the primary module does not become onlinefor 8minutes, the secondary module takes the role of the primary module. This behavior is similar to the line module redundancy mechanism.

•

If high availability for line modules is active, the switchover is stateful. Subscribers are not disconnected and none of the existing client sessions are terminated or locked out during the line module switchover. A data traffic outage of about 2 minutes occurs, although subscribers are not disconnected. PPP echo requests from the subscribers are responded by the access module itself during the switchover period. This method works properly even if LAG interfaces are configured to connect to a LAC device.

•

Information related to line module switchover is not forwarded to applications such as the AAA or RADIUS servers. These modules are not requested again for any accounting or authorization information for the same subscribers that were connected during the time of switchover.

•

When the unified ISSU process is in progress, you cannot configure high availability for line modules if the initialization state of the unified ISSU operation has started. You must wait until the unified ISSU procedure is completed to enable high availability for line modules.

•

Line module highavailability does not interfere with the configurationsmade forunified ISSU and stateful SRP switchover functions. The secondary module in a line module high availability pair does not participate in the unified ISSU operation and is disabled during the upgrade process. The secondary module is cold started after the unified ISSU procedure iscompleted.However, the primary linemodule takes partin the unified ISSU process and undergoes a warm restart.

•

PPP-based stacks (L2TP, PPP, and IP applications) for both IPv4 and IPv6 interfaces support stateful line module switchover.

•

You can manually switch between the primary and secondary modules. While the secondary module attempts to take over as the primary module during a switchover,

Page 96

JunosE 11.3.x Service Availability Configuration Guide

if the secondary module fails to transition as the primary module within 5 minutes, the secondary module is cold booted.

•

SNMP traps are generated after the switchover of the primary line module.

•

Similar to dual SRP configuration and high availability of SRP modules, stateful line module recovery does not prevent the root cause that caused a router reload or stoppage of functioning. Stateful line module recovery enables the system to be returned to the fully functional state as soon as possible. If the conditions that caused the problem recur after a restart, an abrupt reload of the router might occur again. Stateful line module recovery minimizes forwarding impact on a restart to maximize customer uptime and causes the loss of packets during a restart to be limited to a small number of packets that are dropped in a timespan of a few seconds.

Documentation

System Operations When Stateful Line Module Switchover Is Enabled on page 74•

• Application Support for Stateful Line Module Switchover on page 79

• Stateful Line Module Switchover Modes on page 83

• Stateful Line Module Switchover States on page 84

• Guidelines for Activating High Availability on page 87

• Activating High Availability on page 88

• Guidelines for Deactivating High Availability on page 89

• Deactivating High Availability on page 89

System Operations When Stateful Line Module Switchover Is Enabled

Line modules on E120 and E320 routers comprise three components—forwarding controller (FC), interface controller (IC), and the input/output adapter (IOA). The IC operational image runs in the IC section and the FC operational image runs in the FC section. Each line module can be connected to multiple IOAs, although the IOA does not contain an active control processor and has no operational image running on it. The IOA has a control path to the IC, which is used to configure and preset the hardware on the IOA. The IOA has a data path between the FC and the IOA external connections. After the hardware in the IOA is configured, it transfers data between the FC and the IOA external connections.

Line module highavailability or statefulline moduleswitchoverbehavior refers to providing this functionality of uninterrupted connectivity for subscribers by switching over to the operational image running on the IC that is active on the secondary line module of a pair of modules enabled for high availability. The applications on the secondary line module recover to their original statesby reconstructingdata from thepreserved mirrored storage containers to a stable state. After the secondary line module is equipped to take over the load(services) of the primary line module, the switchover of subscriber traffic occurs on the secondary line module. The secondary line module begins to operate normally, although certain users might experience some subscriber data outage.

Page 97

Chapter 4: Managing Stateful Line Module Switchover

The design architecture used for E120 and E320 routers causes the packets that are designated for the SC to be first sent to the IC using a direct memory access (DMA) method. These packets are then forwarded to the SC over the internal 100 Mb Ethernet channel. Similarly, packets that are destined to be transmitted from the router are first sent to the IC over the Ethernet channel and then sent from the IC to the FC using a DMA operation. During the switchover period, until the secondary line module becomes operational, this communication channel from the IC is not active. The amount of time taken for the operational image on the secondary line module to start fully functioning can take up to several seconds.During this period of completionof the switchoverprocess, applicationson the SC handlethis timeout.Applications that areimpacted by this outage are routing protocols or protocols that are time-critical. For example, SRP-based TCP and UDP services are preserved across a switchover, which enables applications, such as Telnet, FTP, SSH, and SNMP, to operate seamlessly.

When the high availability functionality forline modules is active, subscriber sessions are maintained whenever a software or hardware fault is detected onthe primary line module. A briefinterruption occurs inthe subscriber data traffic duringthe time that thesecondary line module takes over as the primary line module.

Documentation

Stateful Line Module Switchover Overview on page 68•

• Guidelines for Configuring Stateful Line Module Switchover on page 70

• Stateful Line Module Switchover Platform Considerations on page 70

• Replacement of Line Modules When Stateful Line Module Switchover Is Enabled on

page 77

• Application Support for Stateful Line Module Switchover on page 79

• Stateful Line Module Switchover Modes on page 83

• Stateful Line Module Switchover States on page 84

• Activating High Availability on page 88

• Deactivating High Availability on page 89

Stateful Line Module Configuration Scenarios

The line module high availability functionality is based on the stateful SRP switchover design architecture, with the implementation extended to two pairs of line modules to function as the primary and secondary module. This section describes the behavior of different system functions when line module high availability is configured on the router.

High Availability Configured and Enabled on the Line Module

If line module high availability is configured and the state is active, when a fault occurs on the primary line module, the primary line module performs a warm switchover to a secondary module. After the switchover, the secondary module starts operating as the new primary module. The previously configured primary module, after it becomes operational, takes over the role of the secondary module.

Page 98

JunosE 11.3.x Service Availability Configuration Guide

When high availability is enabled on a router, the secondary module takes over the role of the primary module, which causes normal system services and subscriber data traffic to continue without interruption after a switchover. The system controller (SC) on E120 and E320routers is referredto asthe SRP module and the main processor in a linemodule is called the interface controller (IC).

High Availability Configured and Disabled on the Line Module

If linemodule high availabilityis configured and the state isnot active, when a faultoccurs on the primary line module, the primary line module performs a cold switchover to a secondary module. After the switchover, the secondary module starts operating as the new primary module. The previously configured primary module, after it becomes operational, takes over the role of the secondary module. Subscribers are disconnected and need to log in again to establish their connections again. This behavior is similar to the functionality experienced during the line module redundancy operation.

High Availability Configured and the Switchover State Is Active or Disabled

Any failureon the secondary line module ora restart ofthe modulecauses high availability to move to the disabled state. The show redundancy line-card command displays the HA status on all line modules in the system. When a line module transitions from one state to another, log messages are seen on the SRP console and SNMP traps, if enabled, are sent.

All CLI commands that cause the line module to cold restart behave in the same manner, except for the method adopted to trigger the switchover action. For example, the reload slot and slot disable commands that reloada primary line module,causing the secondary module to take over as the primary. However, the slot erase command clears the configurations on the line module that is fitted in that slot. If you erase the slot configuration for a primary line module, both the primary and secondary line modules that participate in HA are cold booted. Ifyou erase theslot configuration for the secondary line module, only that module is cold booted and the primary module is not cold booted.

If you enter the reload slot command, after booting up, line modules start operating in HA mode. With the slot disable command, HA is disabled until you reenable the slot.

Rebooting of the System When Line Module High Availability Is Configured

The line modules undergo a cold start, when the router is rebooted, and the secondary line module is held in a state in which it is not online. The primary line module reaches the online state. If the primary line module fails to come up online, within the specified timeout value (of less than 8.5 minutes), the secondary line module takes over as the primary module and HA remains in the disabled state.

Stateful SRP Switchover

During a stateful SRP switchover, a window of time occurs when the communication between interface controllers (IC) is disrupted owing to the switchover to new SRP module, which requires the Ethernet switch to relearn the MAC addresses and the interchassiscommunication (ICC) sessions to be reestablished. The system infrastructure ensures this task ofrelearning of details is transparent to the applications. Any notification sent by the applications on the IC-IC communication is either buffered until the

Page 99

communication is reestablished. Otherwise, the Ethernet switch on the standby SRP module that has become active learns the MAC addresses in standby mode without interrupting the IC-IC communication.

Line Module Redundancy

Line module redundancy andline modulehigh availability are mutually exclusive features. You cannot configure the line modules in a redundancy group to operate in HA mode. Because both the mechanisms are mutually exclusive, if a module is a member of a redundancy group, warm switchover is not supported. Similarly, if line modules are configured in a high availability pair, they cannot be members of a redundancy group and the spare module does not take over as the primary.

Unified ISSU

Unified ISSU can continue, if the configured secondary line module takes over as the primary line module. The secondary line module is disabled during the upgrade phase of the unified ISSU operation and cold boots after the unified ISSU operation is complete. The disabled line module during unified ISSU is cold booted after the unified ISSU operation is complete. Only the primary line module can participate in a unified ISSU operation.

Chapter 4: Managing Stateful Line Module Switchover

Documentation

Replacement of Line Modules When Stateful Line Module Switchover Is Enabled on

•

page 77

• Application Support for Stateful Line Module Switchover on page 79

• Stateful Line Module Switchover Modes on page 83

• Stateful Line Module Switchover States on page 84

• slot erase

• slot disable

• reload slot

Replacement of Line Modules When Stateful Line Module Switchover Is Enabled

You can use the show version command to view the status of the SRP modules and line modules, as well as the running and armed releases. The state field in the output of this command indicates whether the slot that contains the redundant line module indicates standby or is restarting. Any CLI or SNMP command that the system attempts toprocess at the time of restart or recovery of the line module might fail. If you configured the ha logging event category (usingthe logseverity severityValue ha command), log messages are displayed to specify that the line module has warm restarted or cold started. Depending on the nature of failures, the line modules that participate in HA take the following actions:

Reloading the Primary Line Module in Response to Failures

When a software fault occurs on the primary line module or if you enter the slot disable or reload slot commands for the slot in which the primary line module is installed, the

Page 100

JunosE 11.3.x Service Availability Configuration Guide

secondary line module takes overby recoveringall the applications running on the primary module to a stable state. After the secondary module takes over, traffic starts flowing through the secondary module. TheFC and IOAs on the faulty linemodule are cold booted along with the IC. When you use the slot disable command for a slot that contains a line module, you disable only the line module; you do not disable the line module and IOAs associated with it.

Reloading the Secondary Line Module in Response to Failures

When asoftware fault occurs onthe secondaryline module or if you enter theslot disable or reload slot commands for the slot in which the secondary line module is installed, the secondary line module undergoes a cold boot. After the secondary module becomes operational, the reloaded module continues to function as the secondary line module. Any core dumpsthat aregeneratedon the faultyline module are sent to theSRP module, which is the same behavior as the one that occurs when a line module that is not configuredfor HAresets. When you use the slot disable command for a slotthat contains a line module, you disable only the line module; you do not disable the line module and IOAs associated with it.

Disabling the Primary and Secondary Line Module Slots

If you specify the slot erase command on the primary line module to delete the configuration of the module in the selected slot before you install a different type of module, both the primary and secondary line modules are cold booted and line module high availability is disabled after the modules become operational again. If you enter the slot erase command on the secondary line module, only that module is cold booted and line module high availability is disabled.

Reloading the Router When Line Modules Enabled for HA Are Installed

If you enter the reload command on the router to restart the device with the currently available configuration, the previously configured roles of the primary and secondary line modules are preserved. SRP modules reload all line modules and restart form saved configurationfiles. However, any failure ofthe primaryline module to become operational after the prescribed timeout duration causes the secondary module to take over as the primary.

Removing IOAs Without Powering Down from Line Modules

Removal of an IOA from the primary line module without powering down the IOA does not trigger line module switchover. Removal of an IOA from the secondary line module does not cause the module to be cold started. In both such scenarios, we recommend that you perform ahot-swap ofthe IOA in a managed environment whenhigh availability is configured on the line module pair.

Cold and Warm Switchovers of Line Modules In a High Availability Pair

Cold switchover ofthe line module results in the same behavior as the system operations that are witnessed with line module redundancy configured on a router. With both these features, all the existing subscriber sessions are lost during the switchover.

When a warm switchover of the line module in a high availability pair occurs, subscriber sessions are not lost during the switchover.

Juniper JUNOSE SOFTWARE FOR E SERIES 11.3.X - SERVICE AVAILABILITY CONFIGURATION GUIDE 2010-10-08, JUNOSE 11.3 Configuration Manual

Specifications and Main Features

Frequently Asked Questions

User Manual