Junos® OS

Chassis Cluster Feature Guide for Branch SRX

Series Devices

Release

15.1X49-D40

Modified: 2016-06-24

Copyright © 2016, Juniper Networks, Inc.

Juniper Networks, Inc.
1133 Innovation Way
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.

®
Junos OS Chassis Cluster Feature Guide for Branch SRX Series Devices
15.1X49-D40
Copyright © 2016, Juniper Networks, Inc.
All rights reserved.

The information in this document is current as of the date on the title page.

YEAR 2000 NOTICE

Juniper Networks hardware and software products are Year 2000 compliant. 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.

END USER LICENSE AGREEMENT

The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks
software. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at
http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions of
that EULA.

ii Copyright © 2016, Juniper Networks, Inc.

Table of Contents
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Using the Examples in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Merging a Full Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Merging a Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

Part 1 Overview
Chapter 1 Introduction to Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chassis Cluster Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
High Availability Using Chassis Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
How High Availability Is Achieved by Chassis Cluster . . . . . . . . . . . . . . . . . . . . 3
Chassis Cluster Active/Active and Active/Passive Modes . . . . . . . . . . . . . . . . . 4
Chassis Cluster Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
IPv6 Clustering Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Chassis Cluster Supported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Chassis Cluster Features Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Chassis Cluster Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Chapter 2 Understanding Chassis Cluster License Requirements . . . . . . . . . . . . . . . . . 29
Understanding Chassis Cluster Licensing Requirements . . . . . . . . . . . . . . . . . . . . 29
Installing Licenses on the Devices in a Chassis Cluster . . . . . . . . . . . . . . . . . . . . . 30
Verifying Licenses for an SRX Series Device in a Chassis Cluster . . . . . . . . . . . . . . 32
Chapter 3 Planning Your Chassis Cluster Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 35
Preparing Your Equipment for Chassis Cluster Formation . . . . . . . . . . . . . . . . . . . 35
SRX Series Chassis Cluster Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . 36

Part 2 Setting Up Chassis Cluster in SRX Series Devices

Chapter 4 Chassis Cluster Physical Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Connecting SRX Series Devices to Create a Chassis Cluster . . . . . . . . . . . . . . . . . 43

Copyright © 2016, Juniper Networks, Inc. iii

Chassis Cluster Feature Guide for Branch SRX Series Devices

Chapter 5 Setting Up Chassis Cluster Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port
and Logical Interface Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Example: Setting the Chassis Cluster Node ID and Cluster ID for Branch SRX
Series Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Chapter 6 Setting Up Chassis Cluster Management Interfaces . . . . . . . . . . . . . . . . . . . 53
Management Interface on an Active Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . 53
Example: Configuring the Chassis Cluster Management Interface . . . . . . . . . . . . 53
Chapter 7 Setting Up Fabric Interfaces on a Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . 57
Understanding Chassis Cluster Fabric Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Understanding Chassis Cluster Fabric Links . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Understanding Session RTOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Understanding Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Understanding Fabric Data Link Failure and Recovery . . . . . . . . . . . . . . . . . . 59
Example: Configuring the Chassis Cluster Fabric Interfaces . . . . . . . . . . . . . . . . . . 61
Verifying Chassis Cluster Data Plane Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Verifying Chassis Cluster Data Plane Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Clearing Chassis Cluster Data Plane Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Chapter 8 Setting Up Control Plane Interfaces on a Chassis Cluster . . . . . . . . . . . . . . 65
Understanding Chassis Cluster Control Plane and Control Links . . . . . . . . . . . . . 65
Understanding the Chassis Cluster Control Plane . . . . . . . . . . . . . . . . . . . . . 65
Understanding Chassis Cluster Control Links . . . . . . . . . . . . . . . . . . . . . . . . . 66
Verifying Chassis Cluster Control Plane Statistics . . . . . . . . . . . . . . . . . . . . . . . . . 66
Clearing Chassis Cluster Control Plane Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Chapter 9 Setting Up Chassis Cluster Redundancy Groups . . . . . . . . . . . . . . . . . . . . . . 69
Understanding Chassis Cluster Redundancy Groups . . . . . . . . . . . . . . . . . . . . . . . 69
Understanding Chassis Cluster Redundancy Group 0: Routing Engines . . . . 70
Understanding Chassis Cluster Redundancy Groups 1 Through 128 . . . . . . . . 71
Example: Configuring Chassis Cluster Redundancy Groups . . . . . . . . . . . . . . . . . . 73
Chapter 10 Setting Up Chassis Cluster Redundant Ethernet Interfaces . . . . . . . . . . . . . 77
Understanding Chassis Cluster Redundant Ethernet Interfaces . . . . . . . . . . . . . . 77
Example: Configuring Chassis Cluster Redundant Ethernet Interfaces for IPv4
and IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Example: Configuring the Number of Redundant Ethernet Interfaces in a Chassis
Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Chapter 11 Configuring Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Example: Configuring an SRX Series Services Gateway for the Branch as a Chassis
Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Verifying a Chassis Cluster Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Verifying Chassis Cluster Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Clearing Chassis Cluster Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

iv Copyright © 2016, Juniper Networks, Inc.

 Table of Contents

Part 3 Managing Chassis Cluster Operations

Chapter 12 Monitoring Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Understanding Chassis Cluster Redundancy Group Interface Monitoring . . . . . . 105
Example: Configuring Chassis Cluster Interface Monitoring . . . . . . . . . . . . . . . . . 106
Understanding Chassis Cluster Redundancy Group IP Address Monitoring . . . . . 133
Example: Configuring Chassis Cluster Redundancy Group IP Address
Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Chapter 13 Managing Chassis Cluster Redundancy Group Failover . . . . . . . . . . . . . . . . 141
Understanding Chassis Cluster Redundancy Group Failover . . . . . . . . . . . . . . . . . 141
Example: Configuring a Chassis Cluster with a Dampening Time Between
Back-to-Back Redundancy Group Failovers . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Understanding Chassis Cluster Redundancy Group Manual Failover . . . . . . . . . . 143
Understanding SNMP Failover Traps for Chassis Cluster Redundancy Group
Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Initiating a Chassis Cluster Manual Redundancy Group Failover . . . . . . . . . . . . . 146
Verifying Chassis Cluster Failover Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Clearing Chassis Cluster Failover Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Chapter 14 Configuring Chassis Cluster Dual Fabric Links to Increase Redundancy
and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Understanding Chassis Cluster Dual Fabric Links . . . . . . . . . . . . . . . . . . . . . . . . . 151
Example: Configuring the Chassis Cluster Dual Fabric Links with Matching Slots
and Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Example: Configuring Chassis Cluster Dual Fabric Links with Different Slots and
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Chapter 15 Configuring Route Advertisement over Redundant Ethernet Interfaces in
a Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Understanding Conditional Route Advertising in a Chassis Cluster . . . . . . . . . . . 159
Example: Configuring Conditional Route Advertising in a Chassis Cluster . . . . . . 160
Chapter 16 Configuring Redundant Ethernet LAG Interfaces for Increasing High
Availability and Overall Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Understanding Chassis Cluster Redundant Ethernet Interface Link Aggregation
Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Example: Configuring Chassis Cluster Redundant Ethernet Interface Link
Aggregation Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Understanding Chassis Cluster Redundant Ethernet Interface LAG Failover . . . . 170
Scenario 1: Monitored Interface Weight Is 255 . . . . . . . . . . . . . . . . . . . . . . . . . 171
Scenario 2: Monitored Interface Weight Is 75 . . . . . . . . . . . . . . . . . . . . . . . . . 172
Scenario 3: Monitored Interface Weight Is 100 . . . . . . . . . . . . . . . . . . . . . . . . 172
Understanding LACP on Chassis Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups . . . 173
Minimum Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Sub-LAGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Supporting Hitless Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Managing Link Aggregation Control PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Example: Configuring LACP on Chassis Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Example: Configuring Chassis Cluster Minimum Links . . . . . . . . . . . . . . . . . . . . . 178

Copyright © 2016, Juniper Networks, Inc. v

Chassis Cluster Feature Guide for Branch SRX Series Devices

Chapter 17 Simplifying Chassis Cluster Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Understanding Automatic Chassis Cluster Synchronization Between Primary
and Secondary Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Verifying Chassis Cluster Configuration Synchronization Status . . . . . . . . . . . . . 182
NTP Time Synchronization on SRX Series Devices . . . . . . . . . . . . . . . . . . . . . . . . 183
Simplifying Network Management by Synchronizing the Primary and Backup
Routing Engines with NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Part 4 Additional Chassis Cluster Configurations

Chapter 18 Configuring Active/Passive Chassis Cluster Deployments . . . . . . . . . . . . . 193
Understanding Active/Passive Chassis Cluster Deployment . . . . . . . . . . . . . . . . 193
Example: Configuring an Active/Passive Chassis Cluster Pair (CLI) . . . . . . . . . . . 194
Example: Configuring an Active/Passive Chassis Cluster Pair (J-Web) . . . . . . . . 205
Understanding Active/Passive Chassis Cluster Deployment with an IPsec
Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Example: Configuring an Active/Passive Chassis Cluster Pair with an IPsec
Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Example: Configuring an Active/Passive Chassis Cluster Pair with an IPsec Tunnel
(J-Web) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Chapter 19 Enabling Multicast Routing or Asymmetric Routing . . . . . . . . . . . . . . . . . . . 227
Understanding Multicast Routing on a Chassis Cluster . . . . . . . . . . . . . . . . . . . . 227
Understanding PIM Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Understanding Multicast and PIM Session Synchronization . . . . . . . . . . . . . 228
Understanding Asymmetric Routing Chassis Cluster Deployment . . . . . . . . . . . 228
Understanding Failures in the Trust Zone Redundant Ethernet Interface . . 229
Understanding Failures in the Untrust Zone Interfaces . . . . . . . . . . . . . . . . . 229
Example: Configuring an Asymmetric Chassis Cluster Pair . . . . . . . . . . . . . . . . . 230
Chapter 20 Configuring Chassis Cluster Layer 2 Ethernet Switching . . . . . . . . . . . . . . . 243
Layer 2 Ethernet Switching Capability in Chassis Cluster Mode . . . . . . . . . . . . . 243
Understanding Layer 2 Ethernet Switching Capability in Chassis Cluster on
SRX Series Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Understanding Chassis Cluster Failover and New Primary Election . . . . . . . 244
Example: Configuring Switch Fabric Interfaces to Enable Switching in Chassis
Cluster Mode (CLI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Example: Configuring IRB and VLAN with Members Across Two Nodes (CLI) . . 246
Example: Configuring Aggregated Ethernet Device with LAG and LACP (CLI) . . 248

Part 5 Upgrading or Disabling Chassis Cluster

Chapter 21 Upgrading Both Devices Separately . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Upgrading Individual Devices in a Chassis Cluster Separately . . . . . . . . . . . . . . . 253
Chapter 22 Upgrading Both Devices Using ICU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Upgrading Devices in a Chassis Cluster Using ICU . . . . . . . . . . . . . . . . . . . . . . . . 255
Upgrading Both Devices in a Chassis Cluster Using ICU . . . . . . . . . . . . . . . . 255
Upgrading ICU Using a Build Available Locally on a Primary Node in a Chassis
Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

vi Copyright © 2016, Juniper Networks, Inc.

 Table of Contents

Upgrading ICU Using a Build Available on an FTP Server . . . . . . . . . . . . . . . 256

Aborting an Upgrade in a Chassis Cluster During an ICU . . . . . . . . . . . . . . . . 257
Chapter 23 Disabling Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Disabling Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Part 6 Configuration Statements and Operational Commands

Chapter 24 Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Chassis Configuration Statement Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Security Configuration Statement Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
apply-groups (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
cluster (Chassis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
configuration-synchronize (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
control-link-recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
device-count (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
ethernet (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
fabric-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
gigether-options (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
global-threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
global-weight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
gratuitous-arp-count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
heartbeat-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
heartbeat-threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
hold-down-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
interface (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
interface-monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
ip-monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
lacp (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
link-protection (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
member-interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
network-management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
node (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
node (Chassis Cluster Redundancy Group) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
preempt (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
priority (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
redundancy-group (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
redundancy-interface-process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
redundant-ether-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
redundant-parent (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
redundant-pseudo-interface-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
reth-count (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
reth (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
retry-count (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
retry-interval (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
route-active-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
traceoptions (Chassis Cluster) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
weight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Copyright © 2016, Juniper Networks, Inc. vii

Chassis Cluster Feature Guide for Branch SRX Series Devices

Chapter 25 Operational Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

clear chassis cluster control-plane statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
clear chassis cluster data-plane statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
clear chassis cluster failover-count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
clear chassis cluster ip-monitoring failure-count . . . . . . . . . . . . . . . . . . . . . . . . . . 311
clear chassis cluster ip-monitoring failure-count ip-address . . . . . . . . . . . . . . . . 312
clear chassis cluster statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
request chassis cluster configuration-synchronize . . . . . . . . . . . . . . . . . . . . . . . . 314
request chassis cluster failover node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
request chassis cluster failover redundancy-group . . . . . . . . . . . . . . . . . . . . . . . . 316
request chassis cluster failover reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
request chassis fpc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
request system software in-service-upgrade (Maintenance) . . . . . . . . . . . . . . . 319
set chassis cluster cluster-id node reboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
show chassis cluster control-plane statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
show chassis cluster data-plane interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
show chassis cluster data-plane statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
show chassis cluster ethernet-switching interfaces . . . . . . . . . . . . . . . . . . . . . . . 329
show chassis cluster ethernet-switching status . . . . . . . . . . . . . . . . . . . . . . . . . 330
show chassis cluster information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
show chassis cluster information configuration-synchronization . . . . . . . . . . . . 336
show chassis cluster interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
show chassis cluster ip-monitoring status redundancy-group . . . . . . . . . . . . . . 343
show chassis cluster statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
show chassis cluster status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
show chassis environment (Security) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
show chassis ethernet-switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
show chassis fabric plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
show chassis fabric plane-location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
show chassis fabric summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
show chassis hardware (View) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
show chassis routing-engine (View) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
show configuration chassis cluster traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . 402

Part 7 Index
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

viii Copyright © 2016, Juniper Networks, Inc.

List of Figures
Part 1 Overview
Chapter 3 Planning Your Chassis Cluster Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 1: Chassis Cluster Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Part 2 Setting Up Chassis Cluster in SRX Series Devices

Chapter 4 Chassis Cluster Physical Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 2: Connecting SRX Series Devices in a Cluster (SRX300 Devices) . . . . . . . 44
Figure 3: Connecting SRX Series Devices in a Cluster (SRX320 Devices) . . . . . . . 44
Figure 4: Connecting SRX Series Devices in a Cluster (SRX340 Devices) . . . . . . . 44
Figure 5: Connecting SRX Series Devices in a Cluster (SRX345 Devices) . . . . . . . 44
Figure 6: Connecting SRX Series Devices in a Cluster (SRX550 Devices) . . . . . . . 44
Figure 7: Connecting SRX Series Devices in a Cluster (SRX1500 Devices) . . . . . . 45
Chapter 5 Setting Up Chassis Cluster Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 8: Slot Numbering in an SRX Series Chassis Cluster (SRX300
Devices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 9: Slot Numbering in an SRX Series Chassis Cluster (SRX320 Devices) . . 50
Figure 10: Slot Numbering in an SRX Series Chassis Cluster (SRX340
Devices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 11: Slot Numbering in an SRX Series Chassis Cluster (SRX345 Devices) . . 50
Figure 12: Slot Numbering in an SRX Series Chassis Cluster (SRX550
Devices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 13: Slot Numbering in an SRX Series Chassis Cluster (SRX1500
Devices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Chapter 11 Configuring Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figure 14: SRX Series for the Branch Topology Example . . . . . . . . . . . . . . . . . . . . 89

Part 3 Managing Chassis Cluster Operations

Chapter 12 Monitoring Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Figure 15: SRX Series Chassis Cluster Interface Monitoring Topology
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Chapter 15 Configuring Route Advertisement over Redundant Ethernet Interfaces in
a Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Figure 16: Conditional Route Advertising . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Figure 17: Conditional Route Advertising . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Chapter 17 Simplifying Chassis Cluster Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Figure 18: Synchronizing Time from the Peer Routing Engine Using fxp0 . . . . . . 184

Copyright © 2016, Juniper Networks, Inc. ix

Chassis Cluster Feature Guide for Branch SRX Series Devices

Figure 19: Synchronizing Time from the NTP Server Using fxp0 . . . . . . . . . . . . . . 185

Part 4 Additional Chassis Cluster Configurations

Chapter 18 Configuring Active/Passive Chassis Cluster Deployments . . . . . . . . . . . . . 193
Figure 20: Active/Passive Chassis Cluster Scenario . . . . . . . . . . . . . . . . . . . . . . . 194
Figure 21: Active/Passive Chassis Cluster Topology . . . . . . . . . . . . . . . . . . . . . . . 195
Figure 22: Active/Passive Chassis Cluster with IPsec Tunnel Scenario (SRX Series
Devices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Figure 23: Active/Passive Chassis Cluster with IPsec Tunnel Topology (SRX
Series Devices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Chapter 19 Enabling Multicast Routing or Asymmetric Routing . . . . . . . . . . . . . . . . . . . 227
Figure 24: Asymmetric Routing Chassis Cluster Scenario . . . . . . . . . . . . . . . . . . 229
Figure 25: Asymmetric Routing Chassis Cluster Topology . . . . . . . . . . . . . . . . . . . 231
Chapter 20 Configuring Chassis Cluster Layer 2 Ethernet Switching . . . . . . . . . . . . . . . 243
Figure 26: Layer 2 Ethernet Switching Across Chassis Cluster Nodes . . . . . . . . . 244

x Copyright © 2016, Juniper Networks, Inc.

List of Tables
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Part 1 Overview
Chapter 1 Introduction to Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Table 3: Features Supported on a Branch SRX Series Device in a Chassis
Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Table 4: Chassis Cluster Feature Support on Branch SRX Series Devices . . . . . . . 23

Part 2 Setting Up Chassis Cluster in SRX Series Devices

Chapter 5 Setting Up Chassis Cluster Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Table 5: SRX Series Built-in Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Table 6: SRX Series Chassis Cluster Slot Numbering and Physical Port and
Logical Interface Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Chapter 9 Setting Up Chassis Cluster Redundancy Groups . . . . . . . . . . . . . . . . . . . . . . 69
Table 7: Example of Redundancy Groups in a Chassis Cluster . . . . . . . . . . . . . . . . 72
Chapter 10 Setting Up Chassis Cluster Redundant Ethernet Interfaces . . . . . . . . . . . . . 77
Table 8: Maximum Number of Redundant Ethernet Interfaces Allowed . . . . . . . . 78
Chapter 11 Configuring Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Table 9: SRX Series Services Gateways Interface Renumbering . . . . . . . . . . . . . . 89
Table 10: SRX Series Services Gateways for the Branch Interface Settings . . . . . 90

Part 4 Additional Chassis Cluster Configurations

Chapter 18 Configuring Active/Passive Chassis Cluster Deployments . . . . . . . . . . . . . 193
Table 11: Group and Chassis Cluster Configuration Parameters . . . . . . . . . . . . . . 196
Table 12: Chassis Cluster Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . 196
Table 13: Security Zone Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . 197
Table 14: Security Policy Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . 197
Table 15: Group and Chassis Cluster Configuration Parameters . . . . . . . . . . . . . . 210
Table 16: Chassis Cluster Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . 210
Table 17: IKE Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Table 18: IPsec Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Table 19: Static Route Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 212
Table 20: Security Zone Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . 212
Table 21: Security Policy Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . 212

Copyright © 2016, Juniper Networks, Inc. xi

Chassis Cluster Feature Guide for Branch SRX Series Devices

Chapter 19 Enabling Multicast Routing or Asymmetric Routing . . . . . . . . . . . . . . . . . . . 227

Table 22: Group and Chassis Cluster Configuration Parameters . . . . . . . . . . . . . . 231
Table 23: Chassis Cluster Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . 232
Table 24: Security Zone Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . 232
Table 25: Security Policy Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . 233

Part 5 Upgrading or Disabling Chassis Cluster

Chapter 22 Upgrading Both Devices Using ICU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Table 26: request system software in-service-upgrade Output Fields . . . . . . . . 258

Part 6 Configuration Statements and Operational Commands

Chapter 25 Operational Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Table 27: show chassis cluster control-plane statistics Output Fields . . . . . . . . 324
Table 28: show chassis cluster data-plane interfaces Output Fields . . . . . . . . . 326
Table 29: show chassis cluster data-plane statistics Output Fields . . . . . . . . . . 327
Table 30: show chassis cluster ethernet-switching interfaces Output Fields . . . 329
Table 31: show chassis cluster ethernet-switching status Output Fields . . . . . . 330
Table 32: show chassis cluster information Output Fields . . . . . . . . . . . . . . . . . . 332
Table 33: show chassis cluster information configuration-synchronization Output
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Table 34: show chassis cluster interfaces Output Fields . . . . . . . . . . . . . . . . . . . 338
Table 35: show chassis cluster ip-monitoring status Output Fields . . . . . . . . . . 343
Table 36: show chassis cluster ip-monitoring status redundancy group Reason
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Table 37: show chassis cluster statistics Output Fields . . . . . . . . . . . . . . . . . . . . 346
Table 38: show chassis cluster status Output Fields . . . . . . . . . . . . . . . . . . . . . . 350
Table 39: show chassis environment Output Fields . . . . . . . . . . . . . . . . . . . . . . . 353
Table 40: show chassis ethernet-switch Output Fields . . . . . . . . . . . . . . . . . . . . 357
Table 41: show chassis fabric plane Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 361
Table 42: show chassis fabric plane-location Output Fields . . . . . . . . . . . . . . . . 367
Table 43: show chassis fabric summary Output Fields . . . . . . . . . . . . . . . . . . . . 369
Table 44: show chassis hardware Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Table 45: show chassis routing-engine Output Fields . . . . . . . . . . . . . . . . . . . . . 399
Table 46: show configuration chassis cluster traceoptions Output Fields . . . . . 402

xii Copyright © 2016, Juniper Networks, Inc.

About the Documentation

• Documentation and Release Notes on page xiii

• Supported Platforms on page xiii
• Using the Examples in This Manual on page xiii
• Documentation Conventions on page xv
• Documentation Feedback on page xvii
• Requesting Technical Support on page xvii

Documentation and 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/.

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

Juniper Networks Books publishes books by Juniper Networks engineers and subject
matter experts. These books go beyond the technical documentation to explore the
nuances of network architecture, deployment, and administration. The current list can
be viewed at http://www.juniper.net/books.

Supported Platforms

For the features described in this document, the following platforms are supported:

• SRX Series

• vSRX

Using the Examples in This Manual

If you want to use the examples in this manual, you can use the load merge or the load
merge relative command. These commands cause the software to merge the incoming
configuration into the current candidate configuration. The example does not become
active until you commit the candidate configuration.

If the example configuration contains the top level of the hierarchy (or multiple
hierarchies), the example is a full example. In this case, use the load merge command.

Copyright © 2016, Juniper Networks, Inc. xiii

Chassis Cluster Feature Guide for Branch SRX Series Devices

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

Merging a Full Example

To merge a full example, follow these steps:

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

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

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

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

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

Merging a Snippet
To merge a snippet, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration snippet into a text
file, save the file with a name, and copy the file to a directory on your routing platform.

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

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

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

xiv Copyright © 2016, Juniper Networks, Inc.

 About the Documentation

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

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

[edit system scripts]

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

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

Documentation Conventions

Table 1 on page xv defines notice icons used in this guide.

Table 1: Notice Icons

Icon Meaning Description

Informational note Indicates important features or instructions.

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

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

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

Tip Indicates helpful information.

Best practice Alerts you to a recommended use or implementation.

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

Table 2: Text and Syntax Conventions

Convention Description Examples

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

user@host> configure

Copyright © 2016, Juniper Networks, Inc. xv

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 2: Text and Syntax Conventions (continued)

Convention Description Examples

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

Italic text like this • Introduces or emphasizes important • A policy term is a named structure
new terms. that defines match conditions and
• Identifies guide names. actions.
• Junos OS CLI User Guide
• Identifies RFC and Internet draft titles.
• RFC 1997, BGP Communities Attribute

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

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

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

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

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

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

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

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

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

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

xvi Copyright © 2016, Juniper Networks, Inc.

 About the Documentation

Table 2: Text and Syntax Conventions (continued)

Convention Description Examples

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

Documentation Feedback

We encourage you to provide feedback, comments, and suggestions so that we can

improve the documentation. You can provide feedback by using either of the following
methods:

• Online feedback rating system—On any page of the Juniper Networks TechLibrary site
at http://www.juniper.net/techpubs/index.html, simply click the stars to rate the content,
and use the pop-up form to provide us with information about your experience.
Alternately, you can use the online feedback form at
http://www.juniper.net/techpubs/feedback/.

• E-mail—Send your comments to [email protected]. Include the document

or topic name, URL or page number, and software version (if applicable).

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical Assistance
Center (JTAC). If you are a customer with an active J-Care or Partner Support Service
support contract, or are covered under warranty, and need post-sales technical support,
you can access our tools and resources online or open a case with JTAC.

• JTAC policies—For a complete understanding of our JTAC procedures and policies,

review the JTAC User Guide located at
http://www.juniper.net/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/

Copyright © 2016, Juniper Networks, Inc. xvii

Chassis Cluster Feature Guide for Branch SRX Series Devices

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

http://kb.juniper.net/InfoCenter/

• Join and participate in the Juniper Networks Community Forum:

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

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

To verify service entitlement by product serial number, use our Serial Number Entitlement
(SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/

Opening a Case with JTAC

You can open a case with JTAC on the Web or by telephone.

• Use the Case Management tool in the CSC at http://www.juniper.net/cm/.

• Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, see

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

xviii Copyright © 2016, Juniper Networks, Inc.

PART 1

Overview
• Introduction to Chassis Cluster on page 3
• Understanding Chassis Cluster License Requirements on page 29
• Planning Your Chassis Cluster Configuration on page 35

Copyright © 2016, Juniper Networks, Inc. 1

Chassis Cluster Feature Guide for Branch SRX Series Devices

2 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 1

Introduction to Chassis Cluster

• Chassis Cluster Overview on page 3

• Chassis Cluster Supported Features on page 5
• Chassis Cluster Limitations on page 25

Chassis Cluster Overview

Supported Platforms SRX Series, vSRX

• High Availability Using Chassis Clusters on page 3

• How High Availability Is Achieved by Chassis Cluster on page 3
• Chassis Cluster Active/Active and Active/Passive Modes on page 4
• Chassis Cluster Functionality on page 4
• IPv6 Clustering Support on page 4

High Availability Using Chassis Clusters

Modern networks require high availability. In order to accommodate this requirement,
Juniper Networks SRX Series Services Gateways can be configured to operate in cluster
mode, where a pair of devices can be connected together and configured to operate like
a single node, providing device, interface, and service level redundancy.

When configured as a chassis cluster, the two nodes back up each other, with one node
acting as the primary device and the other as the secondary device, ensuring stateful
failover of processes and services in the event of system or hardware failure. If the primary
device fails, the secondary device takes over processing of traffic.

How High Availability Is Achieved by Chassis Cluster

• The network node redundancy is achieved by grouping a pair of the same kind of
supported SRX Series devices into a cluster.

• The devices must be running the same version of the Junos operating system (Junos
OS).

• SRX Series devices must be the same model.

Copyright © 2016, Juniper Networks, Inc. 3

Chassis Cluster Feature Guide for Branch SRX Series Devices

• The control ports on the respective nodes are connected to form a control plane that
synchronizes the configuration and kernel state to facilitate the high availability of
interfaces and services.

• The data plane on the respective nodes is connected over the fabric ports to form a
unified data plane. The fabric link allows for the management of cross-node flow
processing and for the management of session redundancy.

Chassis Cluster Active/Active and Active/Passive Modes

A chassis cluster in active/active mode has transit traffic passing through both nodes of
the cluster all of the time. Whereas a chassis cluster in active/passive mode only has
transit traffic passing through the primary node while the backup node waits in hot
standby.

The data plane software operates in active/active mode. In a chassis cluster, session
information is updated as traffic traverses either device, and this information is transmitted
between the nodes over the fabric link to guarantee that established sessions are not
dropped when a failover occurs. In active/active mode, it is possible for traffic to ingress
the cluster on one node and egress from the other node.

The control plane software operates in active or backup mode.

Chassis Cluster Functionality

Chassis cluster functionality includes:

• Resilient system architecture, with a single active control plane for the entire cluster
and multiple Packet Forwarding Engines. This architecture presents a single device
view of the cluster.

• Synchronization of configuration and dynamic runtime states between nodes within

a cluster.

• Monitoring of physical interfaces, and failover if the failure parameters cross a configured
threshold.

• Support for Generic Routing Encapsulation (GRE) tunnels used to route encapsulated
IPv4/IPv6 traffic by means of an internal interface, gr-0/0/0. This interface is created
by Junos OS at system bootup and is used only for processing GRE tunnels. See the
Interfaces Feature Guide for Security Devices.

At any given instant, a cluster can be in one of the following states: hold, primary,
secondary-hold, secondary, ineligible, and disabled. A state transition can be triggered
because of any event, such as interface monitoring, SPU monitoring, failures, and manual
failovers.

IPv6 Clustering Support

Starting with Junos OS Release 10.4, SRX Series devices running IP version 6 (IPv6) can
be deployed in active/active (failover) chassis cluster configurations in addition to the
existing support of active/passive (failover) chassis cluster configurations. An interface
can be configured with an IPv4 address, IPv6 address, or both. Address book entries can

4 Copyright © 2016, Juniper Networks, Inc.

 Chapter 1: Introduction to Chassis Cluster

include any combination of IPv4 addresses, IPv6 addresses, and Domain Name System
(DNS) names.

Related • Preparing Your Equipment for Chassis Cluster Formation on page 35

Documentation
• Understanding Chassis Cluster Redundancy Groups on page 69

• Understanding Chassis Cluster Redundant Ethernet Interfaces on page 77

Chassis Cluster Supported Features

Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550

Table 3 on page 5 lists the features that are supported on branch SRX Series devices
in a chassis cluster.

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster

Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

Address Books Address books Yes Yes Yes Yes

and Address
Sets
Address sets Yes Yes Yes Yes

Global address objects or sets Yes Yes Yes Yes

Nested address groups Yes Yes Yes Yes

Administrator Local authentication Yes Yes Yes Yes

Authentication
Support
RADIUS Yes Yes Yes Yes

TACACS+ Yes Yes Yes Yes

Alarms Chassis alarms Yes Yes Yes Yes

Interface alarms Yes Yes Yes Yes

System alarms Yes Yes Yes Yes

Copyright © 2016, Juniper Networks, Inc. 5

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

Application Application Yes Yes Yes Yes

1
Identification identification–synchronizing in
a chassis cluster

Application firewall (AppFW) Yes Yes Yes Yes

Application QoS (AppQoS) Yes Yes Yes Yes

Application tracking Yes Yes Yes Yes

(AppTrack)

Custom application signatures Yes Yes Yes Yes

and signature groups

Heuristics-based detection Yes Yes Yes Yes

IDP Yes Yes Yes Yes

Jumbo frames Yes Yes Yes Yes

Nested application Yes Yes Yes Yes

identification

Onbox application tracking Yes Yes Yes Yes

statistics (AppTrack)

SSL proxy Yes Yes Yes Yes

Subscription license Yes Yes Yes Yes

enforcement

6 Copyright © 2016, Juniper Networks, Inc.

 Chapter 1: Introduction to Chassis Cluster

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

ALGs DNS ALG Yes Yes Yes Yes

DNS doctoring support Yes Yes Yes Yes

DNS, FTP, RTSP, and TFTP Yes Yes Yes Yes

ALGs (Layer 2) with chassis
clustering

DSCP marking for SIP, H.323, Yes Yes Yes Yes

MGCP, and SCCP ALGs

FTP Yes Yes Yes Yes

H.323 Yes Yes Yes Yes

H.323–Avaya H.323 Yes Yes Yes Yes

MGCP Yes Yes Yes Yes

PPTP Yes Yes Yes Yes

RPC–MS RPC Yes Yes Yes Yes

RPC–Sun RPC Yes Yes Yes Yes

RSH Yes Yes Yes Yes

RTSP Yes Yes Yes Yes

SIP–NEC SIP Yes Yes Yes Yes

SIP–SCCP SIP Yes Yes Yes Yes

SQL Yes Yes Yes Yes

TALK TFTP Yes Yes Yes Yes

Copyright © 2016, Juniper Networks, Inc. 7

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

Attack Detection Bad IP option Yes Yes Yes Yes

and Prevention
(Screens)
Block fragment traffic Yes Yes Yes Yes

FIN flag without ACK flag Yes Yes Yes Yes

ICMP flood protection Yes Yes Yes Yes

ICMP fragment protection Yes Yes Yes Yes

IP address spoof Yes Yes Yes Yes

IP address sweep Yes Yes Yes Yes

IP record route option Yes Yes Yes Yes

IP security option Yes Yes Yes Yes

IP stream option Yes Yes Yes Yes

IP strict source route option Yes Yes Yes Yes

IP timestamp option Yes Yes Yes Yes

Land attack protection land Yes Yes Yes Yes

Large size ICMP packet Yes Yes Yes Yes

protection

Loose source route option Yes Yes Yes Yes

Ping of death attack protection Yes Yes Yes Yes

Port scan Yes Yes Yes Yes

Source IP-based session limit Yes Yes Yes Yes

SYN-ACK-ACK proxy Yes Yes Yes Yes

protection

SYN and FIN flags Yes Yes Yes Yes

SYN flood protection Yes Yes Yes Yes

SYN fragment protection Yes Yes Yes Yes

8 Copyright © 2016, Juniper Networks, Inc.

 Chapter 1: Introduction to Chassis Cluster

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

TCP address sweep Yes Yes Yes Yes

TCP packet without flag Yes Yes Yes Yes

Teardrop attack protection Yes Yes Yes Yes

UDP address sweep Yes Yes Yes Yes

UDP flood protection Yes Yes Yes Yes

Unknown protocol Yes Yes Yes Yes

WinNuke attack protection Yes Yes Yes Yes

Chassis Allow chassis management Yes Yes Yes Yes

Management
CX111 3G adapter support No No No No

IEEE 802.3af / 802.3at support No No No No

Chassis cluster SPC insert No No No No

Class of Service Classifiers Yes Yes Yes Yes

Code-point aliases (IEEE 802.1) Yes Yes Yes Yes

Egress interface shaping Yes Yes Yes Yes

Forwarding classes Yes Yes Yes Yes

Ingress interface Yes Yes Yes Yes

Policer schedulers (hierarchical Yes Yes Yes Yes

schedulers)

Simple filters No No No No

Transmission queues Yes Yes Yes Yes

Copyright © 2016, Juniper Networks, Inc. 9

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

DHCP DHCP client Yes Yes Yes Yes

DHCP relay agent Yes Yes Yes Yes

DHCP server Yes Yes Yes Yes

DHCP server address pools Yes Yes Yes Yes

DHCP server static mapping Yes Yes Yes Yes

2
DHCPv6 Yes Yes Yes Yes

Diagnostics CLI terminal Yes Yes Yes Yes

Tools
J-Flow version 5 and version 8 Yes Yes Yes Yes

J-Flow version 9 No No No No

Flowd monitoring Yes Yes Yes Yes

Ping host Yes Yes Yes Yes

Ping MPLS No No No No

Traceroute Yes Yes Yes Yes

3
Dynamic VPN Package dynamic VPN client – – – –

Ethernet 10/100/1000 MB Ethernet Yes Yes Yes Yes

Interfaces interface

10-Gigabit Ethernet Interface Yes Yes Yes Yes

SFP+ slots

40/100-Gigabit Ethernet – – – –
interface MPC slots Gigabit

Ethernet, Copper (10-Mbps, Yes Yes Yes Yes

100-Mbps, or 1000-Mbps port)

Gigabit Ethernet interface Yes Yes Yes Yes

Promiscuous mode on Ethernet No No No No

interface

10 Copyright © 2016, Juniper Networks, Inc.

 Chapter 1: Introduction to Chassis Cluster

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

Ethernet Link LACP/LAG cross IOC – – – –

Aggregation (inter-IOC)

LACP (port priority) Layer 3 No Yes No Yes

Mode

LACP (port priority) Layer 2 No Yes No Yes

Mode

Layer 3 LAG on routed ports Yes Yes Yes Yes

Static LAG (routing) Yes Yes Yes Yes

Static LAG (switching) Yes Yes Yes Yes

Switching mode Yes Yes Yes Yes

File Deletion of backup software Yes Yes Yes Yes

Management image

Deletion of individual files Yes Yes Yes Yes

Download of system files Yes Yes Yes Yes

Encryption/decryption of Yes Yes Yes Yes

configuration files

Management of account files Yes Yes Yes Yes

Firewall Firewall authentication on Yes Yes Yes Yes

Authentication Layer 2 transparent
authentication

LDAP authentication server Yes Yes Yes Yes

Local authentication server Yes Yes Yes Yes

Pass-through authentication Yes Yes Yes Yes

RADIUS authentication server Yes Yes Yes Yes

SecurID authentication server Yes Yes Yes Yes

Web authentication Yes Yes Yes Yes

Copyright © 2016, Juniper Networks, Inc. 11

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

Flow-Based and Alarms and auditing Yes Yes Yes Yes

Packet-Based
Processing
End-to-end packet debugging No No No No

Express Path support No No No No

Flow-based processing Yes Yes Yes Yes

Host bound fragmented traffic No No No No

Network processor bundling Yes Yes Yes Yes

Packet-based processing No No No No

Selective stateless Yes Yes Yes Yes

packet-based services

GPRS GPRS (transparent mode and No No No No

route mode)

GTPv2 IMSI prefix and APN filtering No No No No

Message-length filtering No No No No

Message-rate limiting No No No No

Message-type filtering No No No No

Packet sanity check No No No No

Policy-based inspection No No No No

Restart GTPv2 path No No No No

Sequence-number and GTP-U No No No No

validation

Stateful inspection No No No No

Traffic logging No No No No

Tunnel cleanup No No No No

12 Copyright © 2016, Juniper Networks, Inc.

 Chapter 1: Introduction to Chassis Cluster

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

IDP Alarms and auditing Yes Yes Yes Yes

Cryptographic key handling No No No No

DSCP marking No No No No

IDP and application Yes Yes Yes Yes

identification

IDP and UAC coordinated Yes Yes Yes Yes

threat control

IDP class-of-service action No No No No

IDP inline tap mode No No No No

IDP logging Yes Yes Yes Yes

IDP monitoring and debugging Yes Yes Yes Yes

IDP policy Yes Yes Yes Yes

IDP security packet capture Yes Yes Yes Yes

IDP signature database Yes Yes Yes Yes

IDP SSL inspection No No No No

IPS rule base Yes Yes Yes Yes

Jumbo frames No No No No

Performance and capacity No No No No

tuning for IDP

SNMP MIB for IDP monitoring Yes Yes Yes Yes

Copyright © 2016, Juniper Networks, Inc. 13

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

IPsec AH protocol Yes Yes Yes Yes

Alarms and auditing Yes Yes Yes Yes

Antireplay (packet replay Yes Yes Yes Yes

attack prevention)

Autokey management Yes Yes Yes Yes

Dead peer detection (DPD) Yes Yes Yes Yes

Dynamic IPsec VPNs Yes Yes Yes Yes

External Extended Yes Yes Yes Yes

Authentication (XAuth) to a
RADIUS server for remote
access connections

Group VPN with dynamic Yes Yes Yes Yes

policies (server functionality)

IKEv1 and IKEv2 Yes Yes Yes Yes

Manual key management Yes Yes Yes Yes

Policy-based and route-based Yes Yes Yes Yes

VPNs

Route-based VPN support Yes Yes Yes Yes

Tunnel mode Yes Yes Yes Yes

VPN monitoring (proprietary) Yes Yes Yes Yes

Virtual router Yes Yes Yes Yes

IPv6 IPv6 support Yes Yes Yes Yes

14 Copyright © 2016, Juniper Networks, Inc.

 Chapter 1: Introduction to Chassis Cluster

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

Layer 2 Mode 802.1x port-based network Yes Yes Yes Yes

authentication

Flexible Ethernet services Yes Yes Yes Yes

IRB interface Yes Yes Yes Yes

LLDP and LLDP-MED Yes Yes Yes Yes

MAC limit (port security) Yes Yes Yes Yes

Q-in-Q tunneling No No No No

Spanning Tree Protocol Yes Yes Yes Yes

VLAN retagging Yes Yes Yes Yes

VLANs Yes Yes Yes Yes

Copyright © 2016, Juniper Networks, Inc. 15

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

MPLS CCC and TCC Yes Yes Yes Yes

CLNS Interprovider and Yes Yes Yes Yes

carrier-of-carriers VPNs

Filtering PIM register messages Yes Yes Yes Yes

IGMP Yes Yes Yes Yes

Layer 2 VPNs for Ethernet Yes Yes Yes Yes

connections

Layer 3 MPLS VPNs Yes Yes Yes Yes

LDP Yes Yes Yes Yes

MPLS VPNs with VRF tables on Yes Yes Yes Yes

provider edge routers

Multicast VPNs Yes Yes Yes Yes

OSPF and IS-IS traffic Yes Yes Yes Yes

engineering extensions

P2MP LSPs Yes Yes Yes Yes

Primary routing mode (dense No No No No

mode for LAN and sparse mode
for WAN)

Protocol Independent Multicast Yes Yes Yes Yes

(PIM) static RP

RSVP Yes Yes Yes Yes

Secondary and standby LSPs Yes Yes Yes Yes

Session Announcement Yes Yes Yes Yes

Protocol (SAP)

Session Description Protocol Yes Yes Yes Yes

(SDP)

Standards-based fast reroute Yes Yes Yes Yes

VPLS

16 Copyright © 2016, Juniper Networks, Inc.

 Chapter 1: Introduction to Chassis Cluster

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

Multicast VPN Basic multicast features in No No No No

C-instance

Multicast VPN membership No No No No

discovery with BGP

P2MP LSP support No No No No

P2MP OAM to P2MP LSP ping No No No No

Reliable multicast VPN routing No No No No

information exchange

Copyright © 2016, Juniper Networks, Inc. 17

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

NAT Destination IP address Yes Yes Yes Yes

translation

Disabling source Yes Yes Yes Yes

Interface source NAT pool port Yes Yes Yes Yes

NAT address pool utilization Yes Yes Yes Yes

threshold status

NAT port randomization Yes Yes Yes Yes

NAT traversal (NAT-T) for Yes Yes Yes Yes

site-to-site IPsec VPNs (IPv4)

Persistent NAT Yes Yes Yes Yes

Persistent NAT binding for Yes Yes Yes Yes

wildcard ports

Persistent NAT hairpinning Yes Yes Yes Yes

Pool translation Yes Yes Yes Yes

Proxy ARP (IPv4) Yes Yes Yes Yes

Proxy NDP (IPv6) Yes Yes Yes Yes

Removal of persistent NAT Yes Yes Yes Yes

query bindings

Rule-based NAT Yes Yes Yes Yes

Rule translation Yes Yes Yes Yes

Source address and group Yes Yes Yes Yes

address translation for
multicast flows

Source IP address translation Yes Yes Yes Yes

Static NAT Yes Yes Yes Yes

18 Copyright © 2016, Juniper Networks, Inc.

 Chapter 1: Introduction to Chassis Cluster

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

Network Event policies Yes Yes Yes Yes

Operations and
Troubleshooting
Event scripts Yes Yes Yes Yes
Support

Operation scripts Yes Yes Yes Yes

XSLT commit scripts Yes Yes Yes Yes

Packet Capture Packet capture Yes Yes Yes Yes

Public Key Automated certificate Yes Yes Yes Yes

Infrastructure enrollment using SCEP

Automatic generation of Yes Yes Yes Yes

self-signed certificates

CRL update at user-specified Yes Yes Yes Yes

interval

Digital signature generation Yes Yes Yes Yes

Entrust, Microsoft, and Verisign Yes Yes Yes Yes

certificate authorities (CAs)

IKE support Yes Yes Yes Yes

Manual installation of Yes Yes Yes Yes

DER-encoded and
PEM-encoded CRLs

Remote Device Reverse Telnet Yes Yes Yes Yes

Access

RPM Probe RPM probe Yes Yes Yes Yes

Copyright © 2016, Juniper Networks, Inc. 19

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

Routing BGP Yes Yes Yes Yes

BGP extensions for IPv6 Yes Yes Yes Yes

Compressed Real-Time Yes Yes Yes Yes

Transport Protocol (CRTP)

Internet Group Management Yes Yes Yes Yes

Protocol (IGMP)

IPv4 options and broadcast Yes Yes Yes Yes

Internet diagrams

IPv6 routing, forwarding, global Yes Yes Yes Yes

address configuration, and
Internet Control Message
Protocol (ICMP)

IS-IS Yes Yes Yes Yes

Multiple virtual routers Yes Yes Yes Yes

Neighbor Discovery Protocol Yes Yes Yes Yes

(NDP) and Secure Neighbor
Discovery Protocol (SEND)

OSPF v2 Yes Yes Yes Yes

OSPF v3 Yes Yes Yes Yes

RIP next generation (RIPng) Yes Yes Yes Yes

RIP v1, v2 Yes Yes Yes Yes

Static routing Yes Yes Yes Yes

Virtual Router Redundancy Yes Yes Yes Yes

Protocol (VRRP)

Secure Web CAs Yes Yes Yes Yes

Access
HTTP Yes Yes Yes Yes

HTTPS Yes Yes Yes Yes

Security Policy Security policy Yes Yes Yes Yes

20 Copyright © 2016, Juniper Networks, Inc.

 Chapter 1: Introduction to Chassis Cluster

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

Security Zones Functional zone Yes Yes Yes Yes

Security zone Yes Yes Yes Yes

Session Logging Acceleration of security and Yes Yes Yes Yes

traffic logging

Aggressive session aging Yes Yes Yes Yes

Getting information about Yes Yes Yes Yes

sessions

Logging to a single server Yes Yes Yes Yes

Session logging with NAT Yes Yes Yes Yes

information

SMTP SMTP Yes Yes Yes Yes

SNMP SNMP v1, v2, v3 No No No No

Stateless Stateless firewall filters (ACLs) No No No No

Firewall Filters

System Log Files System log archival Yes Yes Yes Yes

System log configuration Yes Yes Yes Yes

Disabling system logs Yes Yes Yes Yes

Filtering system log messages Yes Yes Yes Yes

Multiple system log servers Yes Yes Yes Yes

(control plane logs)

Sending system log messages Yes Yes Yes Yes

to a file

Sending system log messages Yes Yes Yes Yes

to a user terminal

Viewing data plane logs Yes Yes Yes Yes

Viewing system log messages Yes Yes Yes Yes

Copyright © 2016, Juniper Networks, Inc. 21

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

Transparent Bridge domain and transparent No No No No

Mode mode

Class of service No No No No

UTM Antispam Yes Yes Yes Yes

Antivirus–Express Yes No Yes No

Antivirus–Full Yes No Yes No

Antivirus–Sophos Yes No No No

Content filtering Yes Yes Yes Yes

Stateful active/active cluster No No No No

mode

Web filtering–Enhanced Yes Yes Yes Yes

Web filtering–Juniper Networks Yes Yes Yes Yes

local

Web filtering–Surf-control Yes Yes Yes Yes

Web filtering–Websense Yes Yes No No

redirect

Upgrading and Autorecovery Yes Yes Yes Yes

Rebooting
Boot device configuration Yes Yes Yes Yes

Boot device recovery Yes Yes Yes Yes

Chassis components control Yes Yes Yes Yes

Chassis restart Yes Yes Yes Yes

Dual-root partitioning Yes Yes Yes Yes

ISSU No No No No

WELF support Yes Yes Yes Yes

22 Copyright © 2016, Juniper Networks, Inc.

 Chapter 1: Introduction to Chassis Cluster

Table 3: Features Supported on a Branch SRX Series Device in a Chassis Cluster (continued)
Active/Backup Active/Active
Category Feature Active/Backup Failover Active/Active Failover

User Interfaces CLI Yes Yes Yes Yes

J-Web user interface No No No No

Junos XML protocol No No No No

Network and Security Manager Yes Yes Yes Yes

Session and Resource Control No No No No

(SRC) application

1
When the application ID is identified before session failover, the same action taken
before the failover is effective after the failover. That is, the action is published to
AppSecure service modules and takes place based on the application ID of the traffic. If
the application is in the process of being identified before a failover, the application ID is
not identified and the session information will be lost. The application identification
process will be applied on new sessions created on new primary node.
2
DHCPv6 is supported on SRX Series devices running Junos OS Release 12.1 and later
releases.
3
Package Dynamic VPN client is supported on branch SRX Series devices until Junos OS
Release 12.3X48.

Chassis Cluster Features Support

Table 4 on page 23 lists the chassis cluster features that are supported on branch SRX
Series devices.

Table 4: Chassis Cluster Feature Support on Branch SRX Series Devices

Features Branch SRX Series

Active/backup Routing Engine group (RG0) Yes

Active/active data redundancy groups (RGx) Yes

Aggregate Interfaces (link aggregration) Yes

Autorecovery of fabric link Yes

Chassis cluster extended cluster ID Yes

Chassis cluster formation Yes

Encrypted control link No

Copyright © 2016, Juniper Networks, Inc. 23

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 4: Chassis Cluster Feature Support on Branch SRX Series Devices (continued)
Features Branch SRX Series

Chassis clusters (active/backup and active/active) Yes

Control link recovery No

Control plane failover Yes

Dampening time between back-to-back redundancy group failovers Yes

Data plane failover Yes

Dual control links (redundant link for failover) No

Dual fabric links Yes

IP monitoring Yes

Flow forwarding Yes

Graceful restart routing protocols Yes

Graceful protocol restart for BGP Yes

Graceful protocol restart for IS-IS Yes

Graceful protocol restart for OSPF Yes

Graceful Routing Engine switchover (GRES) (between nodes) Yes

HA fabric forwarded packet reordering Interface Yes

HA monitoring Yes

In-band cluster upgrade (ICU) Yes

Junos OS flow-based routing functionality Yes

LACP support for Layer 3 Yes

Layer 2 Ethernet switching capability Yes

Layer 2 transparent mode LAG Yes

Layer 3 LAG Yes

Local interface support (non-reth) Yes

Low-Impact ISSU No

24 Copyright © 2016, Juniper Networks, Inc.

 Chapter 1: Introduction to Chassis Cluster

Table 4: Chassis Cluster Feature Support on Branch SRX Series Devices (continued)
Features Branch SRX Series

Multicast in HA mode Yes

Network Time Protocol (NTP) time synchronization in chassis cluster Yes

Point-to-Point Protocol over Ethernet (PPPoE) over redundant Ethernet interface Yes

Quality of service (QoS) SRX550

Redundancy group 0 (backup for Routing Engine) Yes

Redundancy groups 1 through 128 Yes

Redundant Ethernet interfaces Yes

Redundant Ethernet or aggregate Ethernet interface monitoring Yes

Redundant Ethernet interfaces Yes

SPU monitoring No

Synchronization–backup node configuration from primary node Yes

Synchronization–configuration Yes

Synchronization–Dynamic Routing Protocol (DRP) Yes

Synchronization–policies Yes

Synchronization– session state sync (RTO sync) Yes

TCP support for DNS Yes

Upstream device IP address monitoring on a backup interface Yes

Virtual Router Redundancy Protocol (VRRP) version 3 No

WAN interfaces No

Related • Chassis Cluster Overview on page 3

Documentation
• Chassis Cluster Limitations on page 25

Chassis Cluster Limitations

Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550, vSRX

Copyright © 2016, Juniper Networks, Inc. 25

Chassis Cluster Feature Guide for Branch SRX Series Devices

The SRX Series devices have the following chassis cluster limitations:

Chassis Cluster

• Group VPN is not supported.

• Unified ISSU is not supported.

• VRRP is not supported.

• Starting with Junos OS Release 12.1X45-D10 and later, sampling features such as flow
monitoring, packet capture, and port mirroring are supported on reth interfaces.

• On all SRX Series devices in a chassis cluster, flow monitoring for version 5 and
version 8 is supported. However, flow monitoring for version 9 is not supported.

Flow and Processing

• If you use packet capture on reth interfaces, two files are created, one for ingress
packets and the other for egress packets based on the reth interface name. These files
can be merged outside of the device using tools such as Wireshark or Mergecap.

• If you use port mirroring on reth interfaces, the reth interface cannot be configured as
the output interface. You must use a physical interface as the output interface. If you
configure the reth interface as an output interface using the set forwarding-options
port-mirroring family inet output command, the following error message is displayed.

Port-mirroring configuration error.

Interface type in reth1.0 is not valid for port-mirroring or next-hop-group config

• Any packet-based services such as MPLS and CLNS are not supported.

• On all SRX Series devices, the packet-based forwarding for MPLS and ISO protocol
families is not supported.

NOTE: Flowd monitoring is supported on SRX300, SRX320, SRX340, SRX345,

SRX550, and SRX1500 devices.

Installation and Upgrade

• For SRX300, SRX320, SRX340, SRX345, and SRX550 devices, the reboot parameter
is not available, because the devices in a cluster are automatically rebooted following
an in-band cluster upgrade (ICU).

Interfaces

• On the lsq-0/0/0 interface, Link services MLPPP, MLFR, and CRTP are not supported.

• On the lt-0/0/0 interface, CoS for RPM is not supported.

• The 3G dialer interface is not supported.

• Queuing on the ae interface is not supported.

26 Copyright © 2016, Juniper Networks, Inc.

 Chapter 1: Introduction to Chassis Cluster

Layer 2 Switching

• On SRX Series device failover, access points on the Layer 2 switch reboot and all
wireless clients lose connectivity for 4 to 6 minutes.

MIBs

• The Chassis Cluster MIB is not supported.

Monitoring

• The maximum number of monitoring IPs that can be configured per cluster is 64 for
the branch SRX Series devices.

• On SRX300, SRX320, SRX340, SRX345, SRX550, and SRX1500 devices, logs cannot
be sent to NSM when logging is configured in the stream mode. Logs cannot be sent
because the security log does not support configuration of the source IP address for
the fxp0 interface and the security log destination in stream mode cannot be routed
through the fxp0 interface. This implies that you cannot configure the security log
server in the same subnet as the fxp0 interface and route the log server through the
fxp0 interface.

Related • Preparing Your Equipment for Chassis Cluster Formation on page 35

Documentation

Copyright © 2016, Juniper Networks, Inc. 27

Chassis Cluster Feature Guide for Branch SRX Series Devices

28 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 2

Understanding Chassis Cluster License

Requirements

• Understanding Chassis Cluster Licensing Requirements on page 29

• Installing Licenses on the Devices in a Chassis Cluster on page 30
• Verifying Licenses for an SRX Series Device in a Chassis Cluster on page 32

Understanding Chassis Cluster Licensing Requirements

Supported Platforms SRX Series, vSRX

Some Junos OS software features require a license to activate the feature. To enable a
licensed feature, you need to purchase, install, manage, and verify a license key that
corresponds to each licensed feature.

There is no separate license required for chassis cluster. However, to configure and use
the licensed feature in a chassis cluster setup, you must purchase one license per feature
per device and the license needs to be installed on both nodes of the chassis cluster.
Each license is tied to one software feature pack, and that license is valid for only one
device.

For chassis cluster, you must install licenses that are unique to each device and cannot
be shared between the devices. Both devices (which are going to form a chassis cluster)
must have the valid, identical features licenses installed on them. If both devices do not
have an identical set of licenses, then after a failover, a particular feature (that is, a feature
that is not licensed on both devices) might not work or the configuration might not
synchronize in chassis cluster formation.

Licensing is usually ordered when the device is purchased, and this information is bound
to the chassis serial number. For example, Intrusion Detection and Prevention (IDP) is a
licensed feature and the license for this specific feature is tied to the serial number of
the device.

For information about how to purchase software licenses, contact your Juniper Networks
sales representative at http://www.juniper.net/in/en/contact-us/.

Related • Installing Licenses on the Devices in a Chassis Cluster on page 30

Documentation
• Verifying Licenses for an SRX Series Device in a Chassis Cluster on page 32

Copyright © 2016, Juniper Networks, Inc. 29

Chassis Cluster Feature Guide for Branch SRX Series Devices

Installing Licenses on the Devices in a Chassis Cluster

Supported Platforms SRX Series, vSRX

You can add a license key from a file or a URL, from a terminal, or from the J-Web user
interface. Use the filename option to activate a perpetual license directly on the device.
Use the url option to send a subscription-based license key entitlement (such as unified
threat management [UTM]) to the Juniper Networks licensing server for authorization.
If authorized, the server downloads the license to the device and activates it.

Before adding new licenses, complete the following tasks:

• Purchase the required licenses.

• Set the chassis cluster node ID and the cluster ID. See “Example: Setting the Chassis
Cluster Node ID and Cluster ID for Branch SRX Series Devices” on page 51 or Example:
Setting the Chassis Cluster Node ID and Cluster ID for High-End SRX Series Devices.

• Ensure that your SRX Series device has a connection to the Internet (if particular feature
requires Internet or if (automatic) renewal of license through internet is to be used).
For instructions on establishing basic connectivity, see the Getting Started Guide or
Quick Start Guide for your device.

To install licenses on the primary node of an SRX Series device in a chassis cluster:

1. Run the show chassis cluster status command and identify which node is primary for
redundancy group 0 on your SRX Series device.

{primary:node0}
user@host> show chassis cluster status redundancy-group 0

Cluster ID: 9
Node Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 1

node0 254 primary no no
node1 1 secondary no no

Output to this command indicates that node 0 is primary and node 1 is secondary.

2. From CLI operational mode, enter one of the following CLI commands:

• To add a license key from a file or a URL, enter the following command, specifying
the filename or the URL where the key is located:

user@host> request system license add filename | url

• To add a license key from the terminal, enter the following command:

user@host> request system license add terminal

3. When prompted, enter the license key, separating multiple license keys with a blank
line.

If the license key you enter is invalid, an error appears in the CLI output when you press
Ctrl+d to exit license entry mode.

4. Verify the installed licenses.

30 Copyright © 2016, Juniper Networks, Inc.

 Chapter 2: Understanding Chassis Cluster License Requirements

For more details, see Working with License Keys for SRX Series Devices.

To install licenses on the secondary node of an SRX Series device in a chassis cluster:

1. Initiate a failover to change node 1 (secondary node) to be the primary node:

{primary:node0}

user@host> request chassis cluster failover redundancy-group 0 node 1

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
Initiated manual failover for redundancy group 0

NOTE: Initiating a failover to the secondary node is not required if you are
installing licenses manually on the device. However, if you are installing
the license directly from the Internet, you must initiate a failover.

2. Repeat the steps described in “Step-by-Step Procedure” on page 30 to install licenses

on the secondary node.

3. Reboot the device for licenses to take effect.

NOTE: You must install the updated license on both nodes of the chassis
cluster before the existing license expires.

NOTE: In a chassis cluster configuration, when one device has a license

installed, and the other device does not have the same license installed, an
error message is displayed when you try to configure that specific feature as
shown in the following example:

[edit security utm feature-profile web-filtering type]

'type juniper-enhanced'
warning: requires 'wf_key_websense_ewf' license
<<<<<<<<<<<<<<<<<<<<<<
configuration check succeeds

TIP: If you are not using any specific feature or license , you can delete the
license from both devices in a chassis cluster. You need to connect to each
node separately to delete the licenses. For details, see Example: Deleting a
License Key.

Related • Verifying Licenses for an SRX Series Device in a Chassis Cluster on page 32
Documentation
• Understanding Chassis Cluster Licensing Requirements on page 29

Copyright © 2016, Juniper Networks, Inc. 31

Chassis Cluster Feature Guide for Branch SRX Series Devices

Verifying Licenses for an SRX Series Device in a Chassis Cluster

Supported Platforms SRX Series, vSRX

Purpose You can verify the licenses installed on both the devices in a chassis cluster setup by
using the show system license installed command to view license usage.

32 Copyright © 2016, Juniper Networks, Inc.

 Chapter 2: Understanding Chassis Cluster License Requirements

Action Licenses details on node 0.

user@host> show system license installed

{primary:node0}
user@host> show system license
License usage:
Licenses Licenses Licenses Expiry
Feature name used installed needed
logical-system 1 26 0 permanent
services-offload 0 1 0 permanent

Licenses installed:
License identifier: JUNOS363684
License version: 2
Valid for device: JN111A654AGB
Features:
services-offload - services offload mode
permanent

License identifier: JUNOS531744

License version: 4
Valid for device: JN111A654AGB
Features:
services-offload - services offload mode
permanent

License identifier: JUNOS558173

License version: 4
Valid for device: JN111A654AGB
Features:
logical-system-25 - Logical System Capacity
permanent

Licenses details on node 1.

{secondary-hold:node1}
user@host> show system license
License usage:
Licenses Licenses Licenses Expiry
Feature name used installed needed
idp-sig 0 1 0 permanent
logical-system 1 26 0 permanent
services-offload 0 1 0 permanent

Licenses installed:
License identifier: JUNOS209661
License version: 2
Valid for device: JN111AB4DAGB
Features:
idp-sig - IDP Signature
permanent

License identifier: JUNOS336648

License version: 2
Valid for device: JN111AB4DAGB
Features:
logical-system-25 - Logical System Capacity
permanent

License identifier: JUNOS363685

Copyright © 2016, Juniper Networks, Inc. 33

Chassis Cluster Feature Guide for Branch SRX Series Devices

License version: 2
Valid for device: JN111AB4DAGB
Features:
services-offload - services offload mode
permanent

License identifier: JUNOS531745

License version: 4
Valid for device: JN111AB4DAGB
Features:
services-offload - services offload mode
permanent

Meaning Use the fields License version and Features to make sure that licenses installed on both
the nodes are identical.

Related • Installing Licenses on the Devices in a Chassis Cluster on page 30

Documentation
• Understanding Chassis Cluster Licensing Requirements on page 29

34 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 3

Planning Your Chassis Cluster

Configuration

• Preparing Your Equipment for Chassis Cluster Formation on page 35

• SRX Series Chassis Cluster Configuration Overview on page 36

Preparing Your Equipment for Chassis Cluster Formation

Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550, vSRX

To form a chassis cluster, a pair of the same kind of supported SRX Series devices is
combined to act as a single system that enforces the same overall security.

The following are the device-specific matches required to form a chassis cluster:

• SRX300, SRX320, SRX340, SRX345, and SRX550: Although the devices must be of
the same type, they can contain different Physical Interface Modules (PIMs).

When a device joins a cluster, it becomes a node of that cluster. With the exception of
unique node settings and management IP addresses, nodes in a cluster share the same
configuration.

You can deploy up to 255 chassis clusters in a Layer 2 domain. Clusters and nodes are
identified in the following way:

• A cluster is identified by a cluster ID (cluster-id) specified as a number from 1 through

255. Setting a cluster ID to 0 is equivalent to disabling a cluster. A cluster ID greater
than 15 can only be set when the fabric and control link interfaces are connected
back-to-back.

The following message is displayed when you try to set a cluster ID greater than 15,
and when fabric and control link interfaces are not connected back-to-back or are not
connected on separated private VLANs:

{primary:node1}
user@host> set chassis cluster cluster-id 254 node 1 reboot
For cluster-ids greater than 15 and when deploying more than one cluster in a
single Layer 2 BROADCAST domain, it is mandatory that fabric and control links
are either connected back-to-back or are connected on separate private VLANS.

Copyright © 2016, Juniper Networks, Inc. 35

Chassis Cluster Feature Guide for Branch SRX Series Devices

• A cluster node is identified by a node ID (node) specified as a number from 0 through

1.

Related • Chassis Cluster Overview on page 3

Documentation
• Understanding Chassis Cluster Fabric Interfaces on page 57

SRX Series Chassis Cluster Configuration Overview

Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550, vSRX

Figure 1 on page 37 shows a chassis cluster flow diagram.

Note the following prerequisites for configuring a chassis cluster:

• On SRX Series branch devices, any existing configurations associated with interfaces
that transform to the fxp0 management port and the control port should be removed.
For more information, see “Understanding SRX Series Chassis Cluster Slot Numbering
and Physical Port and Logical Interface Naming” on page 47.

• Confirm that hardware and software are the same on both devices.

• Confirm that license keys are the same on both devices.

36 Copyright © 2016, Juniper Networks, Inc.

 Chapter 3: Planning Your Chassis Cluster Configuration

Figure 1: Chassis Cluster Flow Diagram

This section provides an overview of the basic steps to create an SRX Series chassis
cluster.

NOTE: For SRX300, SRX320, SRX340, SRX345, and SRX550 chassis clusters,
the placement and type of GPIMs, XGPIMs, XPIMs, and Mini-PIMs (as
applicable) must match in the two devices.

To create an SRX Series chassis cluster:

1. Physically connect a pair of the same kind of supported SRX Series devices together.
For more information, see “Connecting SRX Series Devices to Create a Chassis Cluster”
on page 43.

Copyright © 2016, Juniper Networks, Inc. 37

Chassis Cluster Feature Guide for Branch SRX Series Devices

a. Create the fabric link between two nodes in a cluster by connecting any pair of
Ethernet interfaces. For most SRX Series devices, the only requirement is that both
interfaces be Gigabit Ethernet interfaces (or 10-Gigabit Ethernet interfaces). For
SRX300, SRX320, SRX340, SRX345, and SRX550 devices, connect a pair of Gigabit
Ethernet interfaces. For SRX1500 devices, fabric child must be of a similar type.

When using dual fabric link functionality, connect the two pairs of Ethernet
interfaces that you will use on each device. See “Understanding Chassis Cluster
Dual Fabric Links” on page 151.

2. Connect the first device to be initialized in the cluster to the console port. This is the
node that forms the cluster.

For connection instructions, see the Getting Started Guide for your device.

3. Use CLI operational mode commands to enable clustering:

a. Identify the cluster by giving it the cluster ID.

b. Identify the node by giving it its own node ID and then reboot the system.

See “Example: Setting the Chassis Cluster Node ID and Cluster ID for Branch SRX
Series Devices” on page 51.

4. Connect to the console port on the other device and use CLI operational mode
commands to enable clustering:

a. Identify the cluster that the device is joining by setting the same cluster ID you set
on the first node.

b. Identify the node by giving it its own node ID and then reboot the system.

5. Configure the management interfaces on the cluster. See “Example: Configuring the
Chassis Cluster Management Interface” on page 53.

6. Configure the cluster with the CLI. See:

a. Example: Configuring the Number of Redundant Ethernet Interfaces in a Chassis

Cluster on page 84

b. Example: Configuring the Chassis Cluster Fabric Interfaces on page 61

c. Example: Configuring Chassis Cluster Redundancy Groups on page 73

d. Example: Configuring Chassis Cluster Redundant Ethernet Interfaces for IPv4 and
IPv6 Addresses on page 79

e. Example: Configuring Chassis Cluster Interface Monitoring on page 106

7. Initiate manual failover. See “Initiating a Chassis Cluster Manual Redundancy Group
Failover” on page 146.

8. Configure conditional route advertisement over redundant Ethernet interfaces. See

“Understanding Conditional Route Advertising in a Chassis Cluster” on page 159.

9. Verify the configuration. See “Verifying a Chassis Cluster Configuration” on page 99.

38 Copyright © 2016, Juniper Networks, Inc.

 Chapter 3: Planning Your Chassis Cluster Configuration

Related • Connecting SRX Series Devices to Create a Chassis Cluster on page 43

Documentation
• Example: Setting the Chassis Cluster Node ID and Cluster ID for Branch SRX Series
Devices on page 51

• Example: Configuring the Chassis Cluster Management Interface on page 53

• Example: Configuring the Number of Redundant Ethernet Interfaces in a Chassis Cluster

on page 84

• Verifying a Chassis Cluster Configuration on page 99

Copyright © 2016, Juniper Networks, Inc. 39

Chassis Cluster Feature Guide for Branch SRX Series Devices

40 Copyright © 2016, Juniper Networks, Inc.

PART 2

Setting Up Chassis Cluster in SRX Series

Devices
• Chassis Cluster Physical Setup on page 43
• Setting Up Chassis Cluster Identification on page 47
• Setting Up Chassis Cluster Management Interfaces on page 53
• Setting Up Fabric Interfaces on a Chassis Cluster on page 57
• Setting Up Control Plane Interfaces on a Chassis Cluster on page 65
• Setting Up Chassis Cluster Redundancy Groups on page 69
• Setting Up Chassis Cluster Redundant Ethernet Interfaces on page 77
• Configuring Chassis Cluster on page 87

Copyright © 2016, Juniper Networks, Inc. 41

Chassis Cluster Feature Guide for Branch SRX Series Devices

42 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 4

Chassis Cluster Physical Setup

• Connecting SRX Series Devices to Create a Chassis Cluster on page 43

Connecting SRX Series Devices to Create a Chassis Cluster

Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550

An SRX Series chassis cluster is created by physically connecting two identical

cluster-supported SRX Series devices together using a pair of the same type of Ethernet
connections. The connection is made for both a control link and a fabric (data) link
between the two devices.

Control links in a chassis cluster are made using specific ports.

You must use the following ports to form the control link on the branch SRX Series devices:

• For SRX300 devices, connect the ge-0/0/1 on node 0 to the ge-1/0/1 on node 1.

• For SRX320 devices, connect the ge-0/0/1 on node 0 to the ge-3/0/1 on node 1.

• For SRX340 and SRX345 devices, connect the ge-0/0/1 on node 0 to the ge-5/0/1 on
node 1.

• For SRX550 devices, connect the ge-0/0/1 on node 0 to the ge-9/0/1 on node 1.

• SRX1500 devices use dedicated control ports.

The fabric link connection must be any pair of either Gigabit Ethernet or 10-Gigabit
Ethernet interfaces on all SRX Series devices.

To establish a fabric link:

• For SRX300 and SRX320 devices, connect any interface except ge-0/0/0 and ge-0/0/1.

• For SRX340 and SRX345 devices, connect any interface except fxp0 and ge-0/0/.

Figure 2 on page 44, Figure 3 on page 44, Figure 4 on page 44, Figure 5 on page 44,
Figure 6 on page 44, and Figure 7 on page 45 show pairs of SRX Series devices with the
fabric links and control links connected.

Copyright © 2016, Juniper Networks, Inc. 43

Chassis Cluster Feature Guide for Branch SRX Series Devices

Figure 2: Connecting SRX Series Devices in a Cluster (SRX300 Devices)

Figure 3: Connecting SRX Series Devices in a Cluster (SRX320 Devices)

Figure 4: Connecting SRX Series Devices in a Cluster (SRX340 Devices)

Figure 5: Connecting SRX Series Devices in a Cluster (SRX345 Devices)

Figure 6: Connecting SRX Series Devices in a Cluster (SRX550 Devices)

44 Copyright © 2016, Juniper Networks, Inc.

 Chapter 4: Chassis Cluster Physical Setup

Figure 7: Connecting SRX Series Devices in a Cluster (SRX1500 Devices)

Related • SRX Series Chassis Cluster Configuration Overview on page 36

Documentation
• Example: Setting the Chassis Cluster Node ID and Cluster ID for Branch SRX Series
Devices on page 51

• Example: Configuring the Chassis Cluster Management Interface on page 53

• Example: Configuring the Number of Redundant Ethernet Interfaces in a Chassis Cluster

on page 84

Copyright © 2016, Juniper Networks, Inc. 45

Chassis Cluster Feature Guide for Branch SRX Series Devices

46 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 5

Setting Up Chassis Cluster Identification

• Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port and
Logical Interface Naming on page 47
• Example: Setting the Chassis Cluster Node ID and Cluster ID for Branch SRX Series
Devices on page 51

Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port and
Logical Interface Naming

Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550, vSRX

Normally, on SRX Series devices, the built-in interfaces are numbered as follows:

Table 5: SRX Series Built-in Interfaces

Devices Built-In Interfaces

For SRX300, ge-0/0/0 ge-0/0/1 ge-0/0/2 ge-0/0/3 ...

SRX320,
SRX340,
SRX345,
SRX550, and
SRX1500
Devices

SRX1500 devices have 16 GE interfaces and 4 XE ports.

For chassis clustering, all SRX Series devices have a built-in management interface
named fxp0. For most SRX Series devices, the fxp0 interface is a dedicated port.

For SRX340 and SRX345 devices, the fxp0 interface is a dedicated port. For SRX300
and SRX320 devices, after you enable chassis clustering and reboot the system, the
built-in interface named ge-0/0/0 is repurposed as the management interface and is
automatically renamed fxp0.

For SRX300, SRX320, SRX340, and SRX345 devices, after you enable chassis clustering
and reboot the system, the build-in interface named ge-0/0/1is repurposed as the control
interface and is automatically renamed fxp1.

For SRX550 devices, control interfaces are dedicated Gigabit Ethernet ports.

Copyright © 2016, Juniper Networks, Inc. 47

Chassis Cluster Feature Guide for Branch SRX Series Devices

After the devices are connected as a cluster, the slot numbering on one device changes
and thus the interface numbering will change. The slot number for each slot in both nodes
is determined using the following formula:

cluster slot number = (node ID * maximum slots per node) + local slot number

In chassis cluster mode, all FPC related configuration is performed under edit chassis
node node-id fpc hierarchy. In non-cluster mode, the FPC related configuration is performed
under edit chassis fpc hierarchy.

Table 6 on page 48 shows the slot numbering, as well as the physical port and logical
interface numbering, for both of the SRX Series devices that become node 0 and node
1 of the chassis cluster after the cluster is formed.

Table 6: SRX Series Chassis Cluster Slot Numbering and Physical Port and Logical Interface
Naming
Management Control Fabric
Maximum Slot Physical Physical Physical
Slots Per Numbering in Port/Logical Port/Logical Port/Logical
Model Chassis Node a Cluster Interface Interface Interface

1500 Node 0 1 0 fxp0 Dedicated Any Ethernet

Control port port

em0 fab0

Node 1 7 fxp0 Dedicated Any Ethernet

Control port port

em0 fab1

550 Node 0 9 (PIM slots) 0—8 ge-0/0/0 ge-0/0/1 Any Ethernet

port

fxp0 fxp1 fab0

Node 1 9 — 17 ge-9/0/0 ge-9/0/1 Any Ethernet

port

fxp0 fxp1 fab1

340 and 345 Node 0 5 (PIM slots) 0—4 fxp0 ge-0/0/1 Any Ethernet
port

fxp0 fxp1 fab0

Node 1 5—9 fxp0 ge-5/0/1 Any Ethernet

port

fxp0 fxp1 fab1

48 Copyright © 2016, Juniper Networks, Inc.

 Chapter 5: Setting Up Chassis Cluster Identification

Table 6: SRX Series Chassis Cluster Slot Numbering and Physical Port and Logical Interface
Naming (continued)
Management Control Fabric
Maximum Slot Physical Physical Physical
Slots Per Numbering in Port/Logical Port/Logical Port/Logical
Model Chassis Node a Cluster Interface Interface Interface

320 Node 0 3 (PIM slots) 0—2 ge-0/0/0 ge-0/0/1 Any Ethernet

port

fxp0 fxp1 fab0

Node 1 3—5 ge-3/0/0 ge-3/0/1 Any Ethernet

port

fxp0 fxp1 fab1

300 Node 0 1(PIM slot) 0 ge-0/0/0 ge-0/0/1 Any Ethernet

port

fxp0 fxp1 fab0

Node 1 1 ge-1/0/0 ge-1/0/1 Any Ethernet

port

fxp0 fxp1 fab1

NOTE: See the hardware documentation for your particular model (SRX
Series Services Gateways) for details about SRX Series devices. See Interfaces
Feature Guide for Security Devices for a full discussion of interface naming
conventions.

After you enable chassis clustering, the two chassis joined together cease to exist as
individuals and now represent a single system. As a single system, the cluster now has
twice as many slots. (See Figure 8 on page 49, Figure 9 on page 50, Figure 10 on page 50,
Figure 10 on page 50, Figure 11 on page 50, Figure 12 on page 50, and Figure 13 on page 50.)

Figure 8: Slot Numbering in an SRX Series Chassis Cluster (SRX300

Devices)

Node 0 Node 1
g009250

Slot 0 Slot 1

Copyright © 2016, Juniper Networks, Inc. 49

Chassis Cluster Feature Guide for Branch SRX Series Devices

Figure 9: Slot Numbering in an SRX Series Chassis Cluster (SRX320

Devices)

Figure 10: Slot Numbering in an SRX Series Chassis Cluster (SRX340

Devices)

Figure 11: Slot Numbering in an SRX Series Chassis Cluster (SRX345

Devices)

Figure 12: Slot Numbering in an SRX Series Chassis Cluster (SRX550

Devices)
Slot 0 Slot 9
Slot 5 Slot 7 Slot 6 Slot 8 Slot 14 Slot 16 Slot 15 Slot 17

ALARM CONSOLE
ALARM CONSOLE
STATUS STATUS
POWER POWER
HA HA

g034131
MPIM-1 MPIM-1
AUX AUX
MPIM-2 MPIM-2
RPS RPS
ACE ACE
STORAGE STORAGE
1,2
ESD

0 1 0 1

RESET RESET
CONFIG CONFIG

Slot 1 Slot 2 Slot 3 Slot 4 Slot 10 Slot 11 Slot 12 Slot 13

Figure 13: Slot Numbering in an SRX Series Chassis Cluster (SRX1500

Devices)

Related • Example: Configuring an SRX Series Services Gateway for the Branch as a Chassis
Documentation Cluster on page 87

50 Copyright © 2016, Juniper Networks, Inc.

 Chapter 5: Setting Up Chassis Cluster Identification

Example: Setting the Chassis Cluster Node ID and Cluster ID for Branch SRX Series
Devices

Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550, vSRX

This example shows how to set the chassis cluster node ID and chassis cluster ID , which
you must configure after connecting two devices together. A chassis cluster ID identifies
the cluster to which the devices belong, and a chassis cluster node ID identifies a unique
node within the cluster. After wiring the two devices together, you use CLI operational
mode commands to enable chassis clustering by assigning a cluster ID and node ID on
each chassis in the cluster. The cluster ID is the same on both nodes.

• Requirements on page 51
• Overview on page 51
• Configuration on page 51
• Verification on page 52

Requirements

Before you begin, ensure that you can connect to each device through the console port.

Overview
The system uses the chassis cluster ID and chassis cluster node ID to apply the correct
configuration for each node (for example, when you use the apply-groups command to
configure the chassis cluster management interface). The chassis cluster ID and node
ID statements are written to the EPROM, and the statements take effect when the system
is rebooted.

In this example, you configure a chassis cluster ID of 1. You also configure a chassis cluster
node ID of 0 for the first node, which allows redundancy groups to be primary on this
node when priority settings for both nodes are the same, and a chassis cluster node ID
of 1 for the other node.

NOTE: Chassis cluster supports automatic synchronization of configurations.

When a secondary node joins a primary node and a chassis cluster is formed,
the primary node configuration is automatically copied and applied to the
secondary node. See “Understanding Automatic Chassis Cluster
Synchronization Between Primary and Secondary Nodes” on page 181.

Configuration
Step-by-Step To specify the chassis cluster node ID and cluster ID, you need to set two devices to
Procedure cluster mode and reboot the devices. You must enter the following operational mode
commands on both devices:

1. Connect to the first device through the console port.

user@host> set chassis cluster cluster-id 1 node 0 reboot

Copyright © 2016, Juniper Networks, Inc. 51

Chassis Cluster Feature Guide for Branch SRX Series Devices

Successfully enabled chassis cluster. Going to reboot now.

2. Connect to the second device through the console port.

user@host> set chassis cluster cluster-id 1 node 1 reboot

Successfully enabled chassis cluster. Going to reboot now.

Verification

Verifying Chassis Cluster Status

Purpose Verify the status of a chassis cluster.

Action From operational mode, enter the show chassis cluster status command.

{primary:node0}[edit]
user@host> show chassis cluster status

Cluster ID: 1
Node Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 1

node0 100 primary no no
node1 1 secondary no no

Redundancy group: 1 , Failover count: 1

node0 0 primary no no
node1 0 secondary no no

Related • SRX Series Chassis Cluster Configuration Overview on page 36

Documentation
• Example: Configuring the Chassis Cluster Management Interface on page 53

• Example: Configuring the Number of Redundant Ethernet Interfaces in a Chassis Cluster

on page 84

52 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 6

Setting Up Chassis Cluster Management

Interfaces

• Management Interface on an Active Chassis Cluster on page 53

• Example: Configuring the Chassis Cluster Management Interface on page 53

Management Interface on an Active Chassis Cluster

Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550, vSRX

The fxp0 interfaces function like standard management interfaces on SRX Series devices
and allow network access to each node in the cluster.

Most of SRX Series devices contain an fxp0 interface.

For most SRX Series chassis clusters, the fxp0 interface is a dedicated port. SRX340 and
SRX345 devices contain an fxp0 interface. SRX300 and SRX320 devices do not have a
dedicated port for fxp0. The fxp0 interface is repurposed from a built-in interface. The
fxp0 interface is created when the system reboots the devices after you designate one
node as the primary device and the other as the secondary device.

We recommend giving each node in a chassis cluster a unique IP address for the fxp0
interface of each node. This practice allows independent node management.

Related • Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port and
Documentation Logical Interface Naming on page 47

Example: Configuring the Chassis Cluster Management Interface

Supported Platforms SRX Series, vSRX

This example shows how to provide network management access to a chassis cluster.

• Requirements on page 54
• Overview on page 54
• Configuration on page 54
• Verification on page 56

Copyright © 2016, Juniper Networks, Inc. 53

Chassis Cluster Feature Guide for Branch SRX Series Devices

Requirements
Before you begin, set the chassis cluster node ID and cluster ID. See “Example: Setting
the Chassis Cluster Node ID and Cluster ID for Branch SRX Series Devices” on page 51
or Example: Setting the Chassis Cluster Node ID and Cluster ID for High-End SRX Series
Devices.

Overview
You must assign a unique IP address to each node in the cluster to provide network
management access. This configuration is not replicated across the two nodes.

NOTE: If you try to access the nodes in a cluster over the network before you
configure the fxp0 interface, you will lose access to the cluster.

In this example, you configure the following information for IPv4:

• Node 0 name—node0-router

• IP address assigned to node 0—10.1.1.1/24

• Node 1 name—node1-router

• IP address assigned to node 1—10.1.1.2/24

In this example, you configure the following information for IPv6:

• Node 0 name—node0-router

• IP address assigned to node 0—2010:2010:201::2/64

• Node 1 name—node1-router

• IP address assigned to node 1—2010:2010:201::3/64

Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.

To configure a chassis cluster management interface for IPv4:

{primary:node0}[edit]
user@host#
set groups node0 system host-name node0-router
set groups node0 interfaces fxp0 unit 0 family inet address 10.1.1.1/24
set groups node1 system host-name node1-router
set groups node1 interfaces fxp0 unit 0 family inet address 10.1.1.2/24

To configure a chassis cluster management interface for IPv6:

{primary:node0}[edit]

54 Copyright © 2016, Juniper Networks, Inc.

 Chapter 6: Setting Up Chassis Cluster Management Interfaces

user@host#
set groups node0 system host-name node0-router
set groups node0 interfaces fxp0 unit 0 family inet6 address 2010:2010:201::2/64
set groups node1 system host-name node1-router
set groups node1 interfaces fxp0 unit 0 family inet6 address 2010:2010:201::3/64

Step-by-Step To configure a chassis cluster management interface for IPv4:

Procedure
1. Configure the name of node 0 and assign an IP address.

{primary:node0}[edit]
user@host# set groups node0 system host-name node0-router
user@host# set groups node0 interfaces fxp0 unit 0 family inet address 10.1.1.1/24

2. Configure the name of node 1 and assign an IP address.

{primary:node0}[edit]
set groups node1 system host-name node1-router
set groups node1 interfaces fxp0 unit 0 family inet address 10.1.1.2/24

3. If you are done configuring the device, commit the configuration.

{primary:node0}[edit]
user@host# commit

Step-by-Step To configure a chassis cluster management interface for IPv6:

Procedure
1. Configure the name of node 0 and assign an IP address.

{primary:node0}[edit]
user@host# set groups node0 system host-name node0-router
user@host# set groups node0 interfaces fxp0 unit 0 family inet6 address
2010:2010:201::2/64

2. Configure the name of node 1 and assign an IP address.

{primary:node0}[edit]
user@host# set groups node1 system host-name node1-router
user@host# set groups node1 interfaces fxp0 unit 0 family inet6 address
2010:2010:201::3/64

3. If you are done configuring the device, commit the configuration.

{primary:node0}[edit]
user@host# commit

Results From configuration mode, confirm your configuration by entering the show groups and
show apply-groups commands. If the output does not display the intended configuration,
repeat the configuration instructions in this example to correct it.

{primary:node0}[edit]
user@host# show groups
node0 {
system {
host-name node0-router;
}
interfaces {
fxp0 {

Copyright © 2016, Juniper Networks, Inc. 55

Chassis Cluster Feature Guide for Branch SRX Series Devices

unit 0 {
family inet {
address 10.1.1.1/24;
}
}
}
}
}
node1 {
system {
host-name node1-router;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 10.1.1.2/24;
}
}
}
}
}

{primary:node0}[edit]
user@host# show apply-groups
## Last changed: 2010-09-16 11:08:29 UTC
apply-groups "${node}";

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying the Chassis Cluster Management Interface Configuration

Purpose Verify the chassis cluster management interface configuration.

Action To verify the configuration is working properly, enter the show config command.

Related • Management Interface on an Active Chassis Cluster for Branch SRX Series Devices on
Documentation page 53

56 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 7

Setting Up Fabric Interfaces on a Chassis

Cluster

• Understanding Chassis Cluster Fabric Interfaces on page 57

• Example: Configuring the Chassis Cluster Fabric Interfaces on page 61
• Verifying Chassis Cluster Data Plane Interfaces on page 63
• Verifying Chassis Cluster Data Plane Statistics on page 63
• Clearing Chassis Cluster Data Plane Statistics on page 64

Understanding Chassis Cluster Fabric Interfaces

Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550, vSRX

The data plane software, which operates in active/active mode, manages flow processing
and session state redundancy and processes transit traffic. All packets belonging to a
particular session are processed on the same node to ensure that the same security
treatment is applied to them. The system identifies the node on which a session is active
and forwards its packets to that node for processing. (After a packet is processed, the
Packet Forwarding Engine transmits the packet to the node on which its egress interface
exists if that node is not the local one.)

To provide for session (or flow) redundancy, the data plane software synchronizes its
state by sending special payload packets called runtime objects (RTOs) from one node
to the other across the fabric data link. By transmitting information about a session
between the nodes, RTOs ensure the consistency and stability of sessions if a failover
were to occur, and thus they enable the system to continue to process traffic belonging
to existing sessions. To ensure that session information is always synchronized between
the two nodes, the data plane software gives RTOs transmission priority over transit
traffic.

• Understanding Chassis Cluster Fabric Links on page 58

• Understanding Session RTOs on page 59
• Understanding Data Forwarding on page 59
• Understanding Fabric Data Link Failure and Recovery on page 59

Copyright © 2016, Juniper Networks, Inc. 57

Chassis Cluster Feature Guide for Branch SRX Series Devices

Understanding Chassis Cluster Fabric Links

The fabric is the data link between the nodes and is used to forward traffic between the
chassis. Traffic arriving on a node that needs to be processed on the other is forwarded
over the fabric data link. Similarly, traffic processed on a node that needs to exit through
an interface on the other node is forwarded over the fabric.

The data link is referred to as the fabric interface. It is used by the cluster's Packet
Forwarding Engines to transmit transit traffic and to synchronize the data plane software’s
dynamic runtime state. The fabric provides for synchronization of session state objects
created by operations such as authentication, Network Address Translation (NAT),
Application Layer Gateways (ALGs), and IP Security (IPsec) sessions.

When the system creates the fabric interface, the software assigns it an internally derived
IP address to be used for packet transmission.

The fabric is a physical connection between two nodes of a cluster and is formed by
connecting a pair of Ethernet interfaces back-to-back (one from each node).

Unlike for the control link, whose interfaces are determined by the system, you specify
the physical interfaces to be used for the fabric data link in the configuration.

CAUTION: After fabric interfaces have been configured on a chassis cluster,

removing the fabric configuration on either node will cause the redundancy
group 0 (RG0) secondary node to move to a disabled state. (Resetting a
device to the factory default configuration removes the fabric configuration
and thereby causes the RG0 secondary node to move to a disabled state.)
After the fabric configuration is committed, do not reset either device to the
factory default configuration.

For SRX1500, the fabric link can be any pair of Ethernet interfaces spanning the cluster;
the fabric link can be any pair of Gigabit Ethernet interface or any pair of 10-Gigabit
Ethernet interface. For SRX300, SRX320, SRX340, and SRX345 devices, the fabric link
can be any pair of Gigabit Ethernet interfaces.

For SRX Series chassis clusters made up of SRX550 devices, SFP interfaces on Mini-PIMs
cannot be used as the fabric link.

For details about port and interface usage for management, control, and fabric links, see
“Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port and Logical
Interface Naming” on page 47.

The fabric data link does not support fragmentation. To accommodate this state, jumbo
frame support is enabled by default on the link with an MTU size of 8940 bytes. To ensure
that traffic that transits the data link does not exceed this size, we recommend that no
other interfaces exceed the fabric data link's MTU size.

58 Copyright © 2016, Juniper Networks, Inc.

 Chapter 7: Setting Up Fabric Interfaces on a Chassis Cluster

Understanding Session RTOs

The data plane software creates RTOs for UDP and TCP sessions and tracks state
changes. It also synchronizes traffic for IPv4 pass-through protocols such as Generic
Routing Encapsulation (GRE) and IPsec.

RTOs for synchronizing a session include:

• Session creation RTOs on the first packet

• Session deletion and age-out RTOs

• Change-related RTOs, including:

• TCP state changes

• Timeout synchronization request and response messages

• RTOs for creating and deleting temporary openings in the firewall (pinholes) and
child session pinholes

Understanding Data Forwarding

For Junos OS, flow processing occurs on a single node on which the session for that flow
was established and is active. This approach ensures that the same security measures
are applied to all packets belonging to a session.

A chassis cluster can receive traffic on an interface on one node and send it out to an
interface on the other node. (In active/active mode, the ingress interface for traffic might
exist on one node and its egress interface on the other.)

This traversal is required in the following situations:

• When packets are processed on one node, but need to be forwarded out an egress
interface on the other node

• When packets arrive on an interface on one node, but must be processed on the other
node

If the ingress and egress interfaces for a packet are on one node, but the packet must
be processed on the other node because its session was established there, it must
traverse the data link twice. This can be the case for some complex media sessions,
such as voice-over-IP (VoIP) sessions.

Understanding Fabric Data Link Failure and Recovery

NOTE: Intrusion Detection and Prevention (IDP) services do not support

failover. For this reason, IDP services are not applied for sessions that were
present prior to the failover. IDP services are applied for new sessions created
on the new primary node.

Copyright © 2016, Juniper Networks, Inc. 59

Chassis Cluster Feature Guide for Branch SRX Series Devices

The fabric data link is vital to the chassis cluster. If the link is unavailable, traffic forwarding
and RTO synchronization are affected, which can result in loss of traffic and unpredictable
system behavior.

To eliminate this possibility, Junos OS uses fabric monitoring to check whether the fabric
link, or the two fabric links in the case of a dual fabric link configuration, are alive by
periodically transmitting probes over the fabric links. If Junos OS detects fabric faults,
RG1+ status of the secondary node changes to ineligible. It determines that a fabric fault
has occurred if a fabric probe is not received but the fabric interface is active. To recover
from this state, both the fabric links need to come back to online state and should start
exchanging probes. As soon as this happens, all the FPCs on the previously ineligible
node will be reset. They then come to online state and rejoin the cluster.

NOTE: If you make any changes to the configuration while the secondary
node is disabled, execute the commit command to synchronize the
configuration after you reboot the node. If you did not make configuration
changes, the configuration file remains synchronized with that of the primary
node.

Starting with Junos OS Release 12.1X47-D10, recovery of the fabric link and synchronization
take place automatically.

When both the primary and secondary nodes are healthy (that is, there are no failures)
and the fabric link goes down, RG1+ redundancy group(s) on the secondary node becomes
ineligible. When one of the nodes is unhealthy (that is, there is a failure), RG1+ redundancy
group(s) on this node (either the primary or secondary node) becomes ineligible. When
both nodes are unhealthy and the fabric link goes down, RG1+ redundancy group(s) on
the secondary node becomes ineligible. When the fabric link comes up, the node on which
RG1+ became ineligible performs a cold synchronization on all Services Processing Units
and transitions to active standby.

NOTE:
• If RG0 is primary on an unhealthy node, then RG0 will fail over from an
unhealthy to a healthy node. For example, if node 0 is primary for RG0+
and node 0 becomes unhealthy, then RG1+ on node 0 will transition to
ineligible after 66 seconds of a fabric link failure and RG0+ fails over to
node 1, which is the healthy node.

• Only RG1+ transitions to an ineligible state. RG0 continues to be in either

a primary or secondary state.

Use the show chassis cluster interfaces CLI command to verify the status of the fabric
link.

Related • Understanding Chassis Cluster Dual Fabric Links on page 151

Documentation
• Example: Configuring the Chassis Cluster Fabric Interfaces on page 61

60 Copyright © 2016, Juniper Networks, Inc.

 Chapter 7: Setting Up Fabric Interfaces on a Chassis Cluster

• Verifying Chassis Cluster Data Plane Interfaces on page 63

• Verifying Chassis Cluster Data Plane Statistics on page 63

• Clearing Chassis Cluster Data Plane Statistics on page 64

• Preparing Your Equipment for Chassis Cluster Formation on page 35

Example: Configuring the Chassis Cluster Fabric Interfaces

Supported Platforms SRX Series, vSRX

This example shows how to configure the chassis cluster fabric. The fabric is the
back-to-back data connection between the nodes in a cluster. Traffic on one node that
needs to be processed on the other node or to exit through an interface on the other node
passes over the fabric. Session state information also passes over the fabric.

• Requirements on page 61
• Overview on page 61
• Configuration on page 62
• Verification on page 62

Requirements
Before you begin, set the chassis cluster ID and chassis cluster node ID. See Example:
Setting the Chassis Cluster Node ID and Cluster ID.

Overview
In most SRX Series devices in a chassis cluster, you can configure any pair of Gigabit
Ethernet interfaces or any pair of 10-Gigabit interfaces to serve as the fabric between
nodes.

You cannot configure filters, policies, or services on the fabric interface. Fragmentation
is not supported on the fabric link. The MTU size is 8980 bytes. We recommend that no
interface in the cluster exceed this MTU size. Jumbo frame support on the member links
is enabled by default.

This example illustrates how to configure the fabric link.

Only the same type of interfaces can be configured as fabric children, and you must
configure an equal number of child links for fab0 and fab1.

NOTE: If you are connecting each of the fabric links through a switch, you
must enable the jumbo frame feature on the corresponding switch ports. If
both of the fabric links are connected through the same switch, the
RTO-and-probes pair must be in one virtual LAN (VLAN) and the data pair
must be in another VLAN. Here too, the jumbo frame feature must be enabled
on the corresponding switch ports.

Copyright © 2016, Juniper Networks, Inc. 61

Chassis Cluster Feature Guide for Branch SRX Series Devices

Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.

{primary:node0}[edit]
set interfaces fab0 fabric-options member-interfaces ge-0/0/1
set interfaces fab1 fabric-options member-interfaces ge-7/0/1

Step-by-Step To configure the chassis cluster fabric:

Procedure
• Specify the fabric interfaces.

{primary:node0}[edit]
user@host# set interfaces fab0 fabric-options member-interfaces ge-0/0/1
{primary:node0}[edit]
user@host# set interfaces fab1 fabric-options member-interfaces ge-7/0/1

Results From configuration mode, confirm your configuration by entering the show interfaces
command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).

{primary:node0}[edit]
user@host# show interfaces
...
fab0 {
fabric-options {
member-interfaces {
ge-0/0/1;
}
}
}
fab1 {
fabric-options {
member-interfaces {
ge-7/0/1;
}
}
}

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying the Chassis Cluster Fabric

Purpose Verify the chassis cluster fabric.

62 Copyright © 2016, Juniper Networks, Inc.

 Chapter 7: Setting Up Fabric Interfaces on a Chassis Cluster

Action From operational mode, enter the show interfaces terse | match fab command.

{primary:node0}

user@host> show interfaces terse | match fab

ge-0/0/1.0 up up aenet --> fab0.0
ge-7/0/1.0 up up aenet --> fab1.0
fab0 up up
fab0.0 up up inet 30.17.0.200/24
fab1 up up
fab1.0 up up inet 30.18.0.200/24

Related • Verifying Chassis Cluster Data Plane Interfaces on page 63

Documentation
• Verifying Chassis Cluster Data Plane Statistics on page 63

Verifying Chassis Cluster Data Plane Interfaces

Supported Platforms SRX Series, vSRX

Purpose Display chassis cluster data plane interface status.

Action From the CLI, enter the show chassis cluster data-plane interfaces command:

{primary:node1}
user@host> show chassis cluster data-plane interfaces
fab0:
Name Status
ge-2/1/9 up
ge-2/2/5 up
fab1:
Name Status
ge-8/1/9 up
ge-8/2/5 up

Related • Understanding Chassis Cluster Fabric Interfaces for Branch SRX Series on page 57
Documentation
• Understanding Chassis Cluster Fabric Interfaces for High-End SRX Series

• Example: Configuring the Chassis Cluster Fabric Interfaces on page 61

• Verifying Chassis Cluster Data Plane Statistics on page 63

• Clearing Chassis Cluster Data Plane Statistics on page 64

Verifying Chassis Cluster Data Plane Statistics

Supported Platforms SRX Series, vSRX

Purpose Display chassis cluster data plane statistics.

Action From the CLI, enter the show chassis cluster data-plane statistics command:

{primary:node1}
user@host> show chassis cluster data-plane statistics

Services Synchronized:

Copyright © 2016, Juniper Networks, Inc. 63

Chassis Cluster Feature Guide for Branch SRX Series Devices

Service name RTOs sent RTOs received

Translation context 0 0
Incoming NAT 0 0
Resource manager 0 0
Session create 0 0
Session close 0 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RTSP ALG 0 0

Related • Understanding Chassis Cluster Fabric Interfaces for Branch SRX Series on page 57
Documentation
• Understanding Chassis Cluster Fabric Interfaces for High-End SRX Series

• Example: Configuring the Chassis Cluster Fabric Interfaces on page 61

• Verifying Chassis Cluster Data Plane Interfaces on page 63

• Clearing Chassis Cluster Data Plane Statistics on page 64

Clearing Chassis Cluster Data Plane Statistics

Supported Platforms SRX Series, vSRX

To clear displayed chassis cluster data plane statistics, enter the clear chassis cluster
data-plane statistics command from the CLI:

{primary:node1}
user@host> clear chassis cluster data-plane statistics

Cleared data-plane statistics

Related • Understanding Chassis Cluster Fabric Interfaces for Branch SRX Series on page 57
Documentation
• Understanding Chassis Cluster Fabric Interfaces for High-End SRX Series

• Example: Configuring the Chassis Cluster Fabric Interfaces on page 61

• Verifying Chassis Cluster Data Plane Statistics on page 63

• Verifying Chassis Cluster Data Plane Interfaces on page 63

64 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 8

Setting Up Control Plane Interfaces on a

Chassis Cluster

• Understanding Chassis Cluster Control Plane and Control Links on page 65

• Verifying Chassis Cluster Control Plane Statistics on page 66
• Clearing Chassis Cluster Control Plane Statistics on page 67

Understanding Chassis Cluster Control Plane and Control Links

Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550, vSRX

Understanding the Chassis Cluster Control Plane

The control plane software, which operates in active or backup mode, is an integral part
of Junos OS that is active on the primary node of a cluster. It achieves redundancy by
communicating state, configuration, and other information to the inactive Routing Engine
on the secondary node. If the master Routing Engine fails, the secondary one is ready to
assume control.

The control plane software:

• Runs on the Routing Engine and oversees the entire chassis cluster system, including
interfaces on both nodes

• Manages system and data plane resources, including the Packet Forwarding Engine
(PFE) on each node

• Synchronizes the configuration over the control link

• Establishes and maintains sessions, including authentication, authorization, and

accounting (AAA) functions

• Manages application-specific signaling protocols

• Establishes and maintains management sessions, such as Telnet connections

• Handles asymmetric routing

• Manages routing state, Address Resolution Protocol (ARP) processing, and Dynamic
Host Configuration Protocol (DHCP) processing

Information from the control plane software follows two paths:

Copyright © 2016, Juniper Networks, Inc. 65

Chassis Cluster Feature Guide for Branch SRX Series Devices

• On the primary node (where the Routing Engine is active), control information flows
from the Routing Engine to the local Packet Forwarding Engine.

• Control information flows across the control link to the secondary node's Routing
Engine and Packet Forwarding Engine.

The control plane software running on the master Routing Engine maintains state for
the entire cluster, and only processes running on its node can update state information.
The master Routing Engine synchronizes state for the secondary node and also processes
all host traffic.

NOTE: For a single control link in a chassis cluster, the same control port
should be used for the control link connection and for configuration on both
nodes. For example, if port 0 is configured as a control port on node 0, then
port 0 should be configured as a control port on node 1 with a cable connection
between the two ports. For dual control links, control port 0 on node 0 should
be connected to control port 0 on node 1 and control port 1 should be
connected to control port 1 on node 1. Cross connections, that is, connecting
port 0 on one node to port 1 on the other node and vice versa, do not work.

Understanding Chassis Cluster Control Links

The control interfaces provide the control link between the two nodes in the cluster and
are used for routing updates and for control plane signal traffic, such as heartbeat and
threshold information that triggers node failover. The control link is also used to
synchronize the configuration between the nodes. When you submit configuration
statements to the cluster, the configuration is automatically synchronized over the control
link.

The control link relies on a proprietary protocol to transmit session state, configuration,
and liveliness signals across the nodes.

SRX1500 devices use the dedicated control port.

For SRX300, SRX320, SRX340, SRX345, and SRX550 devices, the control link uses the
ge-0/0/1 interface.

For details about port and interface usage for management, control, and fabric links, see
Table 6 on page 48.

Related • Verifying Chassis Cluster Control Plane Statistics on page 66

Documentation
• Clearing Chassis Cluster Control Plane Statistics on page 67

Verifying Chassis Cluster Control Plane Statistics

Supported Platforms SRX Series, vSRX

Purpose Display chassis cluster control plane statistics.

66 Copyright © 2016, Juniper Networks, Inc.

 Chapter 8: Setting Up Control Plane Interfaces on a Chassis Cluster

Action From the CLI, enter the show chassis cluster control-plane statistics command:

{primary:node1}
user@host> show chassis cluster control-plane statistics

Control link statistics:

Control link 0:
Heartbeat packets sent: 124
Heartbeat packets received: 125
Fabric link statistics:
Child link 0
Probes sent: 124
Probes received: 125

{primary:node1}
user@host> show chassis cluster control-plane statistics

Control link statistics:

Control link 0:
Heartbeat packets sent: 258698
Heartbeat packets received: 258693
Control link 1:
Heartbeat packets sent: 258698
Heartbeat packets received: 258693
Fabric link statistics:
Child link 0
Probes sent: 258690
Probes received: 258690
Child link 1
Probes sent: 258505
Probes received: 258505

Related • Clearing Chassis Cluster Control Plane Statistics on page 67

Documentation

Clearing Chassis Cluster Control Plane Statistics

Supported Platforms SRX Series, vSRX

To clear displayed chassis cluster control plane statistics, enter the clear chassis cluster
control-plane statistics command from the CLI:

{primary:node1}
user@host> clear chassis cluster control-plane statistics

Cleared control-plane statistics

Related • Verifying Chassis Cluster Control Plane Statistics on page 66

Documentation

Copyright © 2016, Juniper Networks, Inc. 67

Chassis Cluster Feature Guide for Branch SRX Series Devices

68 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 9

Setting Up Chassis Cluster Redundancy

Groups

• Understanding Chassis Cluster Redundancy Groups on page 69

• Example: Configuring Chassis Cluster Redundancy Groups on page 73

Understanding Chassis Cluster Redundancy Groups

Supported Platforms SRX Series, vSRX

Chassis clustering provides high availability of interfaces and services through redundancy
groups and primacy within groups.

A redundancy group is an abstract construct that includes and manages a collection of

objects. A redundancy group contains objects on both nodes. A redundancy group is
primary on one node and backup on the other at any time. When a redundancy group is
said to be primary on a node, its objects on that node are active.

Redundancy groups are independent units of failover. Each redundancy group fails over
from one node to the other independent of other redundancy groups. When a redundancy
group fails over, all its objects fail over together.

Three things determine the primacy of a redundancy group: the priority configured for
the node, the node ID (in case of tied priorities), and the order in which the node comes
up. If a lower priority node comes up first, then it will assume the primacy for a redundancy
group (and will stay as primary if preempt is not enabled). If preempt is added to a
redundancy group configuration, the device with the higher priority in the group can initiate
a failover to become master. By default, preemption is disabled. For more information
on preemeption, see preempt (Chassis Cluster).

A chassis cluster can include many redundancy groups, some of which might be primary
on one node and some of which might be primary on the other. Alternatively, all
redundancy groups can be primary on a single node. One redundancy group's primacy
does not affect another redundancy group's primacy. You can create up to 128 redundancy
groups.

NOTE: The maximum number of redundancy groups is equal to the number

of redundant Ethernet interfaces that you configure.

Copyright © 2016, Juniper Networks, Inc. 69

Chassis Cluster Feature Guide for Branch SRX Series Devices

You can configure redundancy groups to suit your deployment. You configure a redundancy
group to be primary on one node and backup on the other node. You specify the node on
which the group is primary by setting priorities for both nodes within a redundancy group
configuration. The node with the higher priority takes precedence, and the redundancy
group's objects on it are active.

If a redundancy group is configured so that both nodes have the same priority, the node
with the lowest node ID number always takes precedence, and the redundancy group is
primary on it. In a two-node cluster, node 0 always takes precedence in a priority tie.

Understanding Chassis Cluster Redundancy Group 0: Routing Engines

When you initialize a device in chassis cluster mode, the system creates a redundancy
group referred to as redundancy group 0. Redundancy group 0 manages the primacy
and failover between the Routing Engines on each node of the cluster. As is the case for
all redundancy groups, redundancy group 0 can be primary on only one node at a time.
The node on which redundancy group 0 is primary determines which Routing Engine is
active in the cluster. A node is considered the primary node of the cluster if its Routing
Engine is the active one.

The redundancy group 0 configuration specifies the priority for each node. The following
priority scheme determines redundancy group 0 primacy. Note that the three-second
value is the interval if the default heartbeat-threshold and heartbeat-interval values are
used.

• The node that comes up first (at least three seconds prior to the other node) is the
primary node.

• If both nodes come up at the same time (or within three seconds of each other):

• The node with the higher configured priority is the primary node.

• If there is a tie (either because the same value was configured or because default
settings were used), the node with the lower node ID (node 0) is the primary node.

The previous priority scheme applies to redundancy groups x (redundancy groups

numbered 1 through 128) as well, provided preempt is not configured. (See “Example:
Configuring Chassis Cluster Redundancy Groups” on page 73.)

You cannot enable preemption for redundancy group 0. If you want to change the primary
node for redundancy group 0, you must do a manual failover.

CAUTION: Be cautious and judicious in your use of redundancy group 0

manual failovers. A redundancy group 0 failover implies a Routing Engine
failover, in which case all processes running on the primary node are killed
and then spawned on the new master Routing Engine. This failover could
result in loss of state, such as routing state, and degrade performance by
introducing system churn.

70 Copyright © 2016, Juniper Networks, Inc.

 Chapter 9: Setting Up Chassis Cluster Redundancy Groups

Understanding Chassis Cluster Redundancy Groups 1 Through 128

You can configure one or more redundancy groups numbered 1 through 128, referred to
as redundancy group x. The maximum number of redundancy groups is equal to the
number of redundant Ethernet interfaces that you configure (see Table 8 on page 78).
Each redundancy group x acts as an independent unit of failover and is primary on only
one node at a time.

Each redundancy group x contains one or more redundant Ethernet interfaces. A redundant
Ethernet interface is a pseudointerface that contains at minimum a pair of physical
Gigabit Ethernet interfaces or a pair of Fast Ethernet interfaces. If a redundancy group is
active on node 0, then the child links of all the associated redundant Ethernet interfaces
on node 0 are active. If the redundancy group fails over to node 1, then the child links of
all redundant Ethernet interfaces on node 1 become active.

The following priority scheme determines redundancy group x primacy, provided preempt
is not configured. If preempt is configured, the node with the higher priority is the primary
node. Note that the three-second value is the interval if the default heartbeat-threshold
and heartbeat-interval values are used.

• The node that comes up first (at least three seconds prior to the other node) is the
primary node.

• If both nodes come up at the same time (or within three seconds of each other):

• The node with the higher configured priority is the primary node.

• If there is a tie (either because the same value was configured or because default
settings were used), the node with the lower node ID (node 0) is the primary node.

On SRX Series chassis clusters, you can configure multiple redundancy groups to
load-share traffic across the cluster. For example, you can configure some redundancy
groups x to be primary on one node and some redundancy groups x to be primary on the
other node. You can also configure a redundancy group x in a one-to-one relationship
with a single redundant Ethernet interface to control which interface traffic flows through.

The traffic for a redundancy group is processed on the node where the redundancy group
is active. Because more than one redundancy group can be configured, it is possible that
the traffic from some redundancy groups will be processed on one node while the traffic
for other redundancy groups is processed on the other node (depending on where the
redundancy group is active). Multiple redundancy groups make it possible for traffic to
arrive over an ingress interface of one redundancy group and over an egress interface
that belongs to another redundancy group. In this situation, the ingress and egress
interfaces might not be active on the same node. When this happens, the traffic is
forwarded over the fabric link to the appropriate node.

When you configure a redundancy group x, you must specify a priority for each node to
determine the node on which the redundancy group x is primary. The node with the higher
priority is selected as primary. The primacy of a redundancy group x can fail over from
one node to the other. When a redundancy group x fails over to the other node, its

Copyright © 2016, Juniper Networks, Inc. 71

Chassis Cluster Feature Guide for Branch SRX Series Devices

redundant Ethernet interfaces on that node are active and their interfaces are passing
traffic.

Table 7 on page 72 gives an example of redundancy group x in an SRX Series chassis

cluster and indicates the node on which the group is primary. It shows the redundant
Ethernet interfaces and their interfaces configured for redundancy group x.

NOTE: Some devices have both Gigabit Ethernet ports and Fast Ethernet
ports.

Table 7: Example of Redundancy Groups in a Chassis Cluster

Interface
Group Primary Priority Objects Interface (Node 0) (Node 1)

Redundancy group Node 0 Node 0: 254 Routing Engine on node — —

0 0

Node 1: 2 Routing Engine on node — —

1

Redundancy group Node 0 Node 0: 254 Redundant Ethernet ge-1/0/0 ge-5/0/0

1 interface 0

Node 1: 2 Redundant Ethernet ge-1/3/0 ge-5/3/0

interface 1

Redundancy group Node 1 Node 0: 2 Redundant Ethernet ge-2/0/0 ge-6/0/0

2 interface 2

Node 1: 254 Redundant Ethernet ge-2/3/0 ge-6/3/0

interface 3

Redundancy group Node 0 Node 0: 254 Redundant Ethernet ge-3/0/0 ge-7/0/0

3 interface 4

Node 1: 2 Redundant Ethernet ge-3/3/0 ge-7/3/0

interface 5

As the example for a chassis cluster in Table 7 on page 72 shows:

• The Routing Engine on node 0 is active because redundancy group 0 is primary on

node 0. (The Routing Engine on node 1 is passive, serving as backup.)

• Redundancy group 1 is primary on node 0. Interfaces ge-1/0/0 and ge-1/3/0 belonging

to redundant Ethernet interface 0 and redundant Ethernet interface 1 are active and
handling traffic.

72 Copyright © 2016, Juniper Networks, Inc.

 Chapter 9: Setting Up Chassis Cluster Redundancy Groups

• Redundancy group 2 is primary on node 1. Interfaces ge-6/0/0 and ge-6/3/0 belonging

to redundant Ethernet interface 2 and redundant Ethernet interface 3 are active and
handling traffic.

• Redundancy group 3 is primary on node 0. Interfaces ge-3/0/0 and ge-3/3/0 belonging

to redundant Ethernet interface 4 and redundant Ethernet interface 5 are active and
handling traffic.

Related • Example: Configuring Chassis Cluster Redundancy Groups on page 73

Documentation

Example: Configuring Chassis Cluster Redundancy Groups

Supported Platforms SRX Series, vSRX

This example shows how to configure a chassis cluster redundancy group.

• Requirements on page 73
• Overview on page 73
• Configuration on page 74
• Verification on page 75

Requirements
Before you begin:

1. Set the chassis cluster node ID and cluster ID. See “Example: Setting the Chassis
Cluster Node ID and Cluster ID for Branch SRX Series Devices” on page 51 or Example:
Setting the Chassis Cluster Node ID and Cluster ID for High-End SRX Series Devices.

2. Configure the chassis cluster management interface. See “Example: Configuring the
Chassis Cluster Management Interface” on page 53.

3. Configure the chassis cluster fabric. See “Example: Configuring the Chassis Cluster
Fabric Interfaces” on page 61.

Overview
A chassis cluster redundancy group is an abstract entity that includes and manages a
collection of objects. Each redundancy group acts as an independent unit of failover and
is primary on only one node at a time.

In this example, you create two chassis cluster redundancy groups, 0 and 1:

• 0—Node 0 is assigned a priority of 100, and node 1 is assigned a priority of 1.

• 1—Node 0 is assigned a priority of 100, and node 1 is assigned a priority of 1.

The preempt option is enabled, and the number of gratuitous ARP requests that an
interface can send to notify other network devices of its presence after the redundancy
group it belongs to has failed over is 4.

Copyright © 2016, Juniper Networks, Inc. 73

Chassis Cluster Feature Guide for Branch SRX Series Devices

Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.

[edit]
set chassis cluster redundancy-group 0 node 0 priority 100
set chassis cluster redundancy-group 0 node 1 priority 1
set chassis cluster redundancy-group 1 node 0 priority 100
set chassis cluster redundancy-group 1 node 1 priority 1
set chassis cluster redundancy-group 1 preempt
set chassis cluster redundancy-group 1 gratuitous-arp-count 4

Step-by-Step To configure a chassis cluster redundancy group:

Procedure
1. Specify a redundancy group's priority for primacy on each node of the cluster. The
higher number takes precedence.

{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 0 node 0 priority 100
user@host# set chassis cluster redundancy-group 0 node 1 priority 1
user@host# set chassis cluster redundancy-group 1 node 0 priority 100
user@host# set chassis cluster redundancy-group 1 node 1 priority 1

2. Specify whether a node with a higher priority can initiate a failover to become primary
for the redundancy group.

{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 preempt

3. Specify the number of gratuitous ARP requests that an interface can send to notify
other network devices of its presence after the redundancy group it belongs to has
failed over.

{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 gratuitous-arp-count 4

Results From configuration mode, confirm your configuration by entering the show chassis cluster
status redundancy-group commands. If the output does not display the intended
configuration, repeat the configuration instructions in this example to correct it.

{primary:node0}[edit]
user@host# show chassis cluster
chassis {
cluster {
redundancy-group 0 {
node 0 priority 100;
node 1 priority 1;
}
redundancy-group 1 {
node 0 priority 100;
node 1 priority 1;
preempt;

74 Copyright © 2016, Juniper Networks, Inc.

 Chapter 9: Setting Up Chassis Cluster Redundancy Groups

gratuitous-arp-count 4;
}
}
}

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying Chassis Cluster Redundancy Group Status

Purpose Verify the status of a chassis cluster redundancy group.

Action From operational mode, enter the show chassis cluster status redundancy-group command.

{primary:node0}
user@host>show chassis cluster status redundancy-group 1

Cluster ID: 1
Node Priority Status Preempt Manual failover

Redundancy group: 1 , Failover count: 1

node0 100 secondary no no
node1 1 primary yes no

Related • Understanding Chassis Cluster Redundancy Groups on page 69

Documentation

Copyright © 2016, Juniper Networks, Inc. 75

Chassis Cluster Feature Guide for Branch SRX Series Devices

76 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 10

Setting Up Chassis Cluster Redundant

Ethernet Interfaces

• Understanding Chassis Cluster Redundant Ethernet Interfaces on page 77

• Example: Configuring Chassis Cluster Redundant Ethernet Interfaces for IPv4 and IPv6
Addresses on page 79
• Example: Configuring the Number of Redundant Ethernet Interfaces in a Chassis
Cluster on page 84

Understanding Chassis Cluster Redundant Ethernet Interfaces

Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550, vSRX

A redundant Ethernet interface is a pseudointerface that includes at minimum one

physical interface from each node of the cluster.

NOTE: For SRX300, SRX320, SRX340, SRX345, SRX550, and SRX1500

devices, the total number of logical interfaces that you can configure across
all the redundant Ethernet (reth) interfaces in a chassis cluster deployment
is 1024.

A redundant Ethernet interface must contain, at minimum, a pair of Fast Ethernet

interfaces or a pair of Gigabit Ethernet interfaces that are referred to as child interfaces
of the redundant Ethernet interface (the redundant parent). If two or more child interfaces
from each node are assigned to the redundant Ethernet interface, a redundant Ethernet
interface link aggregation group can be formed. A single redundant Ethernet interface
might include a Fast Ethernet interface from node 0 and a Fast Ethernet interface from
node 1 or a Gigabit Ethernet interface from node 0 and a Gigabit Ethernet interface from
node 1.

NOTE: A redundant Ethernet interface is referred to as a reth in configuration

commands.

The maximum number of redundant Ethernet interfaces that you can configure varies,
depending on the device type you are using, as shown in Table 8 on page 78. Note that

Copyright © 2016, Juniper Networks, Inc. 77

Chassis Cluster Feature Guide for Branch SRX Series Devices

the number of redundant Ethernet interfaces configured determines the number of

redundancy groups that can be configured.

Table 8: Maximum Number of Redundant Ethernet Interfaces Allowed

Maximum Number of
Device reth Interfaces

SRX300, 128
SRX320,
SRX340,
SRX345

SRX550 58

SRX1500 128

A redundant Ethernet interface's child interface is associated with the redundant Ethernet
interface as part of the child interface configuration. The redundant Ethernet interface
child interface inherits most of its configuration from its parent.

NOTE: You can enable promiscuous mode on redundant Ethernet interfaces.

When promiscuous mode is enabled on a Layer 3 Ethernet interface, all
packets received on the interface are sent to the central point or Services
Processing Unit (SPU), regardless of the destination MAC address of the
packet. If you enable promiscuous mode on a redundant Ethernet interface,
promiscuous mode is then enabled on any child physical interfaces.

To enable promiscuous mode on a redundant Ethernet interface, use the

promiscuous-mode statement at the [edit interfaces] hierarchy.

A redundant Ethernet interface inherits its failover properties from the redundancy group
x that it belongs to. A redundant Ethernet interface remains active as long as its primary
child interface is available or active. For example, if reth0 is associated with redundancy
group 1 and redundancy group 1 is active on node 0, then reth0 is up as long as the node
0 child of reth0 is up.

Point-to-Point Protocol over Ethernet (PPPoE) over redundant Ethernet (reth) interface
is supported on SRX300, SRX320, SRX340, SRX345, and SRX550 devices in chassis
cluster mode. This feature allows an existing PPPoE session to continue without starting
a new PPP0E session in the event of a failover.

NOTE: On all branch SRX Series devices, the number of child interfaces per
node is restricted to eight on the reth interface and the number of child
interfaces per reth interface is restricted to eight.

78 Copyright © 2016, Juniper Networks, Inc.

 Chapter 10: Setting Up Chassis Cluster Redundant Ethernet Interfaces

NOTE: When using SRX Series devices in chassis cluster mode, we

recommend that you do not configure any local interfaces (or combination
of local interfaces) along with redundant Ethernet interfaces.

For example:

The following configuration of chassis cluster redundant Ethernet interfaces,

in which interfaces are configured as local interfaces, is not supported:

ge-2/0/2 {
unit 0 {
family inet {
address 1.1.1.1/24;
}
}
}

The following configuration of chassis cluster redundant Ethernet interfaces,

in which interfaces are configured as part of redundant Ethernet interfaces,
is supported:

interfaces {
ge-2/0/2 {
gigether-options {
redundant-parent reth2;
}
}
reth2 {
redundant-ether-options {
redundancy-group 1;
}
unit 0 {
family inet {
address 1.1.1.1/24;
}
}
}
}

Related • Example: Configuring Chassis Cluster Redundant Ethernet Interfaces for IPv4 and IPv6
Documentation Addresses on page 79

• Understanding Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups

on page 165

• Understanding Conditional Route Advertising in a Chassis Cluster on page 159

• Preparing Your Equipment for Chassis Cluster Formation on page 35

Example: Configuring Chassis Cluster Redundant Ethernet Interfaces for IPv4 and IPv6
Addresses

Supported Platforms SRX Series, vSRX

Copyright © 2016, Juniper Networks, Inc. 79

Chassis Cluster Feature Guide for Branch SRX Series Devices

This example shows how to configure chassis cluster redundant Ethernet interfaces. A
redundant Ethernet interface is a pseudointerface that contains two or more physical
interfaces, with at least one from each node of the cluster.

• Requirements on page 80
• Overview on page 80
• Configuration on page 80
• Verification on page 83

Requirements
Before you begin:

• Understand how to set the chassis cluster node ID and cluster ID. See “Example: Setting
the Chassis Cluster Node ID and Cluster ID for Branch SRX Series Devices” on page 51
or Example: Setting the Chassis Cluster Node ID and Cluster ID for High-End SRX Series
Devices.

• Set the number of redundant Ethernet interfaces.

• Understand how to set the chassis cluster fabric. See “Example: Configuring the Chassis
Cluster Fabric Interfaces” on page 61.

• Understand how to set the chassis cluster node redundancy groups. See “Example:
Configuring Chassis Cluster Redundancy Groups” on page 73.

Overview
After physical interfaces have been assigned to the redundant Ethernet interface, you
set the configuration that pertains to them at the level of the redundant Ethernet interface,
and each of the child interfaces inherits the configuration.

If multiple child interfaces are present, then the speed of all the child interfaces must be
the same.

A redundant Ethernet interface is referred to as a reth in configuration commands.

NOTE: You can enable promiscuous mode on redundant Ethernet interfaces.

When promiscuous mode is enabled on a Layer 3 Ethernet interface, all
packets received on the interface are sent to the central point or Services
Processing Unit regardless of the destination MAC address of the packet. If
you enable promiscuous mode on a redundant Ethernet interface,
promiscuous mode is then enabled on any child physical interfaces.

To enable promiscuous mode on a redundant Ethernet interface, use the

promiscuous-mode statement at the [edit interfaces] hierarchy.

Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network

80 Copyright © 2016, Juniper Networks, Inc.

 Chapter 10: Setting Up Chassis Cluster Redundant Ethernet Interfaces

configuration, and copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.

{primary:node0}[edit]
user@host# set interfaces ge-0/0/0 gigether-options redundant-parent reth1
set interfaces ge-7/0/0 gigether-options redundant-parent reth1
set interfaces fe-1/0/0 fast-ether-options redundant-parent reth2
set interfaces fe-8/0/0 fast-ether-options redundant-parent reth2
set interfaces reth1 redundant-ether-options redundancy-group 1
set interfaces reth1 unit 0 family inet mtu 1500
set interfaces reth1 unit 0 family inet address 10.1.1.3/24
set security zones security-zone Trust interfaces reth1.0

To quickly configure this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your network
configuration, and copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.

{primary:node0}[edit]
user@host# set interfaces ge-0/0/0 gigether-options redundant-parent reth1
set interfaces ge-7/0/0 gigether-options redundant-parent reth1
set interfaces fe-1/0/0 fast-ether-options redundant-parent reth2
set interfaces fe-8/0/0 fast-ether-options redundant-parent reth2
set interfaces reth2 redundant-ether-options redundancy-group 1
set interfaces reth2 unit 0 family inet6 mtu 1500
set interfaces reth2 unit 0 family inet6 address 2010:2010:201::2/64
set security zones security-zone Trust interfaces reth2.0

Step-by-Step To configure redundant Ethernet interfaces for IPv4:

Procedure
1. Bind redundant child physical interfaces to reth1.

{primary:node0}[edit]
user@host# set interfaces ge-0/0/0 gigether-options redundant-parent reth1
user@host# set interfaces ge-7/0/0 gigether-options redundant-parent reth1

2. Bind redundant child physical interfaces to reth2.

{primary:node0}[edit]
user@host# set interfaces fe-1/0/0 fast-ether-options redundant-parent reth2
user@host# set interfaces fe-8/0/0 fast-ether-options redundant-parent reth2

3. Add reth1 to redundancy group 1.

{primary:node0}[edit]
user@host# set interfaces reth1 redundant-ether-options redundancy-group 1

4. Set the MTU size.

{primary:node0}[edit]
user@host# set interfaces reth1 unit 0 family inet mtu 1500

NOTE: The maximum transmission unit (MTU) set on the reth interface
can be different from the MTU on the child interface.

Copyright © 2016, Juniper Networks, Inc. 81

Chassis Cluster Feature Guide for Branch SRX Series Devices

5. Assign an IP address to reth1.

{primary:node0}[edit]
user@host# set interfaces reth1 unit 0 family inet address 10.1.1.3/24

6. Associate reth1.0 to the trust security zone.

{primary:node0}[edit]
user@host# set security zones security-zone Trust interfaces reth1.0

Step-by-Step To configure redundant Ethernet interfaces for IPv6:

Procedure
1. Bind redundant child physical interfaces to reth1.

{primary:node0}[edit]
user@host# set interfaces ge-0/0/0 gigether-options redundant-parent reth1
user@host# set interfaces ge-7/0/0 gigether-options redundant-parent reth1

2. Bind redundant child physical interfaces to reth2.

{primary:node0}[edit]
user@host# set interfaces fe-1/0/0 fast-ether-options redundant-parent reth2
user@host# set interfaces fe-8/0/0 fast-ether-options redundant-parent reth2

3. Add reth2 to redundancy group 1.

{primary:node0}[edit]
user@host# set interfaces reth2 redundant-ether-options redundancy-group 1

4. Set the MTU size.

{primary:node0}[edit]
user@host# set interfaces reth2 unit 0 family inet6 mtu 1500

5. Assign an IP address to reth2.

{primary:node0}[edit]
user@host# set interfaces reth2 unit 0 family inet6 address 2010:2010:201::2/64

6. Associate reth2.0 to the trust security zone.

{primary:node0}[edit]
user@host# set security zones security-zone Trust interfaces reth2.0

Results From configuration mode, confirm your configuration by entering the show interfaces
reth0 command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).

{primary:node0}[edit]
user@host# show interfaces
interfaces {
...
fe-1/0/0 {
fastether-options {
redundant-parent reth2;
}

82 Copyright © 2016, Juniper Networks, Inc.

 Chapter 10: Setting Up Chassis Cluster Redundant Ethernet Interfaces

}
fe-8/0/0 {
fastether-options {
redundant-parent reth2;
}
}
ge-0/0/0 {
gigether-options {
redundant-parent reth1;
}
}
ge-7/0/0 {
gigether-options {
redundant-parent reth1;
}
}
reth1 {
redundant-ether-options {
redundancy-group 1;
}
unit 0 {
family inet {
mtu 1500;
address 10.1.1.3/24;
}
}
}
reth2 {
redundant-ether-options {
redundancy-group 1;
}
unit 0 {
family inet6 {
mtu 1500;
address 2010:2010:201::2/64;
}
}
}
...
}

If you are done configuring the device, enter commit from configuration mode.

Verification
Confirm that the configuration is working properly.

• Verifying Chassis Cluster Redundant Ethernet Interfaces on page 83

• Verifying Chassis Cluster Control Links on page 84

Verifying Chassis Cluster Redundant Ethernet Interfaces

Purpose Verify the configuration of the chassis cluster redundant Ethernet interfaces.

Copyright © 2016, Juniper Networks, Inc. 83

Chassis Cluster Feature Guide for Branch SRX Series Devices

Action From operational mode, enter the show interfaces | match reth1 command:

{primary:node0}
user@host> show interfaces | match reth1
ge-0/0/0.0 up down aenet --> reth1.0
ge-7/0/0.0 up down aenet --> reth0.0
reth1 up down
reth1.0 up down inet 10.1.1.3/24

Verifying Chassis Cluster Control Links

Purpose Verify information about the control interface in a chassis cluster configuration.

Action From operational mode, enter the show chassis cluster interfaces command:

{primary:node0}
user@host> show chassis cluster interfaces

Control link status: Down

Control interfaces:
Index Interface Monitored-Status Internal-SA
0 em0 Down Disabled
1 em1 Down Disabled

Fabric link status: Down

Fabric interfaces:
Name Child-interface Status
(Physical/Monitored)
fab0
fab0

Redundant-pseudo-interface Information:
Name Status Redundancy-group
reth1 Up 1

Related • Understanding Chassis Cluster Redundant Ethernet Interfaces on page 77

Documentation

Example: Configuring the Number of Redundant Ethernet Interfaces in a Chassis Cluster

Supported Platforms SRX Series, vSRX

This example shows how to specify the number of redundant Ethernet interfaces for a
chassis cluster. You must configure the redundant Ethernet interfaces count so that the
redundant Ethernet interfaces that you configure are recognized.

• Requirements on page 85
• Overview on page 85
• Configuration on page 85
• Verification on page 85

84 Copyright © 2016, Juniper Networks, Inc.

 Chapter 10: Setting Up Chassis Cluster Redundant Ethernet Interfaces

Requirements
Before you begin, set the chassis cluster ID and chassis cluster node ID. See “Example:
Setting the Chassis Cluster Node ID and Cluster ID for Branch SRX Series Devices” on
page 51 or Example: Setting the Chassis Cluster Node ID and Cluster ID for High-End SRX
Series Devices.

Overview
Before you configure redundant Ethernet interfaces for a chassis cluster, you must specify
the number of redundant Ethernet interfaces for the chassis cluster.

In this example, you set the number of redundant Ethernet interfaces for a chassis cluster
to 2.

Configuration
Step-by-Step To set the number of redundant Ethernet interfaces for a chassis cluster:
Procedure
1. Specify the number of redundant Ethernet interfaces:

{primary:node0}[edit]
user@host# set chassis cluster reth-count 2

2. If you are done configuring the device, commit the configuration.

[edit]
user@host# commit

Verification

Verifying the Number of Redundant Ethernet Interfaces

Purpose Verify that the configuration is working properly.

Action To verify the configuration, enter the show configuration chassis cluster command.

Related • Example: Configuring Chassis Cluster Redundant Ethernet Interfaces for IPv4 and IPv6
Documentation Addresses on page 79

Copyright © 2016, Juniper Networks, Inc. 85

Chassis Cluster Feature Guide for Branch SRX Series Devices

86 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 11

Configuring Chassis Cluster

• Example: Configuring an SRX Series Services Gateway for the Branch as a Chassis
Cluster on page 87
• Verifying a Chassis Cluster Configuration on page 99
• Verifying Chassis Cluster Statistics on page 99
• Clearing Chassis Cluster Statistics on page 101

Example: Configuring an SRX Series Services Gateway for the Branch as a Chassis
Cluster

Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550, vSRX

This example shows how to set up chassis clustering on an SRX Series for the branch
device.

• Requirements on page 87
• Overview on page 88
• Configuration on page 89
• Verification on page 95

Requirements
Before you begin:

• Physically connect the two devices and ensure that they are the same models. For
example, on the SRX1500 Services Gateway, connect the dedicated control ports on
node 0 and node 1.

NOTE: For SRX300, SRX320, SRX340, and SRX345 devices, connect

ge-0/0/1 on node 0 to ge-0/0/1 on node 1.

• Set the two devices to cluster mode and reboot the devices. You must enter the
following operational mode commands on both devices, for example:

• On node 0:

user@host> set chassis cluster cluster-id 1 node 0 reboot

Copyright © 2016, Juniper Networks, Inc. 87

Chassis Cluster Feature Guide for Branch SRX Series Devices

• On node 1:

user@host> set chassis cluster cluster-id 1 node 1 reboot

The cluster-id is the same on both devices, but the node ID must be different because
one device is node 0 and the other device is node 1. The range for the cluster-id is 0
through 255 and setting it to 0 is equivalent to disabling cluster mode.

• After clustering occurs for the devices, continuing with the SRX1500 Services Gateway
example, the ge-0/0/0 interface on node 1 changes to ge-7/0/0.

NOTE:
After clustering occurs,

• For SRX300 devices, the ge-0/0/1 interface on node 1 changes to

ge-1/0/1.

• For SRX320 devices, the ge-0/0/1 interface on node 1 changes to

ge-3/0/1.

• For SRX340 and SRX345 devices, the ge-0/0/1 interface on node 1

changes to ge-5/0/1.

NOTE:
After the reboot, the following interfaces are assigned and repurposed to
form a cluster:

• For SRX300 and SRX320 devices, ge-0/0/0 becomes fxp0 and is used
for individual management of the chassis cluster.

• SRX340 and SRX345 devices contain a dedicated port fxp0.

• For all SRX300, SRX320, SRX340 and SRX345 devices, ge-0/0/1

becomes fxp1 and is used as the control link within the chassis cluster.

• The other interfaces are also renamed on the secondary device.

See “Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port and
Logical Interface Naming” on page 47 for complete mapping of the SRX Series devices.

From this point forward, configuration of the cluster is synchronized between the node
members and the two separate devices function as one device.

Overview
This example shows how to set up chassis clustering on an SRX Series device using the
SRX1500 device as example.

The node 1 renumbers its interfaces by adding the total number of system FPCs to the
original FPC number of the interface. See Table 9 on page 89 for interface renumbering
on the SRX Series device.

88 Copyright © 2016, Juniper Networks, Inc.

 Chapter 11: Configuring Chassis Cluster

Table 9: SRX Series Services Gateways Interface Renumbering

Renumbering
SRX Series Services Gateway Constant Node 0 Interface Name Node 1 Interface Name

SRX300 1 ge-0/0/0 ge-1/0/0

SRX320 3 ge-0/0/0 ge-3/0/0

SRX340 5 ge-0/0/0 ge-5/0/0

SRX345

SRX550 9 ge-0/0/0 ge-9/0/0

SRX1500 7 ge-0/0/0 ge-7/0/0

After clustering is enabled, the system creates fxp0, fxp1, and em0 interfaces. Depending
on the device, the fxp0, fxp1, and em0 interfaces that are mapped to a physical interface
are not user defined. However, the fab interface is user defined.

Figure 14 on page 89 shows the topology used in this example.

Figure 14: SRX Series for the Branch Topology Example

Configuration
CLI Quick To quickly configure a chassis cluster on an SRX1500 Services Gateway, copy the following
Configuration commands and paste them into the CLI:

On {primary:node0}

[edit]
set groups node0 system host-name srx1500-1
set groups node0 interfaces fxp0 unit 0 family inet address 192.16.35.46/24
set groups node1 system host-name srx1500-2

Copyright © 2016, Juniper Networks, Inc. 89

Chassis Cluster Feature Guide for Branch SRX Series Devices

set groups node1 interfaces fxp0 unit 0 family inet address 192.16.35.47/24
set groups node0 system backup-router <backup next-hop from fxp0> destination
<management network/mask>
set groups node1 system backup-router <backup next-hop from fxp0> destination
<management network/mask>
set apply-groups "${node}"
set interfaces fab0 fabric-options member-interfaces ge-0/0/1
set interfaces fab1 fabric-options member-interfaces ge-2/0/1
set chassis cluster redundancy-group 0 node 0 priority 100
set chassis cluster redundancy-group 0 node 1 priority 1
set chassis cluster redundancy-group 1 node 0 priority 100
set chassis cluster redundancy-group 1 node 1 priority 1
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/3 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/2 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-7/0/3 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-7/0/2 weight 255
set chassis cluster reth-count 2
set interfaces ge-0/0/2 gigether-options redundant-parent reth1
set interfaces ge-7/0/2 gigether-options redundant-parent reth1
set interfaces reth1 redundant-ether-options redundancy-group 1
set interfaces reth1 unit 0 family inet address 1.2.0.233/24
set interfaces ge-0/0/3 gigether-options redundant-parent reth0
set interfaces ge-7/0/3 gigether-options redundant-parent reth0
set interfaces reth0 redundant-ether-options redundancy-group 1
set interfaces reth0 unit 0 family inet address 10.16.8.1/24
set security zones security-zone Untrust interfaces reth1.0
set security zones security-zone Trust interfaces reth0.0

If you are configuring a Branch SRX Series device, see Table 10 on page 90 for command
and interface settings for your device and substitute these commands into your CLI.

Table 10: SRX Series Services Gateways for the Branch Interface Settings
SRX340

Command SRX300 SRX320 SRX345 SRX550

set interfaces fab0 ge-0/0/2 ge-0/0/2 ge-0/0/2 ge-0/0/2

fabric-options
member-interfaces

set interfaces fab1 ge-1/0/2 ge-3/0/2 ge-5/0/2 ge-9/0/2

fabric-options
member-interfaces

set chassis cluster ge-0/0/3 weight 255 ge-0/0/3 weight 255 ge-0/0/3 weight 255 ge-1/0/0 weight 255
redundancy-group 1
interface-monitor

set chassis cluster ge-0/0/4 weight 255 ge-0/0/4 weight 255 ge-0/0/4 weight 255 ge-10/0/0 weight 255
redundancy-group 1
interface-monitor

set chassis cluster ge-1/0/3 weight 255 ge-3/0/3 weight 255 ge-5/0/3 weight 255 ge-1/0/1 weight 255
redundancy-group 1
interface-monitor

90 Copyright © 2016, Juniper Networks, Inc.

 Chapter 11: Configuring Chassis Cluster

Table 10: SRX Series Services Gateways for the Branch Interface Settings (continued)
SRX340

Command SRX300 SRX320 SRX345 SRX550

set chassis cluster ge-1/0/4 weight 255 ge-3/0/4 weight 255 ge-5/0/4 weight 255 ge-10/0/1 weight 255
redundancy-group 1
interface-monitor

set interfaces ge-0/0/3 ge-0/0/3 ge-0/0/3 ge-1/0/0

gigether-options gigether-options gigether-options gigether-options
redundant-parent redundant-parent redundant-parent reth0 redundant-parent reth1
reth0 reth0

set interfaces ge-0/0/4 ge-0/0/4 ge-0/0/4 ge-10/0/0

gigether-options gigether-options gigether-options gigether-options
redundant-parent reth1 redundant-parent reth1 redundant-parent reth1 redundant-parent reth1

set interfaces ge-1/0/3 ge-3/0/3 ge-5/0/3 ge-1/0/1

gigether-options gigether-options gigether-options gigether-options
redundant-parent redundant-parent redundant-parent reth0 redundant-parent
reth0 reth0 reth0

set interfaces ge-1/0/4 ge-3/0/4 ge-5/0/4 ge-10/0/1

gigether-options gigether-options gigether-options gigether-options
redundant-parent reth1 redundant-parent reth1 redundant-parent reth1 redundant-parent
reth0

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
Mode in the CLI User Guide.

To configure a chassis cluster on an SRX Series for the branch device:

NOTE: Perform Steps 1 through 5 on the primary device (node 0). They are
automatically copied over to the secondary device (node 1) when you execute
a commit command. The configurations are synchronized because the control
link and fab link interfaces are activated. To verify the configurations, use the
show interface terse command and review the output.

1. Set up hostnames and management IP addresses for each device using configuration
groups. These configurations are specific to each device and are unique to its specific
node.

user@host# set groups node0 system host-name srx1500-1

user@host# set groups node0 interfaces fxp0 unit 0 family inet address
192.16.35.46/24
user@host# set groups node1 system host-name srx1500-2
user@host# set groups node1 interfaces fxp0 unit 0 family inet address
192.16.35.47/24

Copyright © 2016, Juniper Networks, Inc. 91

Chassis Cluster Feature Guide for Branch SRX Series Devices

Set the default route and backup router for each node.

user@host# set groups node0 system backup-router <backup next-hop from fxp0>
destination <management network/mask>
user@host# set groups node1 system backup-router <backup next-hop from fxp0>
destination <management network/mask>

Set the apply-group command so that the individual configurations for each node
set by the previous commands are applied only to that node.

user@host# set apply-groups "${node}"

2. Define the interfaces used for the fab connection (data plane links for RTO sync)
by using physical ports ge-0/0/1 from each node. These interfaces must be
connected back-to-back, or through a Layer 2 infrastructure.

user@host# set interfaces fab0 fabric-options member-interfaces ge-0/0/1

user@host# set interfaces fab1 fabric-options member-interfaces ge-7/0/1

3. Set up redundancy group 0 for the Routing Engine failover properties, and set up
redundancy group 1 (all interfaces are in one redundancy group in this example) to
define the failover properties for the redundant Ethernet interfaces.

user@host# set chassis cluster redundancy-group 0 node 0 priority 100

user@host# set chassis cluster redundancy-group 0 node 1 priority 1
user@host# set chassis cluster redundancy-group 1 node 0 priority 100
user@host# set chassis cluster redundancy-group 1 node 1 priority 1

4. Set up interface monitoring to monitor the health of the interfaces and trigger
redundancy group failover.

NOTE: We do not recommend Interface monitoring for redundancy

group 0 because it causes the control plane to switch from one node
to another node in case interface flap occurs.

user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/3

weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/2
weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-7/0/3
weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-7/0/2
weight 255

NOTE: Interface failover only occurs after the weight reaches 0.

5. Set up the redundant Ethernet (reth) interfaces and assign the redundant interface
to a zone.

user@host# set chassis cluster reth-count 2

user@host# set interfaces ge-0/0/2 gigether-options redundant-parent reth1
user@host# set interfaces ge-7/0/2 gigether-options redundant-parent reth1

92 Copyright © 2016, Juniper Networks, Inc.

 Chapter 11: Configuring Chassis Cluster

user@host# set interfaces reth1 redundant-ether-options redundancy-group 1

user@host# set interfaces reth1 unit 0 family inet address 1.2.0.233/24
user@host# set interfaces ge-0/0/3 gigether-options redundant-parent reth0
user@host# set interfaces ge-7/0/3 gigether-options redundant-parent reth0
user@host# set interfaces reth0 redundant-ether-options redundancy-group 1
user@host# set interfaces reth0 unit 0 family inet address 10.16.8.1/24
user@host# set security zones security-zone Untrust interfaces reth1.0
user@host# set security zones security-zone Trust interfaces reth0.0

Results From operational mode, confirm your configuration by entering the show configuration
command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).

> show configuration

version x.xx.x;
groups {
node0 {
system {
host-name SRX1500-1;
backup-router 10.100.22.1 destination 66.129.243.0/24;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.16.35.46/24;
}
}
}
}
}
node1 {
system {
host-name SRX1500-2;
backup-router 10.100.21.1 destination 66.129.243.0/24; }
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.16.35.47/24;
}
}
}
}
}
}
apply-groups "${node}";
chassis {
cluster {
reth-count 2;
redundancy-group 0 {
node 0 priority 100;
node 1 priority 1;
}
redundancy-group 1 {

Copyright © 2016, Juniper Networks, Inc. 93

Chassis Cluster Feature Guide for Branch SRX Series Devices

node 0 priority 100;

node 1 priority 1;
interface-monitor {
ge–0/0/3 weight 255;
ge–0/0/2 weight 255;
ge–7/0/2 weight 255;
ge–7/0/3 weight 255;
}
}
}
}
interfaces {
ge–0/0/2 {
gigether–options {
redundant–parent reth1;
}
unit 0 {
family inet {
address 2.2.2.2/30;
}
}
}
ge–0/0/3 {
gigether–options {
redundant–parent reth0;
}
}
ge–7/0/2 {
gigether–options {
redundant–parent reth1;
}
}
ge–7/0/3 {
gigether–options {
redundant–parent reth0;
}
}
fab0 {
fabric–options {
member–interfaces {
ge–0/0/1;
}
}
}
fab1 {
fabric–options {
member–interfaces {
ge–2/0/1;
}
}
}
reth0 {
redundant–ether–options {
redundancy–group 1;
}
unit 0 {
family inet {
address 10.16.8.1/24;
}
}
}

94 Copyright © 2016, Juniper Networks, Inc.

 Chapter 11: Configuring Chassis Cluster

reth1 {
redundant–ether–options {
redundancy–group 1;
}
unit 0 {
family inet {
address 1.2.0.233/24;
}
}
}
}
...
security {
zones {
security–zone Untrust {
interfaces {
reth1.0;
}
}
security–zone Trust {
interfaces {
reth0.0;
}
}
}
policies {
from–zone Trust to–zone Untrust {
policy 1 {
match {
source–address any;
destination–address any;
application any;
}
then {
permit;
}
}
}
}
}

If you are done configuring the device, enter commit from configuration mode.

Verification
Confirm that the configuration is working properly.

• Verifying Chassis Cluster Status on page 96

• Verifying Chassis Cluster Interfaces on page 96
• Verifying Chassis Cluster Statistics on page 96
• Verifying Chassis Cluster Control Plane Statistics on page 97
• Verifying Chassis Cluster Data Plane Statistics on page 97
• Verifying Chassis Cluster Redundancy Group Status on page 98
• Troubleshooting with Logs on page 98

Copyright © 2016, Juniper Networks, Inc. 95

Chassis Cluster Feature Guide for Branch SRX Series Devices

Verifying Chassis Cluster Status

Purpose Verify the chassis cluster status, failover status, and redundancy group information.

Action From operational mode, enter the show chassis cluster status command.

{primary:node0}
user@host# show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 1

node0 100 primary no no
node1 1 secondary no no

Redundancy group: 1 , Failover count: 1

node0 0 primary no no
node1 0 secondary no no

Verifying Chassis Cluster Interfaces

Purpose Verify information about chassis cluster interfaces.

Action From operational mode, enter the show chassis cluster interfaces command.

{primary:node0}
user@host> show chassis cluster interfaces
Control link name: em0

Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
reth1 Up 1

Interface Monitoring:
Interface Weight Status Redundancy-group
ge-7/0/3 255 Up 1
ge-7/0/2 255 Up 1
ge-0/0/2 255 Up 1
ge-0/0/3 255 Up 1

Verifying Chassis Cluster Statistics

Purpose Verify information about the statistics of the different objects being synchronized, the
fabric and control interface hellos, and the status of the monitored interfaces in the
cluster.

Action From operational mode, enter the show chassis cluster statistics command.

{primary:node0}
user@host> show chassis cluster statistics

Control link statistics:

Control link 0:
Heartbeat packets sent: 2276
Heartbeat packets received: 2280
Heartbeat packets errors: 0

96 Copyright © 2016, Juniper Networks, Inc.

 Chapter 11: Configuring Chassis Cluster

Fabric link statistics:

Child link 0
Probes sent: 2272
Probes received: 597
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 6 0
Session create 161 0
Session close 148 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0
GPRS GTP 0 0

Verifying Chassis Cluster Control Plane Statistics

Purpose Verify information about chassis cluster control plane statistics (heartbeats sent and
received) and the fabric link statistics (probes sent and received).

Action From operational mode, enter the show chassis cluster control-plane statistics command.

{primary:node0}
user@host> show chassis cluster control-plane statistics

Control link statistics:

Control link 0:
Heartbeat packets sent: 2294
Heartbeat packets received: 2298
Heartbeat packets errors: 0
Fabric link statistics:
Child link 0
Probes sent: 2290
Probes received: 615

Verifying Chassis Cluster Data Plane Statistics

Purpose Verify information about the number of RTOs sent and received for services.

Action From operational mode, enter the show chassis cluster data-plane statistics command.

{primary:node0}
user@host> show chassis cluster data-plane statistics

Services Synchronized:

Copyright © 2016, Juniper Networks, Inc. 97

Chassis Cluster Feature Guide for Branch SRX Series Devices

Service name RTOs sent RTOs received

Translation context 0 0
Incoming NAT 0 0
Resource manager 6 0
Session create 161 0
Session close 148 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0
GPRS GTP 0 0

Verifying Chassis Cluster Redundancy Group Status

Purpose Verify the state and priority of both nodes in a cluster and information about whether
the primary node has been preempted or whether there has been a manual failover.

Action From operational mode, enter the chassis cluster status redundancy-group command.

{primary:node0}
user@host> show chassis cluster status redundancy-group 1
Cluster ID: 1
Node Priority Status Preempt Manual failover

Redundancy group: 1, Failover count: 1

node0 100 primary no no
node1 50 secondary no no

Troubleshooting with Logs

Purpose Use these logs to identify any chassis cluster issues. You should run these logs on both
nodes.

Action From operational mode, enter these show log commands.

user@host> show log jsrpd

user@host> show log chassisd
user@host> show log messages
user@host> show log dcd
user@host> show traceoptions

Related • Understanding Chassis Cluster Redundancy Groups on page 69.

Documentation
• Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port and
Logical Interface Naming on page 47

98 Copyright © 2016, Juniper Networks, Inc.

 Chapter 11: Configuring Chassis Cluster

Verifying a Chassis Cluster Configuration

Supported Platforms SRX Series, vSRX

Purpose Display chassis cluster verification options.

Action From the CLI, enter the show chassis cluster ? command:

{primary:node1}
user@host> show chassis cluster ?
Possible completions:
interfaces Display chassis-cluster interfaces
statistics Display chassis-cluster traffic statistics
status Display chassis-cluster status

Related • Verifying Chassis Cluster Statistics on page 99

Documentation
• Clearing Chassis Cluster Statistics on page 101

Verifying Chassis Cluster Statistics

Supported Platforms SRX Series, vSRX

Purpose Display information about chassis cluster services and interfaces.

Action From the CLI, enter the show chassis cluster statistics command:

{primary:node1}
user@host> show chassis cluster statistics

Control link statistics:

Control link 0:
Heartbeat packets sent: 798
Heartbeat packets received: 784
Fabric link statistics:
Child link 0
Probes sent: 793
Probes received: 0
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 0 0
Session create 0 0
Session close 0 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RTSP ALG 0 0

Copyright © 2016, Juniper Networks, Inc. 99

Chassis Cluster Feature Guide for Branch SRX Series Devices

{primary:node1}
user@host> show chassis cluster statistics

Control link statistics:

Control link 0:
Heartbeat packets sent: 258689
Heartbeat packets received: 258684
Control link 1:
Heartbeat packets sent: 258689
Heartbeat packets received: 258684
Fabric link statistics:
Child link 0
Probes sent: 258681
Probes received: 258681
Child link 1
Probes sent: 258501
Probes received: 258501
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 0 0
Session create 1 0
Session close 1 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0
GPRS GTP 0 0

{primary:node1}
user@host> show chassis cluster statistics

Control link statistics:

Control link 0:
Heartbeat packets sent: 82371
Heartbeat packets received: 82321
Control link 1:
Heartbeat packets sent: 0
Heartbeat packets received: 0

Related • Verifying a Chassis Cluster Configuration on page 99

Documentation
• Clearing Chassis Cluster Statistics on page 101

100 Copyright © 2016, Juniper Networks, Inc.

 Chapter 11: Configuring Chassis Cluster

Clearing Chassis Cluster Statistics

Supported Platforms SRX Series, vSRX

To clear displayed information about chassis cluster services and interfaces, enter the
clear chassis cluster statistics command from the CLI:

{primary:node1}
user@host> clear chassis cluster statistics

Cleared control-plane statistics

Cleared data-plane statistics

Related • Verifying a Chassis Cluster Configuration on page 99

Documentation
• Verifying Chassis Cluster Statistics on page 99

Copyright © 2016, Juniper Networks, Inc. 101

Chassis Cluster Feature Guide for Branch SRX Series Devices

102 Copyright © 2016, Juniper Networks, Inc.

PART 3

Managing Chassis Cluster Operations

• Monitoring Chassis Cluster on page 105
• Managing Chassis Cluster Redundancy Group Failover on page 141
• Configuring Chassis Cluster Dual Fabric Links to Increase Redundancy and
Performance on page 151
• Configuring Route Advertisement over Redundant Ethernet Interfaces in a Chassis
Cluster on page 159
• Configuring Redundant Ethernet LAG Interfaces for Increasing High Availability and
Overall Throughput on page 165
• Simplifying Chassis Cluster Management on page 181

Copyright © 2016, Juniper Networks, Inc. 103

Chassis Cluster Feature Guide for Branch SRX Series Devices

104 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 12

Monitoring Chassis Cluster

• Understanding Chassis Cluster Redundancy Group Interface Monitoring on page 105

• Example: Configuring Chassis Cluster Interface Monitoring on page 106
• Understanding Chassis Cluster Redundancy Group IP Address Monitoring on page 133
• Example: Configuring Chassis Cluster Redundancy Group IP Address
Monitoring on page 136

Understanding Chassis Cluster Redundancy Group Interface Monitoring

Supported Platforms SRX Series, vSRX

For a redundancy group to automatically failover to another node, its interfaces must be
monitored. When you configure a redundancy group, you can specify a set of interfaces
that the redundancy group is to monitor for status (or “health”) to determine whether
the interface is up or down. A monitored interface can be a child interface of any of its
redundant Ethernet interfaces. When you configure an interface for a redundancy group
to monitor, you give it a weight.

Every redundancy group has a threshold tolerance value initially set to 255. When an
interface monitored by a redundancy group becomes unavailable, its weight is subtracted
from the redundancy group's threshold. When a redundancy group's threshold reaches
0, it fails over to the other node. For example, if redundancy group 1 was primary on node
0, on the threshold-crossing event, redundancy group 1 becomes primary on node 1. In
this case, all the child interfaces of redundancy group 1's redundant Ethernet interfaces
begin handling traffic.

To check the interface weight, use the below commands:

• show chassis cluster information

• show chassis cluster interfaces

NOTE: We do not recommend configuring data plane modules such as

interface monitoring and IP monitoring on Redundancy Group 0 (RG0) for
SRX Series devices in a chassis cluster.

Copyright © 2016, Juniper Networks, Inc. 105

Chassis Cluster Feature Guide for Branch SRX Series Devices

CAUTION: Be cautious and judicious in your use of redundancy group 0

manual failovers. A redundancy group 0 failover implies a Routing Engine
(RE) failover, in which case all processes running on the primary node are
killed and then spawned on the new master Routing Engine (RE). This failover
could result in loss of state, such as routing state, and degrade performance
by introducing system churn.

A redundancy group failover occurs because the cumulative weight of the redundancy
group's monitored interfaces has brought its threshold value to 0. When the monitored
interfaces of a redundancy group on both nodes reach their thresholds at the same time,
the redundancy group is primary on the node with the lower node ID, in this case node 0.

NOTE:
• If you want to dampen the failovers occurring because of interface
monitoring failures, use the hold-down-interval statement.

• If a failover occurs on Redundancy Group 0 (RG0), the interface monitoring

on the RG0 secondary is disabled for 30 seconds. This prevents failover of
other redundancy groups along with RG0 failover.

Related • Example: Configuring Chassis Cluster Interface Monitoring on page 106

Documentation
• Understanding Chassis Cluster Redundancy Groups on page 69

• Example: Configuring Chassis Cluster Redundancy Groups on page 73

Example: Configuring Chassis Cluster Interface Monitoring

Supported Platforms SRX Series, vSRX

This example shows how to specify that an interface be monitored by a specific

redundancy group for automatic failover to another node. You assign a weight to the
interface to be monitored also shows how to verify the process of the remaining threshold
of a monitoring interface by configuring two interfaces from each node and mapping
them to redundancy groups.

• Requirements on page 106

• Overview on page 107
• Configuration on page 108
• Verification on page 112

Requirements
Before you begin, create a redundancy group. See “Example: Configuring Chassis Cluster
Redundancy Groups” on page 73.

106 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

Overview
To retrieve the remaining redundancy group threshold after a monitoring interface is
down, you can configure your system to monitor the health of the interfaces belonging
to a redundancy group. When you assign a weight to an interface to be monitored, the
system monitors the interface for availability. If a physical interface fails, the weight is
deducted from the corresponding redundancy group's threshold. Every redundancy group
has a threshold of 255. If the threshold hits 0, a failover is triggered, even if the redundancy
group is in manual failover mode and the preempt option is not enabled.

In this example, you check the process of the remaining threshold of a monitoring interface
by configuring two interfaces from each node and mapping them to Redundancy Group
1 (RG1), each with different weights. You use 130 and 140 for node 0 interfaces and 150
and 120 for node 1 interfaces. You configure one interface from each node and map the
interfaces to Redundancy Group 2 (RG2), each with default weight of 255.

Copyright © 2016, Juniper Networks, Inc. 107

Chassis Cluster Feature Guide for Branch SRX Series Devices

Figure 15 on page 108 illustrates the network topology used in this example.

Figure 15: SRX Series Chassis Cluster Interface Monitoring Topology

Example

Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, copy and paste the commands into the CLI at the edit hierarchy level, and
then enter commit from configuration mode.

set chassis cluster traceoptions flag all

set chassis cluster reth-count 3
set chassis cluster redundancy-group 0 node 0 priority 254
set chassis cluster redundancy-group 0 node 1 priority 1
set chassis cluster redundancy-group 1 node 0 priority 200
set chassis cluster redundancy-group 1 node 1 priority 100
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/1 weight 130
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/2 weight 140
set chassis cluster redundancy-group 1 interface-monitor ge-8/0/1 weight 150
set chassis cluster redundancy-group 1 interface-monitor ge-8/0/2 weight 120
set chassis cluster redundancy-group 2 node 0 priority 200
set chassis cluster redundancy-group 2 node 1 priority 100
set chassis cluster redundancy-group 2 interface-monitor ge-0/0/3 weight 255
set chassis cluster redundancy-group 2 interface-monitor ge-8/0/3 weight 255
set interfaces ge-0/0/1 gigether-options redundant-parent reth0
set interfaces ge-0/0/2 gigether-options redundant-parent reth1
set interfaces ge-0/0/3 gigether-options redundant-parent reth2
set interfaces ge-8/0/1 gigether-options redundant-parent reth0
set interfaces ge-8/0/2 gigether-options redundant-parent reth1
set interfaces ge-8/0/3 gigether-options redundant-parent reth2
set interfaces reth0 redundant-ether-options redundancy-group 1
set interfaces reth0 unit 0 family inet address 10.1.1.1/8
set interfaces reth1 redundant-ether-options redundancy-group 1
set interfaces reth1 unit 0 family inet address 11.1.1.1/8
set interfaces reth2 redundant-ether-options redundancy-group 2
set interfaces reth2 unit 0 family inet address 12.1.1.1/8

108 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
Mode in the Junos OS CLI User Guide.

To configure chassis cluster interface monitoring:

1. Specify the traceoptions for chassis cluster.

[edit chassis cluster]

user@host# set traceoptions flag all

2. Specify the number of redundant Ethernet interfaces.

[edit chassis cluster]

user@host# set reth-count 3

3. Set up redundancy group 0 for the Routing Engine failover properties, and set up
RG1 and RG2 (all interfaces are in one redundancy group in this example) to define
the failover properties for the redundant Ethernet interfaces.

[edit chassis cluster]

user@host# set redundancy-group 0 node 0 priority 254
user@host# set redundancy-group 0 node 1 priority 1
user@host# set redundancy-group 1 node 0 priority 200
user@host# set redundancy-group 1 node 1 priority 100
user@host# set redundancy-group 2 node 0 priority 200
user@host# set redundancy-group 2 node 1 priority 100

4. Set up interface monitoring to monitor the health of the interfaces and trigger
redundancy group failover.

NOTE: We do not recommend interface monitoring for RG0, because

it causes the control plane to switch from one node to another node in
case interface flap occurs.

[edit chassis cluster]

user@host# Set redundancy-group 1 interface-monitor ge-0/0/1 weight 130
user@host# Set redundancy-group 1 interface-monitor ge-0/0/2 weight 140
user@host# Set redundancy-group 1 interface-monitor ge-8/0/1 weight 150
user@host# Set redundancy-group 1 interface-monitor ge-0/0/2 weight 120
user@host# Set redundancy-group 2 interface-monitor ge-0/0/3 weight 255
user@host# Set redundancy-group 2 interface-monitor ge-8/0/3 weight 255

NOTE: Interface failover only occurs after the weight reaches zero.

5. Set up the redundant Ethernet (reth) interfaces and assign them to a zone.

[edit interfaces]
user@host# Set ge-0/0/1 gigether-options redundant-parent reth0
user@host# Set ge-0/0/2 gigether-options redundant-parent reth1
user@host# Set ge-0/0/3 gigether-options redundant-parent reth2
user@host# Set ge-8/0/1 gigether-options redundant-parent reth0

Copyright © 2016, Juniper Networks, Inc. 109

Chassis Cluster Feature Guide for Branch SRX Series Devices

user@host# Set ge-8/0/2 gigether-options redundant-parent reth1

user@host# Set ge-8/0/3 gigether-options redundant-parent reth2
user@host# Set reth0 redundant-ether-options redundancy-group 1
user@host# Set reth0 unit 0 family inet address 10.1.1.1/8
user@host# Set reth1 redundant-ether-options redundancy-group 1
user@host# Set reth1 unit 0 family inet address 11.1.1.1/8
user@host# Set reth2 redundant-ether-options redundancy-group 2
user@host# Set reth2 unit 0 family inet address 12.1.1.1/8

Results From configuration mode, confirm your configuration by entering the show chassis and
show interfaces commands. If the output does not display the intended configuration,
repeat the configuration instructions in this example to correct it.

[edit]
user@host# show chassis
cluster {
traceoptions {
flag all;
}
reth-count 3;
node 0; ## Warning: 'node' is deprecated
node 1; ## Warning: 'node' is deprecated
redundancy-group 0 {
node 0 priority 254;
node 1 priority 1;
}
redundancy-group 1 {
node 0 priority 200;
node 1 priority 100;
interface-monitor {
ge-0/0/1 weight 130;
ge-0/0/2 weight 140;
ge-8/0/1 weight 150;
ge-8/0/2 weight 120;
}
}
redundancy-group 2 {
node 0 priority 200;
node 1 priority 100;
interface-monitor {
ge-0/0/3 weight 255;
ge-8/0/3 weight 255;
}
}
}
[edit]
user@host# show interfaces
ge-0/0/1 {
gigether-options {
redundant-parent reth0;
}
}
ge-0/0/2 {
gigether-options {
redundant-parent reth1;

110 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

}
}
ge-0/0/3 {
gigether-options {
redundant-parent reth2;
}
}
ge-8/0/1 {
gigether-options {
redundant-parent reth0;
}
}
ge-8/0/2 {
gigether-options {
redundant-parent reth1;
}
}
ge-8/0/3 {
gigether-options {
redundant-parent reth2;
}
}
reth0 {
redundant-ether-options {
redundancy-group 1;
}
unit 0 {
family inet {
address 10.1.1.1/8;
}
}
}
reth1 {
redundant-ether-options {
redundancy-group 1;
}
unit 0 {
family inet {
address 11.1.1.1/8;
}
}
}
reth2 {
redundant-ether-options {
redundancy-group 2;
}
unit 0 {
family inet {
address 12.1.1.1/8;
}
}
}

If you are done configuring the device, enter commit from configuration mode.

Copyright © 2016, Juniper Networks, Inc. 111

Chassis Cluster Feature Guide for Branch SRX Series Devices

Verification
The following sections walk you through the process of verifying and (in some cases)
troubleshooting the interface status. The process shows you how to check the status of
each interface in the redundancy group, check them again after they have been disabled,
and looks for details about each interface, until you have circled through all interfaces
in the redundancy group.

In this example, you verify the process of the remaining threshold of a monitoring interface
by configuring two interfaces from each node and mapping them to RG1, each with
different weights. You use 130 and 140 for node 0 interfaces and 150 and 120 for node 1
interfaces. You configure one interface from each node and map the interfaces to RG2,
each with the default weight of 255.

• Verifying Chassis Cluster Status on page 113

• Verifying Chassis Cluster Interfaces on page 113
• Verifying Chassis Cluster Information on page 114
• Verifying Interface ge-0/0/1 Status After Disabling Interface ge-0/0/1 of RG1 in Node
0 with a Weight of 130 on page 115
• Verifying Chassis Cluster Status After Disabling Interface ge-0/0/1 of RG1 in Node 0
with a Weight of 130 on page 116
• Verifying Chassis Cluster Interfaces After Disabling Interface ge-0/0/1 of RG1 in Node
0 with a Weight of 130 on page 116
• Verifying Chassis Cluster Information After Disabling Interface ge-0/0/1 of RG1 in Node
0 with a Weight of 130 on page 117
• Verifying Interface ge-0/0/2 Is Disabled on page 119
• Verifying Chassis Cluster Status After Disabling Interface ge-0/0/2 on page 119
• Verifying Chassis Cluster Interfaces After Disabling Interface ge-0/0/2 on page 120
• Verifying Chassis Cluster Information After Disabling Interface ge-0/0/2 on page 121
• Verifying Interface Status After Disabling ge-0/0/3 on page 122
• Verifying Chassis Cluster Status After Disabling Interface ge-0/0/3 on page 123
• Verifying Chassis Cluster Interfaces After Disabling Interface ge-0/0/3 on page 123
• Verifying Chassis Cluster Information After Disabling Interface ge-0/0/3 on page 124
• Verifying That Interface ge-0/0/2 Is Enabled on page 126
• Verifying Chassis Cluster Status After Enabling Interface ge-0/0/2 on page 126
• Verifying Chassis Cluster Interfaces After Enabling Interface ge-0/0/2 on page 127
• Verifying Chassis Cluster Information After Enabling Interface ge-0/0/2 on page 127
• Verifying Chassis Cluster RG2 Preempt on page 129
• Verifying Chassis Cluster Status After Preempting RG2 on page 129
• Verifying That Interface ge-0/0/3 Is Enabled on page 130
• Verifying Chassis Cluster Status After Enabling Interface ge-0/0/3 on page 130

112 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

• Verifying Chassis Cluster Interfaces After Enabling Interface ge-0/0/3 on page 131
• Verifying Chassis Cluster Information After Enabling Interface ge-0/0/3 on page 132

Verifying Chassis Cluster Status

Purpose Verify the chassis cluster status, failover status, and redundancy group information.

Action From operational mode, enter the show chassis cluster status command.

{primary:node0}
user@host> show chassis cluster status
Monitor Failure codes:
CS Cold Sync monitoring FL Fabric Connection monitoring
GR GRES monitoring HW Hardware monitoring
IF Interface monitoring IP IP monitoring
LB Loopback monitoring MB Mbuf monitoring
NH Nexthop monitoring NP NPC monitoring
SP SPU monitoring SM Schedule monitoring
CF Config Sync monitoring

Cluster ID: 2
Node Priority Status Preempt Manual Monitor-failures

Redundancy group: 0 , Failover count: 1

node0 254 primary no no None
node1 1 secondary no no None

Redundancy group: 1 , Failover count: 1

node0 200 primary no no None
node1 100 secondary no no None

Redundancy group: 2 , Failover count: 1

node0 200 primary no no None
node1 100 secondary no no None

Meaning Use the show chassis cluster status command to confirm that devices in the chassis
cluster are communicating properly, with one device functioning as the primary node
and the other as the secondary node.

Verifying Chassis Cluster Interfaces

Purpose Verify information about the statistics of the different objects being synchronized, the
fabric and control interface hellos, and the status of the monitoring interfaces in the
cluster.

Action From operational mode, enter the show chassis cluster interfaces command.

{primary:node0}
user@host> show chassis cluster interfaces
Control link status: Up

Control interfaces:
Index Interface Monitored-Status Internal-SA
0 em0 Up Disabled
1 em1 Down Disabled

Fabric link status: Up

Copyright © 2016, Juniper Networks, Inc. 113

Chassis Cluster Feature Guide for Branch SRX Series Devices

Fabric interfaces:
Name Child-interface Status
(Physical/Monitored)
fab0 ge-0/0/0 Up / Up
fab0
fab1 ge-8/0/0 Up / Up
fab1

Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
reth1 Up 1
reth2 Up 2

Redundant-pseudo-interface Information:
Name Status Redundancy-group
lo0 Up 0

Interface Monitoring:
Interface Weight Status Redundancy-group
ge-8/0/2 120 Up 1
ge-8/0/1 150 Up 1
ge-0/0/2 140 Up 1
ge-0/0/1 130 Up 1
ge-8/0/3 255 Up 2
ge-0/0/3 255 Up 2

Meaning The sample output confirms that monitoring interfaces are up and that the weight of
each interface being monitored is displayed correctly as configured. These values do not
change if the interface goes up or down. The weights only change for the redundant group
and can be viewed when you use the show chassis cluster information command.

Verifying Chassis Cluster Information

Purpose Verify information about the statistics of the different objects being synchronized, the
fabric and control interface hellos, and the status of the monitoring interfaces in the
cluster.

Action From operational mode, enter the show chassis cluster information command.

{primary:node0}
user@host> show chassis cluster information

node0:
--------------------------------------------------------------------------
Redundancy Group Information:

Redundancy Group 0 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 22:56:27 hold secondary Hold timer expired
Feb 24 22:56:34 secondary primary Better priority (254/1)

Redundancy Group 1 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 23:16:12 hold secondary Hold timer expired

114 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

Feb 24 23:16:12 secondary primary Remote yield (0/0)

Redundancy Group 2 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 23:16:12 hold secondary Hold timer expired
Feb 24 23:16:13 secondary primary Remote yield (0/0)

Chassis cluster LED information:

Current LED color: Green
Last LED change reason: No failures

node1:
--------------------------------------------------------------------------
Redundancy Group Information:

Redundancy Group 0 , Current State: secondary, Weight: 255

Time From To Reason

Feb 24 22:56:34 hold secondary Hold timer expired

Redundancy Group 1 , Current State: secondary, Weight: 255

Time From To Reason

Feb 24 23:16:10 hold secondary Hold timer expired

Redundancy Group 2 , Current State: secondary, Weight: 255

Time From To Reason

Feb 24 23:16:10 hold secondary Hold timer expired

Chassis cluster LED information:

Current LED color: Green
Last LED change reason: No failures

Meaning The sample output confirms that node 0 and node 1 are healthy, and the green LED on
the device indicates that there are no failures. Also, the default weight of the redundancy
group (255) is displayed. The default weight is deducted whenever an interface mapped
to the corresponding redundancy group goes down.

Refer to subsequent verification sections to see how the redundancy group value varies
when a monitoring interface goes down or comes up.

Verifying Interface ge-0/0/1 Status After Disabling Interface ge-0/0/1 of RG1 in

Node 0 with a Weight of 130

Purpose Verify that the interface ge-0/0/1 is disabled on node 0.

Action From configuration mode, enter the set interface ge-0/0/1 disable command.

{primary:node0}
user@host# set interface ge-0/0/1 disable
user@host# commit

node0:
configuration check succeeds
node1:

Copyright © 2016, Juniper Networks, Inc. 115

Chassis Cluster Feature Guide for Branch SRX Series Devices

commit complete
node0:
commit complete

{primary:node0}
user@host# show interfaces ge-0/0/1
disable;
gigether-options {
redundant-parent reth0;
}

Meaning The sample output confirms that interface ge-0/0/1 is disabled.

Verifying Chassis Cluster Status After Disabling Interface ge-0/0/1 of RG1 in Node
0 with a Weight of 130

Purpose Verify the chassis cluster status, failover status, and redundancy group information.

Action From operational mode, enter the show chassis cluster status command.

{primary:node0}
user@host> show chassis cluster status
Monitor Failure codes:
CS Cold Sync monitoring FL Fabric Connection monitoring
GR GRES monitoring HW Hardware monitoring
IF Interface monitoring IP IP monitoring
LB Loopback monitoring MB Mbuf monitoring
NH Nexthop monitoring NP NPC monitoring
SP SPU monitoring SM Schedule monitoring
CF Config Sync monitoring

Cluster ID: 2
Node Priority Status Preempt Manual Monitor-failures

Redundancy group: 0 , Failover count: 1

node0 254 primary no no None
node1 1 secondary no no None

Redundancy group: 1 , Failover count: 1

node0 200 primary no no None
node1 100 secondary no no None

Redundancy group: 2 , Failover count: 1

node0 200 primary no no None
node1 100 secondary no no None

Meaning Use the show chassis cluster status command to confirm that devices in the chassis
cluster are communicating properly, with one device functioning as the primary node
and the other as the secondary node.

Verifying Chassis Cluster Interfaces After Disabling Interface ge-0/0/1 of RG1 in

Node 0 with a Weight of 130

Purpose Verify information about the statistics of the different objects being synchronized, the
fabric and control interface hellos, and the status of the monitoring interfaces in the
cluster.

116 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

Action From operational mode, enter the show chassis cluster interfaces command.

{primary:node0}
user@host> show chassis cluster interfaces
Control link status: Up

Control interfaces:
Index Interface Monitored-Status Internal-SA
0 em0 Up Disabled
1 em1 Down Disabled

Fabric link status: Up

Fabric interfaces:
Name Child-interface Status
(Physical/Monitored)
fab0 ge-0/0/0 Up / Up
fab0
fab1 ge-8/0/0 Up / Up
fab1

Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Down 1
reth1 Up 1
reth2 Up 2

Redundant-pseudo-interface Information:
Name Status Redundancy-group
lo0 Up 0

Interface Monitoring:
Interface Weight Status Redundancy-group
ge-8/0/2 120 Up 1
ge-8/0/1 150 Up 1
ge-0/0/2 140 Up 1
ge-0/0/1 130 Down 1
ge-8/0/3 255 Up 2
ge-0/0/3 255 Up 2

Meaning The sample output confirms that monitoring interface ge-0/0/1 is down.

Verifying Chassis Cluster Information After Disabling Interface ge-0/0/1 of RG1

in Node 0 with a Weight of 130

Purpose Verify information about the statistics of the different objects being synchronized, the
fabric and control interface hellos, and the status of the monitoring interfaces in the
cluster.

Action From operational mode, enter the show chassis cluster information command.

{primary:node0}
user@host> show chassis cluster information

node0:
--------------------------------------------------------------------------
Redundancy Group Information:

Redundancy Group 0 , Current State: primary, Weight: 255

Copyright © 2016, Juniper Networks, Inc. 117

Chassis Cluster Feature Guide for Branch SRX Series Devices

Time From To Reason

Feb 24 22:56:27 hold secondary Hold timer expired
Feb 24 22:56:34 secondary primary Better priority (254/1)

Redundancy Group 1 , Current State: primary, Weight: 125

Time From To Reason

Feb 24 23:16:12 hold secondary Hold timer expired
Feb 24 23:16:12 secondary primary Remote yield (0/0)

Redundancy Group 2 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 23:16:12 hold secondary Hold timer expired
Feb 24 23:16:13 secondary primary Remote yield (0/0)

Chassis cluster LED information:

Current LED color: Green
Last LED change reason: No failures

Failure Information:

Interface Monitoring Failure Information:

Redundancy Group 1, Monitoring status: Unhealthy
Interface Status
ge-0/0/1 Down

node1:
--------------------------------------------------------------------------
Redundancy Group Information:

Redundancy Group 0 , Current State: secondary, Weight: 255

Time From To Reason

Feb 24 22:56:34 hold secondary Hold timer expired

Redundancy Group 1 , Current State: secondary, Weight: 255

Time From To Reason

Feb 24 23:16:10 hold secondary Hold timer expired

Redundancy Group 2 , Current State: secondary, Weight: 255

Time From To Reason

Feb 24 23:16:10 hold secondary Hold timer expired

Chassis cluster LED information:

Current LED color: Amber
Last LED change reason: Monitored objects are down

Meaning The sample output confirms that in node 0, the RG1 weight is reduced to 125 (that is, 255
minus 130) because monitoring interface ge-0/0/1 (weight of 130) went down. The
monitoring status is unhealthy, the device LED is amber, and the interface status of
ge-0/0/1 is down.

118 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

NOTE: If interface ge-0/0/1 is brought back up, the weight of RG1 in node 0
becomes 255. Conversely, if interface ge-0/0/2 is also disabled, the weight
of RG1 in node 0 becomes 0 or less (in this example, 125 minus 140 = -15) and
triggers failover, as indicated in the next verification section.

Verifying Interface ge-0/0/2 Is Disabled

Purpose Verify that interface ge-0/0/2 is disabled on node 0.

Action From configuration mode, enter the set interface ge-0/0/2 disable command.

{primary:node0}
user@host# set interface ge-0/0/2 disable
user@host# commit

node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete

{primary:node0}
user@host# show interfaces ge-0/0/2
disable;
gigether-options {
redundant-parent reth1;
}

Meaning The sample output confirms that interface ge-0/0/2 is disabled.

Verifying Chassis Cluster Status After Disabling Interface ge-0/0/2

Purpose Verify the chassis cluster status, failover status, and redundancy group information.

Action From operational mode, enter the show chassis cluster status command.

{primary:node0}
user@host> show chassis cluster status
Monitor Failure codes:
CS Cold Sync monitoring FL Fabric Connection monitoring
GR GRES monitoring HW Hardware monitoring
IF Interface monitoring IP IP monitoring
LB Loopback monitoring MB Mbuf monitoring
NH Nexthop monitoring NP NPC monitoring
SP SPU monitoring SM Schedule monitoring
CF Config Sync monitoring

Cluster ID: 2
Node Priority Status Preempt Manual Monitor-failures

Redundancy group: 0 , Failover count: 1

node0 254 primary no no None

Copyright © 2016, Juniper Networks, Inc. 119

Chassis Cluster Feature Guide for Branch SRX Series Devices

node1 1 secondary no no None

Redundancy group: 1 , Failover count: 2

node0 0 secondary no no IF
node1 100 primary no no None

Redundancy group: 2 , Failover count: 1

node0 200 primary no no None
node1 100 secondary no no None

Meaning Use the show chassis cluster status command to confirm that devices in the chassis
cluster are communicating properly, with one device functioning as the primary node
and the other as the secondary node. On RG1, you see interface failure, because both
interfaces mapped to RG1 on node 0 failed during interface monitoring.

Verifying Chassis Cluster Interfaces After Disabling Interface ge-0/0/2

Purpose Verify information about chassis cluster interfaces.

Action From operational mode, enter the show chassis cluster interfaces command.

{primary:node0}
user@host> show chassis cluster interfaces
Control link status: Up

Control interfaces:
Index Interface Monitored-Status Internal-SA
0 em0 Up Disabled
1 em1 Down Disabled

Fabric link status: Up

Fabric interfaces:
Name Child-interface Status
(Physical/Monitored)
fab0 ge-0/0/0 Up / Up
fab0
fab1 ge-8/0/0 Up / Up
fab1

Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
reth1 Up 1
reth2 Up 2

Redundant-pseudo-interface Information:
Name Status Redundancy-group
lo0 Up 0

Interface Monitoring:
Interface Weight Status Redundancy-group
ge-8/0/2 120 Up 1
ge-8/0/1 150 Up 1
ge-0/0/2 140 Down 1
ge-0/0/1 130 Down 1
ge-8/0/3 255 Up 2
ge-0/0/3 255 Up 2

120 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

Meaning The sample output confirms that monitoring interfaces ge-0/0/1 and ge-0/0/2 are down.

Verifying Chassis Cluster Information After Disabling Interface ge-0/0/2

Purpose Verify information about the statistics of the different objects being synchronized, the
fabric and control interface hellos, and the status of the monitoring interfaces in the
cluster.

Action From operational mode, enter the show chassis cluster information command.

{primary:node0}
user@host> show chassis cluster information

node0:
--------------------------------------------------------------------------
Redundancy Group Information:

Redundancy Group 0 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 22:56:27 hold secondary Hold timer expired
Feb 24 22:56:34 secondary primary Better priority (254/1)

Redundancy Group 1 , Current State: secondary, Weight: -15

Time From To Reason

Feb 24 23:16:12 hold secondary Hold timer expired
Feb 24 23:16:12 secondary primary Remote yield (0/0)
Feb 24 23:31:36 primary secondary-hold Monitor failed: IF
Feb 24 23:31:37 secondary-hold secondary Ready to become secondary

Redundancy Group 2 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 23:16:12 hold secondary Hold timer expired
Feb 24 23:16:13 secondary primary Remote yield (0/0)

Chassis cluster LED information:

Current LED color: Amber
Last LED change reason: Monitored objects are down

Failure Information:

Interface Monitoring Failure Information:

Redundancy Group 1, Monitoring status: Failed
Interface Status
ge-0/0/2 Down
ge-0/0/1 Down

node1:
--------------------------------------------------------------------------
Redundancy Group Information:

Redundancy Group 0 , Current State: secondary, Weight: 255

Time From To Reason

Feb 24 22:56:34 hold secondary Hold timer expired

Copyright © 2016, Juniper Networks, Inc. 121

Chassis Cluster Feature Guide for Branch SRX Series Devices

Redundancy Group 1 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 23:16:10 hold secondary Hold timer expired
Feb 24 23:31:36 secondary primary Remote is in secondary hold

Redundancy Group 2 , Current State: secondary, Weight: 255

Time From To Reason

Feb 24 23:16:10 hold secondary Hold timer expired

Chassis cluster LED information:

Current LED color: Amber
Last LED change reason: Monitored objects are down

Meaning The sample output confirms that in node 0, monitoring interfaces ge-0/0/1 and ge-0/0/2
are down. The weight of RG1 on node 0 reached zero value, which triggered RG1 failover
during use of the show chassis cluster status command.

NOTE: For RG2, the default weight of 255 is set for redundant Ethernet
interface 2 (reth2). When interface monitoring is required, we recommend
that you use the default weight when you do not have backup links like those
in RG1. That is, if interface ge-0/0/3 is disabled, it immediately triggers failover
because the weight becomes 0 (255 minus 225), as indicated in the next
verification section.

Verifying Interface Status After Disabling ge-0/0/3

Purpose Verify that interface ge-0/0/3 is disabled on node 0.

Action From configuration mode, enter the set interface ge-0/0/3 disable command.

{primary:node0}
user@host# set interface ge-0/0/3 disable
user@host# commit

node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete

{primary:node0}
user@host# show interfaces ge-0/0/3
disable;
gigether-options {
redundant-parent reth2;
}

Meaning The sample output confirms that interface ge-0/0/3 is disabled.

122 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

Verifying Chassis Cluster Status After Disabling Interface ge-0/0/3

Purpose Verify the chassis cluster status, failover status, and redundancy group information.

Action From operational mode, enter the show chassis cluster status command.

{primary:node0}
user@host> show chassis cluster status
Monitor Failure codes:
CS Cold Sync monitoring FL Fabric Connection monitoring
GR GRES monitoring HW Hardware monitoring
IF Interface monitoring IP IP monitoring
LB Loopback monitoring MB Mbuf monitoring
NH Nexthop monitoring NP NPC monitoring
SP SPU monitoring SM Schedule monitoring
CF Config Sync monitoring

Cluster ID: 2
Node Priority Status Preempt Manual Monitor-failures

Redundancy group: 0 , Failover count: 1

node0 254 primary no no None
node1 1 secondary no no None

Redundancy group: 1 , Failover count: 2

node0 0 secondary no no IF
node1 100 primary no no None

Redundancy group: 2 , Failover count: 2

node0 0 secondary no no IF
node1 100 primary no no None

Meaning Use the show chassis cluster status command to confirm that devices in the chassis
cluster are communicating properly, with one device functioning as the primary node
and the other as the secondary node.

Verifying Chassis Cluster Interfaces After Disabling Interface ge-0/0/3

Purpose Verify information about chassis cluster interfaces.

Action From operational mode, enter the show chassis cluster interfaces command.

{primary:node0}
user@host> show chassis cluster interfaces
Control link status: Up

Control interfaces:
Index Interface Monitored-Status Internal-SA
0 em0 Up Disabled
1 em1 Down Disabled

Fabric link status: Up

Fabric interfaces:
Name Child-interface Status
(Physical/Monitored)
fab0 ge-0/0/0 Up / Up

Copyright © 2016, Juniper Networks, Inc. 123

Chassis Cluster Feature Guide for Branch SRX Series Devices

fab0
fab1 ge-8/0/0 Up / Up
fab1

Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
reth1 Up 1
reth2 Up 2

Redundant-pseudo-interface Information:
Name Status Redundancy-group
lo0 Up 0

Interface Monitoring:
Interface Weight Status Redundancy-group
ge-8/0/2 120 Up 1
ge-8/0/1 150 Up 1
ge-0/0/2 140 Down 1
ge-0/0/1 130 Down 1
ge-8/0/3 255 Up 2
ge-0/0/3 255 Down 2

Meaning The sample output confirms that monitoring interfaces ge-0/0/1, ge-0/0/2, and ge-0/0/3
are down.

Verifying Chassis Cluster Information After Disabling Interface ge-0/0/3

Purpose Verify information about the statistics of the different objects being synchronized, the
fabric and control interface hellos, and the status of the monitoring interfaces in the
cluster.

Action From operational mode, enter the show chassis cluster information command.

{primary:node0}
user@host> show chassis cluster information

node0:
--------------------------------------------------------------------------
Redundancy Group Information:

Redundancy Group 0 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 22:56:27 hold secondary Hold timer expired
Feb 24 22:56:34 secondary primary Better priority (254/1)

Redundancy Group 1 , Current State: secondary, Weight: -15

Time From To Reason

Feb 24 23:16:12 hold secondary Hold timer expired
Feb 24 23:16:12 secondary primary Remote yield (0/0)
Feb 24 23:31:36 primary secondary-hold Monitor failed: IF
Feb 24 23:31:37 secondary-hold secondary Ready to become secondary

Redundancy Group 2 , Current State: secondary, Weight: 0

Time From To Reason

Feb 24 23:16:12 hold secondary Hold timer expired

124 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

Feb 24 23:16:13 secondary primary Remote yield (0/0)

Feb 24 23:35:57 primary secondary-hold Monitor failed: IF
Feb 24 23:35:58 secondary-hold secondary Ready to become secondary

Chassis cluster LED information:

Current LED color: Amber
Last LED change reason: Monitored objects are down

Failure Information:

Interface Monitoring Failure Information:

Redundancy Group 1, Monitoring status: Failed
Interface Status
ge-0/0/2 Down
ge-0/0/1 Down
Redundancy Group 2, Monitoring status: Failed
Interface Status
ge-0/0/3 Down

node1:
--------------------------------------------------------------------------
Redundancy Group Information:

Redundancy Group 0 , Current State: secondary, Weight: 255

Time From To Reason

Feb 24 22:56:34 hold secondary Hold timer expired

Redundancy Group 1 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 23:16:10 hold secondary Hold timer expired
Feb 24 23:31:36 secondary primary Remote is in secondary hold

Redundancy Group 2 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 23:16:10 hold secondary Hold timer expired
Feb 24 23:35:57 secondary primary Remote is in secondary hold

Chassis cluster LED information:

Current LED color: Amber
Last LED change reason: Monitored objects are down

Meaning The sample output confirms that in node 0, monitoring interfaces ge-0/0/1, ge-0/0/2,
and ge-0/0/3 are down.

NOTE: In regard to RG1, making any interface in node 0 go up should trigger

a failover only if the preempt option is enabled. In the example, preempt is
not enabled. Therefore the node should return to normal, with no monitor
failure showing for RG1.

Copyright © 2016, Juniper Networks, Inc. 125

Chassis Cluster Feature Guide for Branch SRX Series Devices

Verifying That Interface ge-0/0/2 Is Enabled

Purpose Verify that interface ge-0/0/2 is enabled on node 0.

Action From configuration mode, enter the delete interfaces ge-0/0/2 disable command.

{primary:node0}
user@host# delete interfaces ge-0/0/2 disable
user@host# commit

node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete

Meaning The sample output confirms that interface ge-0/0/2 disable is deleted.

Verifying Chassis Cluster Status After Enabling Interface ge-0/0/2

Purpose Verify the chassis cluster status, failover status, and redundancy group information.

Action From operational mode, enter the show chassis cluster status command.

{primary:node0}
user@host> show chassis cluster status
Monitor Failure codes:
CS Cold Sync monitoring FL Fabric Connection monitoring
GR GRES monitoring HW Hardware monitoring
IF Interface monitoring IP IP monitoring
LB Loopback monitoring MB Mbuf monitoring
NH Nexthop monitoring NP NPC monitoring
SP SPU monitoring SM Schedule monitoring
CF Config Sync monitoring

Cluster ID: 2
Node Priority Status Preempt Manual Monitor-failures

Redundancy group: 0 , Failover count: 1

node0 254 primary no no None
node1 1 secondary no no None

Redundancy group: 1 , Failover count: 2

node0 200 secondary no no None
node1 100 primary no no None

Redundancy group: 2 , Failover count: 2

node0 0 secondary no no IF
node1 100 primary no no None

Meaning Use the show chassis cluster status command to confirm that devices in the chassis
cluster are communicating properly, with as one device functioning as the primary node
and the other as the secondary node.

126 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

Verifying Chassis Cluster Interfaces After Enabling Interface ge-0/0/2

Purpose Verify information about chassis cluster interfaces.

Action From operational mode, enter the show chassis cluster interfaces command.

{primary:node0}
user@host> show chassis cluster interfaces
Control link status: Up

Control interfaces:
Index Interface Monitored-Status Internal-SA
0 em0 Up Disabled
1 em1 Down Disabled

Fabric link status: Up

Fabric interfaces:
Name Child-interface Status
(Physical/Monitored)
fab0 ge-0/0/0 Up / Up
fab0
fab1 ge-8/0/0 Up / Up
fab1

Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
reth1 Up 1
reth2 Up 2

Redundant-pseudo-interface Information:
Name Status Redundancy-group
lo0 Up 0

Interface Monitoring:
Interface Weight Status Redundancy-group
ge-8/0/2 120 Up 1
ge-8/0/1 150 Up 1
ge-0/0/2 140 Up 1
ge-0/0/1 130 Down 1
ge-8/0/3 255 Up 2
ge-0/0/3 255 Down 2

Meaning The sample output confirms that monitoring interfaces ge-0/0/1 and ge-0/0/3 are down.
Monitoring interface ge-0/0/2 is up after the disable has been deleted.

Verifying Chassis Cluster Information After Enabling Interface ge-0/0/2

Purpose Verify information about the statistics of the different objects being synchronized, the
fabric and control interface hellos, and the status of the monitoring interfaces in the
cluster.

Action From operational mode, enter the show chassis cluster information command.

{primary:node0}
user@host> show chassis cluster information

Copyright © 2016, Juniper Networks, Inc. 127

Chassis Cluster Feature Guide for Branch SRX Series Devices

node0:
--------------------------------------------------------------------------
Redundancy Group Information:

Redundancy Group 0 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 22:56:27 hold secondary Hold timer expired
Feb 24 22:56:34 secondary primary Better priority (254/1)

Redundancy Group 1 , Current State: secondary, Weight: 125

Time From To Reason

Feb 24 23:16:12 hold secondary Hold timer expired
Feb 24 23:16:12 secondary primary Remote yield (0/0)
Feb 24 23:31:36 primary secondary-hold Monitor failed: IF
Feb 24 23:31:37 secondary-hold secondary Ready to become secondary

Redundancy Group 2 , Current State: secondary, Weight: 0

Time From To Reason

Feb 24 23:16:12 hold secondary Hold timer expired
Feb 24 23:16:13 secondary primary Remote yield (0/0)
Feb 24 23:35:57 primary secondary-hold Monitor failed: IF
Feb 24 23:35:58 secondary-hold secondary Ready to become secondary

Chassis cluster LED information:

Current LED color: Amber
Last LED change reason: Monitored objects are down

Failure Information:

Interface Monitoring Failure Information:

Redundancy Group 1, Monitoring status: Unhealthy
Interface Status
ge-0/0/1 Down
Redundancy Group 2, Monitoring status: Failed
Interface Status
ge-0/0/3 Down

node1:
--------------------------------------------------------------------------
Redundancy Group Information:

Redundancy Group 0 , Current State: secondary, Weight: 255

Time From To Reason

Feb 24 22:56:34 hold secondary Hold timer expired

Redundancy Group 1 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 23:16:10 hold secondary Hold timer expired
Feb 24 23:31:36 secondary primary Remote is in secondary hold

Redundancy Group 2 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 23:16:10 hold secondary Hold timer expired

128 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

Feb 24 23:35:57 secondary primary Remote is in secondary hold

Chassis cluster LED information:

Current LED color: Amber
Last LED change reason: Monitored objects are down

Meaning The sample output confirms that in node 0, monitoring interfaces ge-0/0/1 and ge-0/0/3
are down. Monitoring interface ge-0/0/2 is active after the disable has been deleted.

Verifying Chassis Cluster RG2 Preempt

Purpose Verify that the chassis cluster RG2 is preempted on node 0.

Action From configuration mode, enter the set chassis cluster redundancy-group 2 preempt
command.
{primary:node0}
user@host# set chassis cluster redundancy-group 2 preempt
user@host# commit

node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete

Meaning The sample output confirms that chassis cluster RG2 preempted on node 0.

NOTE: In the next section, you check that RG2 fails over back to node 0 when
preempt is enabled when the disabled node 0 interface is brought online.

Verifying Chassis Cluster Status After Preempting RG2

Purpose Verify the chassis cluster status, failover status, and redundancy group information.

Action From operational mode, enter the show chassis cluster status command.

{primary:node0}
user@host> show chassis cluster status
Monitor Failure codes:
CS Cold Sync monitoring FL Fabric Connection monitoring
GR GRES monitoring HW Hardware monitoring
IF Interface monitoring IP IP monitoring
LB Loopback monitoring MB Mbuf monitoring
NH Nexthop monitoring NP NPC monitoring
SP SPU monitoring SM Schedule monitoring
CF Config Sync monitoring

Cluster ID: 2

Copyright © 2016, Juniper Networks, Inc. 129

Chassis Cluster Feature Guide for Branch SRX Series Devices

Node Priority Status Preempt Manual Monitor-failures

Redundancy group: 0 , Failover count: 1

node0 254 primary no no None
node1 1 secondary no no None

Redundancy group: 1 , Failover count: 2

node0 200 secondary no no None
node1 100 primary no no None

Redundancy group: 2 , Failover count: 2

node0 0 secondary yes no IF
node1 100 primary yes no None

Meaning Use the show chassis cluster status command to confirm that devices in the chassis
cluster are communicating properly, with one device functioning as the primary node
and the other as the secondary node.

Verifying That Interface ge-0/0/3 Is Enabled

Purpose Verify that interface ge-0/0/3 is enabled on node 0.

Action From configuration mode, enter the delete interfaces ge-0/0/3 disable command.

{primary:node0}
user@host# delete interfaces ge-0/0/3 disable
user@host# commit

node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete

Meaning The sample output confirms that interface ge-0/0/3 disable has been deleted.

Verifying Chassis Cluster Status After Enabling Interface ge-0/0/3

Purpose Verify the chassis cluster status, failover status, and redundancy group information.

Action From operational mode, enter the show chassis cluster status command.

{primary:node0}
user@host> show chassis cluster status
Monitor Failure codes:
CS Cold Sync monitoring FL Fabric Connection monitoring
GR GRES monitoring HW Hardware monitoring
IF Interface monitoring IP IP monitoring
LB Loopback monitoring MB Mbuf monitoring
NH Nexthop monitoring NP NPC monitoring
SP SPU monitoring SM Schedule monitoring
CF Config Sync monitoring

Cluster ID: 2
Node Priority Status Preempt Manual Monitor-failures

130 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

Redundancy group: 0 , Failover count: 1

node0 254 primary no no None
node1 1 secondary no no None

Redundancy group: 1 , Failover count: 2

node0 200 secondary no no None
node1 100 primary no no None

Redundancy group: 2 , Failover count: 3

node0 200 primary yes no None
node1 100 secondary yes no None

Meaning Use the show chassis cluster status command to confirm that devices in the chassis
cluster are communicating properly, with one device functioning as the primary node
and the other as the secondary node.

Verifying Chassis Cluster Interfaces After Enabling Interface ge-0/0/3

Purpose Verify information about chassis cluster interfaces.

Action From operational mode, enter the show chassis cluster interfaces command.

{primary:node0}
user@host> show chassis cluster interfaces
Control link status: Up

Control interfaces:
Index Interface Monitored-Status Internal-SA
0 em0 Up Disabled
1 em1 Down Disabled

Fabric link status: Up

Fabric interfaces:
Name Child-interface Status
(Physical/Monitored)
fab0 ge-0/0/0 Up / Up
fab0
fab1 ge-8/0/0 Up / Up
fab1

Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
reth1 Up 1
reth2 Up 2

Redundant-pseudo-interface Information:
Name Status Redundancy-group
lo0 Up 0

Interface Monitoring:
Interface Weight Status Redundancy-group
ge-8/0/2 120 Up 1
ge-8/0/1 150 Up 1
ge-0/0/2 140 Up 1
ge-0/0/1 130 Down 1

Copyright © 2016, Juniper Networks, Inc. 131

Chassis Cluster Feature Guide for Branch SRX Series Devices

ge-8/0/3 255 Up 2
ge-0/0/3 255 Up 2

Meaning The sample output confirms that monitoring interface ge-0/0/1 is down. Monitoring
interfaces ge-0/0/2, and ge-0/0/3 are up after deleting the disable.

Verifying Chassis Cluster Information After Enabling Interface ge-0/0/3

Purpose Verify information about the statistics of the different objects being synchronized, the
fabric and control interface hellos, and the status of the monitoring interfaces in the
cluster.

Action From operational mode, enter the show chassis cluster information command.

{primary:node0}
user@host> show chassis cluster information

node0:
--------------------------------------------------------------------------
Redundancy Group Information:

Redundancy Group 0 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 22:56:27 hold secondary Hold timer expired
Feb 24 22:56:34 secondary primary Better priority (254/1)

Redundancy Group 1 , Current State: secondary, Weight: 125

Time From To Reason

Feb 24 23:16:12 hold secondary Hold timer expired
Feb 24 23:16:12 secondary primary Remote yield (0/0)
Feb 24 23:31:36 primary secondary-hold Monitor failed: IF
Feb 24 23:31:37 secondary-hold secondary Ready to become secondary

Redundancy Group 2 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 23:16:12 hold secondary Hold timer expired
Feb 24 23:16:13 secondary primary Remote yield (0/0)
Feb 24 23:35:57 primary secondary-hold Monitor failed: IF
Feb 24 23:35:58 secondary-hold secondary Ready to become secondary
Feb 24 23:45:45 secondary primary Remote is in secondary hold

Chassis cluster LED information:

Current LED color: Green
Last LED change reason: No failures

Failure Information:

Interface Monitoring Failure Information:

Redundancy Group 1, Monitoring status: Unhealthy
Interface Status
ge-0/0/1 Down

node1:
--------------------------------------------------------------------------
Redundancy Group Information:

132 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

Redundancy Group 0 , Current State: secondary, Weight: 255

Time From To Reason

Feb 24 22:56:34 hold secondary Hold timer expired

Redundancy Group 1 , Current State: primary, Weight: 255

Time From To Reason

Feb 24 23:16:10 hold secondary Hold timer expired
Feb 24 23:31:36 secondary primary Remote is in secondary hold

Redundancy Group 2 , Current State: secondary, Weight: 255

Time From To Reason

Feb 24 23:16:10 hold secondary Hold timer expired
Feb 24 23:35:57 secondary primary Remote is in secondary hold

Feb 24 23:45:45 primary secondary-hold Preempt (100/200)

Feb 24 23:45:46 secondary-hold secondary Ready to become secondary

Chassis cluster LED information:

Current LED color: Amber
Last LED change reason: Monitored objects are down

Meaning The sample output confirms that in node 0, monitoring interface ge-0/0/1 is down. RG2
on node 0 state is back to primary state (because of the preempt enable) with a healthy
weight of 255 when interface ge-0/0/3 is back up.

Related • Example: Configuring Chassis Cluster Redundancy Groups on page 73

Documentation
• Understanding Chassis Cluster Redundancy Group Interface Monitoring on page 105

• Understanding Chassis Cluster Redundancy Group IP Address Monitoring for Branch

SRX Series Devices on page 133

• Understanding Chassis Cluster Redundancy Group IP Address Monitoring for High-End

SRX Series Devices

• Understanding Chassis Cluster Redundancy Group Failover on page 141

• Understanding Chassis Cluster Redundancy Groups on page 69

• Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port and
Logical Interface Naming for Branch SRX Series Devices on page 47

• Understanding SRX Series Chassis Cluster Slot Numbering, Physical Port and Logical
Interface Naming for High-End SRX Series Devices

Understanding Chassis Cluster Redundancy Group IP Address Monitoring

Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550, vSRX

Redundancy group IP address monitoring checks end-to-end connectivity and allows a

redundancy group to fail over because of the inability of a redundant Ethernet interface

Copyright © 2016, Juniper Networks, Inc. 133

Chassis Cluster Feature Guide for Branch SRX Series Devices

(known as a reth) to reach a configured IP address. Redundancy groups on both devices

in a cluster can be configured to monitor specific IP addresses to determine whether an
upstream device in the network is reachable. The redundancy group can be configured
such that if the monitored IP address becomes unreachable, the redundancy group will
fail over to its backup to maintain service. The primary difference between this monitoring
feature and interface monitoring is that IP address monitoring allows for failover when
the interface is still up but the network device it is connected to is not reachable for some
reason. It may be possible under those circumstances for the other node in the cluster
to route traffic around the problem.

NOTE: If you want to dampen the failovers occurring because of IP address

monitoring failures, use the hold-down-interval statement.

IP address monitoring configuration allows you to set not only the address to monitor
and its failover weight but also a global IP address monitoring threshold and weight. Only
after the IP address monitoring global-threshold is reached because of cumulative
monitored address reachability failure will the IP address monitoring global-weight value
be deducted from the redundant group’s failover threshold. Thus, multiple addresses
can be monitored simultaneously as well as monitored to reflect their importance to
maintaining traffic flow. Also, the threshold value of an IP address that is unreachable
and then becomes reachable again will be restored to the monitoring threshold. This will
not, however, cause a failback unless the preempt option has been enabled.

When configured, the IP address monitoring failover value (global-weight) is considered

along with interface monitoring—if set—and built-in failover monitoring, including SPU
monitoring, cold-sync monitoring, and NPC monitoring (on supported platforms). The
main IP addresses that should be monitored are router gateway addresses to ensure
that valid traffic coming into the services gateway can be forwarded to the appropriate
network router.

NOTE: Starting in Junos OS Release 12.1X46-D35, for all SRX Series devices,
the reth interface supports proxy ARP.

One Services Processing Unit (SPU) or Packet Forwarding Engine (PFE) per node is
designated to send Internet Control Message Protocol (ICMP) ping packets for the
monitored IP addresses on the cluster. The primary PFE sends ping packets using Address
Resolution Protocol (ARP) requests resolved by the Routing Engine (RE). The source for
these pings is the redundant Ethernet interface MAC and IP addresses. The secondary
PFE resolves ARP requests for the monitored IP address itself. The source for these pings
is the physical child MAC address and a secondary IP address configured on the redundant
Ethernet interface. For the ping reply to be received on the secondary interface, the I/O
card (IOC), central PFE processor, or Flex IOC adds both the physical child MAC address
and the redundant Ethernet interface MAC address to its MAC table. The secondary PFE
responds with the physical child MAC address to ARP requests sent to the secondary IP
address configured on the redundant Ethernet interface.

134 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

The default interval to check the reachability of a monitored IP address is once per second.
The interval can be adjusted using the retry-interval command. The default number of
permitted consecutive failed ping attempts is 5. The number of allowed consecutive
failed ping attempts can be adjusted using the retry-count command. After failing to
reach a monitored IP address for the configured number of consecutive attempts, the IP
address is determined to be unreachable and its failover value is deducted from the
redundancy group's global-threshold.

Once the IP address is determined to be unreachable, its weight is deducted from the
global-threshold. If the recalculated global-threshold value is not 0, the IP address is
marked unreachable, but the global-weight is not deducted from the redundancy group’s
threshold. If the redundancy group IP monitoring global-threshold reaches 0 and there
are unreachable IP addresses, the redundancy group will continuously fail over and fail
back between the nodes until either an unreachable IP address becomes reachable or
a configuration change removes unreachable IP addresses from monitoring. Note that
both default and configured hold-down-interval failover dampening is still in effect.

Every redundancy group x has a threshold tolerance value initially set to 255. When an
IP address monitored by redundancy group x becomes unavailable, its weight is subtracted
from the redundancy group x's threshold. When redundancy group x's threshold reaches
0, it fails over to the other node. For example, if redundancy group 1 was primary on node
0, on the threshold-crossing event, redundancy group 1 becomes primary on node 1. In
this case, all the child interfaces of redundancy group 1's redundant Ethernet interfaces
begin handling traffic.

A redundancy group x failover occurs because the cumulative weight of the redundancy
group x's monitored IP addresses and other monitoring has brought its threshold value
to 0. When the monitored IP addresses of redundancy group x on both nodes reach their
thresholds at the same time, redundancy group x is primary on the node with the lower
node ID, which is typically node 0.

NOTE: Upstream device failure detection for the chassis cluster feature is
supported on SRX300, SRX320, SRX340, SRX345, and SRX1500 devices.

Monitoring can be accomplished only if the IP address is reachable on a redundant

Ethernet interface (known as a reth in CLI commands and interface listings), and IP
addresses cannot be monitored over a tunnel. For an IP address to be monitored through
a redundant Ethernet interface on a secondary cluster node, the interface must have a
secondary IP address configured. IP address monitoring cannot be used on a chassis
cluster running in transparent mode.

NOTE: Redundancy group IP address monitoring is not supported for IPv6

destinations.

Related • Understanding Chassis Cluster Redundancy Groups on page 69

Documentation
• Understanding Chassis Cluster Redundancy Group Interface Monitoring on page 105

Copyright © 2016, Juniper Networks, Inc. 135

Chassis Cluster Feature Guide for Branch SRX Series Devices

• Example: Configuring Chassis Cluster Redundancy Group IP Address Monitoring on

page 136

• Understanding Chassis Cluster Redundancy Group Failover on page 141

Example: Configuring Chassis Cluster Redundancy Group IP Address Monitoring

Supported Platforms SRX Series, vSRX

This example shows how to configure redundancy group IP address monitoring for an
SRX Series device in a chassis cluster.

• Requirements on page 136

• Overview on page 136
• Configuration on page 137
• Verification on page 138

Requirements
Before you begin:

• Set the chassis cluster node ID and cluster ID. See “Example: Setting the Chassis Cluster
Node ID and Cluster ID for Branch SRX Series Devices” on page 51 or Example: Setting
the Chassis Cluster Node ID and Cluster ID for High-End SRX Series Devices.

• Configure the chassis cluster management interface. See “Example: Configuring the
Chassis Cluster Management Interface” on page 53.

• Configure the chassis cluster fabric. See “Example: Configuring the Chassis Cluster
Fabric Interfaces” on page 61.

Overview
You can configure redundancy groups to monitor upstream resources by pinging specific
IP addresses that are reachable through redundant Ethernet interfaces on either node
in a cluster. You can also configure global threshold, weight, retry interval, and retry count
parameters for a redundancy group. When a monitored IP address becomes unreachable,
the weight of that monitored IP address is deducted from the redundancy group IP
address monitoring global threshold. When the global threshold reaches 0, the global
weight is deducted from the redundancy group threshold. The retry interval determines
the ping interval for each IP address monitored by the redundancy group. The pings are
sent as soon as the configuration is committed. The retry count sets the number of
allowed consecutive ping failures for each IP address monitored by the redundancy group.

In this example, you configure the following settings for redundancy group 1:

• IP address to monitor—10.1.1.10

• IP address monitoring global-weight—100

• IP address monitoring global-threshold—200

136 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

NOTE: The threshold applies cumulatively to all IP addresses monitored

by the redundancy group.

• IP address retry-interval—3 seconds

• IP address retry-count—10

• Weight—150

• Redundant Ethernet interface—reth1.0

• Secondary IP address—10.1.1.101

Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.

{primary:node0}[edit]
user@host#
set chassis cluster redundancy-group 1 ip-monitoring global-weight 100
set chassis cluster redundancy-group 1 ip-monitoring global-threshold 200
set chassis cluster redundancy-group 1 ip-monitoring retry-interval 3
set chassis cluster redundancy-group 1 ip-monitoring retry-count 10
set chassis cluster redundancy-group 1 ip-monitoring family inet 10.1.1.10 weight 150
interface reth1.0 secondary-ip-address 10.1.1.101

Step-by-Step To configure redundancy group IP address monitoring:

Procedure
1. Specify a global monitoring weight.

{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 ip-monitoring global-weight
100

2. Specify the global monitoring threshold.

{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 ip-monitoring global-threshold
200

3. Specify the retry interval.

{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 ip-monitoring retry-interval 3

4. Specify the retry count.

{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 ip-monitoring retry-count 10

5. Specify the IP address to be monitored, weight, redundant Ethernet interface, and

secondary IP address.

{primary:node0}[edit]

Copyright © 2016, Juniper Networks, Inc. 137

Chassis Cluster Feature Guide for Branch SRX Series Devices

user@host# set chassis cluster redundancy-group 1 ip-monitoring family inet 10.1.1.10

weight 100 interface reth1.0 secondary-ip-address 10.1.1.101

Results From configuration mode, confirm your configuration by entering the show chassis cluster
redundancy-group 1 command. If the output does not display the intended configuration,
repeat the configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).

{primary:node0}[edit]
user@host# show chassis cluster redundancy-group 1
ip-monitoring {
global-weight 100;
global-threshold 200;
family {
inet {
10.1.1.10 {
weight 100;
interface reth1.0 secondary-ip-address 10.1.1.101;
}
}
}
}

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying the Status of Monitored IP Addresses for a Redundancy Group

Purpose Verify the status of monitored IP addresses for a redundancy group.

Action From operational mode, enter the show chassis cluster ip-monitoring status command.
For information about a specific group, enter the show chassis cluster ip-monitoring status
redundancy-group command.

{primary:node0}
user@host> show chassis cluster ip-monitoring status
node0:
--------------------------------------------------------------------------

Redundancy group: 1
Global threshold: 200
Current threshold: -120

IP address Status Failure count Reason Weight

10.1.1.10 reachable 0 n/a 220
10.1.1.101 reachable 0 n/a 100

node1:
--------------------------------------------------------------------------

Redundancy group: 1
Global threshold: 200

138 Copyright © 2016, Juniper Networks, Inc.

 Chapter 12: Monitoring Chassis Cluster

Current threshold: -120

IP address Status Failure count Reason Weight

10.1.1.10 reachable 0 n/a 220
10.1.1.101 reachable 0 n/a 100

Related • Understanding Chassis Cluster Redundancy Group Interface Monitoring on page 105
Documentation
• Understanding Chassis Cluster Redundancy Group IP Address Monitoring for Branch
SRX Series Devices on page 133

• Understanding Chassis Cluster Redundancy Group IP Address Monitoring for High-End

SRX Series Devices

• Understanding Chassis Cluster Redundancy Group Failover on page 141

Copyright © 2016, Juniper Networks, Inc. 139

Chassis Cluster Feature Guide for Branch SRX Series Devices

140 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 13

Managing Chassis Cluster Redundancy

Group Failover

• Understanding Chassis Cluster Redundancy Group Failover on page 141

• Example: Configuring a Chassis Cluster with a Dampening Time Between Back-to-Back
Redundancy Group Failovers on page 142
• Understanding Chassis Cluster Redundancy Group Manual Failover on page 143
• Understanding SNMP Failover Traps for Chassis Cluster Redundancy Group
Failover on page 145
• Initiating a Chassis Cluster Manual Redundancy Group Failover on page 146
• Verifying Chassis Cluster Failover Status on page 148
• Clearing Chassis Cluster Failover Status on page 149

Understanding Chassis Cluster Redundancy Group Failover

Supported Platforms SRX Series, vSRX

Chassis cluster employs a number of highly efficient failover mechanisms that promote
high availability to increase your system's overall reliability and productivity.

A redundancy group is a collection of objects that fail over as a group. Each redundancy
group monitors a set of objects (physical interfaces), and each monitored object is
assigned a weight. Each redundancy group has an initial threshold of 255. When a
monitored object fails, the weight of the object is subtracted from the threshold value
of the redundancy group. When the threshold value reaches zero, the redundancy group
fails over to the other node. As a result, all the objects associated with the redundancy
group fail over as well. Graceful restart of the routing protocols enables the SRX Series
device to minimize traffic disruption during a failover.

Back-to-back failovers of a redundancy group in a short interval can cause the cluster
to exhibit unpredictable behavior. To prevent such unpredictable behavior, configure a
dampening time between failovers. On failover, the previous primary node of a redundancy
group moves to the secondary-hold state and stays in the secondary-hold state until the
hold-down interval expires. After the hold-down interval expires, the previous primary
node moves to the secondary state. If a failure occurs on the new primary node during
the hold-down interval, the system fails over immediately and overrides the hold-down
interval.

Copyright © 2016, Juniper Networks, Inc. 141

Chassis Cluster Feature Guide for Branch SRX Series Devices

The default dampening time for a redundancy group 0 is 300 seconds (5 minutes) and
is configurable to up to 1800 seconds with the hold-down-interval statement. For some
configurations, such as those with a large number of routes or logical interfaces, the
default interval or the user-configured interval might not be sufficient. In such cases, the
system automatically extends the dampening time in increments of 60 seconds until
the system is ready for failover.

Redundancy groups x (redundancy groups numbered 1 through 128) have a default

dampening time of 1 second, with a range from 0 through 1800 seconds.

The hold-down interval affects manual failovers, as well as automatic failovers associated
with monitoring failures.

On SRX Series devices, chassis cluster failover performance is optimized to scale with
more logical interfaces. Previously, during redundancy group failover, gratuitous arp
(GARP) is sent by the Juniper Services Redundancy Protocol (jsrpd) process running in
the Routing Engine on each logical interface to steer the traffic to the appropriate node.
With logical interface scaling, the Routing Engine becomes the checkpoint and GARP is
directly sent from the Services Processing Unit (SPU).

Related • Example: Configuring Chassis Cluster Redundancy Groups on page 73

Documentation
• Understanding Chassis Cluster Redundancy Group Manual Failover on page 143

• Understanding SNMP Failover Traps for Chassis Cluster Redundancy Group Failover
on page 145

• Initiating a Chassis Cluster Manual Redundancy Group Failover on page 146

Example: Configuring a Chassis Cluster with a Dampening Time Between Back-to-Back

Redundancy Group Failovers

Supported Platforms SRX Series, vSRX

This example shows how to configure the dampening time between back-to-back
redundancy group failovers for a chassis cluster. Back-to-back redundancy group failovers
that occur too quickly can cause a chassis cluster to exhibit unpredictable behavior.

• Requirements on page 142

• Overview on page 143
• Configuration on page 143

Requirements
Before you begin:

• Understand redundancy group failover. See “Understanding Chassis Cluster Redundancy

Group Failover” on page 141.

• Understand redundancy group manual failover. See “Understanding Chassis Cluster

Redundancy Group Manual Failover” on page 143.

142 Copyright © 2016, Juniper Networks, Inc.

 Chapter 13: Managing Chassis Cluster Redundancy Group Failover

Overview
The dampening time is the minimum interval allowed between back-to-back failovers
for a redundancy group. This interval affects manual failovers and automatic failovers
caused by interface monitoring failures.

In this example, you set the minimum interval allowed between back-to-back failovers
to 420 seconds for redundancy group 0.

Configuration
Step-by-Step To configure the dampening time between back-to-back redundancy group failovers:
Procedure
1. Set the dampening time for the redundancy group.

{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 0 hold-down-interval 420

2. If you are done configuring the device, commit the configuration.

{primary:node0}[edit]
user@host# commit

Verification

Purpose Verify that the configuration is working properly.

Action To verify the configuration, enter the show configuration chassis cluster command.

Related • Understanding Chassis Cluster Redundancy Groups on page 69

Documentation
• Example: Configuring Chassis Cluster Redundancy Groups on page 73

• Understanding Chassis Cluster Redundancy Group Manual Failover on page 143

• Understanding SNMP Failover Traps for Chassis Cluster Redundancy Group Failover
on page 145

• Initiating a Chassis Cluster Manual Redundancy Group Failover on page 146

Understanding Chassis Cluster Redundancy Group Manual Failover

Supported Platforms SRX Series, vSRX

You can initiate a redundancy group x (redundancy groups numbered 1 through 128)
failover manually. A manual failover applies until a failback event occurs.

For example, suppose that you manually do a redundancy group 1 failover from node 0
to node 1. Then an interface that redundancy group 1 is monitoring fails, dropping the
threshold value of the new primary redundancy group to zero. This event is considered
a failback event, and the system returns control to the original redundancy group.

Copyright © 2016, Juniper Networks, Inc. 143

Chassis Cluster Feature Guide for Branch SRX Series Devices

You can also initiate a redundancy group 0 failover manually if you want to change the
primary node for redundancy group 0. You cannot enable preemption for redundancy
group 0.

NOTE: If preempt is added to a redundancy group configuration, the device

with the higher priority in the group can initiate a failover to become master.
By default, preemption is disabled. For more information on preemeption,
see preempt (Chassis Cluster).

When you do a manual failover for redundancy group 0, the node in the primary state
transitions to the secondary-hold state. The node stays in the secondary-hold state for
the default or configured time (a minimum of 300 seconds) and then transitions to the
secondary state.

State transitions in cases where one node is in the secondary-hold state and the other
node reboots, or the control link connection or fabric link connection is lost to that node,
are described as follows:

• Reboot case—The node in the secondary-hold state transitions to the primary state;
the other node goes dead (inactive).

• Control link failure case—The node in the secondary-hold state transitions to the
ineligible state and then to a disabled state; the other node transitions to the primary
state.

• Fabric link failure case—The node in the secondary-hold state transitions directly to
the ineligible state.

NOTE: Starting with Junos OS Release 12.1X46D20 and Junos OS Release

12.1X47-D10, fabric monitoring is enabled by default. With this enabling,
the node transitions directly to the ineligible state in case of fabric link
failures.

Keep in mind that during an in-service software upgrade (ISSU), the transitions described
here cannot happen. Instead, the other (primary) node transitions directly to the secondary
state because Juniper Networks releases earlier than 10.0 do not interpret the
secondary-hold state. While you start an ISSU, if one of the nodes has one or more
redundancy groups in the secondary-hold state, you must wait for them to move to the
secondary state before you can do manual failovers to make all the redundancy groups
be primary on one node.

CAUTION: Be cautious and judicious in your use of redundancy group 0

manual failovers. A redundancy group 0 failover implies a Routing Engine
failover, in which case all processes running on the primary node are killed
and then spawned on the new master Routing Engine. This failover could
result in loss of state, such as routing state, and degrade performance by
introducing system churn.

144 Copyright © 2016, Juniper Networks, Inc.

 Chapter 13: Managing Chassis Cluster Redundancy Group Failover

NOTE: In some Junos OS releases, for redundancy groups x, it is possible to

do a manual failover on a node that has 0 priority. We recommend that you
use the show chassis cluster status command to check the redundancy group
node priorities before doing the manual failover. However, from Junos OS
Releases 12.1X44-D25, 12.1X45-D20, 12.1X46-D10, and 12.1X47-D10 and later,
the readiness check mechanism for manual failover is enhanced to be more
restrictive, so that you cannot set manual failover to a node in a redundancy
group that has 0 priority. This enhancement prevents traffic from being
dropped unexpectedly due to a failover attempt to a 0 priority node, which
is not ready to accept traffic.

Related • Understanding Chassis Cluster Redundancy Group Failover on page 141

Documentation
• Initiating a Chassis Cluster Manual Redundancy Group Failover on page 146

• Example: Configuring a Chassis Cluster with a Dampening Time Between Back-to-Back

Redundancy Group Failovers on page 142

• Understanding SNMP Failover Traps for Chassis Cluster Redundancy Group Failover
on page 145

• Understanding Chassis Cluster Redundant Ethernet Interfaces for Branch SRX Series
Devices on page 77

• Understanding Chassis Cluster Redundant Ethernet Interfaces for High-End SRX Series
Devices

Understanding SNMP Failover Traps for Chassis Cluster Redundancy Group Failover

Supported Platforms SRX Series, vSRX

Chassis clustering supports SNMP traps, which are triggered whenever there is a
redundancy group failover.

The trap message can help you troubleshoot failovers. It contains the following
information:

• The cluster ID and node ID

• The reason for the failover

• The redundancy group that is involved in the failover

• The redundancy group’s previous state and current state

These are the different states that a cluster can be in at any given instant: hold, primary,
secondary-hold, secondary, ineligible, and disabled. Traps are generated for the following
state transitions (only a transition from a hold state does not trigger a trap):

• primary <–> secondary

• primary –> secondary-hold

Copyright © 2016, Juniper Networks, Inc. 145

Chassis Cluster Feature Guide for Branch SRX Series Devices

• secondary-hold –> secondary

• secondary –> ineligible

• ineligible –> disabled

• ineligible –> primary

• secondary –> disabled

A transition can be triggered because of any event, such as interface monitoring, SPU
monitoring, failures, and manual failovers.

The trap is forwarded over the control link if the outgoing interface is on a node different
from the node on the Routing Engine that generates the trap.

You can specify that a trace log be generated by setting the traceoptions flag snmp
statement.

Related • Understanding Chassis Cluster Redundancy Group Manual Failover on page 143
Documentation
• Initiating a Chassis Cluster Manual Redundancy Group Failover on page 146

• Example: Configuring a Chassis Cluster with a Dampening Time Between Back-to-Back

Redundancy Group Failovers on page 142

• Understanding Chassis Cluster Redundant Ethernet Interfaces for Branch SRX Series
Devices on page 77

• Understanding Chassis Cluster Redundant Ethernet Interfaces for High-End SRX Series
Devices

Initiating a Chassis Cluster Manual Redundancy Group Failover

Supported Platforms SRX Series, vSRX

You can initiate a failover manually with the request command. A manual failover bumps
up the priority of the redundancy group for that member to 255.

Before you begin, complete the following tasks:

• Example: Configuring Chassis Cluster Redundancy Groups on page 73

• Example: Configuring Chassis Cluster Redundant Ethernet Interfaces for IPv4 and IPv6
Addresses on page 79

• Example: Configuring a Chassis Cluster with a Dampening Time Between Back-to-Back

Redundancy Group Failovers on page 142

CAUTION: Be cautious and judicious in your use of redundancy group 0

manual failovers. A redundancy group 0 failover implies a Routing Engine
(RE) failover, in which case all processes running on the primary node are
killed and then spawned on the new master Routing Engine (RE). This failover

146 Copyright © 2016, Juniper Networks, Inc.

 Chapter 13: Managing Chassis Cluster Redundancy Group Failover

could result in loss of state, such as routing state, and degrade performance
by introducing system churn.

NOTE: For redundancy groups x (redundancy groups numbered 1 through

128), it is possible to do a manual failover on a node that has 0 priority . We
recommend that you check the redundancy group node priorities before doing
the manual failover.

Use the show command to display the status of nodes in the cluster:

{primary:node0}
user@host> show chassis cluster status redundancy-group 0
Cluster ID: 9
Node Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 1

node0 254 primary no no
node1 1 secondary no no

Output to this command indicates that node 0 is primary.

Use the request command to trigger a failover and make node 1 primary:

{primary:node0}
user@host> request chassis cluster failover redundancy-group 0 node 1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Initiated manual failover for redundancy group 0

Use the show command to display the new status of nodes in the cluster:

{secondary-hold:node0}
user@host> show chassis cluster status redundancy-group 0
Cluster ID: 9
Node Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 2

node0 254 secondary-hold no yes
node1 255 primary no yes

Output to this command shows that node 1 is now primary and node 0 is in the
secondary-hold state. After 5 minutes, node 0 will transition to the secondary state.

You can reset the failover for redundancy groups by using the request command. This
change is propagated across the cluster.
{secondary-hold:node0}
user@host> request chassis cluster failover reset redundancy-group 0 node 0
node0:
--------------------------------------------------------------------------
No reset required for redundancy group 0.

node1:
--------------------------------------------------------------------------
Successfully reset manual failover for redundancy group 0

Copyright © 2016, Juniper Networks, Inc. 147

Chassis Cluster Feature Guide for Branch SRX Series Devices

You cannot trigger a back-to-back failover until the 5-minute interval expires.
{secondary-hold:node0}
user@host> request chassis cluster failover redundancy-group 0 node 0
node0:
--------------------------------------------------------------------------
Manual failover is not permitted as redundancy-group 0 on node0 is in
secondary-hold state.

Use the show command to display the new status of nodes in the cluster:

{secondary-hold:node0}
user@host> show chassis cluster status redundancy-group 0
Cluster ID: 9
Node Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 2

node0 254 secondary-hold no no
node1 1 primary no no

Output to this command shows that a back-to-back failover has not occurred for either
node.

After doing a manual failover, you must issue the reset failover command before requesting
another failover.

When the primary node fails and comes back up, election of the primary node is done
based on regular criteria (priority and preempt).

Related • Understanding Chassis Cluster Redundancy Group Manual Failover on page 143
Documentation
• Example: Configuring a Chassis Cluster with a Dampening Time Between Back-to-Back
Redundancy Group Failovers on page 142

• Understanding SNMP Failover Traps for Chassis Cluster Redundancy Group Failover
on page 145

• Understanding Chassis Cluster Redundant Ethernet Interfaces for Branch SRX Series
Devices on page 77

• Understanding Chassis Cluster Redundant Ethernet Interfaces for High-End SRX Series
Devices

Verifying Chassis Cluster Failover Status

Supported Platforms SRX Series, vSRX

Purpose Display the failover status of a chassis cluster.

Action From the CLI, enter the show chassis cluster status command:

{primary:node1}
user@host> show chassis cluster status
Cluster ID: 3
Node name Priority Status Preempt Manual failover

Redundancy-group: 0, Failover count: 1

148 Copyright © 2016, Juniper Networks, Inc.

 Chapter 13: Managing Chassis Cluster Redundancy Group Failover

node0 254 primary no no

node1 2 secondary no no

Redundancy-group: 1, Failover count: 1

node0 254 primary no no
node1 1 secondary no no

{primary:node1}
user@host> show chassis cluster status
Cluster ID: 15
Node Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 5

node0 200 primary no no
node1 0 lost n/a n/a

Redundancy group: 1 , Failover count: 41

node0 101 primary no no
node1 0 lost n/a n/a

{primary:node1}
user@host> show chassis cluster status
Cluster ID: 15
Node Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 5

node0 200 primary no no
node1 0 unavailable n/a n/a

Redundancy group: 1 , Failover count: 41

node0 101 primary no no
node1 0 unavailable n/a n/a

Related • Initiating a Chassis Cluster Manual Redundancy Group Failover on page 146
Documentation
• Example: Configuring the Number of Redundant Ethernet Interfaces in a Chassis Cluster
on page 84

• Verifying a Chassis Cluster Configuration on page 99

• Verifying Chassis Cluster Statistics on page 99

• Clearing Chassis Cluster Failover Status on page 149

Clearing Chassis Cluster Failover Status

Supported Platforms SRX Series, vSRX

To clear the failover status of a chassis cluster, enter the clear chassis cluster failover-count
command from the CLI:
{primary:node1}
user@host> clear chassis cluster failover-count
Cleared failover-count for all redundancy-groups

Related • Initiating a Chassis Cluster Manual Redundancy Group Failover on page 146
Documentation

Copyright © 2016, Juniper Networks, Inc. 149

Chassis Cluster Feature Guide for Branch SRX Series Devices

• Example: Configuring the Number of Redundant Ethernet Interfaces in a Chassis Cluster

on page 84

• Verifying a Chassis Cluster Configuration on page 99

• Verifying Chassis Cluster Statistics on page 99

• Verifying Chassis Cluster Failover Status on page 148

150 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 14

Configuring Chassis Cluster Dual Fabric

Links to Increase Redundancy and
Performance

• Understanding Chassis Cluster Dual Fabric Links on page 151

• Example: Configuring the Chassis Cluster Dual Fabric Links with Matching Slots and
Ports on page 152
• Example: Configuring Chassis Cluster Dual Fabric Links with Different Slots and
Ports on page 154

Understanding Chassis Cluster Dual Fabric Links

Supported Platforms SRX Series, vSRX

You can connect two fabric links between each device in a cluster, which provides a
redundant fabric link between the members of a cluster. Having two fabric links helps to
avoid a possible single point of failure.

When you use dual fabric links, the RTOs and probes are sent on one link and the
fabric-forwarded and flow-forwarded packets are sent on the other link. If one fabric link
fails, the other fabric link handles the RTOs and probes, as well as the data forwarding.
The system selects the physical interface with the lowest slot, PIC, or port number on
each node for the RTOs and probes.

For all SRX Series devices, you can connect two fabric links between two devices,
effectively reducing the chance of a fabric link failure.

In most SRX Series devices in a chassis cluster, you can configure any pair of Gigabit
Ethernet interfaces or any pair of 10-Gigabit interfaces to serve as the fabric between
nodes.

For dual fabric links, both of the child interface types should be the same type. For
example, both should be Gigabit Ethernet interfaces or 10-Gigabit interfaces.

NOTE: SRX300, SRX320, SRX340, and SRX345 devices support Gigabit

Ethernet interfaces only.

Copyright © 2016, Juniper Networks, Inc. 151

Chassis Cluster Feature Guide for Branch SRX Series Devices

Related • Understanding Chassis Cluster Fabric Interfaces on page 57

Documentation
• Example: Configuring the Chassis Cluster Fabric Interfaces on page 61

• Verifying Chassis Cluster Data Plane Interfaces on page 63

• Verifying Chassis Cluster Data Plane Statistics on page 63

• Clearing Chassis Cluster Data Plane Statistics on page 64

Example: Configuring the Chassis Cluster Dual Fabric Links with Matching Slots and
Ports

Supported Platforms SRX Series, vSRX

This example shows how to configure the chassis cluster fabric with dual fabric links
with matching slots and ports. The fabric is the back-to-back data connection between
the nodes in a cluster. Traffic on one node that needs to be processed on the other node
or to exit through an interface on the other node passes over the fabric. Session state
information also passes over the fabric.

• Requirements on page 152

• Overview on page 152
• Configuration on page 153
• Verification on page 154

Requirements
Before you begin, set the chassis cluster ID and chassis cluster node ID. See “Example:
Setting the Chassis Cluster Node ID and Cluster ID for Branch SRX Series Devices” on
page 51 or Example: Setting the Chassis Cluster Node ID and Cluster ID for High-End SRX
Series Devices.

Overview
In most SRX Series devices in a chassis cluster, you can configure any pair of Gigabit
Ethernet interfaces or any pair of 10-Gigabit interfaces to serve as the fabric between
nodes.

You cannot configure filters, policies, or services on the fabric interface. Fragmentation
is not supported on the fabric link. The MTU size is 8980 bytes. We recommend that no
interface in the cluster exceed this MTU size. Jumbo frame support on the member links
is enabled by default.

This example illustrates how to configure the fabric link with dual fabric links with
matching slots and ports on each node.

A typical configuration is where the dual fabric links are formed with matching slots/ports
on each node. That is, ge-3/0/0 on node 0 and ge-10/0/0 on node 1 match, as do ge-0/0/0
on node 0 and ge-7/0/0 on node 1 (the FPC slot offset is 7).

152 Copyright © 2016, Juniper Networks, Inc.

 Chapter 14: Configuring Chassis Cluster Dual Fabric Links to Increase Redundancy and Performance

Only the same type of interfaces can be configured as fabric children, and you must
configure an equal number of child links for fab0 and fab1.

NOTE: If you are connecting each of the fabric links through a switch, you
must enable the jumbo frame feature on the corresponding switch ports. If
both of the fabric links are connected through the same switch, the
RTO-and-probes pair must be in one virtual LAN (VLAN) and the data pair
must be in another VLAN. Here, too, the jumbo frame feature must be enabled
on the corresponding switch ports.

Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.

{primary:node0}[edit]
set interfaces fab0 fabric-options member-interfaces ge-0/0/0
set interfaces fab0 fabric-options member-interfaces ge-3/0/0
set interfaces fab1 fabric-options member-interfaces ge-7/0/0
set interfaces fab1 fabric-options member-interfaces ge-10/0/0

Step-by-Step To configure the chassis cluster fabric with dual fabric links with matching slots and ports
Procedure on each node:

• Specify the fabric interfaces.

{primary:node0}[edit]
user@host# set interfaces fab0 fabric-options member-interfaces ge-0/0/0
user@host# set interfaces fab0 fabric-options member-interfaces ge-3/0/0
user@host# set interfaces fab1 fabric-options member-interfaces ge-7/0/0
user@host# set interfaces fab1 fabric-options member-interfaces ge-10/0/0

Results From configuration mode, confirm your configuration by entering the show interfaces
command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).

{primary:node0}[edit]
user@host# show interfaces
...
fab0 {
fabric-options {
member-interfaces {
ge-0/0/0;
ge-3/0/0;
}
}

Copyright © 2016, Juniper Networks, Inc. 153

Chassis Cluster Feature Guide for Branch SRX Series Devices

}
fab1 {
fabric-options {
member-interfaces {
ge-7/0/0;
ge-10/0/0;
}
}
}

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying the Chassis Cluster Fabric

Purpose Verify the chassis cluster fabric.

Action From operational mode, enter the show interfaces terse | match fab command.

{primary:node0}

user@host> show interfaces terse | match fab

ge-0/0/0.0 up up aenet --> fab0.0
ge-3/0/0.0 up up aenet --> fab0.0
ge-7/0/0.0 up up aenet --> fab1.0
ge-10/0/0.0 up up aenet --> fab1.0
fab0 up up
fab0.0 up up inet 30.17.0.200/24
fab1 up up
fab1.0 up up inet 30.18.0.200/24

Related • Understanding Chassis Cluster Dual Fabric Links for Branch SRX Series on page 151
Documentation
• Understanding Chassis Cluster Dual Fabric Links for High-End SRX Series

• Example: Configuring Chassis Cluster Dual Fabric Links with Different Slots and Ports
on page 154

• Example: Configuring the Chassis Cluster Fabric Interfaces on page 61

Example: Configuring Chassis Cluster Dual Fabric Links with Different Slots and Ports

Supported Platforms SRX Series, vSRX

This example shows how to configure the chassis cluster fabric with dual fabric links
with different slots and ports. The fabric is the back-to-back data connection between
the nodes in a cluster. Traffic on one node that needs to be processed on the other node
or to exit through an interface on the other node passes over the fabric. Session state
information also passes over the fabric.

• Requirements on page 155

• Overview on page 155

154 Copyright © 2016, Juniper Networks, Inc.

 Chapter 14: Configuring Chassis Cluster Dual Fabric Links to Increase Redundancy and Performance

• Configuration on page 155

• Verification on page 156

Requirements
Before you begin, set the chassis cluster ID and chassis cluster node ID. See “Example:
Setting the Chassis Cluster Node ID and Cluster ID for Branch SRX Series Devices” on
page 51 or Example: Setting the Chassis Cluster Node ID and Cluster ID for High-End SRX
Series Devices.

Overview
In most SRX Series devices in a chassis cluster, you can configure any pair of Gigabit
Ethernet interfaces or any pair of 10-Gigabit interfaces to serve as the fabric between
nodes.

You cannot configure filters, policies, or services on the fabric interface. Fragmentation
is not supported on the fabric link. The MTU size is 8980 bytes. We recommend that no
interface in the cluster exceed this MTU size. Jumbo frame support on the member links
is enabled by default.

This example illustrates how to configure the fabric link with dual fabric links with different
slots and ports on each node.

Make sure you physically connect the RTO-and-probes link to the RTO-and-probes link
on the other node. Likewise, make sure you physically connect the data link to the data
link on the other node.

That is, physically connect the following two pairs:

• The node 0 RTO-and-probes link ge-2/1/9 to the node 1 RTO-and-probes link ge-11/0/0

• The node 0 data link ge-2/2/5 to the node 1 data link ge-11/3/0

Only the same type of interfaces can be configured as fabric children, and you must
configure an equal number of child links for fab0 and fab1.

NOTE: If you are connecting each of the fabric links through a switch, you
must enable the jumbo frame feature on the corresponding switch ports. If
both of the fabric links are connected through the same switch, the
RTO-and-probes pair must be in one virtual LAN (VLAN) and the data pair
must be in another VLAN. Here too, the jumbo frame feature must be enabled
on the corresponding switch ports.

Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.

Copyright © 2016, Juniper Networks, Inc. 155

Chassis Cluster Feature Guide for Branch SRX Series Devices

{primary:node0}[edit]
set interfaces fab0 fabric-options member-interfaces ge-2/1/9
set interfaces fab0 fabric-options member-interfaces ge-2/2/5
set interfaces fab1 fabric-options member-interfaces ge-11/0/0
set interfaces fab1 fabric-options member-interfaces ge-11/3/0

Step-by-Step To configure the chassis cluster fabric with dual fabric links with different slots and ports
Procedure on each node:

• Specify the fabric interfaces.

{primary:node0}[edit]
user@host# set interfaces fab0 fabric-options member-interfaces ge-2/1/9
user@host# set interfaces fab0 fabric-options member-interfaces ge-2/2/5
user@host# set interfaces fab1 fabric-options member-interfaces ge-11/0/0
user@host# set interfaces fab1 fabric-options member-interfaces ge-11/3/0

Results From configuration mode, confirm your configuration by entering the show interfaces
command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).

{primary:node0}[edit]
user@host# show interfaces
...
fab0 {
fabric-options {
member-interfaces {
ge-2/1/9;
ge-2/2/5;
}
}
}
fab1 {
fabric-options {
member-interfaces {
ge-11/0/0;
ge-11/3/0;
}
}
}

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying the Chassis Cluster Fabric

Purpose Verify the chassis cluster fabric.

156 Copyright © 2016, Juniper Networks, Inc.

 Chapter 14: Configuring Chassis Cluster Dual Fabric Links to Increase Redundancy and Performance

Action From operational mode, enter the show interfaces terse | match fab command.

{primary:node0}

user@host> show interfaces terse | match fab

ge-2/1/9.0 up up aenet --> fab0.0
ge-2/2/5.0 up up aenet --> fab0.0
ge-11/0/0.0 up up aenet --> fab1.0
ge-11/3/0.0 up up aenet --> fab1.0
fab0 up up
fab0.0 up up inet 30.17.0.200/24
fab1 up up
fab1.0 up up inet 30.18.0.200/24

Related • Understanding Chassis Cluster Dual Fabric Links for Branch SRX Series on page 151
Documentation
• Understanding Chassis Cluster Dual Fabric Links for High-End SRX Series

• Example: Configuring the Chassis Cluster Dual Fabric Links with Matching Slots and
Ports on page 152

Copyright © 2016, Juniper Networks, Inc. 157

Chassis Cluster Feature Guide for Branch SRX Series Devices

158 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 15

Configuring Route Advertisement over

Redundant Ethernet Interfaces in a
Chassis Cluster

• Understanding Conditional Route Advertising in a Chassis Cluster on page 159

• Example: Configuring Conditional Route Advertising in a Chassis Cluster on page 160

Understanding Conditional Route Advertising in a Chassis Cluster

Supported Platforms SRX Series, vSRX

Route advertisement over redundant Ethernet interfaces in a chassis cluster is complicated

by the fact that the active node in the cluster can change dynamically. Conditional route
advertisement enables you to advertise routes in such a way that incoming traffic from
the core network is attracted to the Border Gateway Protocol (BGP) interface that exists
on the same node as the currently active redundant Ethernet interface. In this way, traffic
is processed by the active node and does not traverse the fabric interface between nodes.
You do this by manipulating the BGP attribute at the time routes are advertised by BGP.

The goal of conditional route advertisement in a chassis cluster is to ensure that incoming
traffic from the upstream network arrives on the node that is on the currently active
redundant Ethernet interface. To understand how this works, keep in mind that in a
chassis cluster, each node has its own set of interfaces. Figure 16 on page 160 shows a
typical scenario, with a redundant Ethernet interface connecting the corporate LAN,
through a chassis cluster, to an external network segment.

Copyright © 2016, Juniper Networks, Inc. 159

Chassis Cluster Feature Guide for Branch SRX Series Devices

Figure 16: Conditional Route Advertising

Related • Example: Configuring Conditional Route Advertising in a Chassis Cluster on page 160
Documentation
• Verifying a Chassis Cluster Configuration on page 99

• Verifying Chassis Cluster Statistics on page 99

Example: Configuring Conditional Route Advertising in a Chassis Cluster

Supported Platforms SRX Series, vSRX

160 Copyright © 2016, Juniper Networks, Inc.

 Chapter 15: Configuring Route Advertisement over Redundant Ethernet Interfaces in a Chassis Cluster

This example shows how to configure conditional route advertising in a chassis cluster
to ensure that incoming traffic from the upstream network arrives on the node that is on
the currently active redundant Ethernet interface.

• Requirements on page 161

• Overview on page 161
• Configuration on page 163

Requirements
Before you begin, understand conditional route advertising in a chassis cluster. See
“Understanding Conditional Route Advertising in a Chassis Cluster” on page 159.

Overview
As illustrated in Figure 17 on page 162, routing prefixes learned from the redundant Ethernet
interface through the IGP are advertised toward the network core using BGP. Two BGP
sessions are maintained, one from interface t1-1/0/0 and one from t1-1/0/1 for BGP
multihoming. All routing prefixes are advertised on both sessions. Thus, for a route
advertised by BGP, learned over a redundant Ethernet interface, if the active redundant
Ethernet interface is on the same node as the BGP session, you advertise the route with
a “good” BGP attribute.

Copyright © 2016, Juniper Networks, Inc. 161

Chassis Cluster Feature Guide for Branch SRX Series Devices

Figure 17: Conditional Route Advertising

To achieve this behavior, you apply a policy to BGP before exporting routes. An additional
term in the policy match condition determines the current active redundant Ethernet
interface child interface of the next hop before making the routing decision. When the
active status of a child redundant Ethernet interface changes, BGP reevaluates the export
policy for all routes affected.

The condition statement in this configuration works as follows. The command states
that any routes evaluated against this condition will pass only if:

• The routes have a redundant Ethernet interface as their next-hop interface.

162 Copyright © 2016, Juniper Networks, Inc.

 Chapter 15: Configuring Route Advertisement over Redundant Ethernet Interfaces in a Chassis Cluster

• The current child interface of the redundant Ethernet interface is active at node 0 (as
specified by the route-active-on node0 keyword).

{primary:node0}[edit]
user@host# set policy-options condition reth-nh-active-on-0 route-active-on node0

Note that a route might have multiple equal-cost next hops, and those next hops might
be redundant Ethernet interfaces, regular interfaces, or a combination of both. The route
still satisfies the requirement that it has a redundant Ethernet interface as its next hop.

If you use the BGP export policy set for node 0 in the previous example command, only
OSPF routes that satisfy the following requirements will be advertised through the session:

• The OSPF routes have a redundant Ethernet interface as their next hop.

• The current child interface of the redundant Ethernet interface is currently active at
node 0.

You must also create and apply a separate policy statement for the other BGP session
by using this same process.

In addition to the BGP MED attribute, you can define additional BGP attributes, such as
origin-code, as-path, and community.

Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.

{primary:node0}[edit]
set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0 from protocol
ospf
set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0 from condition
reth-nh-active-on-0
set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0 then metric 10
set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0 then accept
set policy-options condition reth-nh-active-on-0 route-active-on node0

Step-by-Step To configure conditional route advertising:

Procedure
• Create the policies.

{primary:node0}[edit]
user@host# set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0
from protocol ospf
{primary:node0}[edit]
user@host# set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0
from condition reth-nh-active-on-0
{primary:node0}[edit]
user@host# set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0
then metric 10
{primary:node0}[edit]
user@host# set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0
then accept

Copyright © 2016, Juniper Networks, Inc. 163

Chassis Cluster Feature Guide for Branch SRX Series Devices

{primary:node0}[edit]
user@host# set policy-options condition reth-nh-active-on-0 route-active-on node0

Results From configuration mode, confirm your configuration by entering the show policy-options
command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.

{primary:node0}[edit]
user@host# show policy-options
policy-statement reth-nh-active-on-0 {
term ospf-on-0 {
from {
protocol ospf;
condition reth-nh-active-on-0;
}
then {
metric 10;
accept;
}
}
}
condition reth-nh-active-on-0 route-active-on node0;

If you are done configuring the device, enter commit from configuration mode.

Related • Understanding Conditional Route Advertising in a Chassis Cluster on page 159

Documentation
• Verifying a Chassis Cluster Configuration on page 99

• Verifying Chassis Cluster Statistics on page 99

164 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 16

Configuring Redundant Ethernet LAG

Interfaces for Increasing High Availability
and Overall Throughput

• Understanding Chassis Cluster Redundant Ethernet Interface Link Aggregation

Groups on page 165
• Example: Configuring Chassis Cluster Redundant Ethernet Interface Link Aggregation
Groups on page 167
• Understanding Chassis Cluster Redundant Ethernet Interface LAG Failover on page 170
• Understanding LACP on Chassis Clusters on page 173
• Example: Configuring LACP on Chassis Clusters on page 175
• Example: Configuring Chassis Cluster Minimum Links on page 178

Understanding Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups

Supported Platforms SRX1500, SRX300, SRX320, SRX340, SRX345, SRX550, vSRX

Support for Ethernet link aggregation groups (LAGs) based on IEEE 802.3ad makes it
possible to aggregate physical interfaces on a standalone device. LAGs on standalone
devices provide increased interface bandwidth and link availability. Aggregation of links
in a chassis cluster allows a redundant Ethernet interface to add more than two physical
child interfaces thereby creating a redundant Ethernet interface LAG. A redundant Ethernet
interface LAG can have up to eight links per redundant Ethernet interface per node (for
a total of 16 links per redundant Ethernet interface).

The aggregated links in a redundant Ethernet interface LAG provide the same bandwidth
and redundancy benefits of a LAG on a standalone device with the added advantage of
chassis cluster redundancy. A redundant Ethernet interface LAG has two types of
simultaneous redundancy. The aggregated links within the redundant Ethernet interface
on each node are redundant; if one link in the primary aggregate fails, its traffic load is
taken up by the remaining links. If enough child links on the primary node fail, the redundant
Ethernet interface LAG can be configured so that all traffic on the entire redundant
Ethernet interface fails over to the aggregate link on the other node. You can also configure
interface monitoring for LACP-enabled redundancy group reth child links for added
protection.

Copyright © 2016, Juniper Networks, Inc. 165

Chassis Cluster Feature Guide for Branch SRX Series Devices

Aggregated Ethernet interfaces, known as local LAGs, are also supported on either node
of a chassis cluster but cannot be added to redundant Ethernet interfaces. Local LAGs
are indicated in the system interfaces list using an ae- prefix. Likewise any child interface
of an existing local LAG cannot be added to a redundant Ethernet interface and vice
versa. Note that it is necessary for the switch (or switches) used to connect the nodes
in the cluster to have a LAG link configured and 802.3ad enabled for each LAG on both
nodes so that the aggregate links are recognized as such and correctly pass traffic. The
total maximum number of combined individual node LAG interfaces (ae) and redundant
Ethernet (reth) interfaces per cluster is 128.

NOTE: The redundant Ethernet interface LAG child links from each node in
the chassis cluster must be connected to a different LAG at the peer devices.
If a single peer switch is used to terminate the redundant Ethernet interface
LAG, two separate LAGs must be used in the switch.

Links from different PICs or IOCs and using different cable types (for example, copper
and fiber-optic) can be added to the same redundant Ethernet interface LAG but the
speed of the interfaces must be the same and all interfaces must be in full duplex mode.
We recommend, however, that for purposes of reducing traffic processing overhead,
interfaces from the same PIC or IOC be used whenever feasible. Regardless, all interfaces
configured in a redundant Ethernet interface LAG share the same virtual MAC address.

NOTE: SRX Series devices interface-monitoring feature now allows

monitoring of redundant Ethernet/aggregated Ethernet interfaces.

Redundant Ethernet interface configuration also includes a minimum-links setting that

allows you to set a minimum number of physical child links on the primary node in a given
redundant Ethernet interface that must be working for the interface to be up. The default
minimum-links value is 1. Note that the minimum-links setting only monitors child links
on the primary node. Redundant Ethernet interfaces do not use physical interfaces on
the backup node for either ingress or egress traffic.

Note the following support details:

• Quality of service (QoS) is supported in a redundant Ethernet interface LAG. Guaranteed

bandwidth is, however, duplicated across all links. If a link is lost, there is a corresponding
loss of guaranteed bandwidth.

• Layer 2 transparent mode and Layer 2 security features are supported in redundant
Ethernet interface LAGs.

• Link Aggregation Control Protocol (LACP) is supported in chassis cluster deployments,

where aggregated Ethernet interfaces and redundant Ethernet interfaces are supported
simultaneously.

• Chassis cluster management, control, and fabric interfaces cannot be configured as

redundant Ethernet interface LAGs or added to a redundant Ethernet interface LAG.

166 Copyright © 2016, Juniper Networks, Inc.

 Chapter 16: Configuring Redundant Ethernet LAG Interfaces for Increasing High Availability and Overall Throughput

• Network processor (NP) bundling can coexist with redundant Ethernet interface LAGs
on the same cluster. However, assigning an interface simultaneously to a redundant
Ethernet interface LAG and a network processor bundle is not supported.

NOTE: IOC2 cards do not have network processors but IOC1 cards do have
them.

• Single flow throughput is limited to the speed of a single physical link regardless of the
speed of the aggregate interface.

NOTE: On SRX300, SRX320, SRX340, SRX345, and SRX550 devices, the

speed mode and link mode configuration is available for member interfaces
of a reth interface.

NOTE: For more information about Ethernet interface link aggregation and
LACP, see the “Aggregated Ethernet” information in the Interfaces Feature
Guide for Security Devices.

Related • Understanding Chassis Cluster Redundant Ethernet Interfaces on page 77

Documentation
• Example: Configuring Chassis Cluster Redundant Ethernet Interface Link Aggregation
Groups on page 167

• Example: Configuring Chassis Cluster Minimum Links on page 178

• Understanding Conditional Route Advertising in a Chassis Cluster on page 159

• Preparing Your Equipment for Chassis Cluster Formation on page 35

Example: Configuring Chassis Cluster Redundant Ethernet Interface Link Aggregation

Groups

Supported Platforms SRX Series, vSRX

This example shows how to configure a redundant Ethernet interface link aggregation
group for a chassis cluster. Chassis cluster configuration supports more than one child
interface per node in a redundant Ethernet interface. When at least two physical child
interface links from each node are included in a redundant Ethernet interface configuration,
the interfaces are combined within the redundant Ethernet interface to form a redundant
Ethernet interface link aggregation group.

• Requirements on page 168

• Overview on page 168
• Configuration on page 168
• Verification on page 170

Copyright © 2016, Juniper Networks, Inc. 167

Chassis Cluster Feature Guide for Branch SRX Series Devices

Requirements
Before you begin:

• Configure chassis cluster redundant interfaces. See “Example: Configuring Chassis

Cluster Redundant Ethernet Interfaces for IPv4 and IPv6 Addresses” on page 79.

• Understand chassis cluster redundant Ethernet interface link aggregation groups. See
“Understanding Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups
for Branch SRX Series Devices” on page 165 or Understanding Chassis Cluster Redundant
Ethernet Interface Link Aggregation Groups for High-End SRX Series Devices.

Overview

NOTE: For aggregation to take place, the switch used to connect the nodes
in the cluster must enable IEEE 802.3ad link aggregation for the redundant
Ethernet interface physical child links on each node. Because most switches
support IEEE 802.3ad and are also LACP capable, we recommend that you
enable LACP on SRX Series devices. In cases where LACP is not available on
the switch, you should not enable LACP on SRX Series devices.

In this example, you assign six Ethernet interfaces to reth1 to form the Ethernet interface
link aggregation group:

• ge-1/0/1—reth1

• ge-1/0/2—reth1

• ge-1/0/3—reth1

• ge-12/0/1—reth1

• ge-12/0/2—reth1

• ge-12/0/3—reth1

NOTE: A maximum of eight physical interfaces per node in a cluster, for a

total of 16 child interfaces, can be assigned to a single redundant Ethernet
interface when a redundant Ethernet interface LAG is being configured.

NOTE: Junos OS supports LACP and LAG on a redundant Ethernet interface,

which is called RLAG.

Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network

168 Copyright © 2016, Juniper Networks, Inc.

 Chapter 16: Configuring Redundant Ethernet LAG Interfaces for Increasing High Availability and Overall Throughput

configuration, and copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.

{primary:node0}[edit]
set interfaces ge-1/0/1 gigether-options redundant-parent reth1
set interfaces ge-1/0/2 gigether-options redundant-parent reth1
set interfaces ge-1/0/3 gigether-options redundant-parent reth1
set interfaces ge-12/0/1 gigether-options redundant-parent reth1
set interfaces ge-12/0/2 gigether-options redundant-parent reth1
set interfaces ge-12/0/3 gigether-options redundant-parent reth1

Step-by-Step To configure a redundant Ethernet interface link aggregation group:

Procedure
• Assign Ethernet interfaces to reth1.

{primary:node0}[edit]
user@host# set interfaces ge-1/0/1 gigether-options redundant-parent reth1
user@host# set interfaces ge-1/0/2 gigether-options redundant-parent reth1
user@host# set interfaces ge-1/0/3 gigether-options redundant-parent reth1
user@host# set interfaces ge-12/0/1 gigether-options redundant-parent reth1
user@host# set interfaces ge-12/0/2 gigether-options redundant-parent reth1
user@host# set interfaces ge-12/0/3 gigether-options redundant-parent reth1

Results From configuration mode, confirm your configuration by entering the show interfaces
reth1 command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).

user@host# show interfaces reth1

...
ge-1/0/1 {
gigether-options {
redundant-parent reth1;
}
}
ge-1/0/2 {
gigether-options {
redundant-parent reth1;
}
}
ge-1/0/3 {
gigether-options {
redundant-parent reth1;
}
}
ge-12/0/1 {
gigether-options {
redundant-parent reth1;
}
}
ge-12/0/2 {
gigether-options {

Copyright © 2016, Juniper Networks, Inc. 169

Chassis Cluster Feature Guide for Branch SRX Series Devices

redundant-parent reth1;
}
}
ge-12/0/3 {
gigether-options {
redundant-parent reth1;
}
}
...

If you are done configuring the device, enter commit from configuration mode.

Verification

Verifying the Redundant Ethernet Interface LAG Configuration

Purpose Verify the redundant Ethernet interface LAG configuration.

Action From operational mode, enter the show interfaces terse | match reth command.

{primary:node0}

user@host> show interfaces terse | match reth

ge-1/0/1.0 up down aenet --> reth1.0
ge-1/0/2.0 up down aenet --> reth1.0
ge-1/0/3.0 up down aenet --> reth1.0
ge-12/0/1.0 up down aenet --> reth1.0
ge-12/0/2.0 up down aenet --> reth1.0
ge-12/0/3.0 up down aenet --> reth1.0
reth0 up down
reth0.0 up down inet 10.100.37.214/24
reth1 up down
reth1.0 up down inet

Related • Understanding Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups
Documentation for Branch SRX Series Devices on page 165

• Understanding Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups

for High-End SRX Series Devices

• Understanding Chassis Cluster Redundant Ethernet Interface LAG Failover on page 170

• Understanding LACP on Chassis Clusters on page 173

• Example: Configuring LACP on Chassis Clusters on page 175

• Example: Configuring Chassis Cluster Minimum Links on page 178

Understanding Chassis Cluster Redundant Ethernet Interface LAG Failover

Supported Platforms SRX Series, vSRX

170 Copyright © 2016, Juniper Networks, Inc.

 Chapter 16: Configuring Redundant Ethernet LAG Interfaces for Increasing High Availability and Overall Throughput

To control failover of redundant Ethernet (reth) interfaces, it is important to configure

the weights of interface monitoring according to the minimum-links setting. This
configuration requires that the weights be equally distributed among the monitored links
such that when the number of active physical interface links falls below the minimum-links
setting, the computed weight for that redundancy group falls to zero or below zero. This
triggers a failover of the redundant Ethernet interfaces link aggregation group (LAG) once
the number of physical links falls below the minimum-links value.

Consider a reth0 interface LAG with four underlying physical links and the minimum-links
value set as 2. In this case, a failover is triggered only when the number of active physical
links is less than 2.

NOTE:
• Interface-monitor and minimum-links values are used to monitor LAG link
status and correctly calculate failover weight.

• The minimum-links value is used to keep the redundant Ethernet link status.
However, to trigger a failover, interface-monitor must be set.

Configure the underlying interface attached to the redundant Ethernet LAG.

{primary:node0}[edit]
user@host# set interfaces ge-0/0/4 gigether-options redundant-parent reth0
user@host# set interfaces ge-0/0/5 gigether-options redundant-parent reth0
user@host# set interfaces ge-0/0/6 gigether-options redundant-parent reth0
user@host# set interfaces ge-0/0/7 gigether-options redundant-parent reth0

Specify the minimum number of links for the redundant Ethernet interface as 2.

{primary:node0}[edit]
user@host# set interfaces reth0 redundant-ether-options minimum-links 2

Set up interface monitoring to monitor the health of the interfaces and trigger redundancy
group failover.

The following scenarios provide examples of how to monitor redundant Ethernet LAG
failover:

• Scenario 1: Monitored Interface Weight Is 255 on page 171

• Scenario 2: Monitored Interface Weight Is 75 on page 172
• Scenario 3: Monitored Interface Weight Is 100 on page 172

Scenario 1: Monitored Interface Weight Is 255

Specify the monitored interface weight as 255 for each underlying interface.

{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight
255
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5 weight
255

Copyright © 2016, Juniper Networks, Inc. 171

Chassis Cluster Feature Guide for Branch SRX Series Devices

user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/6 weight

255
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/7 weight
255

In this case, although there are three active physical links and the redundant Ethernet
LAG could have handled the traffic because of minimum-links configured, one physical
link is still down, which triggers a failover based on the computed weight.

Scenario 2: Monitored Interface Weight Is 75

Specify the monitored interface weight as 75 for each underlying interface.

{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight
75
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5 weight
75
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/6 weight
75
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/7 weight
75

In this case, when three physical links are down, the redundant Ethernet interface will go
down due to minimum-links configured. However, the failover will not happen, which in
turn will result in traffic outage.

Scenario 3: Monitored Interface Weight Is 100

Specify the monitored interface weight as 100 for each underlying interface.

{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight
100
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5 weight
100
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/6 weight
100
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/7 weight
100

In this case, when the three physical links are down, the redundant Ethernet interface
will go down because of the minimum-links value. However, at the same time a failover
would be triggered because of interface monitoring computed weights, ensuring that
there is no traffic disruption.

Of all the three scenarios, scenario 3 illustrates the most ideal way to manage redundant
Ethernet LAG failover.

Related • Understanding Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups
Documentation for Branch SRX Series Devices on page 165

• Understanding Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups

for High-End SRX Series Devices

172 Copyright © 2016, Juniper Networks, Inc.

 Chapter 16: Configuring Redundant Ethernet LAG Interfaces for Increasing High Availability and Overall Throughput

• Example: Configuring Chassis Cluster Redundant Ethernet Interface Link Aggregation

Groups on page 167

• Understanding LACP on Chassis Clusters on page 173

• Example: Configuring LACP on Chassis Clusters on page 175

• Example: Configuring Chassis Cluster Minimum Links on page 178

Understanding LACP on Chassis Clusters

Supported Platforms SRX Series

You can combine multiple physical Ethernet ports to form a logical point-to-point link,
known as a link aggregation group (LAG) or bundle, such that a media access control
(MAC) client can treat the LAG as if it were a single link.

LAGs can be established across nodes in a chassis cluster to provide increased interface
bandwidth and link availability.

The Link Aggregation Control Protocol (LACP) provides additional functionality for LAGs.
LACP is supported in standalone deployments, where aggregated Ethernet interfaces
are supported, and in chassis cluster deployments, where aggregated Ethernet interfaces
and redundant Ethernet interfaces are supported simultaneously.

You configure LACP on a redundant Ethernet interface by setting the LACP mode for the
parent link with the lacp statement. The LACP mode can be off (the default), active, or
passive.

This topic contains the following sections:

• Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups on page 173
• Sub-LAGs on page 174
• Supporting Hitless Failover on page 175
• Managing Link Aggregation Control PDUs on page 175

Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups

A redundant Ethernet interface has active and standby links located on two nodes in a
chassis cluster. All active links are located on one node, and all standby links are located
on the other node. You can configure up to eight active links and eight standby links per
node.

When at least two physical child interface links from each node are included in a redundant
Ethernet interface configuration, the interfaces are combined within the redundant
Ethernet interface to form a redundant Ethernet interface LAG.

Having multiple active redundant Ethernet interface links reduces the possibility of
failover. For example, when an active link is out of service, all traffic on this link is
distributed to other active redundant Ethernet interface links, instead of triggering a
redundant Ethernet active/standby failover.

Copyright © 2016, Juniper Networks, Inc. 173

Chassis Cluster Feature Guide for Branch SRX Series Devices

Aggregated Ethernet interfaces, known as local LAGs, are also supported on either node
of a chassis cluster but cannot be added to redundant Ethernet interfaces. Likewise, any
child interface of an existing local LAG cannot be added to a redundant Ethernet interface,
and vice versa. The total maximum number of combined individual node LAG interfaces
(ae) and redundant Ethernet (reth) interfaces per cluster is 128.

However, aggregated Ethernet interfaces and redundant Ethernet interfaces can coexist,
because the functionality of a redundant Ethernet interface relies on the Junos OS
aggregated Ethernet framework.

For more information, see “Understanding Chassis Cluster Redundant Ethernet Interface
Link Aggregation Groups for Branch SRX Series Devices” on page 165 or Understanding
Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups for High-End SRX
Series Devices.

Minimum Links

Redundant Ethernet interface configuration includes a minimum-links setting that allows

you to set a minimum number of physical child links in a redundant Ethernet interface
LAG that must be working on the primary node for the interface to be up. The default
minimum-links value is 1. When the number of physical links on the primary node in a
redundant Ethernet interface falls below the minimum-links value, the interface will be
down even if some links are still working. For more information, see “Example: Configuring
Chassis Cluster Minimum Links” on page 178.

Sub-LAGs
LACP maintains a point-to-point LAG. Any port connected to the third point is denied.
However, a redundant Ethernet interface does connect to two different systems or two
remote aggregated Ethernet interfaces by design.

To support LACP on both redundant Ethernet interface active and standby links, a
redundant Ethernet interface can be modeled to consist of two sub-LAGs, where all
active links form an active sub-LAG and all standby links form a standby sub-LAG.

In this model, LACP selection logic is applied and limited to one sub-LAG at a time. In
this way, two redundant Ethernet interface sub-LAGs are maintained simultaneously
while all the LACP advantages are preserved for each sub-LAG.

It is necessary for the switches used to connect the nodes in the cluster to have a LAG
link configured and 802.3ad enabled for each LAG on both nodes so that the aggregate
links will be recognized as such and correctly pass traffic.

NOTE: The redundant Ethernet interface LAG child links from each node in
the chassis cluster must be connected to a different LAG at the peer devices.
If a single peer switch is used to terminate the redundant Ethernet interface
LAG, two separate LAGs must be used in the switch.

174 Copyright © 2016, Juniper Networks, Inc.

 Chapter 16: Configuring Redundant Ethernet LAG Interfaces for Increasing High Availability and Overall Throughput

Supporting Hitless Failover

With LACP, the redundant Ethernet interface supports hitless failover between the active
and standby links in normal operation. The term hitless means that the redundant Ethernet
interface state remains up during a failover.

The lacpd process manages both the active and standby links of the redundant Ethernet
interfaces. A redundant Ethernet interface state remains up when the number of active
up links is more than the number of minimum links configured. Therefore, to support
hitless failover, the LACP state on the redundant Ethernet interface standby links must
be collected and distributed before failover occurs.

Managing Link Aggregation Control PDUs

The protocol data units (PDUs) contain information about the state of the link. By default,
aggregated and redundant Ethernet links do not exchange link aggregation control PDUs.

You can configure PDUs exchange in the following ways:

• Configure Ethernet links to actively transmit link aggregation control PDUs

• Configure Ethernet links to passively transmit PDUs, sending out link aggregation
control PDUs only when they are received from the remote end of the same link

The local end of a child link is known as the actor and the remote end of the link is known
as the partner. That is, the actor sends link aggregation control PDUs to its protocol
partner that convey what the actor knows about its own state and that of the partner’s
state.

You configure the interval at which the interfaces on the remote side of the link transmit
link aggregation control PDUs by configuring the periodic statement on the interfaces on
the local side. It is the configuration on the local side that specifies the behavior of the
remote side. That is, the remote side transmits link aggregation control PDUs at the
specified interval. The interval can be fast (every second) or slow (every 30 seconds).

For more information, see “Example: Configuring LACP on Chassis Clusters” on page 175.

By default, the actor and partner transmit link aggregation control PDUs every second.
You can configure different periodic rates on active and passive interfaces. When you
configure the active and passive interfaces at different rates, the transmitter honors the
receiver’s rate.

Related • Example: Configuring LACP on Chassis Clusters on page 175

Documentation

Example: Configuring LACP on Chassis Clusters

Supported Platforms SRX Series

Copyright © 2016, Juniper Networks, Inc. 175

Chassis Cluster Feature Guide for Branch SRX Series Devices

This example shows how to configure LACP on chassis clusters.

• Requirements on page 176

• Overview on page 176
• Configuration on page 176
• Verification on page 177

Requirements
Before you begin:

• Add the aggregated Ethernet interfaces using the device count. See Example: Configuring
the Number of Aggregated Ethernet Interfaces on a Device.

• Associate physical interfaces with the aggregated Ethernet Interfaces. See Example:
Associating Physical Interfaces with Aggregated Ethernet Interfaces.

• Configure the aggregated Ethernet link speed. See Example: Configuring Aggregated
Ethernet Link Speed.

• Configure the aggregated Ethernet minimum links speed. See Example: Configuring
Aggregated Ethernet Minimum Links.

• Configure the LACP on standalone devices. See Example: Configuring LACP on

Standalone Devices.

Overview
In this example, you set LACP to passive mode for the reth0 interface. You set the LACP
mode for the reth1 interface to active and set the link aggregation control PDU transmit
interval to slow, which is every 30 seconds.

Configuration
Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
Mode in the CLI User Guide.

To configure LACP on chassis clusters:

1. Set the first LACP on primary node1.

[edit interfaces]
user@host# set reth0 redundant-ether-options lacp passive

2. Set the second LACP.

[edit interfaces]
user@host# set reth1 redundant-ether-options lacp active
user@host# set reth1 redundant-ether-options lacp periodic slow

3. If you are done configuring the device, commit the configuration.

[edit interfaces]
user@host# commit

176 Copyright © 2016, Juniper Networks, Inc.

 Chapter 16: Configuring Redundant Ethernet LAG Interfaces for Increasing High Availability and Overall Throughput

Verification

Verifying LACP on Redundant Ethernet Interfaces

Purpose Display LACP status information for redundant Ethernet interfaces.

Action From operational mode, enter the show lacp interfaces reth0 command.

user@host> show lacp interfaces reth0

Aggregated interface: reth0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-11/0/0 Actor No No Yes Yes Yes Yes Fast Active
ge-11/0/0 Partner No No Yes Yes Yes Yes Fast Active
ge-11/0/1 Actor No No Yes Yes Yes Yes Fast Active
ge-11/0/1 Partner No No Yes Yes Yes Yes Fast Active
ge-11/0/2 Actor No No Yes Yes Yes Yes Fast Active
ge-11/0/2 Partner No No Yes Yes Yes Yes Fast Active
ge-11/0/3 Actor No No Yes Yes Yes Yes Fast Active
ge-11/0/3 Partner No No Yes Yes Yes Yes Fast Active
ge-3/0/0 Actor No No Yes Yes Yes Yes Fast Active
ge-3/0/0 Partner No No Yes Yes Yes Yes Fast Active
ge-3/0/1 Actor No No Yes Yes Yes Yes Fast Active
ge-3/0/1 Partner No No Yes Yes Yes Yes Fast Active
ge-3/0/2 Actor No No Yes Yes Yes Yes Fast Active
ge-3/0/2 Partner No No Yes Yes Yes Yes Fast Active
ge-3/0/3 Actor No No Yes Yes Yes Yes Fast Active
ge-3/0/3 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-11/0/0 Current Fast periodic Collecting distributing
ge-11/0/1 Current Fast periodic Collecting distributing
ge-11/0/2 Current Fast periodic Collecting distributing
ge-11/0/3 Current Fast periodic Collecting distributing
ge-3/0/0 Current Fast periodic Collecting distributing
ge-3/0/1 Current Fast periodic Collecting distributing
ge-3/0/2 Current Fast periodic Collecting distributing
ge-3/0/3 Current Fast periodic Collecting distributing
{primary:node1}

The output shows redundant Ethernet interface information, such as the following:

• The LACP state—Indicates whether the link in the bundle is an actor (local or near-end
of the link) or a partner (remote or far-end of the link).

• The LACP mode—Indicates whether both ends of the aggregated Ethernet interface
are enabled (active or passive)—at least one end of the bundle must be active.

• The periodic link aggregation control PDU transmit rate.

• The LACP protocol state—Indicates the link is up if it is collecting and distributing

packets.

Related • Understanding LACP on Chassis Clusters on page 173

Documentation
• Verifying LACP on Redundant Ethernet Interfaces

Copyright © 2016, Juniper Networks, Inc. 177

Chassis Cluster Feature Guide for Branch SRX Series Devices

Example: Configuring Chassis Cluster Minimum Links

Supported Platforms SRX Series, vSRX

This example shows how to specify a minimum number of physical links assigned to a
redundant Ethernet interface on the primary node that must be working for the interface
to be up.

• Requirements on page 178

• Overview on page 178
• Configuration on page 178
• Verification on page 179

Requirements
Before you begin:

• Configure redundant Ethernet interfaces. See “Example: Configuring Chassis Cluster

Redundant Ethernet Interfaces for IPv4 and IPv6 Addresses” on page 79.

• Understand redundant Ethernet interface link aggregation groups. See “Example:

Configuring Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups”
on page 167.

Overview

When a redundant Ethernet interface has more than two child links, you can set a
minimum number of physical links assigned to the interface on the primary node that
must be working for the interface to be up. When the number of physical links on the
primary node falls below the minimum-links value, the interface will be down even if
some links are still working.

In this example, you specify that three child links on the primary node and bound to reth1
(minimum-links value) be working to prevent the interface from going down. For example,
in a redundant Ethernet interface LAG configuration in which six interfaces are assigned
to reth1, setting the minimum-links value to 3 means that all reth1 child links on the primary
node must be working to prevent the interface’s status from changing to down.

NOTE: Although it is possible to set a minimum-links value for a redundant

Ethernet interface with only two child interfaces (one on each node), we do
not recommend it.

Configuration
Step-by-Step To specify the minimum number of links:
Procedure
1. Specify the minimum number of links for the redundant Ethernet interface.

{primary:node0}[edit]

178 Copyright © 2016, Juniper Networks, Inc.

 Chapter 16: Configuring Redundant Ethernet LAG Interfaces for Increasing High Availability and Overall Throughput

user@host# set interfaces reth1 redundant-ether-options minimum-links 3

2. If you are done configuring the device, commit the configuration.

{primary:node0}[edit]
user@host# commit

Verification

Verifying the Chassis Cluster Minimum Links Configuration

Purpose To verify the configuration is working properly, enter the show interface reth1 command.

Action From operational mode, enter the show show interfaces reth1 command.

{primary:node0}[edit]
user@host> show interfaces reth1
Physical interface: reth1, Enabled, Physical link is Down
Interface index: 129, SNMP ifIndex: 548
Link-level type: Ethernet, MTU: 1514, Speed: Unspecified, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,
Flow control: Disabled, Minimum links needed: 3, Minimum bandwidth needed: 0
Device flags : Present Running
Interface flags: Hardware-Down SNMP-Traps Internal: 0x0
Current address: 00:10:db:ff:10:01, Hardware address: 00:10:db:ff:10:01
Last flapped : 2010-09-15 15:54:53 UTC (1w0d 22:07 ago)
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)

Logical interface reth1.0 (Index 68) (SNMP ifIndex 550)

Flags: Hardware-Down Device-Down SNMP-Traps 0x0 Encapsulation: ENET2
Statistics Packets pps Bytes bps
Bundle:
Input : 0 0 0 0
Output: 0 0 0 0
Security: Zone: untrust
Allowed host-inbound traffic : bootp bfd bgp dns dvmrp igmp ldp msdp nhrp
ospf pgm pim rip router-discovery rsvp sap vrrp dhcp finger ftp tftp
ident-reset http https ike netconf ping reverse-telnet reverse-ssh rlogin
rpm rsh snmp snmp-trap ssh telnet traceroute xnm-clear-text xnm-ssl lsping
ntp sip
Protocol inet, MTU: 1500
Flags: Sendbcast-pkt-to-re

Related • Understanding Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups
Documentation Branch SRX Series Devices on page 165

• Understanding Chassis Cluster Redundant Ethernet Interface Link Aggregation Groups

for High-End SRX Series Devices

• Example: Configuring Chassis Cluster Redundant Ethernet Interface Link Aggregation

Groups on page 167

• Understanding Conditional Route Advertising in a Chassis Cluster on page 159

Copyright © 2016, Juniper Networks, Inc. 179

Chassis Cluster Feature Guide for Branch SRX Series Devices

180 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 17

Simplifying Chassis Cluster Management

• Understanding Automatic Chassis Cluster Synchronization Between Primary and

Secondary Nodes on page 181
• Verifying Chassis Cluster Configuration Synchronization Status on page 182
• NTP Time Synchronization on SRX Series Devices on page 183
• Simplifying Network Management by Synchronizing the Primary and Backup Routing
Engines with NTP on page 183

Understanding Automatic Chassis Cluster Synchronization Between Primary and

Secondary Nodes

Supported Platforms SRX Series, vSRX

When you set up an SRX Series chassis cluster, the SRX Series devices must be identical,
including their configuration. The chassis cluster synchronization feature automatically
synchronizes the configuration from the primary node to the secondary node when the
secondary joins the primary as a cluster. By eliminating the manual work needed to ensure
the same configurations on each node in the cluster, this feature reduces expenses.

If you want to disable automatic chassis cluster synchronization between the primary
and secondary nodes, you can do so by entering the set chassis cluster
configuration-synchronize no-secondary-bootup-auto command in configuration mode.

At any time, to reenable automatic chassis cluster synchronization, use the delete chassis
cluster configuration-synchronize no-secondary-bootup-auto command in configuration
mode.

To see whether the automatic chassis cluster synchronization is enabled or not, and to
see the status of the synchronization, enter the show chassis cluster information
configuration-synchronization operational command.

Either the entire configuration from the primary node is applied successfully to the
secondary node, or the secondary node retains its original configuration. There is no
partial synchronization.

Copyright © 2016, Juniper Networks, Inc. 181

Chassis Cluster Feature Guide for Branch SRX Series Devices

NOTE: If you create a cluster with cluster IDs greater than 16, and then decide
to roll back to a previous release image that does not support extended
cluster IDs, the system comes up as standalone.

NOTE: If you have a cluster set up and running with an earlier release of Junos
OS, you can upgrade to Junos OS Release 12.1X45-D10 and re-create a cluster
with cluster IDs greater than 16. However, if for any reason you decide to
revert to the previous version of Junos OS that did not support extended
cluster IDs, the system comes up with standalone devices after you reboot.
However, if the cluster ID set is less than 16 and you roll back to a previous
release, the system will come back with the previous setup.

Related • Verifying Chassis Cluster Configuration Synchronization Status on page 182

Documentation
• NTP Time Synchronization on SRX Series Devices on page 183

• Simplifying Network Management by Synchronizing the Primary and Backup Routing

Engines with NTP on page 183

Verifying Chassis Cluster Configuration Synchronization Status

Supported Platforms SRX Series, vSRX

Purpose Display the configuration synchronization status of a chassis cluster.

Action From the CLI, enter the show chassis cluster information configuration-synchronization
command:
{primary:node0}
user@host> show chassis cluster information configuration-synchronization

node0:
--------------------------------------------------------------------------

Configuration Synchronization:
Status:
Activation status: Enabled
Last sync operation: Auto-Sync
Last sync result: Not needed
Last sync mgd messages:

Events:
Mar 5 01:48:53.662 : Auto-Sync: Not needed.

node1:
--------------------------------------------------------------------------

Configuration Synchronization:
Status:
Activation status: Enabled
Last sync operation: Auto-Sync
Last sync result: Succeeded

182 Copyright © 2016, Juniper Networks, Inc.

 Chapter 17: Simplifying Chassis Cluster Management

Last sync mgd messages:

mgd: rcp: /config/juniper.conf: No such file or directory
mgd: commit complete

Events:
Mar 5 01:48:55.339 : Auto-Sync: In progress. Attempt: 1
Mar 5 01:49:40.664 : Auto-Sync: Succeeded. Attempt: 1

Related • Understanding Automatic Chassis Cluster Synchronization Between Primary and

Documentation Secondary Nodes on page 181

• NTP Time Synchronization on SRX Series Devices on page 183

• Simplifying Network Management by Synchronizing the Primary and Backup Routing

Engines with NTP on page 183

• show chassis cluster information configuration-synchronization on page 336

NTP Time Synchronization on SRX Series Devices

Supported Platforms SRX Series, vSRX

Network Time Protocol (NTP) is used to synchronize the time between the Packet
Forwarding Engine and the Routing Engine in a standalone device and between two
devices in a chassis cluster.

In both standalone and chassis cluster modes, the primary Routing Engine runs the NTP
process to get the time from the external NTP server. Although the secondary Routing
Engine runs the NTP process in an attempt to get the time from the external NTP server,
this attempt fails because of network issues. For this reason, the secondary Routing
Engine uses NTP to get the time from the primary Routing Engine.

Use NTP to:

• Send the time from the primary Routing Engine to the secondary Routing Engine through
the chassis cluster control link.

• Get the time from an external NTP server to the primary or a standalone Routing Engine.

• Get the time from the Routing Engine NTP process to the Packet Forwarding Engine.

Related • Simplifying Network Management by Synchronizing the Primary and Backup Routing
Documentation Engines with NTP on page 183

Simplifying Network Management by Synchronizing the Primary and Backup Routing

Engines with NTP

Supported Platforms SRX Series, vSRX

This example shows how to simplify management by synchronizing the time between
two SRX Series devices operating in a chassis cluster. Using a Network Time Protocol

Copyright © 2016, Juniper Networks, Inc. 183

Chassis Cluster Feature Guide for Branch SRX Series Devices

(NTP) server, you synchronize the primary Routing Engine with the secondary Routing
Engine through the management port.

• Requirements on page 184

• Overview on page 184
• Configuration on page 185
• Verification on page 187

Requirements
This example uses the following hardware and software components:

• SRX Series devices operating in a chassis cluster

• Junos OS Release 12.1X47-D10 or later

Before you begin:

• Understand the basics of the Network Time Protocol. See Time Management Routing
Guide for Administration Devices.

Overview
When SRX Series devices are operating in chassis cluster mode, the backup Routing
Engine cannot access the external NTP server through the revenue port. The following
two examples synchronize the time from the peer Routing Engine or from the NTP server,
both using the management port:

• Synchronizing Time from the Peer Routing Engine with the Management Port (fxp0)

• Synchronizing Time from the NTP Server with the Management Port (fxp0)

Topology

Figure 18 on page 184 shows the time synchronization from the peer Routing Engine using
the management port, fxp0.

Figure 18: Synchronizing Time from the Peer Routing Engine Using fxp0

With this configuration, both Routing Engines in a chassis cluster will have two NTP
servers (one Routing Engine points to the external server, and the other Routing Engine
points to the peer Routing Engine fxp0 address). In the primary Routing Engine, both NTP
servers are reachable, and the NTP process selects the best server for synchronizing time.

184 Copyright © 2016, Juniper Networks, Inc.

 Chapter 17: Simplifying Chassis Cluster Management

The secondary Routing Engine can reach only one NTP server (pointing to the peer fxp0
address), so this server is used for synchronizing time.

Figure 19 on page 185 shows the time synchronization from the NTP server using the
management port, fxp0.

Figure 19: Synchronizing Time from the NTP Server Using fxp0

In this configuration, the NTP server address is 10.208.0.50, which is reachable through
the management port. The management ports of both Routing Engines in chassis cluster
mode are enabled. In this configuration, both Routing Engines can access the NTP server
to synchronize time.

Configuration
• Synchronizing Time from the Peer Routing Engine Using the Management Port
(fxp0) on page 186
• Synchronizing Time from the NTP Server Using the Management Port (fxp0) on page 186
• Results on page 186

CLI Quick To quickly configure this example, and synchronize the time from the peer Routing Engine
Configuration using the management port, copy the following commands, paste them into a text file,
remove any line breaks, change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter
commit from configuration mode.

set system ntp server 1.1.1.121

set groups node0 system ntp server 10.208.131.32
set groups node1 system ntp server 10.208.131.31

NOTE: 10.208.131.32 is the fxp0 IP address of node 0, and 10.208.131.31 is the

fxp0 IP address of node 1.

To quickly configure this example, and synchronize the time from the NTP server using
the management port, copy the following commands, paste them into a text file, remove
any line breaks, change any details necessary to match your network configuration, copy
and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit
from configuration mode.

set system ntp server 10.208.0.50

Copyright © 2016, Juniper Networks, Inc. 185

Chassis Cluster Feature Guide for Branch SRX Series Devices

Synchronizing Time from the Peer Routing Engine Using the Management Port
(fxp0)

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
Mode in the CLI User Guide.

To synchronize the time from the peer Routing Engine using the management port:

1. Configure the NTP server.

[edit system]
user@host#set ntp server 1.1.1.121

2. Configure the NTP server address for node 0.

[edit groups]
user@host#set node0 system ntp server 10.208.131.32

3. Configure the NTP server address for node 1.

[edit groups]
user@host#set node1 system ntp server 10.208.131.31

Synchronizing Time from the NTP Server Using the Management Port (fxp0)

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
Mode in the CLI User Guide.

To synchronize the time from the NTP server using the management port:

• Configure the NTP server address.

[edit system]
user@host#set ntp server 10.208.0.50

Results

From configuration mode, confirm your configuration by entering the show system ntp
command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).

{primary:node0}[edit]
user@host# show system ntp
server 1.1.1.121
{primary:node0}[edit]
user@host# show groups node0 system ntp
server 10.208.131.32;
{primary:node0}[edit]
user@host# show groups node1 system ntp

186 Copyright © 2016, Juniper Networks, Inc.

 Chapter 17: Simplifying Chassis Cluster Management

server 10.208.131.31;

If you are done configuring the device, enter commit from configuration mode.

Verification
Confirm that the configuration is working properly.

• Verifying the NTP Configuration on the Primary Node on page 187

• Verifying the NTP Configuration on the Secondary Node on page 188

Verifying the NTP Configuration on the Primary Node

Purpose Verify that the configuration is working properly.

Action From operational mode, enter the show ntp associations command:

user@host> show ntp associations

remote refid st t when poll reach delay offset jitter
==============================================================================
*1-1-1-121-dynami 10.208.0.50 4 - 63 64 65 4.909 -12.067 2.014
+10.208.131.32 129.96.0.1 6 - 1 64 377 0.251 -1.828 2.021

From operational mode, enter the show ntp status command:

user@host> show ntp status

status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg,
version="ntpd 4.2.0-a Fri Mar 21 00:50:30 PDT 2014 (1)",
processor="i386", system="JUNOS12.1I20140320_srx_12q1_x47.1-637245",
leap=00, stratum=5, precision=-20, rootdelay=209.819,
rootdispersion=513.087, peer=14596, refid=1.1.1.121,
reftime=d6dbb2f9.b3f41ff7 Tue, Mar 25 2014 15:47:05.702, poll=6,
clock=d6dbb47a.72918b20 Tue, Mar 25 2014 15:53:30.447, state=4,
offset=-6.066, frequency=-55.135, jitter=4.343, stability=0.042

Meaning The output on the primary node shows the NTP association as follows:

• remote—Address or name of the remote NTP peer.

• refid—Reference identifier of the remote peer. If the reference identifier is not known,
this field shows a value of 0.0.0.0.

• st—Stratum of the remote peer.

• t—Type of peer: b (broadcast), l (local), m (multicast), or u (unicast).

• when—When the last packet from the peer was received.

• poll—Polling interval, in seconds.

• reach—Reachability register, in octal.

• delay—Current estimated delay of the peer, in milliseconds.

• offset—Current estimated offset of the peer, in milliseconds.

• jitter—Magnitude of jitter, in milliseconds.

The output on the primary node shows the NTP status as follows:

Copyright © 2016, Juniper Networks, Inc. 187

Chassis Cluster Feature Guide for Branch SRX Series Devices

• status—System status word, a code representing the status items listed.

• x events—Number of events that have occurred since the last code change. An event
is often the receipt of an NTP polling message.

• version—A detailed description of the version of NTP being used.

• processor—Current hardware platform and version of the processor.

• system—Detailed description of the name and version of the operating system in use.

• leap—Number of leap seconds in use.

• stratum—Stratum of the peer server. Anything greater than 1 is a secondary reference

source, and the number roughly represents the number of hops away from the stratum
1 server. Stratum 1 is a primary reference, such as an atomic clock.

• precision—Precision of the peer clock, how precisely the frequency and time can be
maintained with this particular timekeeping system.

• rootdelay—Total roundtrip delay to the primary reference source, in seconds.

• rootdispersion—Maximum error relative to the primary reference source, in seconds.

• peer—Identification number of the peer in use.

• refid—Reference identifier of the remote peer. If the reference identifier is not known,
this field shows a value of 0.0.0.0.

• reftime—Local time, in timestamp format, when the local clock was last updated. If
the local clock has never been synchronized, the value is zero.

• poll—NTP broadcast message polling interval, in seconds.

• clock—Current time on the local router clock.

• state—Current mode of NTP operation, where 1 is symmetric active, 2 is symmetric

passive, 3 is client, 4 is server, and 5 is broadcast.

• offset—Current estimated offset of the peer, in milliseconds. Indicates the time

difference between the reference clock and the local clock.

• frequency—Frequency of the clock.

• jitter—Magnitude of jitter, in milliseconds.

• stability—Measurement of how well this clock can maintain a constant frequency.

Verifying the NTP Configuration on the Secondary Node

Purpose Verify that the configuration is working properly.

Action From operational mode, enter the show ntp associations command:

user@host> show ntp associations

remote refid st t when poll reach delay offset jitter
==============================================================================
1-1-1-121-dynami .INIT. 16 - - 1024 0 0.000 0.000 4000.00
+10.208.131.31 1.1.1.121 5 - 14 64 377 0.244 -0.929 1.510
*129.96.0.1 1.1.1.121 5 u 32 64 377 0.417 0.760 1.204

188 Copyright © 2016, Juniper Networks, Inc.

 Chapter 17: Simplifying Chassis Cluster Management

From operational mode, enter the show ntp status command:

user@host> show ntp status

status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg,
version="ntpd 4.2.0-a Thu Mar 13 01:53:03 PDT 2014 (1)",
processor="i386", system="JUNOS12.1I20140312_srx_12q1_x47.2-635305",
leap=00, stratum=12, precision=-20, rootdelay=2.408,
rootdispersion=892.758, peer=51948, refid=1.1.1.121,
reftime=d6d646bb.853d2f42 Fri, Mar 21 2014 13:03:55.520, poll=6,
clock=d6d647bc.e8f28b2f Fri, Mar 21 2014 13:08:12.909, state=4,
offset=-1.126, frequency=-62.564, jitter=0.617, stability=0.002

Meaning The output on the secondary node shows the NTP association as follows:

• remote—Address or name of the remote NTP peer.

• refid—Reference identifier of the remote peer. If the reference identifier is not known,
this field shows a value of 0.0.0.0.

• st—Stratum of the remote peer.

• t—Type of peer: b (broadcast), l (local), m (multicast), or u (unicast).

• when—When the last packet from the peer was received.

• poll—Polling interval, in seconds.

• reach—Reachability register, in octal.

• delay—Current estimated delay of the peer, in milliseconds.

• offset—Current estimated offset of the peer, in milliseconds.

• jitter—Magnitude of jitter, in milliseconds.

The output on the secondary node shows the NTP status as follows:

• status—System status word, a code representing the status items listed.

• x events—Number of events that have occurred since the last code change. An event
is often the receipt of an NTP polling message.

• version—A detailed description of the version of NTP being used.

• processor—Current hardware platform and version of the processor.

• system—Detailed description of the name and version of the operating system in use.

• leap—Number of leap seconds in use.

• stratum—Stratum of the peer server. Anything greater than 1 is a secondary reference

source, and the number roughly represents the number of hops away from the stratum
1 server. Stratum 1 is a primary reference, such as an atomic clock.

• precision—Precision of the peer clock, how precisely the frequency and time can be
maintained with this particular timekeeping system.

• rootdelay—Total roundtrip delay to the primary reference source, in seconds.

• rootdispersion—Maximum error relative to the primary reference source, in seconds.

Copyright © 2016, Juniper Networks, Inc. 189

Chassis Cluster Feature Guide for Branch SRX Series Devices

• peer—Identification number of the peer in use.

• refid—Reference identifier of the remote peer. If the reference identifier is not known,
this field shows a value of 0.0.0.0.

• reftime—Local time, in timestamp format, when the local clock was last updated. If
the local clock has never been synchronized, the value is zero.

• poll—NTP broadcast message polling interval, in seconds.

• clock—Current time on the local router clock.

• state—Current mode of NTP operation, where 1 is symmetric active, 2 is symmetric

passive, 3 is client, 4 is server, and 5 is broadcast.

• offset—Current estimated offset of the peer, in milliseconds. Indicates the time

difference between the reference clock and the local clock.

• frequency—Frequency of the clock.

• jitter—Magnitude of jitter, in milliseconds.

• stability—Measurement of how well this clock can maintain a constant frequency.

Related • Time Management Routing Guide for Administration Devices

Documentation
• NTP Time Synchronization on SRX Series Devices on page 183

• Verifying Chassis Cluster Configuration Synchronization Status on page 182

190 Copyright © 2016, Juniper Networks, Inc.

PART 4

Additional Chassis Cluster Configurations

• Configuring Active/Passive Chassis Cluster Deployments on page 193
• Enabling Multicast Routing or Asymmetric Routing on page 227
• Configuring Chassis Cluster Layer 2 Ethernet Switching on page 243

Copyright © 2016, Juniper Networks, Inc. 191

Chassis Cluster Feature Guide for Branch SRX Series Devices

192 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 18

Configuring Active/Passive Chassis Cluster

Deployments

• Understanding Active/Passive Chassis Cluster Deployment on page 193

• Example: Configuring an Active/Passive Chassis Cluster Pair (CLI) on page 194
• Example: Configuring an Active/Passive Chassis Cluster Pair (J-Web) on page 205
• Understanding Active/Passive Chassis Cluster Deployment with an IPsec
Tunnel on page 207
• Example: Configuring an Active/Passive Chassis Cluster Pair with an IPsec
Tunnel on page 208
• Example: Configuring an Active/Passive Chassis Cluster Pair with an IPsec Tunnel
(J-Web) on page 223

Understanding Active/Passive Chassis Cluster Deployment

Supported Platforms SRX Series, vSRX

In this case, a single device in the cluster is used to route all traffic while the other device
is used only in the event of a failure (see Figure 20 on page 194). When a failure occurs,
the backup device becomes master and controls all forwarding.

Copyright © 2016, Juniper Networks, Inc. 193

Chassis Cluster Feature Guide for Branch SRX Series Devices

Figure 20: Active/Passive Chassis Cluster Scenario

EX Series Untrust zone EX Series

reth 1.0

Both reths belong to SRX Series SRX Series

redundancy group 1

reth 0.0

EX Series EX Series

g030682
Trust zone

An active/passive chassis cluster can be achieved by using redundant Ethernet interfaces

(reths) that are all assigned to the same redundancy group. If any of the interfaces in an
active group in a node fails, the group is declared inactive and all the interfaces in the
group fail over to the other node.

This configuration minimizes the traffic over the fabric link because only one node in the
cluster forwards traffic at any given time.

Related • Example: Configuring an Active/Passive Chassis Cluster Pair (CLI) on page 194
Documentation
• Example: Configuring an Active/Passive Chassis Cluster Pair (J-Web) on page 205

Example: Configuring an Active/Passive Chassis Cluster Pair (CLI)

Supported Platforms SRX Series, vSRX

This example shows how to configure active/passive chassis clustering for devices.

• Requirements on page 194

• Overview on page 195
• Configuration on page 197
• Verification on page 202

Requirements
Before you begin:

194 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

1. Physically connect a pair of devices together, ensuring that they are the same models.

2. Create a fabric link by connecting a Gigabit Ethernet interface on one device to another
Gigabit Ethernet interface on the other device.

3. Create a control link by connecting the control port of the two SRX1500 devices.

4. Connect to one of the devices using the console port. (This is the node that forms the
cluster.) and set the cluster ID and node number.

user@host> set chassis cluster cluster-id 1 node 0 reboot

5. Connect to the other device using the console port and set the cluster ID and node
number.

user@host> set chassis cluster cluster-id 1 node 1 reboot

Overview
In this example, a single device in the cluster is used to route all traffic, and the other
device is used only in the event of a failure. (See Figure 21 on page 195.) When a failure
occurs, the backup device becomes master and controls all forwarding.

Figure 21: Active/Passive Chassis Cluster Topology

You can create an active/passive chassis cluster by configuring redundant Ethernet

interfaces (reths) that are all assigned to the same redundancy group. This configuration
minimizes the traffic over the fabric link because only one node in the cluster forwards
traffic at any given time.

In this example, you configure group (applying the configuration with the apply-groups
command) and chassis cluster information. Then you configure security zones and security
policies. See Table 11 on page 196 through Table 14 on page 197.

Copyright © 2016, Juniper Networks, Inc. 195

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 11: Group and Chassis Cluster Configuration Parameters

Feature Name Configuration Parameters

Groups node0 • Hostname: srx1500-A

• Interface: fxp0
• Unit 0
• 192.168.3.110/24

node1 • Hostname: srx1500-B

• Interface: fxp0
• Unit 0
• 192.168.3.111/24

Table 12: Chassis Cluster Configuration Parameters

Feature Name Configuration Parameters

Fabric links fab0 Interface: ge-0/0/1

fab1 Interface: ge-7/0/1

Heartbeat interval – 1000

Heartbeat threshold – 3

Redundancy group 0 • Priority:

• Node 0: 254
• Node 1: 1

1 • Priority:
• Node 0: 254
• Node 1: 1

Interface monitoring

• ge-0/0/4
• ge-7/0/4
• ge-0/0/5
• ge-7/0/5

Number of redundant Ethernet – 2

interfaces

Interfaces ge-0/0/4 Redundant parent: reth1

ge-7/0/4 Redundant parent: reth1

ge-0/0/5 Redundant parent: reth0

ge-7/0/5 Redundant parent: reth0

196 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

Table 12: Chassis Cluster Configuration Parameters (continued)

Feature Name Configuration Parameters

reth0 Redundancy group: 1

• Unit 0
• 10.16.8.1/24

reth1 Redundancy group: 1

• Unit 0
• 11.2.0.233/24

Table 13: Security Zone Configuration Parameters

Name Configuration Parameters

trust The reth1.0 interface is bound to this zone.

untrust The reth0.0 interface is bound to this zone.

Table 14: Security Policy Configuration Parameters

Purpose Name Configuration Parameters

This security policy permits traffic from the trust ANY • Match criteria:
zone to the untrust zone. • source-address any
• destination-address any
• application any

• Action: permit

Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.

[edit]
set groups node0 system host-name srx1500-A
set groups node0 interfaces fxp0 unit 0 family inet address 192.168.3.110/24
set groups node1 system host-name srx1500-B
set groups node1 interfaces fxp0 unit 0 family inet address 192.168.3.111/24
set apply-groups “${node}”
set interfaces fab0 fabric-options member-interfaces ge-0/0/1
set interfaces fab1 fabric-options member-interfaces ge-7/0/1
set chassis cluster heartbeat-interval 1000
set chassis cluster heartbeat-threshold 3
set chassis cluster redundancy-group 0 node 0 priority 100
set chassis cluster redundancy-group 0 node 1 priority 1
set chassis cluster redundancy-group 1 node 0 priority 100

Copyright © 2016, Juniper Networks, Inc. 197

Chassis Cluster Feature Guide for Branch SRX Series Devices

set chassis cluster redundancy-group 1 node 1 priority 1

set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-7/0/4 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-7/0/5 weight 255
set chassis cluster reth-count 2
set interfaces ge-0/0/5 gigether-options redundant-parent reth1
set interfaces ge-7/0/5 gigether-options redundant-parent reth1
set interfaces ge-0/0/4 gigether-options redundant-parent reth0
set interfaces ge-7/0/4 gigether-options redundant-parent reth0
set interfaces reth0 redundant-ether-options redundancy-group 1
set interfaces reth0 unit 0 family inet address 10.16.8.1/24
set interfaces reth1 redundant-ether-options redundancy-group 1
set interfaces reth1 unit 0 family inet address 1.2.0.233/24
set security zones security-zone untrust interfaces reth1.0
set security zones security-zone trust interfaces reth0.0
set security policies from-zone trust to-zone untrust policy ANY match source-address
any
set security policies from-zone trust to-zone untrust policy ANY match destination-address
any
set security policies from-zone trust to-zone untrust policy ANY match application any
set security policies from-zone trust to-zone untrust policy ANY then permit

Step-by-Step To configure an active/passive chassis cluster:

Procedure
1. Configure the management interface.

{primary:node0}[edit]
user@host# set groups node0 system host-name srx1500-A
user@host# set groups node0 interfaces fxp0 unit 0 family inet address
192.168.3.110/24
user@host# set groups node1 system host-name srx1500-B
user@host# set groups node1 interfaces fxp0 unit 0 family inet address
192.168.3.111/24
user@host# set apply-groups “${node}”

2. Configure the fabric interface.

{primary:node0}[edit]
user@host# set interfaces fab0 fabric-options member-interfaces ge-0/0/1
user@host# set interfaces fab1 fabric-options member-interfaces ge-7/0/1

3. Configure heartbeat settings.

{primary:node0}[edit]
user@host# set chassis cluster heartbeat-interval 1000
user@host# set chassis cluster heartbeat-threshold 3

4. Configure redundancy groups.

{primary:node0}[edit]
user@host# set chassis cluster redundancy-group 0 node 0 priority 100
user@host# set chassis cluster redundancy-group 0 node 1 priority 1
user@host# set chassis cluster redundancy-group 1 node 0 priority 100
user@host# set chassis cluster redundancy-group 1 node 1 priority 1
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4
weight 255

198 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

user@host# set chassis cluster redundancy-group 1 interface-monitor ge-7/0/4

weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5
weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-7/0/5
weight 255

5. Configure redundant Ethernet interfaces.

{primary:node0}[edit]
user@host# set chassis cluster reth-count 2
user@host# set interfaces ge-0/0/5 gigether-options redundant-parent reth1
user@host# set interfaces ge-7/0/5 gigether-options redundant-parent reth1
user@host# set interfaces ge-0/0/4 gigether-options redundant-parent reth0
user@host# set interfaces ge-7/0/4 gigether-options redundant-parent reth0
user@host# set interfaces reth0 redundant-ether-options redundancy-group 1
user@host# set interfaces reth0 unit 0 family inet address 10.16.8.1/24
user@host# set interfaces reth1 redundant-ether-options redundancy-group 1
user@host# set interfaces reth1 unit 0 family inet address 1.2.0.233/24

6. Configure security zones.

{primary:node0}[edit]
user@host# set security zones security-zone untrust interfaces reth1.0
user@host# set security zones security-zone trust interfaces reth0.0

7. Configure security policies.

{primary:node0}[edit]
user@host# set security policies from-zone trust to-zone untrust policy ANY match
source-address any
user@host# set security policies from-zone trust to-zone untrust policy ANY match
destination-address any
user@host# set security policies from-zone trust to-zone untrust policy ANY match
application any
user@host# set security policies from-zone trust to-zone untrust policy ANY then
permit

Results From configuration mode, confirm your configuration by entering the show configuration
command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).

user@host> show configuration

version x.xx.x;
groups {
node0 {
system {
host-name srx1500-A;
}
interfaces {
fxp0 {
unit 0 {
family inet {

Copyright © 2016, Juniper Networks, Inc. 199

Chassis Cluster Feature Guide for Branch SRX Series Devices

address 192.168.3.110/24;
}
}
}
}
}
node1 {
system {
host-name srx1500-B;
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.3.111/24;
}
}
}
}
}
}
apply-groups "${node}";
chassis {
cluster {
reth-count 2;
heartbeat-interval 1000;
heartbeat-threshold 3;
redundancy-group 0 {
node 0 priority 100;
node 1 priority 1;
}
redundancy-group 1 {
node 0 priority 100;
node 1 priority 1;
interface-monitor {
ge–0/0/4 weight 255;
ge–7/0/4 weight 255;
ge–0/0/5 weight 255;
ge–7/0/5 weight 255;
}
}
}
}
interfaces {
ge–0/0/4 {
gigether–options {
redundant–parent reth0;
}
}
ge–7/0/4{
gigether–options {
redundant–parent reth0;
}
}
ge–0/0/5 {
gigether–options {
redundant–parent reth1;

200 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

}
}
ge–7/0/5 {
gigether–options {
redundant–parent reth1;
}
}
fab0 {
fabric–options {
member–interfaces {
ge–0/0/1;
}
}
}
fab1 {
fabric–options {
member–interfaces {
ge–7/0/1;
}
}
}
reth0 {
redundant–ether–options {
redundancy–group 1;
}
unit 0 {
family inet {
address 10.16.8.1/24;
}
}
}
reth1 {
redundant–ether–options {
redundancy–group 1;
}
unit 0 {
family inet {
address 1.2.0.233/24;
}
}
}
}
...
security {
zones {
security–zone untrust {
interfaces {
reth1.0;
}
}
security–zone trust {
interfaces {
reth0.0;
}
}
}

Copyright © 2016, Juniper Networks, Inc. 201

Chassis Cluster Feature Guide for Branch SRX Series Devices

policies {
from-zone trust to-zone untrust {
policy ANY {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
}
}

If you are done configuring the device, enter commit from configuration mode.

Verification
Confirm that the configuration is working properly.

• Verifying Chassis Cluster Status on page 202

• Verifying Chassis Cluster Interfaces on page 202
• Verifying Chassis Cluster Statistics on page 203
• Verifying Chassis Cluster Control Plane Statistics on page 204
• Verifying Chassis Cluster Data Plane Statistics on page 204
• Verifying Chassis Cluster Redundancy Group Status on page 205
• Troubleshooting with Logs on page 205

Verifying Chassis Cluster Status

Purpose Verify the chassis cluster status, failover status, and redundancy group information.

Action From operational mode, enter the show chassis cluster status command.

{primary:node0}
user@host> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 1

node0 100 primary no no
node1 1 secondary no no

Redundancy group: 1 , Failover count: 1

node0 100 primary no no
node1 1 secondary no no

Verifying Chassis Cluster Interfaces

Purpose Verify information about chassis cluster interfaces.

202 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

Action From operational mode, enter the show chassis cluster interfaces command.

{primary:node0}
user@host> show chassis cluster interfaces
Control link name: fxp1

Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
reth1 Up 1

Interface Monitoring:
Interface Weight Status Redundancy-group
ge-0/0/4 255 Up 1
ge-7/0/4 255 Up 1
ge-0/0/5 255 Up 1
ge-7/0/5 255 Up 1

Verifying Chassis Cluster Statistics

Purpose Verify information about the statistics of the different objects being synchronized, the
fabric and control interface hellos, and the status of the monitored interfaces in the
cluster.

Action From operational mode, enter the show chassis cluster statistics command.

{primary:node0}
user@host> show chassis cluster statistics

Control link statistics:

Control link 0:
Heartbeat packets sent: 2276
Heartbeat packets received: 2280
Heartbeat packets errors: 0
Fabric link statistics:
Child link 0
Probes sent: 2272
Probes received: 597
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 6 0
Session create 161 0
Session close 148 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0

Copyright © 2016, Juniper Networks, Inc. 203

Chassis Cluster Feature Guide for Branch SRX Series Devices

GPRS GTP 0 0

Verifying Chassis Cluster Control Plane Statistics

Purpose Verify information about chassis cluster control plane statistics (heartbeats sent and
received) and the fabric link statistics (probes sent and received).

Action From operational mode, enter the show chassis cluster control-plane statistics command.

{primary:node0}
user@host> show chassis cluster control-plane statistics

Control link statistics:

Control link 0:
Heartbeat packets sent: 258689
Heartbeat packets received: 258684
Heartbeat packets errors: 0
Fabric link statistics:
Child link 0
Probes sent: 258681
Probes received: 258681

Verifying Chassis Cluster Data Plane Statistics

Purpose Verify information about the number of RTOs sent and received for services.

Action From operational mode, enter the show chassis cluster data-plane statistics command.

{primary:node0}
user@host> show chassis cluster data-plane statistics

Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 6 0
Session create 161 0
Session close 148 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0
GPRS GTP 0 0

204 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

Verifying Chassis Cluster Redundancy Group Status

Purpose Verify the state and priority of both nodes in a cluster and information about whether
the primary node has been preempted or whether there has been a manual failover.

Action From operational mode, enter the chassis cluster status redundancy-group command.

{primary:node0}
user@host> show chassis cluster status redundancy-group 1
Cluster ID: 1
Node Priority Status Preempt Manual failover

Redundancy-Group: 1, Failover count: 1

node0 100 primary no no
node1 1 secondary no no

Troubleshooting with Logs

Purpose Use these logs to identify any chassis cluster issues. You should run these logs on both
nodes.

Action From operational mode, enter these show commands.

user@host> show log jsrpd

user@host> show log chassisd
user@host> show log messages
user@host> show log dcd
user@host> show traceoptions

Related • Understanding Active/Passive Chassis Cluster Deployment on page 193

Documentation
• Example: Configuring an Active/Passive Chassis Cluster Pair (J-Web) on page 205

Example: Configuring an Active/Passive Chassis Cluster Pair (J-Web)

Supported Platforms SRX Series, vSRX

1. Enable clustering. See Step 1 in “Example: Configuring an Active/Passive Chassis

Cluster Pair (CLI)” on page 194.

2. Configure the management interface. See Step 2 in “Example: Configuring an

Active/Passive Chassis Cluster Pair (CLI)” on page 194.

3. Configure the fabric interface. See Step 3 in “Example: Configuring an Active/Passive

Chassis Cluster Pair (CLI)” on page 194.

4. Configure the redundancy groups.

• Select Configure>Chassis Cluster.

• Enter the following information, and then click Apply:

Redundant ether-Interface Count: 2

Heartbeat Interval: 1000

Copyright © 2016, Juniper Networks, Inc. 205

Chassis Cluster Feature Guide for Branch SRX Series Devices

Heartbeat Threshold: 3

Nodes: 0

Group Number: 0

Priorities: 100

• Enter the following information, and then click Apply:

Nodes: 0

Group Number: 1

Priorities: 1

• Enter the following information, and then click Apply:

Nodes: 1

Group Number: 0

Priorities: 100

5. Configure the redundant Ethernet interfaces.

• Select Configure>Chassis Cluster.

• Select ge-0/0/4.

• Enter reth1 in the Redundant Parent box.

• Click Apply.

• Select ge-7/0/4.

• Enter reth1 in the Redundant Parent box.

• Click Apply.

• Select ge-0/0/5.

• Enter reth0 in the Redundant Parent box.

• Click Apply.

• Select ge-7/0/5.

• Enter reth0 in the Redundant Parent box.

• Click Apply.

• See Step 5 in “Example: Configuring an Active/Passive Chassis Cluster Pair (CLI)”

on page 194 for the last four configuration settings.

6. Configure the security zones. See Step 6 in “Example: Configuring an Active/Passive

Chassis Cluster Pair (CLI)” on page 194.

206 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

7. Configure the security policies. See Step 7 in “Example: Configuring an Active/Passive

Chassis Cluster Pair (CLI)” on page 194.

8. Click OK to check your configuration and save it as a candidate configuration, then

click Commit Options>Commit.

Related • Understanding Active/Passive Chassis Cluster Deployment on page 193

Documentation
• Example: Configuring an Active/Passive Chassis Cluster Pair (CLI) on page 194

Understanding Active/Passive Chassis Cluster Deployment with an IPsec Tunnel

Supported Platforms SRX Series, vSRX

In this case, a single device in the cluster terminates in an IPsec tunnel and is used to
process all traffic while the other device is used only in the event of a failure (see
Figure 22 on page 207). When a failure occurs, the backup device becomes master and
controls all forwarding.

Figure 22: Active/Passive Chassis Cluster with IPsec Tunnel Scenario

(SRX Series Devices)

An active/passive chassis cluster can be achieved by using redundant Ethernet interfaces

(reths) that are all assigned to the same redundancy group. If any of the interfaces in an
active group in a node fails, the group is declared inactive and all the interfaces in the
group fail over to the other node.

This configuration provides a way for a site-to-site IPsec tunnel to terminate in an

active/passive cluster where a redundant Ethernet interface is used as the tunnel endpoint.
In the event of a failure, the redundant Ethernet interface in the backup SRX Series device
becomes active, forcing the tunnel to change endpoints to terminate in the new active
SRX Series device. Because tunnel keys and session information are synchronized between

Copyright © 2016, Juniper Networks, Inc. 207

Chassis Cluster Feature Guide for Branch SRX Series Devices

the members of the chassis cluster, a failover does not require the tunnel to be
renegotiated and all established sessions are maintained.

NOTE: Dynamic tunnels cannot load-balance across different SPCs.

Related • Understanding Active/Passive Chassis Cluster Deployment on page 193

Documentation
• Example: Configuring an Active/Passive Chassis Cluster Pair with an IPsec Tunnel on
page 208

• Example: Configuring an Active/Passive Chassis Cluster Pair with an IPsec Tunnel

(J-Web) on page 223

Example: Configuring an Active/Passive Chassis Cluster Pair with an IPsec Tunnel

Supported Platforms SRX Series, vSRX

This example shows how to configure active/passive chassis clustering with an IPsec
tunnel for SRX Series devices.

• Requirements on page 208

• Overview on page 209
• Configuration on page 213
• Verification on page 220

Requirements
Before you begin:

• Get two SRX5000 models with identical hardware configurations, one SRX1500 edge
router, and four EX Series Ethernet switches.

• Physically connect the two devices (back-to-back for the fabric and control ports)
and ensure that they are the same models. You can configure both the fabric and
control ports on the SRX5000 line.

• Set the two devices to cluster mode and reboot the devices. You must enter the
following operational mode commands on both devices, for example:

• On node 0:

user@host> set chassis cluster cluster-id 1 node 0 reboot

• On node 1:

user@host> set chassis cluster cluster-id 1 node 1 reboot

The cluster ID is the same on both devices, but the node ID must be different because
one device is node 0 and the other device is node 1. The range for the cluster ID is 1
through 255. Setting a cluster ID to 0 is equivalent to disabling a cluster.

208 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

Cluster ID greater than 15 can only be set when the fabric and control link interfaces
are connected back-to-back.

• Get two SRX5000 models with identical hardware configurations, one SRX1500 edge
router, and four EX Series Ethernet switches.

• Physically connect the two devices (back-to-back for the fabric and control ports)
and ensure that they are the same models. You can configure both the fabric and
control ports on the SRX5000 line.

From this point forward, configuration of the cluster is synchronized between the node
members and the two separate devices function as one device. Member-specific
configurations (such as the IP address of the management port of each member) are
entered using configuration groups.

Overview
In this example, a single device in the cluster terminates in an IPsec tunnel and is used
to process all traffic, and the other device is used only in the event of a failure. (See
Figure 23 on page 209.) When a failure occurs, the backup device becomes master and
controls all forwarding.

Figure 23: Active/Passive Chassis Cluster with IPsec Tunnel Topology

(SRX Series Devices)

In this example, you configure group (applying the configuration with the apply-groups
command) and chassis cluster information. Then you configure IKE, IPsec, static route,
security zone, and security policy parameters. See Table 15 on page 210 through
Table 21 on page 212.

Copyright © 2016, Juniper Networks, Inc. 209

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 15: Group and Chassis Cluster Configuration Parameters

Feature Name Configuration Parameters

Groups node0 • Hostname: SRX5800-1

• Interface: fxp0
• Unit 0
• 172.19.100.50/24

node1 • Hostname: SRX5800-2

• Interface: fxp0
• Unit 0
• 172.19.100.51/24

Table 16: Chassis Cluster Configuration Parameters

Feature Name Configuration Parameters

Fabric links fab0 Interface: xe-5/3/0

fab1 Interface: xe-17/3/0

Number of redundant Ethernet – 2

interfaces

Heartbeat interval – 1000

Heartbeat threshold – 3

Redundancy group 0 • Priority:

• Node 0: 254
• Node 1: 1

1 • Priority:
• Node 0: 254
• Node 1: 1

Interface monitoring

• xe-5/0/0
• xe-5/1/0
• xe-17/0/0
• xe-17/1/0

Interfaces xe-5/1/0 Redundant parent: reth1

xe-5/1/0 Redundant parent: reth1

xe-5/0/0 Redundant parent: reth0

210 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

Table 16: Chassis Cluster Configuration Parameters (continued)

Feature Name Configuration Parameters

xe-17/0/0 Redundant parent: reth0

reth0 Redundancy group: 1

• Unit 0
• 10.1.1.60/16

reth1 Redundancy group: 1

• Multipoint
• Unit 0
• 10.10.1.1/30

st0

• Unit 0
• 10.10.1.1/30

Table 17: IKE Configuration Parameters

Feature Name Configuration Parameters

Proposal proposal-set -
standard

Policy preShared • Mode: main

• Proposal reference: proposal-set standard
• IKE Phase 1 policy authentication method: pre-shared-key ascii-text

Gateway SRX1500-1 • IKE policy reference: perShared

• External interface: reth0.0
• Gateway address: 10.1.1.90

NOTE: On all high-end SRX Series devices, only reth interfaces are supported for IKE
external interface configuration in IPsec VPN. Other interface types can be configured,
but IPsec VPN might not work.

On all branch SRX Series devices, reth interfaces and the lo0 interface are supported
for IKE external interface configuration in IPsec VPN. Other interface types can be
configured, but IPsec VPN might not work.

On all high-end SRX Series devices, the lo0 logical interface cannot be configured with
RG0 if used as an IKE gateway external interface.

Table 18: IPsec Configuration Parameters

Feature Name Configuration Parameters

Proposal proposal-set standard –

Copyright © 2016, Juniper Networks, Inc. 211

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 18: IPsec Configuration Parameters (continued)

Feature Name Configuration Parameters

Policy std –

VPN SRX1500-1 • IKE gateway reference: SRX1500-1

• IPsec policy reference: std
• Bind to interface: st0.0
• VPN monitoring: vpn-monitor optimized
• Tunnels established: establish-tunnels immediately

NOTE: The manual VPN name and the site-to-site gateway name cannot
be the same.

Table 19: Static Route Configuration Parameters

Name Configuration Parameters

0.0.0.0/0 Next hop: 10.2.1.1

10.3.0.0/16 Next hop: 10.10.1.2

Table 20: Security Zone Configuration Parameters

Name Configuration Parameters

trust • All system services are allowed.

• All protocols are allowed.
• The reth0.0 interface is bound to this zone.

untrust • All system services are allowed.

• All protocols are allowed.
• The reth1.0 interface is bound to this zone.

vpn • All system services are allowed.

• All protocols are allowed.
• The st0.0 interface is bound to this zone.

Table 21: Security Policy Configuration Parameters

Purpose Name Configuration Parameters

This security policy permits traffic from the trust ANY • Match criteria:
zone to the untrust zone. • source-address any
• destination-address any
• application any

• Action: permit

212 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

Table 21: Security Policy Configuration Parameters (continued)

Purpose Name Configuration Parameters

This security policy permits traffic from the trust vpn-any • Match criteria:
zone to the vpn zone. • source-address any
• destination-address any
• application any

• Action: permit

Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.

{primary:node0}[edit]
set chassis cluster control-ports fpc 2 port 0
set chassis cluster control-ports fpc 14 port 0
set groups node0 system host-name SRX5800-1
set groups node0 interfaces fxp0 unit 0 family inet address 172.19.100.50/24
set groups node1 system host-name SRX5800-2
set groups node1 interfaces fxp0 unit 0 family inet address 172.19.100.51/24
set apply-groups “${node}”
set interfaces fab0 fabric-options member-interfaces xe-5/3/0
set interfaces fab1 fabric-options member-interfaces xe-17/3/0
set chassis cluster reth-count 2
set chassis cluster heartbeat-interval 1000
set chassis cluster heartbeat-threshold 3
set chassis cluster node 0
set chassis cluster node 1
set chassis cluster redundancy-group 0 node 0 priority 254
set chassis cluster redundancy-group 0 node 1 priority 1
set chassis cluster redundancy-group 1 node 0 priority 254
set chassis cluster redundancy-group 1 node 1 priority 1
set chassis cluster redundancy-group 1 preempt
set chassis cluster redundancy-group 1 interface-monitor xe-5/0/0 weight 255
set chassis cluster redundancy-group 1 interface-monitor xe-5/1/0 weight 255
set chassis cluster redundancy-group 1 interface-monitor xe-17/0/0 weight 255
set chassis cluster redundancy-group 1 interface-monitor xe-17/1/0 weight 255
set interfaces xe-5/1/0 gigether-options redundant-parent reth1
set interfaces xe-17/1/0 gigether-options redundant-parent reth1
set interfaces xe-5/0/0 gigether-options redundant-parent reth0
set interfaces xe-17/0/0 gigether-options redundant-parent reth0
set interfaces reth0 redundant-ether-options redundancy-group 1
set interfaces reth0 unit 0 family inet address 10.1.1.60/16
set interfaces reth1 redundant-ether-options redundancy-group 1
set interfaces reth1 unit 0 family inet address 10.2.1.60/16
set interfaces st0 unit 0 multipoint family inet address 10.10.1.1/30
set security ike policy preShared mode main
set security ike policy preShared proposal-set standard
set security ike policy preShared pre-shared-key ascii-text "$ABC123"## Encrypted
password

Copyright © 2016, Juniper Networks, Inc. 213

Chassis Cluster Feature Guide for Branch SRX Series Devices

set security ike gateway SRX1500-1 ike-policy preShared

set security ike gateway SRX1500-1 address 10.1.1.90
set security ike gateway SRX1500-1 external-interface reth0.0
set security ipsec policy std proposal-set standard
set security ipsec vpn SRX1500-1 bind-interface st0.0
set security ipsec vpn SRX1500-1 vpn-monitor optimized
set security ipsec vpn SRX1500-1 ike gateway SRX1500-1
set security ipsec vpn SRX1500-1 ike ipsec-policy std
set security ipsec vpn SRX1500-1 establish-tunnels immediately
set routing-options static route 0.0.0.0/0 next-hop 10.2.1.1
set routing-options static route 10.3.0.0/16 next-hop 10.10.1.2
set security zones security-zone untrust host-inbound-traffic system-services all
set security zones security-zone untrust host-inbound-traffic protocols all
set security zones security-zone untrust interfaces reth1.0
set security zones security-zone trust host-inbound-traffic system-services all
set security zones security-zone trust host-inbound-traffic protocols all
set security zones security-zone trust interfaces reth0.0
set security zones security-zone vpn host-inbound-traffic system-services all 144
set security zones security-zone vpn host-inbound-traffic protocols all
set security zones security-zone vpn interfaces st0.0
set security policies from-zone trust to-zone untrust policy ANY match source-address
any
set security policies from-zone trust to-zone untrust policy ANY match destination-address
any
set security policies from-zone trust to-zone untrust policy ANY match application any
set security policies from-zone trust to-zone vpn policy vpn-any then permit

Step-by-Step To configure an active/passive chassis cluster pair with an IPsec tunnel:

Procedure
1. Configure control ports.

{primary:node0}[edit]
user@host# set chassis cluster control-ports fpc 2 port 0
user@host# set chassis cluster control-ports fpc 14 port 0

2. Configure the management interface.

{primary:node0}[edit]
user@host# set groups node0 system host-name SRX5800-1
user@host# set groups node0 interfaces fxp0 unit 0 family inet address
172.19.100.50/24
user@host#set groups node1 system host-name SRX5800-2
user@host# set groups node1 interfaces fxp0 unit 0 family inet address
172.19.100.51/24
user@host# set apply-groups “${node}”

3. Configure the fabric interface.

{primary:node0}[edit]
user@host# set interfaces fab0 fabric-options member-interfaces xe-5/3/0
user@host# set interfaces fab1 fabric-options member-interfaces xe-17/3/0

4. Configure redundancy groups.

{primary:node0}[edit]
user@host# set chassis cluster reth-count 2
user@host# set chassis cluster heartbeat-interval 1000
user@host# set chassis cluster heartbeat-threshold 3

214 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

user@host# set chassis cluster node 0

user@host# set chassis cluster node 1
user@host# set chassis cluster redundancy-group 0 node 0 priority 254
user@host# set chassis cluster redundancy-group 0 node 1 priority 1
user@host# set chassis cluster redundancy-group 1 node 0 priority 254
user@host# set chassis cluster redundancy-group 1 node 1 priority 1
user@host# set chassis cluster redundancy-group 1 preempt
user@host# set chassis cluster redundancy-group 1 interface-monitor xe-5/0/0
weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor xe-5/1/0
weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor xe-17/0/0
weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor xe-17/1/0
weight 255

5. Configure redundant Ethernet interfaces.

{primary:node0}[edit]
user@host# set interfaces xe-5/1/0 gigether-options redundant-parent reth1
user@host# set interfaces xe-17/1/0 gigether-options redundant-parent reth1
user@host# set interfaces xe-5/0/0 gigether-options redundant-parent reth0
user@host# set interfaces xe-17/0/0 gigether-options redundant-parent reth0
user@host# set interfaces reth0 redundant-ether-options redundancy-group 1
user@host# set interfaces reth0 unit 0 family inet address 10.1.1.60/16
user@host# set interfaces reth1 redundant-ether-options redundancy-group 1
user@host# set interfaces reth1 unit 0 family inet address 10.2.1.60/16

6. Configure IPsec parameters.

{primary:node0}[edit]
user@host# set interfaces st0 unit 0 multipoint family inet address 10.10.1.1/30
user@host# set security ike policy preShared mode main
user@host# set security ike policy preShared proposal-set standard
user@host# set security ike policy preShared pre-shared-key ascii-text "$ABC123"##
Encrypted password
user@host# set security ike gateway SRX1500-1 ike-policy preShared
user@host# set security ike gateway SRX1500-1 address 10.1.1.90
user@host# set security ike gateway SRX1500-1 external-interface reth0.0
user@host# set security ipsec policy std proposal-set standard
user@host# set security ipsec vpn SRX1500-1 bind-interface st0.0
user@host# set security ipsec vpn SRX1500-1 vpn-monitor optimized
user@host# set security ipsec vpn SRX1500-1 ike gateway SRX1500-1
user@host# set security ipsec vpn SRX1500-1 ike ipsec-policy std
user@host# set security ipsec vpn SRX1500-1 establish-tunnels immediately

7. Configure static routes.

{primary:node0}[edit]
user@host# set routing-options static route 0.0.0.0/0 next-hop 10.2.1.1
user@host# set routing-options static route 10.3.0.0/16 next-hop 10.10.1.2

8. Configure security zones.

{primary:node0}[edit]
user@host# set security zones security-zone untrust host-inbound-traffic
system-services all
user@host# set security zones security-zone untrust host-inbound-traffic protocols
all

Copyright © 2016, Juniper Networks, Inc. 215

Chassis Cluster Feature Guide for Branch SRX Series Devices

user@host# set security zones security-zone untrust interfaces reth1.0

user@host# set security zones security-zone trust host-inbound-traffic
system-services all
user@host# set security zones security-zone trust host-inbound-traffic protocols
all
user@host# set security zones security-zone trust interfaces reth0.0
user@host# set security zones security-zone vpn host-inbound-traffic
system-services all
user@host# set security zones security-zone vpn host-inbound-traffic protocols all
user@host# set security zones security-zone vpn interfaces st0.0

9. Configure security policies.

{primary:node0}[edit]
user@host# set security policies from-zone trust to-zone untrust policy ANY match
source-address any
user@host# set security policies from-zone trust to-zone untrust policy ANY match
destination-address any
user@host# set security policies from-zone trust to-zone untrust policy ANY match
application any
user@host# set security policies from-zone trust to-zone vpn policy vpn-any then
permit

Results From operational mode, confirm your configuration by entering the show configuration
command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).

user@host> show configuration

version x.xx.x;
groups {
node0 {
system {
host-name SRX58001;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 172.19.100.50/24;
}
}
}
}
}
node1 {
system {
host-name SRX58002;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 172.19.100.51/24;
}

216 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

}
}
}
}
}
apply-groups "${node}";
system {
root-authentication {
encrypted-password "$ABC123";
}
}
chassis {
cluster {
reth-count 2;
heartbeat-interval 1000;
heartbeat-threshold 3;
control-ports {
fpc 2 port 0;
fpc 14 port 0;
}
redundancy-group 0 {
node 0 priority 254;
node 1 priority 1;
}
redundancy-group 1 {
node 0 priority 254;
node 1 priority 1;
preempt;
interface-monitor {
xe–6/0/0 weight 255;
xe–6/1/0 weight 255;
xe–18/0/0 weight 255;
xe–18/1/0 weight 255;
}
}
}
}
interfaces {
xe–5/0/0 {
gigether–options {
redundant–parent reth0;
}
}
xe–5/1/0 {
gigether–options {
redundant–parent reth1;
}
}
xe–17/0/0 {
gigether–options {
redundant–parent reth0;
}
}
xe–17/1/0 {
gigether–options {
redundant–parent reth1;
}
}
fab0 {
fabric–options {
member–interfaces {

Copyright © 2016, Juniper Networks, Inc. 217

Chassis Cluster Feature Guide for Branch SRX Series Devices

xe–5/3/0;
}
}
}
fab1 {
fabric–options {
member–interfaces {
xe–17/3/0;
}
}
}
reth0 {
redundant–ether–options {
redundancy–group 1;
}
unit 0 {
family inet {
address 10.1.1.60/16;
}
}
}
reth1 {
redundant–ether–options {
redundancy–group 1;
}
unit 0 {
family inet {
address 10.2.1.60/16;
}
}
}
st0 {
unit 0 {
multipoint;
family inet {
address 5.4.3.2/32;
}
}
}
}
routing–options {
static {
route 0.0.0.0/0 {
next–hop 10.2.1.1;
}
route 10.3.0.0/16 {
next–hop 10.10.1.2;
}
}
}
security {
zones {
security–zone trust {
host–inbound–traffic {
system–services {
all;
}
}
interfaces {
reth0.0;
}

218 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

}
security–zone untrust
host-inbound-traffic {
system-services {
all;
}
}
protocols {
all;
}
interfaces {
reth1.0;
}
}

security-zone vpn {
host-inbound-traffic {
system-services {
all;
}
}
protocols {
all;
}
interfaces {
st0.0;
}

}
}
policies {
from–zone trust to–zone untrust {
policy ANY {
match {
source–address any;
destination–address any;
application any;
}
then {
permit;
}
}
}
from–zone trust to–zone vpn {
policy vpn {
match {
source–address any;
destination–address any;
application any;
}
then {
permit;
}
}
}
}
}

If you are done configuring the device, enter commit from configuration mode.

Copyright © 2016, Juniper Networks, Inc. 219

Chassis Cluster Feature Guide for Branch SRX Series Devices

Verification
Confirm that the configuration is working properly.

• Verifying Chassis Cluster Status on page 220

• Verifying Chassis Cluster Interfaces on page 220
• Verifying Chassis Cluster Statistics on page 221
• Verifying Chassis Cluster Control Plane Statistics on page 221
• Verifying Chassis Cluster Data Plane Statistics on page 222
• Verifying Chassis Cluster Redundancy Group Status on page 222
• Troubleshooting with Logs on page 223

Verifying Chassis Cluster Status

Purpose Verify the chassis cluster status, failover status, and redundancy group information.

Action From operational mode, enter the show chassis cluster status command.

{primary:node0}
show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 1

node0 1 primary no no
node1 254 secondary no no

Redundancy group: 1 , Failover count: 1

node0 1 primary yes no
node1 254 secondary yes no

Verifying Chassis Cluster Interfaces

Purpose Verify the chassis cluster interfaces.

Action From operational mode, enter the show chassis cluster interfaces command.

{primary:node0}
user@host> show chassis cluster interfaces
Control link name: fxp1

Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
reth1 Up 1

Interface Monitoring:
Interface Weight Status Redundancy-group
xe-5/0/0 255 Up 1
xe-5/1/0 255 Up 1
xe-17/0/0 255 Up 1
xe-17/1/0 255 Up 1

220 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

Verifying Chassis Cluster Statistics

Purpose Verify information about chassis cluster services and control link statistics (heartbeats
sent and received), fabric link statistics (probes sent and received), and the number of
RTOs sent and received for services.

Action From operational mode, enter the show chassis cluster statistics command.

{primary:node0}
user@host> show chassis cluster statistics

Control link statistics:

Control link 0:
Heartbeat packets sent: 258689
Heartbeat packets received: 258684
Heartbeat packets errors: 0
Fabric link statistics:
Child link 0
Probes sent: 258681
Probes received: 258681
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 6 0
Session create 161 0
Session close 148 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0
GPRS GTP 0 0

Verifying Chassis Cluster Control Plane Statistics

Purpose Verify information about chassis cluster control plane statistics (heartbeats sent and
received) and the fabric link statistics (probes sent and received).

Action From operational mode, enter the show chassis cluster control-panel statistics command.

{primary:node0}
user@host> show chassis cluster control-plane statistics

Control link statistics:

Control link 0:
Heartbeat packets sent: 258689

Copyright © 2016, Juniper Networks, Inc. 221

Chassis Cluster Feature Guide for Branch SRX Series Devices

Heartbeat packets received: 258684

Heartbeat packets errors: 0
Fabric link statistics:
Child link 0
Probes sent: 258681
Probes received: 258681

Verifying Chassis Cluster Data Plane Statistics

Purpose Verify information about the number of RTOs sent and received for services.

Action From operational mode, enter the show chassis cluster data-plane statistics command.

{primary:node0}
user@host> show chassis cluster data-plane statistics

Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 6 0
Session create 161 0
Session close 148 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0
GPRS GTP 0 0

Verifying Chassis Cluster Redundancy Group Status

Purpose Verify the state and priority of both nodes in a cluster and information about whether
the primary node has been preempted or whether there has been a manual failover.

Action From operational mode, enter the chassis cluster status redundancy-group command.

{primary:node0}
user@host> show chassis cluster status redundancy-group 1
Cluster ID: 1
Node Priority Status Preempt Manual failover

Redundancy-Group: 1, Failover count: 1

node0 0 primary yes no
node1 254 secondary yes no

222 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

Troubleshooting with Logs

Purpose Use these logs to identify any chassis cluster issues. You should run these logs on both
nodes.

Action From operational mode, enter these show commands.

user@host> show log jsrpd

user@host> show log chassisd
user@host> show log messages
user@host> show log dcd
user@host> show traceoptions

Related • Understanding Active/Passive Chassis Cluster Deployment on page 193

Documentation
• Understanding Active/Passive Chassis Cluster Deployment with an IPsec Tunnel on
page 207

• Example: Configuring an Active/Passive Chassis Cluster Pair with an IPsec Tunnel

(J-Web) on page 223

Example: Configuring an Active/Passive Chassis Cluster Pair with an IPsec Tunnel

(J-Web)

Supported Platforms SRX Series, vSRX

1. Enable clusters. See Step 1 in “Example: Configuring an Active/Passive Chassis Cluster

Pair with an IPsec Tunnel” on page 208.

2. Configure the management interface. See Step 2 in “Example: Configuring an

Active/Passive Chassis Cluster Pair with an IPsec Tunnel” on page 208.

3. Configure the fabric interface. See Step 3 in “Example: Configuring an Active/Passive

Chassis Cluster Pair with an IPsec Tunnel” on page 208.

4. Configure the redundancy groups.

• Select Configure>System Properties>Chassis Cluster.

• Enter the following information, and then click Apply:

Redundant ether-Interfaces Count: 2

Heartbeat Interval: 1000

Heartbeat Threshold: 3

Nodes: 0

Group Number: 0

Priorities: 254

• Enter the following information, and then click Apply:

Nodes: 0

Copyright © 2016, Juniper Networks, Inc. 223

Chassis Cluster Feature Guide for Branch SRX Series Devices

Group Number: 1

Priorities: 254

• Enter the following information, and then click Apply:

Nodes: 1

Group Number: 0

Priorities: 1

• Enter the following information, and then click Apply:

Nodes: 1

Group Number: 1

Priorities: 1

Preempt: Select the check box.

Interface Monitor—Interface: xe-5/0/0

Interface Monitor—Weight: 255

Interface Monitor—Interface: xe-5/1/0

Interface Monitor—Weight: 255

Interface Monitor—Interface: xe-17/0/0

Interface Monitor—Weight: 255

Interface Monitor—Interface: xe-17/1/0

Interface Monitor—Weight: 255

5. Configure the redundant Ethernet interfaces.

• Select Configure>System Properties>Chassis Cluster.

• Select xe-5/1/0.

• Enter reth1 in the Redundant Parent box.

• Click Apply.

• Select xe-17/1/0.

• Enter reth1 in the Redundant Parent box.

• Click Apply.

• Select xe-5/0/0.

• Enter reth0 in the Redundant Parent box.

• Click Apply.

• Select xe-17/0/0.

• Enter reth0 in the Redundant Parent box.

224 Copyright © 2016, Juniper Networks, Inc.

 Chapter 18: Configuring Active/Passive Chassis Cluster Deployments

• Click Apply.

• See Step 5 in “Example: Configuring an Active/Passive Chassis Cluster Pair with an

IPsec Tunnel” on page 208.

6. Configure the IPsec configuration. See Step 6 in “Example: Configuring an

Active/Passive Chassis Cluster Pair with an IPsec Tunnel” on page 208.

7. Configure the static routes .

• Select Configure>Routing>Static Routing.

• Click Add.

• Enter the following information, and then click Apply:

Static Route Address: 0.0.0.0/0

Next-Hop Addresses: 10.2.1.1

• Enter the following information, and then click Apply:

Static Route Address: 10.3.0.0/16

Next-Hop Addresses: 10.10.1.2

8. Configure the security zones. See Step 8 in “Example: Configuring an Active/Passive

Chassis Cluster Pair with an IPsec Tunnel” on page 208.

9. Configure the security policies. See Step 9 in “Example: Configuring an Active/Passive

Chassis Cluster Pair with an IPsec Tunnel” on page 208.

10. Click OK to check your configuration and save it as a candidate configuration, then
click Commit Options>Commit.

Related • Understanding Active/Passive Chassis Cluster Deployment with an IPsec Tunnel on

Documentation page 207

• Example: Configuring an Active/Passive Chassis Cluster Pair with an IPsec Tunnel on

page 208

Copyright © 2016, Juniper Networks, Inc. 225

Chassis Cluster Feature Guide for Branch SRX Series Devices

226 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 19

Enabling Multicast Routing or Asymmetric

Routing

• Understanding Multicast Routing on a Chassis Cluster on page 227

• Understanding Asymmetric Routing Chassis Cluster Deployment on page 228
• Example: Configuring an Asymmetric Chassis Cluster Pair on page 230

Understanding Multicast Routing on a Chassis Cluster

Supported Platforms SRX Series, vSRX

Multicast routing support across nodes in a chassis cluster allows multicast protocols,
such as Protocol Independent Multicast (PIM) versions 1 and 2, Internet Group
Management Protocol (IGMP), Session Announcement Protocol (SAP), and Distance
Vector Multicast Routing Protocol (DVMRP), to send traffic across interfaces in the
cluster. Note, however, that the multicast protocols should not be enabled on the chassis
management interface (fxp0) or on the fabric interfaces (fab0 and fab1). Multicast
sessions will be synched across the cluster and will be maintained during redundant
group failovers. During failover, as with other types of traffic, there might be some
multicast packet loss.

Multicast data forwarding in a chassis cluster uses the incoming interface to determine
whether or not the session remains active. Packets will be forwarded to the peer node if
a leaf session’s outgoing interface is on the peer instead of on the incoming interface’s
node. Multicast routing on a chassis cluster supports tunnels for both incoming and
outgoing interfaces.

Multicast traffic has an upstream (toward source) and downstream (toward subscribers)
direction in traffic flows. The devices replicate (fanout) a single multicast packet to
multiple networks that contain subscribers. In the chassis cluster environment, multicast
packet fanouts can be active on either nodes.

If the incoming interface is active on the current node and backup on the peer node, then
the session is active on the current node and backup on the peer node.

Multicast configuration on a chassis cluster is the same as multicast configuration on a

standalone device. See the Junos OS Routing Protocols Library for Security Devices for
more information.

Copyright © 2016, Juniper Networks, Inc. 227

Chassis Cluster Feature Guide for Branch SRX Series Devices

Understanding PIM Data Forwarding

Protocol Independent Multicast (PIM) is used between devices to track the multicast
packets to be forwarded to each other.

A PIM session encapsulates multicast data into a PIM unicast packet. A PIM session
creates the following sessions:

• Control session

• Data session

The data session saves the control session ID. The control session and the data session
are closed independently. The incoming interface is used to determine whether the PIM
session is active or not. If the outgoing interface is active on the peer node, packets are
transferred to the peer node for transmission.

Understanding Multicast and PIM Session Synchronization

Synchronizing multicast and PIM sessions helps to prevent packet loss due to failover
because the sessions do not need to be set up again when there is a failover.

In PIM sessions, the control session is synchronized to the backup node, and then the
data session is synchronized.

In multicast sessions, the template session is synchronized to the peer node, then all the
leaf sessions are synchronized, and finally the template session is synchronized again.

Related • Understanding Asymmetric Routing Chassis Cluster Deployment on page 228

Documentation
• Example: Configuring an Asymmetric Chassis Cluster Pair on page 230

Understanding Asymmetric Routing Chassis Cluster Deployment

Supported Platforms SRX Series, vSRX

In this case, chassis cluster makes use of its asymmetric routing capability (see
Figure 24 on page 229). Traffic received by a node is matched against that node’s session
table. The result of this lookup determines whether or not that node should process the
packet or forward it to the other node over the fabric link. Sessions are anchored on the
egress node for the first packet that created the session. If traffic is received on the node
in which the session is not anchored, those packets are forwarded over the fabric link to
the node where the session is anchored.

NOTE: The anchor node for the session can change if there are changes in
routing during the session.

228 Copyright © 2016, Juniper Networks, Inc.

 Chapter 19: Enabling Multicast Routing or Asymmetric Routing

Figure 24: Asymmetric Routing Chassis Cluster Scenario

In this scenario, two Internet connections are used, with one being preferred. The
connection to the trust zone is done by using a redundant Ethernet interface to provide
LAN redundancy for the devices in the trust zone. This scenario describes two failover
cases in which sessions originate in the trust zone with a destination of the Internet
(untrust zone).

• Understanding Failures in the Trust Zone Redundant Ethernet Interface on page 229
• Understanding Failures in the Untrust Zone Interfaces on page 229

Understanding Failures in the Trust Zone Redundant Ethernet Interface

Under normal operating conditions, traffic flows from the trust zone interface ge-0/0/1,
belonging to reth0.0, to the Internet. Because the primary Internet connection is on node
0, sessions are both created in node 0 and synced to node 1. However, session are only
active on node 0.

A failure in interface ge-0/0/1 triggers a failover of the redundancy group, causing interface
ge-7/0/1 in node 1 to become active. After the failover, traffic arrives at node 1. After
session lookup, the traffic is sent to node 0 because the session is active on this node.
Node 0 then processes the traffic and forwards it to the Internet. The return traffic follows
a similar process. The traffic arrives at node 0 and gets processed for security
purposes—for example, antispam scanning, antivirus scanning, and application of security
policies—on node 0 because the session is anchored to node 0. The packet is then sent
to node 1 through the fabric interface for egress processing and eventual transmission
out of node 1 through interface ge-7/0/1.

Understanding Failures in the Untrust Zone Interfaces

In this case, sessions are migrated from node to node. Under normal operating conditions,
traffic is processed by only node 0. A failure of interface ge-0/0/0 on node 0 causes a
change in the routing table, so that it now points to interface ge-7/0/0 in node 1. After

Copyright © 2016, Juniper Networks, Inc. 229

Chassis Cluster Feature Guide for Branch SRX Series Devices

the failure, sessions in node 0 become inactive, and the passive sessions in node 1 become
active. Traffic arriving from the trust zone is still received on interface ge-0/0/1, but is
forwarded to node 1 for processing. After traffic is processed in node 1, it is forwarded to
the Internet through interface ge-7/0/0.

In this chassis cluster configuration, redundancy group 1 is used to control the redundant
Ethernet interface connected to the trust zone. As configured in this scenario, redundancy
group 1 fails over only if interface ge-0/0/1 or ge-7/0/1 fails, but not if the interfaces
connected to the Internet fail. Optionally, the configuration could be modified to permit
redundancy group 1 to monitor all interfaces connected to the Internet and fail over if an
Internet link were to fail. So, for example, the configuration can allow redundancy group
1 to monitor ge-0/0/0 and make ge-7/0/1 active for reth0 if the ge-0/0/0 Internet link
fails. (This option is not described in the following configuration examples.)

Related • Understanding Multicast Routing on a Chassis Cluster on page 227

Documentation
• Example: Configuring an Asymmetric Chassis Cluster Pair on page 230

Example: Configuring an Asymmetric Chassis Cluster Pair

Supported Platforms SRX Series, vSRX

This example shows how to configure a chassis cluster pair of devices to allow asymmetric
routing. Configuring asymmetric routing for a chassis cluster allows traffic received on
either device to be processed seamlessly.

• Requirements on page 230

• Overview on page 231
• Configuration on page 233
• Verification on page 238

Requirements
Before you begin:

1. Physically connect a pair of devices together, ensuring that they are the same models.

a. To create the fabric link, connect a Gigabit Ethernet interface on one device to
another Gigabit Ethernet interface on the other device.

b. To create the control link, connect the control port of the two SRX1500 devices.

2. Connect to one of the devices using the console port. (This is the node that forms the
cluster.)

a. Set the cluster ID and node number.

user@host> set chassis cluster cluster-id 1 node 0 reboot

3. Connect to the other device using the console port.

a. Set the cluster ID and node number.

230 Copyright © 2016, Juniper Networks, Inc.

 Chapter 19: Enabling Multicast Routing or Asymmetric Routing

user@host> set chassis cluster cluster-id 1 node 1 reboot

Overview
In this example, a chassis cluster provides asymmetric routing. As illustrated in
Figure 25 on page 231, two Internet connections are used, with one being preferred. The
connection to the trust zone is provided by a redundant Ethernet interface to provide
LAN redundancy for the devices in the trust zone.

Figure 25: Asymmetric Routing Chassis Cluster Topology

In this example, you configure group (applying the configuration with the apply-groups
command) and chassis cluster information. Then you configure security zones and security
policies. See Table 22 on page 231 through Table 25 on page 233.

Table 22: Group and Chassis Cluster Configuration Parameters

Feature Name Configuration Parameters

Groups node0 • Hostname: srxseries-1

• Interface: fxp0
• Unit 0
• 192.168.100.50/24

node1 • Hostname: srxseries-2

• Interface: fxp0
• Unit 0
• 192.168.100.51/24

Copyright © 2016, Juniper Networks, Inc. 231

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 23: Chassis Cluster Configuration Parameters

Feature Name Configuration Parameters

Fabric links fab0 Interface: ge-0/0/7

fab1 Interface: ge-7/0/7

Heartbeat interval – 1000

Heartbeat threshold – 3

Redundancy group 1 • Priority:

• Node 0: 100
• Node 1: 1

Interface monitoring

• ge-0/0/3
• ge-7/0/3

Number of redundant Ethernet – 1

interfaces

Interfaces ge-0/0/1 • Unit 0

• 1.4.0.202/24

ge-7/0/1 • Unit 0
• 1.2.1.233/24

ge-0/0/3 •

Redundant parent: reth0

ge-7/0/3 •

Redundant parent: reth0

reth0 • Unit 0
• 10.16.8.1/24

Table 24: Security Zone Configuration Parameters

Name Configuration Parameters

trust The reth0.0 interface is bound to this zone.

untrust The ge-0/0/1 and ge-7/0/1 interfaces are bound to this zone.

232 Copyright © 2016, Juniper Networks, Inc.

 Chapter 19: Enabling Multicast Routing or Asymmetric Routing

Table 25: Security Policy Configuration Parameters

Purpose Name Configuration Parameters

This security policy permits traffic from the trust ANY • Match criteria:
zone to the untrust zone. • source-address any
• destination-address any
• application any

• Action: permit

Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.

{primary:node0}[edit]
set groups node0 system host-name srxseries-1
set groups node0 interfaces fxp0 unit 0 family inet address 192.168.100.50/24
set groups node1 system host-name srxseries-2
set groups node1 interfaces fxp0 unit 0 family inet address 192.168.100.51/24
set apply-groups “${node}”
set interfaces fab0 fabric-options member-interfaces ge-0/0/7
set interfaces fab1 fabric-options member-interfaces ge-7/0/7
set chassis cluster reth-count 1
set chassis cluster heartbeat-interval 1000
set chassis cluster heartbeat-threshold 3
set chassis cluster redundancy-group 1 node 0 priority 100
set chassis cluster redundancy-group 1 node 1 priority 1
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/3 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-7/0/3 weight 255
set interfaces ge-0/0/1 unit 0 family inet address 1.4.0.202/24
set interfaces ge-0/0/3 gigether-options redundant-parent reth0
set interfaces ge-7/0/1 unit 0 family inet address 1.2.1.233/24
set interfaces ge-7/0/3 gigether-options redundant-parent reth0
set interfaces reth0 unit 0 family inet address 10.16.8.1/24
set routing-options static route 0.0.0.0/0 qualified-next-hop 1.4.0.1 metric 10
set routing-options static route 0.0.0.0/0 qualified-next-hop 1.2.1.1 metric 100
set security zones security-zone untrust interfaces ge-0/0/1.0
set security zones security-zone untrust interfaces ge-7/0/1.0
set security zones security-zone trust interfaces reth0.0
set security policies from-zone trust to-zone untrust policy ANY match source-address
any
set security policies from-zone trust to-zone untrust policy ANY match destination-address
any
set security policies from-zone trust to-zone untrust policy ANY match application any
set security policies from-zone trust to-zone untrust policy ANY then permit

Step-by-Step To configure an asymmetric chassis cluster pair:

Procedure
1. Configure the management interface.

{primary:node0}[edit]

Copyright © 2016, Juniper Networks, Inc. 233

Chassis Cluster Feature Guide for Branch SRX Series Devices

user@host# set groups node0 system host-name srxseries-1

user@host# set groups node0 interfaces fxp0 unit 0 family inet address
192.168.100.50/24
user@host# set groups node1 system host-name srxseries-2
user@host#set groups node1 interfaces fxp0 unit 0 family inet address
192.168.100.51/24
user@host# set apply-groups “${node}”

2. Configure the fabric interface.

{primary:node0}[edit]
user@host# set interfaces fab0 fabric-options member-interfaces ge-0/0/7
user@host# set interfaces fab1 fabric-options member-interfaces ge-7/0/7

3. Configure the number of redundant Ethernet interfaces.

{primary:node0}[edit]
user@host# set chassis cluster reth-count 1

4. Configure the redundancy groups.

{primary:node0}[edit]
user@host# set chassis cluster heartbeat-interval 1000
user@host# set chassis cluster heartbeat-threshold 3
user@host# set chassis cluster node 0
user@host# set chassis cluster node 1
user@host# set chassis cluster redundancy-group 1 node 0 priority 100
user@host# set chassis cluster redundancy-group 1 node 1 priority 1
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/3
weight 255
user@host# set chassis cluster redundancy-group 1 interface-monitor ge-7/0/3
weight 255

5. Configure the redundant Ethernet interfaces.

{primary:node0}[edit]
user@host# set interfaces ge-0/0/1 unit 0 family inet address 1.4.0.202/24
user@host# set interfaces ge-0/0/3 gigether-options redundant-parent reth0
user@host# set interfaces ge-7/0/1 unit 0 family inet address 1.2.1.233/24
user@host# set interfaces ge-7/0/3 gigether-options redundant-parent reth0
user@host# set interfaces reth0 unit 0 family inet address 10.16.8.1/24

6. Configure the static routes (one to each ISP, with preferred route through ge-0/0/1).

{primary:node0}[edit]
user@host# set routing-options static route 0.0.0.0/0 qualified-next-hop 1.4.0.1
metric 10
user@host# set routing-options static route 0.0.0.0/0 qualified-next-hop 1.2.1.1
metric 100

7. Configure the security zones.

{primary:node0}[edit]
user@host# set security zones security-zone untrust interfaces ge-0/0/1.0
user@host# set security zones security-zone untrust interfaces ge-7/0/1.0
user@host# set security zones security-zone trust interfaces reth0.0

8. Configure the security policies.

{primary:node0}[edit]

234 Copyright © 2016, Juniper Networks, Inc.

 Chapter 19: Enabling Multicast Routing or Asymmetric Routing

user@host# set security policies from-zone trust to-zone untrust policy ANY match
source-address any
user@host# set security policies from-zone trust to-zone untrust policy ANY match
destination-address any
user@host# set security policies from-zone trust to-zone untrust policy ANY match
application any
user@host# set security policies from-zone trust to-zone untrust policy ANY then
permit

Results From operational mode, confirm your configuration by entering the show configuration
command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).

user@host> show configuration

version x.xx.x;
groups {
node0 {
system {
host-name srxseries-1;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.100.50/24;
}
}
}
}
}
node1 {
system {
host-name srxseries-2;
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.100.51/24;
}
}
}
}
}
}
apply-groups "${node}";
chassis {
cluster {
reth-count 1;
heartbeat-interval 1000;
heartbeat-threshold 3;
redundancy-group 1 {

Copyright © 2016, Juniper Networks, Inc. 235

Chassis Cluster Feature Guide for Branch SRX Series Devices

node 0 priority 100;

node 1 priority 1;
interface-monitor {
ge-0/0/3 weight 255;
ge-7/0/3 weight 255;
}
}
}
}
interfaces {
ge-0/0/3 {
gigether–options {
redundant–parent reth0;
}
}
ge-7/0/3 {
gigether–options {
redundant–parent reth0;
}
}
ge–0/0/1 {
unit 0 {
family inet {
address 1.4.0.202/24;
}
}
}
ge–7/0/1 {
unit 0 {
family inet {
address 1.2.1.233/24;
}
}
}
fab0 {
fabric–options {
member–interfaces {
ge–0/0/7;
}
}
}
fab1 {
fabric–options {
member–interfaces {
ge–7/0/7;
}
}
}
reth0 {
gigether–options {
redundancy–group 1;
}
unit 0 {
family inet {
address 10.16.8.1/24;
}

236 Copyright © 2016, Juniper Networks, Inc.

 Chapter 19: Enabling Multicast Routing or Asymmetric Routing

}
}
}
...
routing-options {
static {
route 0.0.0.0/0 {
next-hop 1.4.0.1;
metric 10;
}
}
}
routing-options {
static {
route 0.0.0.0/0 {
next-hop 1.2.1.1;
metric 100;
}
}
}
security {
zones {
security–zone untrust {
interfaces {
ge-0/0/1.0;
ge-7/0/1.0;
}
}
security–zone trust {
interfaces {
reth0.0;
}
}
}
policies {
from-zone trust to-zone untrust {
policy ANY {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
}
}

If you are done configuring the device, enter commit from configuration mode.

Copyright © 2016, Juniper Networks, Inc. 237

Chassis Cluster Feature Guide for Branch SRX Series Devices

Verification
Confirm that the configuration is working properly.

• Verifying Chassis Cluster Status on page 238

• Verifying Chassis Cluster Interfaces on page 238
• Verifying Chassis Cluster Statistics on page 238
• Verifying Chassis Cluster Control Plane Statistics on page 239
• Verifying Chassis Cluster Data Plane Statistics on page 240
• Verifying Chassis Cluster Redundancy Group Status on page 240
• Troubleshooting with Logs on page 240

Verifying Chassis Cluster Status

Purpose Verify the chassis cluster status, failover status, and redundancy group information.

Action From operational mode, enter the show chassis cluster status command.

{primary:node0}
user@host> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover

Redundancy group: 1 , Failover count: 1

node0 100 primary no no
node1 1 secondary no no

Verifying Chassis Cluster Interfaces

Purpose Verify information about chassis cluster interfaces.

Action From operational mode, enter the show chassis cluster interfaces command.

{primary:node0}
user@host> show chassis cluster interfaces
Control link name: fxp1

Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1

Interface Monitoring:
Interface Weight Status Redundancy-group
ge-0/0/3 255 Up 1
ge-7/0/3 255 Up 1

Verifying Chassis Cluster Statistics

Purpose Verify information about the statistics of the different objects being synchronized, the
fabric and control interface hellos, and the status of the monitored interfaces in the
cluster.

238 Copyright © 2016, Juniper Networks, Inc.

 Chapter 19: Enabling Multicast Routing or Asymmetric Routing

Action From operational mode, enter the show chassis cluster statistics command.

{primary:node0}
user@host> show chassis cluster statistics

Control link statistics:

Control link 0:
Heartbeat packets sent: 228
Heartbeat packets received: 2370
Heartbeat packets errors: 0
Fabric link statistics:
Child link 0
Probes sent: 2272
Probes received: 597
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 6 0
Session create 160 0
Session close 147 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0
GPRS GTP 0 0

Verifying Chassis Cluster Control Plane Statistics

Purpose Verify information about chassis cluster control plane statistics (heartbeats sent and
received) and the fabric link statistics (probes sent and received).

Action From operational mode, enter the show chassis cluster control-plane statistics command.

{primary:node0}
user@host> show chassis cluster control-plane statistics

Control link statistics:

Control link 0:
Heartbeat packets sent: 258689
Heartbeat packets received: 258684
Heartbeat packets errors: 0
Fabric link statistics:
Child link 0
Probes sent: 258681
Probes received: 258681

Copyright © 2016, Juniper Networks, Inc. 239

Chassis Cluster Feature Guide for Branch SRX Series Devices

Verifying Chassis Cluster Data Plane Statistics

Purpose Verify information about the number of RTOs sent and received for services.

Action From operational mode, enter the show chassis cluster data-plane statistics command.

{primary:node0}
user@host> show chassis cluster data-plane statistics

Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 6 0
Session create 160 0
Session close 147 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0
GPRS GTP 0 0

Verifying Chassis Cluster Redundancy Group Status

Purpose Verify the state and priority of both nodes in a cluster and information about whether
the primary node has been preempted or whether there has been a manual failover.

Action From operational mode, enter the chassis cluster status redundancy-group command.

{primary:node0}
user@host> show chassis cluster status redundancy-group 1
Cluster ID: 1
Node Priority Status Preempt Manual failover

Redundancy-Group: 1, Failover count: 1

node0 100 primary no no
node1 1 secondary no no

Troubleshooting with Logs

Purpose Use these logs to identify any chassis cluster issues. You should run these logs on both
nodes.

Action From operational mode, enter these show commands.

user@host> show log jsrpd

240 Copyright © 2016, Juniper Networks, Inc.

 Chapter 19: Enabling Multicast Routing or Asymmetric Routing

user@host> show log chassisd

user@host> show log messages
user@host> show log dcd
user@host> show traceoptions

Related • Understanding Multicast Routing on a Chassis Cluster on page 227

Documentation
• Understanding Asymmetric Routing Chassis Cluster Deployment on page 228

Copyright © 2016, Juniper Networks, Inc. 241

Chassis Cluster Feature Guide for Branch SRX Series Devices

242 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 20

Configuring Chassis Cluster Layer 2

Ethernet Switching

• Layer 2 Ethernet Switching Capability in Chassis Cluster Mode on page 243

• Example: Configuring Switch Fabric Interfaces to Enable Switching in Chassis Cluster
Mode (CLI) on page 245
• Example: Configuring IRB and VLAN with Members Across Two Nodes (CLI) on page 246
• Example: Configuring Aggregated Ethernet Device with LAG and LACP (CLI) on page 248

Layer 2 Ethernet Switching Capability in Chassis Cluster Mode

Supported Platforms SRX550, vSRX

• Understanding Layer 2 Ethernet Switching Capability in Chassis Cluster on SRX Series

Devices on page 243
• Understanding Chassis Cluster Failover and New Primary Election on page 244

Understanding Layer 2 Ethernet Switching Capability in Chassis Cluster on SRX Series Devices
Ethernet ports support various Layer 2 features such as Spanning Tree Protocols (xSTP),
DOT1X, Link Aggregation (LAG), Internet Group Membership Protocol (IGMP), GARP
VLAN Registration Protocol (GVRP), Link Layer Discovery Protocol (LLDP), and snooping.
The enhanced feature extends Layer 2 switching capability to devices in a chassis cluster.
This feature allows users to use Ethernet switching features on both nodes of a chassis
cluster. The Ethernet ports on either of the nodes can be configured for family Ethernet
switching. Users can configure a Layer 2 VLAN domain with member ports from both the
nodes and the Layer 2 switching protocols on both the devices.

NOTE: On SRX550 devices, Layer 2 Ethernet switching is supported in chassis

cluster mode.

NOTE: On SRX300, SRX320, SRX340, SRX345, and SRX1500 devices, Layer

2 Ethernet switching is not supported in chassis cluster mode.

Figure 26 on page 244 shows the Layer 2 switching across chassis cluster nodes:

Copyright © 2016, Juniper Networks, Inc. 243

Chassis Cluster Feature Guide for Branch SRX Series Devices

Figure 26: Layer 2 Ethernet Switching Across Chassis Cluster Nodes

To ensure that Layer 2 switching works seamlessly across chassis cluster nodes, a
dedicated physical link connecting the nodes is required. This type of link is called a
switching fabric interface (swfab). Its purpose is to carry Layer 2 traffic between the nodes.

NOTE: Configuring a LAG with members across nodes is not supported.

WARNING: If a swfab interface is not configured on both the nodes and if

you try to configure Ethernet switching-related features on the nodes, behavior
of the nodes might be unpredictable.

Understanding Chassis Cluster Failover and New Primary Election

When chassis cluster failover occurs, a new primary node is elected and the Ethernet
Switching Daemon (ESWD) runs in a different node. During failover, the chassis control
subsystem is restarted. Also during failover, the traffic outage occurs until the PICs are
up and the VLAN entries are reprogrammed. After failover, all Layer 2 protocols reconverge
because Layer 2 protocols states are not maintained in the secondary node.

NOTE: The Q-in-Q feature in chassis cluster mode is not supported because
of chip limitation for swfab interface configuration in Broadcom chipsets.

Related • Example: Configuring Switch Fabric Interfaces to Enable Switching in Chassis Cluster
Documentation Mode (CLI) on page 245

• Example: Configuring IRB and VLAN with Members Across Two Nodes (CLI) on page 246

• Example: Configuring Aggregated Ethernet Device with LAG and LACP (CLI) on page 248

244 Copyright © 2016, Juniper Networks, Inc.

 Chapter 20: Configuring Chassis Cluster Layer 2 Ethernet Switching

Example: Configuring Switch Fabric Interfaces to Enable Switching in Chassis Cluster

Mode (CLI)

Supported Platforms SRX1500, SRX550, vSRX

This example shows how to configure swfab to enable switching in chassis cluster mode.

• Requirements on page 245

• Overview on page 245
• Configuration on page 245

Requirements
The physical link used as the switch fabric members must be directly connected. Switching
supported ports must be used for swfab interfaces.

Before you begin, read through the following example to understand the configuration
of chassis cluster fabric:

• Example: Configuring the Chassis Cluster Fabric Interfaces on page 61

Overview
New pseudointerfaces swfab0 and swfab1 will be created for Layer 2 fabric functionality.
Users need to configure dedicated Ethernet ports on each side of the node to be
associated with the swfab interface.

Configuration
Step-by-Step To configure swfab interfaces:
Procedure
1. Configure swfab0 and swfab1 to associate switch fabric interfaces to enable
switching across the nodes. Note that swfab0 corresponds to node 0 and
swfab1corresponds to node 1.

{primary:node0} [edit]
user@host# set interfaces swfab0 fabric-options member-interfaces ge-0/0/6
user@host# set interfaces swfab0 fabric-options member-interfaces ge-0/0/7
user@host# set interfaces swfab1 fabric-options member-interfaces ge-5/0/6
user@host# set interfaces swfab1 fabric-options member-interfaces ge-5/0/7

2. If you are done configuring the device, commit the configuration.

{primary:node0} [edit]
user@host# commit

Verification

Purpose Verify that the user will be allowed to configure multiple ports as members of swfab
ports.

Copyright © 2016, Juniper Networks, Inc. 245

Chassis Cluster Feature Guide for Branch SRX Series Devices

Action From configuration mode, enter the show interfaces swfab0 command to view the
configured interfaces for each port.
user@host# show interfaces swfab0
fabric-options{
member-interfaces {
ge-0/0/6;
ge-0/0/7;
}
}

From the configuration mode, enter the show chassis cluster ethernet-switching
interfaces command to view the appropriate member interfaces.
user@host# show chassis cluster ethernet-switching interfaces
swfab0:
Name Status
ge-0/0/6 up
ge-0/0/7 up
swfab1:
Name Status
ge-5/0/6 up
ge-5/0/7 up

Related • SRX Series Chassis Cluster Configuration Overview on page 36

Documentation

Example: Configuring IRB and VLAN with Members Across Two Nodes (CLI)

Supported Platforms SRX1500, SRX550, vSRX

• Requirements on page 246

• Overview on page 246
• Configuration on page 246
• Verification on page 248

Requirements
No special configuration beyond device initialization is required before configuring this
feature.

Overview
This example shows configuration of IRB and configuration of VLAN with members across
node 0 and node 1.

Configuration
Step-by-Step To configure VLAN, follow the steps from 1 to 4 and then commit the configuration. To
Procedure configure IRB, follow the steps from 1 to 8.

1. Configure Ethernet switching on the node0 interface.

{primary:node0} [edit]
user@host# set interfaces ge-2/0/0 unit 0 family ethernet-switching

246 Copyright © 2016, Juniper Networks, Inc.

 Chapter 20: Configuring Chassis Cluster Layer 2 Ethernet Switching

2. Configure Ethernet switching on the node1 interface.

{primary:node0} [edit]
user@host# set interfaces ge-11/0/0 unit 0 family ethernet-switching

3. Create VLAN vlan10 with vlan-id 10.

{primary:node0} [edit]
user@host# set vlans vlan10 vlan-id 10

4. Add ports from both nodes to the VLAN.

{primary:node0} [edit]
user@host# set vlans vlan10 interface ge-2/0/0
user@host# set vlans vlan10 interface ge-11/0/0

5. Assign an IP address to the VLAN.

{primary:node0} [edit]
user@host# set interfaces vlan unit 10 family inet address 45.45.45.1/24

6. Associate Layer 3 VLAN interface to vlan10.

{primary:node0} [edit]
user@host# set vlans vlan10 l3-interface vlan.10

7. Check the configuration by entering the show vlans and show interfaces commands.

user@host# show vlans

vlan10 {
vlan-id 10;
interface {
ge-2/0/0.0;
ge-11/0/0.0;
}
l3-interface vlan.10;
}

user@host# show interfaces

ge-2/0/0 {
unit 0 {
family ethernet-switching;
}
}
ge-11/0/0 {
unit 0 {
family ethernet-switching;
}
}
vlan {
unit 10 {
family inet {
address 45.45.45.1/24;
}
}
}

8. If you are done configuring the device, commit the configuration.

[edit]
user@host# commit

Copyright © 2016, Juniper Networks, Inc. 247

Chassis Cluster Feature Guide for Branch SRX Series Devices

Verification

Verifying VLAN and IRB

Purpose To verify that the configurations of VLAN and IRB are working properly.

Action From configuration mode, enter the show interfaces terse ge-2/0/0 command to view
the node 0 interface.
user@host# run show interfaces terse ge-2/0/0
Interface Admin Link Proto Local Remote
ge-2/0/0 up up
ge-2/0/0.0 up up eth-switch

From configuration mode, enter the show interfaces terse ge-11/0/0 command to view
the node 1 interface.
user@host# run show interfaces terse ge-11/0/0
Interface Admin Link Proto Local Remote
ge-11/0/0 up up
ge-11/0/0.0 up up eth-switch

From configuration mode, enter the show vlans command to view the VLAN interface.

user@host# run show vlans

Name Tag Interfaces
default 1 None
vlan10 10 ge-2/0/0.0*, ge-11/0/0.0*

Related • SRX Series Chassis Cluster Configuration Overview on page 36

Documentation

Example: Configuring Aggregated Ethernet Device with LAG and LACP (CLI)

Supported Platforms SRX1500, SRX550, vSRX

• Requirements on page 248

• Overview on page 248
• Configuration on page 249
• Verification on page 250

Requirements
No special configuration beyond device initialization is required before configuring this
feature.

Overview
This example shows the configuration of aggregated Ethernet (ae) devices with LAG
and LACP.

248 Copyright © 2016, Juniper Networks, Inc.

 Chapter 20: Configuring Chassis Cluster Layer 2 Ethernet Switching

Configuration
Step-by-Step To configure LAG:
Procedure
1. Configure the number of ae devices with LAG interface that you need to create.

[edit]
user@host# set chassis aggregated-devices ethernet device-count 5

2. Add a port to the ae device with LAG.

[edit]
user@host# set interfaces ge-2/0/1 gigether-options 802.3ad ae0
user@host# set interfaces ge-2/0/2 gigether-options 802.3ad ae0

3. Configure LACP for the ae device with LAG.

[edit]
user@host# set interfaces ae0 aggregated-ether-options lacp active

4. Configure family Ethernet switching for the ae device with LAG.

[edit]
user@host# set interfaces ae0 unit 0 family ethernet-switching

5. Configure VLAN.

[edit]
user@host# set vlans vlan20 vlan-id 20

6. Add the ae interface to the VLAN.

[edit]
user@host# set vlans vlan20 interface ae0

7. Check the configuration by entering the show vlans and show interfaces commands

user@host# show vlans

vlan20 {
vlan-id 20;
interface {
ae0.0;
}
}

user@host# show interfaces

ge-2/0/1 {
gigether-options {
802.3ad ae0;
}
}
ge-2/0/2 {
gigether-options {
802.3ad ae0;
}
}
ae0 {
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {

Copyright © 2016, Juniper Networks, Inc. 249

Chassis Cluster Feature Guide for Branch SRX Series Devices

family ethernet-switching;
}
}

8. If you are done configuring the device, commit the configuration.

[edit]
user@host# commit

NOTE: Likewise, you can configure other devices with LAG and LACP.

Verification

Verifying Aggregated Ethernet Device with LAG and LACP

Purpose Verify that you can configure ae devices with LAG and LACP.

Action From configuration mode, enter the show lacp interfaces to view the LACP interfaces.

user@host# run show lacp interfaces

Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-2/0/1 Actor No No Yes Yes Yes Yes Fast Active
ge-2/0/1 Partner No No Yes Yes Yes Yes Fast Active
ge-2/0/2 Actor No No Yes Yes Yes Yes Fast Active
ge-2/0/2 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-2/0/1 Current Fast periodic Collecting distributing
ge-2/0/2 Current Fast periodic Collecting distributing

From configuration mode, enter the show vlans command to view the VLAN interfaces.

user@host# run show vlans

Name Tag Interfaces
default 1 None
vlan20 20 ae0.0

From configuration mode, enter the show interfaces (interface name) command to view
the status of the ge-2/0/1 and ge-2/0/2 interfaces.
user@host# run show interfaces ge-2/0/1 terse
Interface Admin Link Proto Local Remote
ge-2/0/1 up up
ge-2/0/1.0 up up aenet --> ae0.0

user@host# run show interfaces ge-2/0/2 terse

Interface Admin Link Proto Local Remote
ge-2/0/2 up up
ge-2/0/2.0 up up aenet --> ae0.0

Related • SRX Series Chassis Cluster Configuration Overview on page 36

Documentation

250 Copyright © 2016, Juniper Networks, Inc.

PART 5

Upgrading or Disabling Chassis Cluster

• Upgrading Both Devices Separately on page 253
• Upgrading Both Devices Using ICU on page 255
• Disabling Chassis Cluster on page 259

Copyright © 2016, Juniper Networks, Inc. 251

Chassis Cluster Feature Guide for Branch SRX Series Devices

252 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 21

Upgrading Both Devices Separately

• Upgrading Individual Devices in a Chassis Cluster Separately on page 253

Upgrading Individual Devices in a Chassis Cluster Separately

Supported Platforms SRX Series, vSRX

Devices in a chassis cluster can be upgraded separately one at a time; some models
allow one device after the other to be upgraded using failover and an in-service software
upgrade (ISSU) to reduce the operational impact of the upgrade.

To upgrade each device in a chassis cluster separately:

NOTE: During this type of chassis cluster upgrade, a service disruption of

about 3 to 5 minutes occurs.

1. Load the new image file on node 0.

2. Perform the image upgrade without rebooting the node by entering:

user@host> request system software add image_name

3. Load the new image file on node 1.

4. Repeat Step 2.

5. Reboot both nodes simultaneously.

Related • Upgrading Both Devices in a Chassis Cluster Using an ISSU for High-End SRX Series
Documentation Devices

• Upgrading Devices in a Chassis Cluster Using ICU for Branch SRX Series Devices on
page 255

Copyright © 2016, Juniper Networks, Inc. 253

Chassis Cluster Feature Guide for Branch SRX Series Devices

254 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 22

Upgrading Both Devices Using ICU

• Upgrading Devices in a Chassis Cluster Using ICU on page 255

Upgrading Devices in a Chassis Cluster Using ICU

Supported Platforms SRX1500, SRX1500, SRX300, SRX300, SRX300, SRX300, SRX300, SRX320, SRX320,
SRX320, SRX320, SRX320, SRX340, SRX340, SRX340, SRX340, SRX340, SRX345, SRX345,
SRX345, SRX345, SRX345, SRX550, SRX550, SRX550, SRX550, SRX550, vSRX

• Upgrading Both Devices in a Chassis Cluster Using ICU on page 255

• Upgrading ICU Using a Build Available Locally on a Primary Node in a Chassis
Cluster on page 256
• Upgrading ICU Using a Build Available on an FTP Server on page 256
• Aborting an Upgrade in a Chassis Cluster During an ICU on page 257

Upgrading Both Devices in a Chassis Cluster Using ICU

Supported Platforms

Starting from Junos OS 15.1X49-D50 onwards, in-band cluster upgrade (ICU) is supported
in SRX1500 devices.

For SRX300, SRX320, SRX340, SRX345, and SRX550 devices, the devices in a chassis
cluster can be upgraded with a minimal service disruption of approximately 30 seconds
using in-band cluster upgrade (ICU) with the no-sync option. The chassis cluster ICU
feature allows both devices in a cluster to be upgraded from supported Junos OS versions.

The impact on traffic is as follows:

• Drop in traffic (30 seconds approximately)

• Loss of security flow sessions

NOTE: ICU is not supported on SRX1500 devices.

Before you begin, note the following:

Copyright © 2016, Juniper Networks, Inc. 255

Chassis Cluster Feature Guide for Branch SRX Series Devices

• ICU is available with the no-sync option only.

• This feature is available only on Junos OS Releases 11.2 R2 and later.

• Before starting ICU, you should ensure that sufficient disk space is available. See
Upgrading ICU Using a Build Available Locally on a Primary Node in a Chassis Cluster and
Upgrading ICU Using a Build Available on an FTP Server.

• This feature cannot be used to downgrade to a build earlier than Junos OS 11.2 R2.

The upgrade is initiated with the Junos OS build locally available on the primary node of
the device or on an FTP server.

NOTE:
• The primary node, RG0, changes to the secondary node after an ICU
upgrade.

• During ICU, the chassis cluster redundancy groups are failed over to the
primary node to change the cluster to active/passive mode.

• ICU states can be checked from the syslog or with the console/terminal
logs.

• ICU requires that both nodes be running a dual-root partitioning scheme.

ICU will not continue if it fails to detect dual-root partitioning on either of
the nodes.

Upgrading ICU Using a Build Available Locally on a Primary Node in a Chassis Cluster

Supported Platforms

NOTE: Ensure that sufficient disk space is available for the Junos OS package
in the /var/tmp location in the secondary node of the cluster.

To upgrade ICU using a build locally available on the primary node of a cluster:

1. Copy the Junos OS package build to the primary node at any location, or mount a
network file server folder containing the Junos OS build.

2. Start ICU by entering the following command:

user@host> request system software in-service-upgrade image_name no-sync

Upgrading ICU Using a Build Available on an FTP Server

Supported Platforms

256 Copyright © 2016, Juniper Networks, Inc.

 Chapter 22: Upgrading Both Devices Using ICU

NOTE: Ensure that sufficient disk space is available for the Junos OS package
in the /var/tmp location in both the primary and the secondary nodes of the
cluster.

To upgrade ICU using a build available on an FTP server:

1. Place the Junos OS build on an FTP server.

2. Start ICU by entering the following command:

user@root> request system software in-service-upgrade <ftp url for junos image>
no-sync

user@root> request system software in-service-upgrade

ftp://<user>:<password>@<server>:/<path> no-sync
This command upgrades the Junos OS and reboots both nodes in turn.

NOTE: The upgrade process displays the following warning message to

reboot the system:

WARNING: A reboot is required to load this software correctly. Use the request
system reboot command when software installation is complete.

This warning message can be ignored because the ICU process automatically
reboots both the nodes.

Aborting an Upgrade in a Chassis Cluster During an ICU

Supported Platforms

You can abort an ICU at any time by issuing the following command on the primary node:

request system software abort in-service-upgrade

NOTE: Issuing an abort command during or after the secondary node reboots
puts the cluster in an inconsistent state. The secondary node boots up running
the new Junos OS build, while the primary continues to run the older Junos
OS build.

NOTE: This command is not supported on SRX1500 devices.

To recover from the chassis cluster inconsistent state, perform the following actions
sequentially on the secondary node:

1. Issue an abort command:

request system software abort in-service-upgrade

Copyright © 2016, Juniper Networks, Inc. 257

Chassis Cluster Feature Guide for Branch SRX Series Devices

2. Roll back the Junos OS build by entering the following command:

request system software rollback node < node-id >

3. Reboot the secondary node immediately by using the following command:

request system reboot

NOTE: You must execute the above steps sequentially to complete the
recovery process and avoid cluster instability.

Table 26 on page 258 lists the options and their descriptions for the request system software
in-service-upgrade command.

Table 26: request system software in-service-upgrade Output Fields

Options Description

no-sync Disables the flow state from syncing up when the old secondary node has booted with a new
Junos OS image.

no-tcp-syn-check Creates a window wherein the TCP SYN check for the incoming packets will be disabled. The
default value for the window is 7200 seconds (2 hours).

no-validate Disables the validation of the configuration at the time of the installation. The system behavior
is similar to software add.

unlink Removes the package from the local media after installation.

NOTE:
• During ICU, if an abort command is executed, ICU will abort only after the
current operation finishes. This is required to avoid any inconsistency with
the devices.

For example, if formatting and upgrade of a node is in progress, ICU aborts

after this operation finishes.

• After an abort, ICU will try to roll back the build on the nodes if the upgrading
nodes step was completed.

Related • Verifying a Chassis Cluster Configuration on page 99

Documentation

258 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 23

Disabling Chassis Cluster

• Disabling Chassis Cluster on page 259

Disabling Chassis Cluster

Supported Platforms SRX Series, vSRX

To disable chassis cluster, enter the following command:

{primary:node1}
user@host# set chassis cluster disable reboot
Successfully disabled chassis cluster. Going to reboot now.

After the system reboots, the chassis cluster is disabled.

NOTE: After the chassis cluster is disabled using this CLI command, you do
not have a similar CLI option to enable it back.

You can also use the below CLI commands to disable chassis cluster:

• To disable cluster on node0:

user@host# set chassis cluster cluster-id 0 node 0 reboot

• To disable cluster on node1:

user@host# set chassis cluster cluster-id 0 node 1 reboot

NOTE: Setting cluster-id to zero disables clustering on a device.

Related • Upgrading Individual Devices in a Chassis Cluster Separately on page 253

Documentation
• Upgrading Both Devices in a Chassis Cluster Using an ISSU for High-End SRX Series
Devices

• Upgrading Devices in a Chassis Cluster Using ICU for Branch SRX Series Devices on
page 255

Copyright © 2016, Juniper Networks, Inc. 259

Chassis Cluster Feature Guide for Branch SRX Series Devices

260 Copyright © 2016, Juniper Networks, Inc.

PART 6

Configuration Statements and

Operational Commands
• Configuration Statements on page 263
• Operational Commands on page 305

Copyright © 2016, Juniper Networks, Inc. 261

Chassis Cluster Feature Guide for Branch SRX Series Devices

262 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 24

Configuration Statements

• Chassis Configuration Statement Hierarchy on page 264

• Security Configuration Statement Hierarchy on page 267
• apply-groups (Chassis Cluster) on page 269
• cluster (Chassis) on page 270
• configuration-synchronize (Chassis Cluster) on page 271
• control-link-recovery on page 272
• device-count (Chassis Cluster) on page 272
• ethernet (Chassis Cluster) on page 273
• fabric-options on page 274
• gigether-options (Chassis Cluster) on page 275
• global-threshold on page 276
• global-weight on page 277
• gratuitous-arp-count on page 278
• heartbeat-interval on page 279
• heartbeat-threshold on page 280
• hold-down-interval on page 281
• interface (Chassis Cluster) on page 282
• interface-monitor on page 283
• ip-monitoring on page 284
• lacp (Interfaces) on page 285
• link-protection (Chassis Cluster) on page 286
• member-interfaces on page 286
• network-management on page 287
• node (Chassis Cluster) on page 288
• node (Chassis Cluster Redundancy Group) on page 288
• preempt (Chassis Cluster) on page 289
• priority (Chassis Cluster) on page 289
• redundancy-group (Chassis Cluster) on page 290

Copyright © 2016, Juniper Networks, Inc. 263

Chassis Cluster Feature Guide for Branch SRX Series Devices

• redundancy-interface-process on page 291

• redundant-ether-options on page 292
• redundant-parent (Interfaces) on page 293
• redundant-pseudo-interface-options on page 293
• reth-count (Chassis Cluster) on page 294
• reth (Interfaces) on page 295
• retry-count (Chassis Cluster) on page 300
• retry-interval (Chassis Cluster) on page 301
• route-active-on on page 301
• traceoptions (Chassis Cluster) on page 302
• weight on page 304

Chassis Configuration Statement Hierarchy

Supported Platforms SRX Series, vSRX

Use the statements in the chassis configuration hierarchy to configure alarms, aggregated
devices, clusters, the Routing Engine, and other chassis properties.

chassis {
aggregated-devices {
ethernet {
device-count number;
lacp {
link-protection {
non-revertive;
}
system-priority number;
}
}
sonet {
device-count number;
}
}
alarm {
ds1 {
ais (ignore | red | yellow);
ylw (ignore | red | yellow);
}
ethernet {
link-down (ignore | red | yellow);
}
integrated-services {
failure (ignore | red | yellow);
}
management-ethernet {
link-down (ignore | red | yellow);
}
serial {
cts-absent (ignore | red | yellow);

264 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

dcd-absent (ignore | red | yellow);

dsr-absent (ignore | red | yellow);
loss-of-rx-clock (ignore | red | yellow);
loss-of-tx-clock (ignore | red | yellow);
}
services {
hw-down (ignore | red | yellow);
linkdown (ignore | red | yellow);
pic-hold-reset (ignore | red | yellow);
pic-reset (ignore | red | yellow);
rx-errors (ignore | red | yellow);
sw-down (ignore | red | yellow);
tx-errors (ignore | red | yellow);
}
t3 {
ais (ignore | red | yellow);
exz (ignore | red | yellow);
ferf (ignore | red | yellow);
idle (ignore | red | yellow);
lcv (ignore | red | yellow);
lof (ignore | red | yellow);
los (ignore | red | yellow);
pll (ignore | red | yellow);
ylw (ignore | red | yellow);
}
}
cluster {
configuration-synchronize {
no-secondary-bootup-auto;
}
control-link-recovery;
heartbeat-interval milliseconds;
heartbeat-threshold number;
network-management {
cluster-master;
}
redundancy-group group-number {
gratuitous-arp-count number;
hold-down-interval number;
interface-monitor interface-name {
weight number;
}
ip-monitoring {
family {
inet {
ipv4-address {
interface {
logical-interface-name;
secondary-ip-address ip-address;
}
weight number;
}
}
}
global-threshold number;
global-weight number;

Copyright © 2016, Juniper Networks, Inc. 265

Chassis Cluster Feature Guide for Branch SRX Series Devices

retry-count number;
retry-interval seconds;
}
node (0 | 1 ) {
priority number;
}
preempt;
}
reth-count number;
traceoptions {
file {
filename;
files number;
match regular-expression;
(world-readable | no-world-readable);
size maximum-file-size;
}
flag flag;
level {
(alert | all | critical | debug | emergency | error | info | notice | warning);
}
no-remote-trace;
}
}
config-button {
no-clear;
no-rescue;
}
craft-lockout;
fpc slot-number {
offline;
pic slot-number {
aggregate-ports;
framing {
(e1 | e3 | sdh | sonet | t1 | t3);
}
ingress-policer-overhead bytes
max-queues-per-interface (4 | 8);
mlfr-uni-nni-bundles number;
no-multi-rate;
np-cache;
port slot-number {
framing (e1 | e3 | sdh | sonet | t1 | t3);
speed (oc12-stm4 | oc3-stm1 | oc48-stm16);
}
q-pic-large-buffer (large-scale | small-scale);
services-offload {
low-latency;
per-session-statistics;
}
shdsl {
pic-mode (1-port-atm | 2-port-atm | 4-port-atm | efm);
}
sparse-dlcis;
traffic-manager {
egress-shaping-overhead number;

266 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

ingress-shaping-overhead number;
mode (egress-only | ingress-and-egress);
}
tunnel-queuing;
}
services-offload;
}
ioc-npc-connectivity {
ioc slot-number {
npc (npc-slot-number | none);
}
}
maximum-ecmp (16 | 32 | 64);
network-services (ethernet | IP);
routing-engine {
bios {
no-auto-upgrade;
}
on-disk-failure {
disk-failure-action (halt | reboot);
}
usb-wwan {
port 1;
}
}
usb {
storage {
disable;
}
}
}

Related • cluster (Chassis) on page 270

Documentation
• ip-monitoring on page 284

Security Configuration Statement Hierarchy

Supported Platforms SRX Series, vSRX

Use the statements in the security configuration hierarchy to configure actions, certificates,
dynamic virtual private networks (VPNs), firewall authentication, flow, forwarding options,
group VPNs, Intrusion Detection Prevention (IDP), Internet Key Exchange (IKE), Internet
Protocol Security (IPsec), logging, Network Address Translation (NAT), public key
infrastructure (PKI), policies, resource manager, rules, screens, secure shell known hosts,
trace options, user identification, unified threat management (UTM), and zones.
Statements that are exclusive to the SRX Series devices running Junos OS are described
in this section.

Copyright © 2016, Juniper Networks, Inc. 267

Chassis Cluster Feature Guide for Branch SRX Series Devices

Each of the following topics lists the statements at a sub-hierarchy of the [edit security]
hierarchy.

• [edit security address-book] Hierarchy Level

• [edit security alarms] Hierarchy Level

• [edit security alg] Hierarchy Level

• [edit security analysis] Hierarchy Level

• [edit security application-firewall] Hierarchy Level

• [edit security application-tracking] Hierarchy Level

• [edit security certificates] Hierarchy Level

• [edit security datapath-debug] Hierarchy Level

• [edit security dynamic-vpn] Hierarchy Level

• [edit security firewall-authentication] Hierarchy Level

• [edit security flow] Hierarchy Level

• [edit security forwarding-options] Hierarchy Level

• [edit security forwarding-process] Hierarchy Level

• [edit security gprs] Hierarchy Level

• [edit security group-vpn] Hierarchy Level

• [edit security idp] Hierarchy Level

• [edit security ike] Hierarchy Level

• [edit security ipsec] Hierarchy Level

• [edit security log] Hierarchy Level

• [edit security nat] Hierarchy Level

• [edit security pki] Hierarchy Level

• [edit security policies] Hierarchy Level

• [edit security resource-manager] Hierarchy Level

• [edit security screen] Hierarchy Level

• [edit security softwires] Hierarchy Level

• [edit security ssh-known-hosts] Hierarchy Level

• [edit security traceoptions] Hierarchy Level

• [edit security user-identification] Hierarchy Level

• [edit security utm] Hierarchy Level

• [edit security zones] Hierarchy Level

268 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

Related • CLI User Guide

Documentation
• CLI Explorer

apply-groups (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax apply-groups [${node}]

Hierarchy Level [edit chassis cluster]

Release Information Statement introduced in Junos OS Release 9.0.

Description Apply node-specific parameters to each node in a chassis cluster.

Options ${node} —Each node (node0 or node1) in a chassis cluster.

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

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

Related • cluster (Chassis) on page 270

Documentation

Copyright © 2016, Juniper Networks, Inc. 269

Chassis Cluster Feature Guide for Branch SRX Series Devices

cluster (Chassis)

Supported Platforms SRX Series, vSRX

Syntax cluster {
configuration-synchronize {
no-secondary-bootup-auto;
}
control-link-recovery;
heartbeat-interval milliseconds;
heartbeat-threshold number;
network-management {
cluster-master;
}
redundancy-group group-number {
gratuitous-arp-count number;
hold-down-interval number;
interface-monitor interface-name {
weight number;
}
ip-monitoring {
family {
inet {
ipv4-address {
interface {
logical-interface-name;
secondary-ip-address ip-address;
}
weight number;
}
}
}
global-threshold number;
global-weight number;
retry-count number;
retry-interval seconds;
}
node (0 | 1 ) {
priority number;
}
preempt;
}
reth-count number;
traceoptions {
file {
filename;
files number;
match regular-expression;
(world-readable | no-world-readable);
size maximum-file-size;
}
flag flag;
level {
(alert | all | critical | debug | emergency | error | info | notice | warning);
}

270 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

no-remote-trace;
}
}

Hierarchy Level [edit chassis]

Release Information Statement introduced in Junos OS Release 9.0.

Description Configure a chassis cluster.

Options The remaining statements are explained separately. See CLI Explorer.

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

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

Related • ip-monitoring on page 284

Documentation

configuration-synchronize (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax configuration-synchronize {
no-secondary-bootup-auto;
}

Hierarchy Level [edit chassis cluster]

Release Information Statement introduced in Junos OS Release 12.1X47-D10.

Description Disables the automatic chassis cluster synchronization between the primary and
secondary nodes. To reenable automatic chassis cluster synchronization, use the delete
chassis cluster configuration-synchronize no-secondary-bootup-auto command in
configuration mode.

Options no-secondary-bootup-auto—Disable the automatic chassis cluster synchronization

between the primary and secondary nodes.

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

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

Related • Understanding Automatic Chassis Cluster Synchronization Between Primary and

Documentation Secondary Nodes on page 181

• request chassis cluster configuration-synchronize on page 314

• show chassis cluster information configuration-synchronization on page 336

Copyright © 2016, Juniper Networks, Inc. 271

Chassis Cluster Feature Guide for Branch SRX Series Devices

control-link-recovery

Supported Platforms SRX Series, vSRX

Syntax control-link-recovery;

Hierarchy Level [edit chassis cluster]

Release Information Statement introduced in Junos OS Release 9.5.

Description Enable control link recovery to be done automatically by the system. After the control
link recovers, the system checks whether it receives at least 30 consecutive heartbeats
on the control link. This is to ensure that the control link is not flapping and is perfectly
healthy. Once this criterion is met, the system issues an automatic reboot on the node
that was disabled when the control link failed. When the disabled node reboots, the node
rejoins the cluster. There is no need for any manual intervention.

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

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

Related • interface (Chassis Cluster) on page 282

Documentation

device-count (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax device-count number;

Hierarchy Level [edit chassis aggregated-devices ethernet]

[edit chassis aggregated-devices sonnet]

Release Information Statement introduced in Junos OS Release 10.2.

Description Configure the number of aggregated logical devices.

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

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

Related • cluster (Chassis) on page 270

Documentation
• Example: Configuring Aggregated Ethernet Device with LAG and LACP (CLI) on page 248

272 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

ethernet (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax ethernet {
device-count number;
lacp {
link-protection {
non-revertive;
}
system-priority number;
}
}

Hierarchy Level [edit chassis aggregated-devices]

Release Information Statement introduced in Junos OS Release 10.2.

Description Configure properties for aggregated Ethernet devices.

Options The remaining statements are explained separately. See CLI Explorer.

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

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

Related • cluster (Chassis) on page 270

Documentation
• Example: Configuring Aggregated Ethernet Device with LAG and LACP (CLI) on page 248

Copyright © 2016, Juniper Networks, Inc. 273

Chassis Cluster Feature Guide for Branch SRX Series Devices

fabric-options

Supported Platforms SRX Series, vSRX

Syntax fabric-options {
member-interfaces member-interface-name ;
}

Hierarchy Level [edit interfaces interface-name ]

Release Information Statement introduced in Junos OS Release 8.5.

Description Configure fabric interface specific options in chassis clusters.

NOTE: When you run the system autoinstallation command, the command
will configure unit 0 logical interface for all the active state physical interfaces.
However, few commands like fabric-options do not allow its physical interface
to be configured with a logical interface. If the system autoinstallation and
the fabric-options commands are configured together the following message
is displayed incompatible with 'system autoinstallation’.

Options The remaining statements are explained separately. See CLI Explorer.

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

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

Related • Example: Configuring the Chassis Cluster Fabric Interfaces on page 61

Documentation
• member-interfaces on page 286

274 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

gigether-options (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax gigether-options {
802.3ad {
backup | primary
lacp {
port-priority number;
}
}
auto-negotiation {
remote-fault;
}
flow-control | no-flow-control;
ieee-802-3az-eee ;
ignore-l3-incompletes;
loopback | no-loopback
loopback-remote
no-auto-negotiation;
redundant-parent interface-name;
}

Hierarchy Level [edit interface interface-name]

Release Information Statement introduced in Junos OS Release 9.2.

Description Configure Gigabit Ethernet specific interface properties.

Options The remaining statements are explained separately. See CLI Explorer.

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

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

Related • Understanding Chassis Cluster Redundant Ethernet Interfaces

Documentation
• Example: Configuring Chassis Cluster Redundant Ethernet Interfaces for IPv4 and IPv6
Addresses on page 79

Copyright © 2016, Juniper Networks, Inc. 275

Chassis Cluster Feature Guide for Branch SRX Series Devices

global-threshold

Supported Platforms SRX Series, vSRX

Syntax global-threshold number;

Hierarchy Level [edit chassis cluster redundancy-group group-number ip-monitoring ]

Release Information Statement introduced in Junos OS Release 10.1.

Description Specify the failover value for all IP addresses monitored by the redundancy group. When
IP addresses with a configured total weight in excess of the threshold have become
unreachable, the weight of IP monitoring is deducted from the redundancy group
threshold.

Options number —Value at which the IP monitoring weight will be applied against the redundancy
group failover threshold.
Range: 0 through 255
Default: 0

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

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

Related • ip-monitoring on page 284

Documentation

276 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

global-weight

Supported Platforms SRX Series, vSRX

Syntax global-weight number;

Hierarchy Level [edit chassis cluster redundancy-group group-number ip-monitoring ]

Release Information Statement introduced in Junos OS Release 10.1.

Description Specify the relative importance of all IP address monitored objects to the operation of
the redundancy group. Every monitored IP address is assigned a weight. If the monitored
address becomes unreachable, the weight of the object is deducted from the
global-threshold of IP monitoring objects in its redundancy group. When the
global-threshold reaches 0, the global-weight is deducted from the redundancy group.
Every redundancy group has a default threshold of 255. If the threshold reaches 0, a
failover is triggered. Failover is triggered even if the redundancy group is in manual failover
mode and preemption is not enabled.

Options number —Combined weight assigned to all monitored IP addresses. A higher weight value
indicates a greater importance.
Range: 0 through 255
Default: 255

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

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

Related • ip-monitoring on page 284

Documentation

Copyright © 2016, Juniper Networks, Inc. 277

Chassis Cluster Feature Guide for Branch SRX Series Devices

gratuitous-arp-count

Supported Platforms SRX Series, vSRX

Syntax gratuitous-arp-count number;

Hierarchy Level [edit chassis cluster redundancy-group group-number]

Release Information Statement introduced in Junos OS Release 9.0.

Description Specify the number of gratuitous Address Resolution Protocol (ARP) requests to send
on an active interface after failover.

Options number—Number of gratuitous ARP requests that a newly elected primary device in a
chassis cluster sends out to announce its presence to the other network devices.
Range: 1 through 16
Default: 4

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

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

Related • redundancy-group (Chassis Cluster) on page 290

Documentation

278 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

heartbeat-interval

Supported Platforms SRX Series, vSRX

Syntax heartbeat-interval milliseconds;

Hierarchy Level [edit chassis cluster]

Release Information Statement introduced in Junos OS Release 9. Statement updated in Junos OS Release
10.4.

Description Set the interval between the periodic signals broadcast to the devices in a chassis cluster
to indicate that the active node is operational.

The heartbeat-interval option works in combination with the heartbeat-threshold option

to define the wait time before failover is triggered in a chassis cluster. The default values
of these options produce a wait time of 3 seconds. In a large configuration approaching
full capacity on an SRX5400 or SRX5600 or SRX5800 device, however, we recommend
that you increase the failover wait time to 5 seconds.

For example, a heartbeat-threshold of 3 and a heartbeat-interval of 1000 milliseconds

result in a total wait of 3 seconds before failover is triggered. To increase this wait to 5
seconds, you could increase the heartbeat-threshold, the heartbeat-interval, or both. A
heartbeat-threshold of 5 and a heartbeat-interval of 1000 milliseconds would yield a wait
time of 5 seconds. Setting the heartbeat-threshold to 4 and the heartbeat-interval to
1250 milliseconds would also yield a wait time of 5 seconds.

NOTE: In a chassis cluster scaling environment, the heartbeat-threshold must

always be set to 8.

Options milliseconds —Time interval between any two heartbeat messages.

Range: 1000 through 2000 milliseconds
Default: 1000 milliseconds

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

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

Related • cluster (Chassis) on page 270

Documentation

Copyright © 2016, Juniper Networks, Inc. 279

Chassis Cluster Feature Guide for Branch SRX Series Devices

heartbeat-threshold

Supported Platforms SRX Series, vSRX

Syntax heartbeat-threshold number;

Hierarchy Level [edit chassis cluster]

Release Information Statement introduced in Junos OS Release 9.0. Statement updated in Junos OS Release
10.4.

Description Set the number of consecutive missed heartbeat signals that a device in a chassis cluster
must exceed to trigger failover of the active node.

The heartbeat-threshold option works in combination with the heartbeat-interval option

to define the wait time before failover is triggered in a chassis cluster. The default values
of these options produce a wait time of 3 seconds. In a large configuration approaching
full capacity on an SRX5400 or SRX5600 or SRX5800 device, however, we recommend
that you increase the failover wait time to 5 seconds.

For example, a heartbeat-threshold of 3 and a heartbeat-interval of 1000 milliseconds

result in a total wait of 3 seconds before failover is triggered. To increase this wait to 5
seconds, you could increase the heartbeat-threshold, the heartbeat-interval, or both. A
heartbeat-threshold of 5 and a heartbeat-interval of 1000 milliseconds would yield a wait
time of 5 seconds. Setting the heartbeat-threshold to 4 and the heartbeat-interval to
1250 milliseconds would also yield a wait time of 5 seconds.

Options number —Number of consecutive missed heartbeats.

Range: 3 through 8
Default: 3

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

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

Related • cluster (Chassis) on page 270

Documentation

280 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

hold-down-interval

Supported Platforms SRX Series, vSRX

Syntax hold-down-interval number;

Hierarchy Level [edit chassis cluster redundancy-group group-number]

Release Information Statement introduced in Junos OS Release 10.0.

Description Set the minimum interval to be allowed between back-to-back failovers for the specified
redundancy group (affects manual failovers, as well as automatic failovers associated
with monitoring failures).

For redundancy group 0, this setting prevents back-to-back failovers from occurring less
than 5 minutes (300 seconds) apart. Note that a redundancy group 0 failover implies a
Routing Engine failure.

For some configurations, such as ones with a large number of routes or logical interfaces,
the default or specified interval for redundancy group 0 might not be sufficient. In such
cases, the system automatically extends the dampening time in increments of 60 seconds
until the system is ready for failover.

Options number—Number of seconds specified for the interval.

Range: For redundancy group 0, 300 through 1800 seconds; for redundancy group 1
through 128, 0 through 1800 seconds.
Default: For redundancy group 0, 300 seconds; for redundancy group 1 through 128, 1
second.

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

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

Related • cluster (Chassis) on page 270

Documentation

Copyright © 2016, Juniper Networks, Inc. 281

Chassis Cluster Feature Guide for Branch SRX Series Devices

interface (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax interface {
logical-interface-name;
secondary-ip-address ip-address;
}

Hierarchy Level [edit chassis cluster redundancy-group group-number ip-monitoring family family-name
IP–address]

Release Information Statement introduced in Junos OS Release 10.1.

Description Specify the redundant Ethernet interface, including its logical-unit-number, through which
the monitored IP address must be reachable. The specified redundant Ethernet interface
can be in any redundancy group. Likewise specify a secondary IP address to be used as
a ping source for monitoring the IP address through the secondary node’s redundant
Ethernet interface link.

Options • rethX.logical-unit-number—Redundant Ethernet interface through which the monitored

IP address must be reachable. You must specify the redundant Ethernet interface
logical-unit-number. Note that you must also configure a secondary ping source IP
address (see below).

Range: reth0.logical-unit-number through reth128.logical-unit-number (device dependent)

NOTE: If the redundant Ethernet interface belongs to a VPN routing and

forwarding (VRF) routing instance type, then the IP monitoring feature will
not work.

• secondary-ip-address IP–address—Specify the IP address that will be used as the source

IP address of ping packets for IP monitoring from the secondary child link of the
redundant Ethernet interface. An IP address for sourcing the ping packets on the primary
link of the redundant Ethernet interface must be configured before you can configure
secondary-ip-address. For legacy support reasons, monitoring on an IP address without
identifying a redundant Ethernet interface and without configuring a secondary ping
source IP address is permitted but not recommended.

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

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

Related • cluster (Chassis) on page 270

Documentation

282 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

interface-monitor

Supported Platforms SRX Series, vSRX

Syntax interface-monitor interface-name {

weight number;
}

Hierarchy Level [edit chassis cluster redundancy-group group-number ]

Release Information Statement introduced in Junos OS Release 9.0.

Description Specify a redundancy group interface to be monitored for failover and the relative weight
of the interface.

Options interface-name —Name of the physical interface to monitor.

The remaining statements are explained separately. See CLI Explorer.

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

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

Related • cluster (Chassis) on page 270

Documentation

Copyright © 2016, Juniper Networks, Inc. 283

Chassis Cluster Feature Guide for Branch SRX Series Devices

ip-monitoring

Supported Platforms SRX Series, vSRX

Syntax ip-monitoring {
family {
inet {
ipv4-address {
interface {
logical-interface-name;
secondary-ip-address ip-address;
}
weight number;
}
}
}
global-threshold number;
global-weight number;
retry-count number;
retry-interval seconds;
}

Hierarchy Level [edit chassis cluster redundancy-group group-number ]

Release Information Statement updated in Junos OS Release 10.1.

Description Specify a global IP address monitoring threshold and weight, and the interval between
pings (retry-interval) and the number of consecutive ping failures (retry-count) permitted
before an IP address is considered unreachable for all IP addresses monitored by the
redundancy group. Also specify IP addresses, a monitoring weight, a redundant Ethernet
interface number, and a secondary IP monitoring ping source for each IP address, for the
redundancy group to monitor.

Options family inet IPv4 address—The address to be continually monitored for reachability.

NOTE: All monitored object failures, including IP monitoring, are deducted

from the redundancy group threshold priority. Other monitored objects include
interface monitor, SPU monitor, cold-sync monitor, and NPC monitor (on
supported platforms).

The remaining statements are explained separately. See CLI Explorer.

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

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

Related • interface (Chassis Cluster) on page 282

Documentation
• global-threshold on page 276

• global-weight on page 277

284 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

• weight on page 304

• Example: Configuring Chassis Cluster Redundancy Group IP Address Monitoring on

page 136

lacp (Interfaces)

Supported Platforms SRX Series

Syntax lacp {
port-priority port-number;
}

Hierarchy Level [edit interfaces interface-name redundant-ether-options]

Release Information Statement introduced in Junos OS Release 10.2.

Description For redundant Ethernet interfaces in a chassis cluster only, configure Link Aggregation
Control Protocol (LACP).

Options • active—Initiate transmission of LACP packets.

• passive—Respond to LACP packets.

Default: If you do not specify lacp as either active or passive, LACP remains off (the
default).

The remaining statements are explained separately. See CLI Explorer.

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

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

Related • Understanding LACP on Standalone Devices

Documentation

Copyright © 2016, Juniper Networks, Inc. 285

Chassis Cluster Feature Guide for Branch SRX Series Devices

link-protection (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax link-protection {
non-revertive;
}

Hierarchy Level [edit chassis aggregated-devices ethernet lacp]

Release Information Statement introduced in Junos OS Release 10.2.

Description Enable Link Aggregation Control Protocol (LACP) link protection at the global (chassis)
level.

Options non-revertive—Disable the ability to switch to a better priority link (if one is available)
once a link is established as active and a collection or distribution is enabled.

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

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

Related • cluster (Chassis) on page 270

Documentation
• Example: Configuring Aggregated Ethernet Device with LAG and LACP (CLI) on page 248

member-interfaces

Supported Platforms SRX Series, vSRX

Syntax member-interfaces member-interface-name;

Hierarchy Level [edit interfaces interface-name fabric-options]

Release Information Statement introduced in Junos OS Release 8.5.

Description Specify the member interface name. Member interfaces that connect to each other must
be of the same type.

Options member-interface-name —Member interface name.

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

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

Related • Understanding Interfaces

Documentation

286 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

network-management

Supported Platforms SRX Series, vSRX

Syntax network-management {
cluster-master;
}

Hierarchy Level [edit chassis cluster]

Release Information Statement introduced in Junos OS Release 11.1.

Description Define parameters for network management. To manage an SRX Series Services Gateway
cluster through a non-fxp0 interface, use this command to define the node as a virtual
chassis in NSM. This command establishes a single DMI connection from the primary
node to the NSM server. This connection is used to manage both nodes in the cluster.
Note that the non-fxp0 interface (regardless of which node it is present on) is always
controlled by the primary node in the cluster. The output of a <get-system-information>
RPC returns a <chassis-cluster> tag in all SRX Series devices. When NSM receives this
tag, it models SRX Series clusters as devices with autonomous control planes.

Options cluster-master—Enable in-band management on the primary cluster node through NSM.

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

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

Related • cluster (Chassis) on page 270

Documentation

Copyright © 2016, Juniper Networks, Inc. 287

Chassis Cluster Feature Guide for Branch SRX Series Devices

node (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax node (0 | 1 ) {
priority number;
}

Hierarchy Level [edit chassis cluster]

Release Information Statement introduced in Junos OS Release 9.0.

Description Identify the device in a chassis cluster. The node 0 device in the cluster has the chassis
ID 1, and the node 1 device in the cluster has the chassis ID 2.

Options node-number —Cluster node number.

Range: 0 through 1

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

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

Related • cluster (Chassis) on page 270

Documentation

node (Chassis Cluster Redundancy Group)

Supported Platforms SRX Series, vSRX

Syntax node (0 | 1 ) {
priority number;
}

Hierarchy Level [edit chassis cluster redundancy-group group-number ]

Release Information Statement introduced in Junos OS Release 9.0.

Description Identify each cluster node in a redundancy group and set its relative priority for mastership.

Options node-number —Cluster node number, set with the chassis cluster node node-number
statement.

The remaining statements are explained separately. See CLI Explorer.

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

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

Related • redundancy-group (Chassis Cluster) on page 290

Documentation

288 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

preempt (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax preempt;

Hierarchy Level [edit chassis cluster redundancy-group group-number ]

Release Information Statement introduced in Junos OS Release 9.0.

Description Enable chassis cluster node preemption within a redundancy group. If preempt is added
to a redundancy group configuration, the device with the higher priority in the group can
initiate a failover to become master. By default, preemption is disabled.

Initiating a failover with the request chassis cluster failover node or request chassis cluster
failover redundancy-group command overrides the priority settings and preemption.

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

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

Related • redundancy-group (Chassis Cluster) on page 290

Documentation

priority (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax priority number;

Hierarchy Level [edit chassis cluster redundancy-group group-number node node-number ]

Release Information Statement introduced in Junos OS Release 9.0.

Description Define the priority of a node (device) in a redundancy group. Initiating a failover with the
request chassis cluster failover node or request chassis cluster failover redundancy-group
command overrides the priority settings.

Options priority-number —Priority value of the node. The eligible node with the highest priority is
elected master.
Range: 1 through 254

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

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

Related • redundancy-group (Chassis Cluster) on page 290

Documentation

Copyright © 2016, Juniper Networks, Inc. 289

Chassis Cluster Feature Guide for Branch SRX Series Devices

redundancy-group (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax redundancy-group group-number {

gratuitous-arp-count number;
hold-down-interval number;
interface-monitor interface-name {
weight number;
}
ip-monitoring {
family {
inet {
ipv4-address {
interface {
logical-interface-name;
secondary-ip-address ip-address;
}
weight number;
}
}
}
global-threshold number;
global-weight number;
retry-count number;
retry-interval seconds;
}
node (0 | 1 ) {
priority number;
}
preempt;
}

Hierarchy Level [edit chassis cluster]

Release Information Statement introduced in Junos OS Release 9.0.

Description Define a redundancy group. Except for redundancy group 0, a redundancy group is a
logical interface consisting of two physical Ethernet interfaces, one on each chassis. One
interface is active, and the other is on standby. When the active interface fails, the standby
interface becomes active. The logical interface is called a redundant Ethernet interface
(reth).

Redundancy group 0 consists of the two Routing Engines in the chassis cluster and
controls which Routing Engine is primary. You must define redundancy group 0 in the
chassis cluster configuration.

Options group-number —Redundancy group identification number.

Range: 0 through 128

290 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

NOTE: The maximum number of redundancy groups is equal to the number

of redundant Ethernet interfaces that you configure.

The remaining statements are explained separately. See CLI Explorer.

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

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

Related • ip-monitoring on page 284

Documentation

redundancy-interface-process

Supported Platforms SRX Series, vSRX

Syntax redundancy-interface-process {
command binary-file-path;
disable;
failover (alternate-media | other-routing-engine);
}

Hierarchy Level [edit system processes]

Release Information Statement introduced in Junos OS Release 8.5.

Description Specify as an active or backup process of an application server, configure to process

traffic for more than one logical application server.

Options • command binary-file-path—Path to the binary process.

• disable—Disable the redundancy interface management process.

• failover—Configure the device to reboot if the software process fails four times within
30 seconds, and specify the software to use during the reboot.

• alternate-media—Configure the device to switch to backup media that contains a

version of the system if a software process fails repeatedly.

• other-routing-engine—Instruct the secondary Routing Engine to take mastership if

a software process fails. If this statement is configured for a process, and that process
fails four times within 30 seconds, then the device reboots from the secondary
Routing Engine.

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

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

Related • cluster (Chassis) on page 270

Documentation

Copyright © 2016, Juniper Networks, Inc. 291

Chassis Cluster Feature Guide for Branch SRX Series Devices

redundant-ether-options

Supported Platforms SRX Series, vSRX

Syntax redundant-ether-options {
(flow-control | no-flow-control);
lacp {
(active | passive);
periodic (fast | slow);
}
link-speed speed;
(loopback | no-loopback);
minimum-links number;
redundancy-group number;
source-address-filter mac-address;
(source-filtering | no-source-filtering);
}

Hierarchy Level [edit interfaces interface-name]

Release Information Statement introduced in Junos OS Release 9.2.

Description Configure Ethernet redundancy options for a chassis cluster.

Options The remaining statements are explained separately. See CLI Explorer.

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

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

Related • Example: Enabling Eight Queue Class of Service on Redundant Ethernet Interfaces
Documentation
• Example: Configuring Chassis Cluster Redundant Ethernet Interfaces for IPv4 and IPv6
Addresses on page 79

292 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

redundant-parent (Interfaces)

Supported Platforms SRX Series, vSRX

Syntax redundant-parent redundant-ethernet-interface-name;

Hierarchy Level [edit interfaces interface-name gigether-options]

[edit interfaces interface-name fastether-options]

Release Information Statement introduced in Junos OS Release 10.2.

Description Assign local (child) interfaces to the redundant Ethernet (reth) interfaces. A redundant
Ethernet interface contains a pair of Fast Ethernet interfaces or a pair of Gigabit Ethernet
interfaces that are referred to as child interfaces of the redundant Ethernet interface (the
redundant parent).

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

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

Related • Example: Configuring Chassis Cluster Redundant Ethernet Interfaces for IPv4 and IPv6
Documentation Addresses on page 79

redundant-pseudo-interface-options

Supported Platforms SRX Series, vSRX

Syntax redundant-pseudo-interface-options {
redundancy-group redundancy-group;
}

Hierarchy Level [edit interfaces lo0]

Release Information Statement introduced in Junos OS Release 12.1X44-D10.

Description Configure the loopback pseudointerface in a redundancy group.

An Internet Key Exchange (IKE) gateway operating in chassis cluster, needs an external
interface to communicate with a peer device. When an external interface (a reth interface
or a standalone interface) is used for communication; the interface might go down when
the physical interfaces are down. Instead, use loopback interfaces as an alternative to
physical interfaces.

Options redundancy-group redundancy-group-number— Configure the redundancy group number.

Range: 0 through 255

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

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

Related • Understanding Loopback Interface for a High Availability VPN

Documentation

Copyright © 2016, Juniper Networks, Inc. 293

Chassis Cluster Feature Guide for Branch SRX Series Devices

reth-count (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax reth-count number;

Hierarchy Level [edit chassis cluster]

Release Information Statement introduced in Junos OS Release 9.0.

Description Specify the number of redundant Ethernet (reth) interfaces allowed in the chassis cluster.
Note that the number of reth interfaces configured determines the number of redundancy
groups that can be configured.

Options number —Number of redundant Ethernet interfaces allowed.

Range: 1 through 128
Default: 0

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

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

Related • cluster (Chassis) on page 270

Documentation

294 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

reth (Interfaces)

Supported Platforms SRX Series, vSRX

Syntax reth <0 |1> {

accounting-profile;
description;
disable;
encapsulation;
gratuitous-arp-reply;
hierarchical-scheduler {
implicit-hierarchy;
maximum-hierarchy-levels;
}
mac;
mtu;
native-vlan-id;
no-gratuitous-arp-reply;
no-gratuitous-arp-request;
(per-unit-scheduler | no-per-unit-scheduler);
promiscuous-mode;
redundant-ether-options {
(flow-control | no-flow-control);
lacp {
(active | passive);
periodic (fast | slow);
}
link-speed speed;
(loopback | no-loopback);
minimum-links number;
redundancy-group number;
}
traceoptions {
flag (all | event | ipc | media);
}
}
(traps | no-traps);
unit unit-number {
accounting-profile name;
alias;
bandwidth bandwidth;
description text;
disable;
encapsulation (dix | ether-vpls-fr | frame-relay-ppp | ppp-over-ether | vlan-bridge |
vlan-ccc | vlan-vpls |vlan-tcc);
family {
ethernet-switching {
bridge-domain-type (svlan| bvlan);
inner-vlan [members];
inter-switch-link;
interface-mode (access | trunk);
recovery-timeout seconds;
storm-control;
vlan [members];
vlan-auto-sense;

Copyright © 2016, Juniper Networks, Inc. 295

Chassis Cluster Feature Guide for Branch SRX Series Devices

vlan-rewrite {
translate {
from-vlan-id;
to-vlan-id ;
}
}
}
inet {
accounting {
destination-class-usage;
source-class-usage {
input;
output;
}
}
address (source–address/prefix) {
arp destination-address ;
}
broadcast address;
preferred;
primary;
vrrp-group group-id {
(accept-data | no-accept-data);
advertise-interval seconds;
advertisements-threshold number;
authentication-key key-value;
authentication-type (md5 | simple);
fast-interval milliseconds;
inet6-advertise-interval milliseconds
(preempt <hold-timeseconds> | no-preempt );
preferred;
priority value;
track {
interface interface-name {
bandwidth-threshold bandwidth;
priority-cost value;
}
priority-hold-time seconds;
route route-address{
routing-instance routing-instance;
priority-cost value;
}
}
virtual-address [address];
virtual-link-local-address address;
vrrp-inherit-from {
active-group value;
active-interface interface-name;
}
}
web-authentication {
http;
https;
redirect-to-https;
}
}

296 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

dhcp {
client-identifier {
(ascii string | hexadecimal string);
}
lease-time (length | infinite);
retransmission-attempt value;
retransmission-interval seconds;
server-address server-address;
update-server;
vendor-id vendor-id ;
}
dhcp-client {
client-identifier {
prefix {
host-name;
logical-system-name;
routing-instance-name;
}
use-interface-description (device | logical);
user-id (ascii string| hexadecimal string);
}
lease-time (length | infinite);
retransmission-attempt value;
retransmission-interval seconds;
server-address server-address;
update-server;
vendor-id vendor-id ;
}
filter {
group number;
input filter-name;
input-list [filter-name];
output filter-name;
output-list [filter-name];
}
mtu value;
no-neighbor-learn;
no-redirects;
policer {
input input-name;
}
primary;
rpf-check {
fail-filter filter-name;
mode {
loose;
}
}
sampling {
input;
output;
}
simple-filter;
unconditional-src-learn;
unnumbered-address {
interface-name;

Copyright © 2016, Juniper Networks, Inc. 297

Chassis Cluster Feature Guide for Branch SRX Series Devices

preferred-source-address preferred-source-address;
}
}
inet6 {
accounting {
destination-class-usage;
source-class-usage {
input;
ouput;
}
}
address source–address/prefix {
eui-64;
ndp address {
(mac mac-address | multicast-mac multicast-mac-address);
publish;
}
preferred;
primary;
vrrp-inet6-group group_id {
(accept-data | no-accept-data);
advertisements-threshold number;
authentication-key value;
authentication-type (md5 | simple);
fast-interval milliseconds;
inet6-advertise-interval milliseconds;
(preempt <hold-time seconds>| no-preempt );
priority value;
track {
interface interface-name {
bandwidth-threshold value;
priority-cost value;
}
priority-hold-time seconds;
route route-address{
routing-instance routing-instance;
}
}
vrrp-inherit-from {
active-group value;
active-interface interface-name;
}
}
web-authentication {
http;
https;
redirect-to-https;
}
}
(dad-disable | no-dad-disable);
filter {
group number;
input filter-name;
input-list [filter-name];
output filter-name;
output-list [filter-name];

298 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

}
mtu value;
nd6-stale-time seconds;
no-neighbor-learn;
no-redirects;
rpf-check {
fail-filter filter-name;
mode {
loose;
}
}
sampling {
input;
output;
}
unnumbered-address;
}
iso {
address source-address;
mtu value;
}
vpls {
filter {
group number;
input filter-name;
input-list [filter-name];
output filter-name;
output-list [filter-name];
}
policer {
input input-name;
output output-name;
}
}
}
native-inner-vlan-id value;
(no-traps | traps);
proxy-arp (restricted | unrestricted);
traps;
vlan-id vlan-id;
vlan-id-list vlan-id-list;
vlan-id-range vlan-id1-vlan-id2;
}
vlan-tagging;
}

Hierarchy Level [edit interfaces]

Release Information Statement introduced in Junos OS Release 10.2.

Description Configure a redundant Ethernet interface (reth) for chassis cluster. It is a pseudointerface
that includes at minimum of one physical interface from each node of the cluster.

Options The remaining statements are explained separately. See CLI Explorer.

Copyright © 2016, Juniper Networks, Inc. 299

Chassis Cluster Feature Guide for Branch SRX Series Devices

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

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

Related • Example: Configuring Chassis Cluster Redundant Ethernet Interfaces for IPv4 and IPv6
Documentation Addresses on page 79

• cluster (Chassis) on page 270

• redundant-ether-options on page 292

• lacp (Interfaces) on page 285

retry-count (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax retry-count number;

Hierarchy Level [edit chassis cluster redundancy-group group-number ip-monitoring ]

Release Information Statement introduced in Junos OS Release 10.1.

Description Specify the number of consecutive ping attempts that must fail before an IP address
monitored by the redundancy group is declared unreachable. (See retry-interval for a
related redundancy group IP address monitoring variable.)

Options count—Number of consecutive ping attempt failures before a monitored IP address is

declared unreachable.
Range: 1 through 15
Default: 5

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

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

Related • cluster (Chassis) on page 270

Documentation

300 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

retry-interval (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax retry-interval interval;

Hierarchy Level [edit chassis cluster redundancy-group group-number ip-monitoring ]

Release Information Statement introduced in Junos OS Release 10.1.

Description Specify the ping packet send frequency (in seconds) for each IP address monitored by
the redundancy group. (See retry-count for a related IP address monitoring configuration
variable.)

Options interval—Pause time between each ping sent to each IP address monitored by the
redundancy group.
Range: 1 to 30 seconds
Default: 1 second

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

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

Related • ip-monitoring on page 284

Documentation

route-active-on

Supported Platforms SRX Series, vSRX

Syntax route-active-on (node0 | node1);

Hierarchy Level [edit policy-options condition condition-name ]

Release Information Statement introduced in Junos OS Release 9.0.

Description For chassis cluster configurations, identify the device (node) on which a route is active.

Options node0 | node1—Node in a chassis cluster.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • cluster (Chassis) on page 270

Documentation

Copyright © 2016, Juniper Networks, Inc. 301

Chassis Cluster Feature Guide for Branch SRX Series Devices

traceoptions (Chassis Cluster)

Supported Platforms SRX Series, vSRX

Syntax traceoptions {
file {
filename;
files number;
match regular-expression;
(world-readable | no-world-readable);
size maximum-file-size;
}
flag flag;
level {
(alert | all | critical | debug | emergency | error | info | notice | warning);
}
no-remote-trace;
}

Hierarchy Level [edit chassis cluster]

Release Information Statement modified in Junos OS Release 9.5.

Description Define chassis cluster redundancy process tracing operations.

Options • file filename —Name of the file to receive the output of the tracing operation. Enclose
the name within quotation marks. All files are placed in the directory /var/log.

• files number —(Optional) Maximum number of trace files. When a trace file named
trace-file reaches its maximum size, it is renamed to trace-file .0, then trace-file.1 , and
so on, until the maximum number of trace files is reached. The oldest archived file is
overwritten.

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

Range: 2 through 1000 files

Default: 10 files

• match regular-expression —(Optional) Refine the output to include lines that contain
the regular expression.

• size maximum-file-size —(Optional) Maximum size of each trace file, in kilobytes (KB),
megabytes (MB), or gigabytes (GB). When a trace file named trace-file reaches this
size, it is renamed trace-file .0. When the trace-file again reaches its maximum size,
trace-file .0 is renamed trace-file .1 and trace-file is renamed trace-file .0. This
renaming scheme continues until the maximum number of trace files is reached. Then
the oldest trace file is overwritten.

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

Syntax: x k to specify KB, x m to specify MB, or x g to specify GB

302 Copyright © 2016, Juniper Networks, Inc.

 Chapter 24: Configuration Statements

Range: 0 KB through 1 GB
Default: 128 KB

• world-readable | no-world-readable—(Optional) By default, log files can be accessed

only by the user who configures the tracing operation. The world-readable option
enables any user to read the file. To explicitly set the default behavior, use the
no-world-readable option.

• flag—Trace operation or operations to perform on chassis cluster redundancy processes.

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

• all—Trace all the events

• configuration—Trace configuration events

• routing-socket—Trace logging of rtsock activity

• snmp—Trace SNMP events

Required Privilege trace—To view this statement in the configuration.

Level trace-control—To add this statement to the configuration.

Related • cluster (Chassis) on page 270

Documentation

Copyright © 2016, Juniper Networks, Inc. 303

Chassis Cluster Feature Guide for Branch SRX Series Devices

weight

Supported Platforms SRX Series, vSRX

Syntax interface-monitor interface-name {

weight number;
}

Hierarchy Level [edit chassis cluster redundancy-group group-number interface-monitor interface ]

[edit chassis cluster redundancy-group group-number ip-monitoring IP–address]

Release Information Statement modified in Junos OS Release 10.1.

Description Specify the relative importance of the object to the operation of the redundancy group.
This statement is primarily used with interface monitoring and IP address monitoring
objects. The failure of an object—such as an interface—with a greater weight brings the
group closer to failover. Every monitored object is assigned a weight.

• interface-monitor objects—If the object fails, its weight is deducted from the threshold
of its redundancy group;

• ip-monitoring objects—If a monitored IP address becomes unreachable for any reason,

the weight assigned to that monitored IP address is deducted from the redundancy
group’s global-threshold for IP address monitoring.

Every redundancy group has a default threshold of 255. If the threshold reaches 0, a
failover is triggered. Failover is triggered even if the redundancy group is in manual failover
mode and preemption is not enabled.

Options number —Weight assigned to the interface or monitored IP address. A higher weight value
indicates a greater importance.
Range: 0 through 255

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

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

Related • cluster (Chassis) on page 270

Documentation

304 Copyright © 2016, Juniper Networks, Inc.

CHAPTER 25

Operational Commands

• clear chassis cluster control-plane statistics

• clear chassis cluster data-plane statistics
• clear chassis cluster failover-count
• clear chassis cluster ip-monitoring failure-count
• clear chassis cluster ip-monitoring failure-count ip-address
• clear chassis cluster statistics
• request chassis cluster configuration-synchronize
• request chassis cluster failover node
• request chassis cluster failover redundancy-group
• request chassis cluster failover reset
• request chassis fpc
• request system software in-service-upgrade (Maintenance)
• set chassis cluster cluster-id node reboot
• show chassis cluster control-plane statistics
• show chassis cluster data-plane interfaces
• show chassis cluster data-plane statistics
• show chassis cluster ethernet-switching interfaces
• show chassis cluster ethernet-switching status
• show chassis cluster information
• show chassis cluster information configuration-synchronization
• show chassis cluster interfaces
• show chassis cluster ip-monitoring status redundancy-group
• show chassis cluster statistics
• show chassis cluster status
• show chassis environment (Security)
• show chassis ethernet-switch
• show chassis fabric plane
• show chassis fabric plane-location

Copyright © 2016, Juniper Networks, Inc. 305

Chassis Cluster Feature Guide for Branch SRX Series Devices

• show chassis fabric summary

• show chassis hardware (View)
• show chassis routing-engine (View)
• show configuration chassis cluster traceoptions

306 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

clear chassis cluster control-plane statistics

Supported Platforms SRX Series, vSRX

Syntax clear chassis cluster control-plane statistics

Release Information Command introduced in Junos OS Release 9.3.

Description Clear the control plane statistics of a chassis cluster.

Required Privilege clear

Level

Related • show chassis cluster control-plane statistics on page 324

Documentation

List of Sample Output clear chassis cluster control-plane statistics on page 307

Output Fields When you enter this command, you are provided feedback on the status of your request.

Sample Output
clear chassis cluster control-plane statistics
user@host> clear chassis cluster control-plane statistics
Cleared control-plane statistics

Copyright © 2016, Juniper Networks, Inc. 307

Chassis Cluster Feature Guide for Branch SRX Series Devices

clear chassis cluster data-plane statistics

Supported Platforms SRX Series, vSRX

Syntax clear chassis cluster data-plane statistics

Release Information Command introduced in Junos OS Release 9.3.

Description Clear the data plane statistics of a chassis cluster.

Required Privilege clear

Level

Related • show chassis cluster data-plane statistics on page 327

Documentation

List of Sample Output clear chassis cluster data-plane statistics on page 308

Output Fields When you enter this command, you are provided feedback on the status of your request.

Sample Output
clear chassis cluster data-plane statistics
user@host> clear chassis cluster data-plane statistics
Cleared data-plane statistics

308 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

clear chassis cluster failover-count

Supported Platforms SRX Series, vSRX

Syntax clear chassis cluster failover-count

Release Information Command introduced in Junos OS Release 9.3.

Description Clear the failover count of all redundancy-groups.

Required Privilege clear

Level

Related • request chassis cluster failover node on page 315

Documentation
• request chassis cluster failover reset on page 317

• show chassis cluster status on page 350

List of Sample Output show chassis cluster status on page 309

clear chassis cluster failover-count on page 309
show chassis cluster status on page 309

Output Fields When you enter this command, you are provided feedback on the status of your request.

Sample Output
The following example displays the redundancy groups before and after the
failover-counts are cleared.

show chassis cluster status

user@host> show chassis cluster status

Cluster ID: 3
Node name Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 1

node0 200 secondary no no
node1 100 primary no no

Redundancy group: 1 , Failover count: 2

node0 100 primary no no
node1 10 secondary no no

clear chassis cluster failover-count

user@host> clear chassis cluster failover-count
Cleared failover-count for all redundancy-groups

show chassis cluster status

user@host> show chassis cluster status

Cluster ID: 3
Node name Priority Status Preempt Manual failover

Copyright © 2016, Juniper Networks, Inc. 309

Chassis Cluster Feature Guide for Branch SRX Series Devices

Redundancy group: 0 , Failover count: 0

node0 200 secondary no no
node1 100 primary no no

Redundancy group: 1 , Failover count: 0

node0 100 primary no no
node1 10 secondary no no

310 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

clear chassis cluster ip-monitoring failure-count

Supported Platforms SRX Series, vSRX

Syntax clear chassis cluster ip-monitoring failure-count

Release Information Command introduced in Junos OS Release 10.1.

Description Clear the failure count for all IP addresses.

Required Privilege clear

Level

Related • clear chassis cluster failover-count on page 309

Documentation
• clear chassis cluster ip-monitoring failure-count ip-address on page 312

Output Fields When you enter this command, you are provided feedback on the status of your request.

Sample Output
user@host> clear chassis cluster ip-monitoring failure-count

node0:
--------------------------------------------------------------------------
Cleared failure count for all IPs

node1:
--------------------------------------------------------------------------
Cleared failure count for all IPs

Copyright © 2016, Juniper Networks, Inc. 311

Chassis Cluster Feature Guide for Branch SRX Series Devices

clear chassis cluster ip-monitoring failure-count ip-address

Supported Platforms SRX Series, vSRX

Syntax clear chassis cluster ip-monitoring failure-count ip-address 1.1.1.1

Release Information Command introduced in Junos OS Release 10.1.

Description Clear the failure count for a specified IP address.

NOTE: Entering an IP address at the end of this command is optional. If you

do not specify an IP address, the failure count for all monitored IP addresses
is cleared.

Required Privilege clear

Level

Related • clear chassis cluster failover-count on page 309

Documentation
• clear chassis cluster ip-monitoring failure-count on page 311

Output Fields When you enter this command, you are provided feedback on the status of your request.

Sample Output
user@host> clear chassis cluster ip-monitoring failure-count ip-address 1.1.1.1

node0:
--------------------------------------------------------------------------
Cleared failure count for IP: 1.1.1.1

node1:
--------------------------------------------------------------------------
Cleared failure count for IP: 1.1.1.1

312 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

clear chassis cluster statistics

Supported Platforms SRX Series, vSRX

Syntax clear chassis cluster statistics

Release Information Command introduced in Junos OS Release 9.3.

Description Clear the control plane and data plane statistics of a chassis cluster.

Required Privilege clear

Level

Related • show chassis cluster statistics on page 346

Documentation

List of Sample Output clear chassis cluster statistics on page 313

Output Fields When you enter this command, you are provided feedback on the status of your request.

Sample Output
clear chassis cluster statistics
user@host> clear chassis cluster statistics
Cleared control-plane statistics
Cleared data-plane statistics

Copyright © 2016, Juniper Networks, Inc. 313

Chassis Cluster Feature Guide for Branch SRX Series Devices

request chassis cluster configuration-synchronize

Supported Platforms SRX Series, vSRX

Syntax request chassis cluster configuration-synchronize

Release Information Command introduced in Junos OS Release 12.1X47-D10.

Description Synchronizes the configuration from the primary node to the secondary node when the
secondary node joins the primary node in a cluster.

Required Privilege maintenance

Level

Related • Understanding Automatic Chassis Cluster Synchronization Between Primary and

Documentation Secondary Nodes on page 181

• Verifying Chassis Cluster Configuration Synchronization Status on page 182

• NTP Time Synchronization on SRX Series Devices on page 183

List of Sample Output request chassis cluster configuration-synchronize on page 314

Output Fields When you enter this command, you are provided feedback on the status of your request.

Sample Output
request chassis cluster configuration-synchronize
user@host> request chassis cluster configuration-synchronize
Performing configuration synchronization from remote node.

314 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

request chassis cluster failover node

Supported Platforms SRX Series, vSRX

Syntax request chassis cluster failover node node-number

redundancy-group group-number

Release Information Command introduced in Junos OS Release 9.0.

Description For chassis cluster configurations, initiate manual failover in a redundancy group from
one node to the other, which becomes the primary node, and automatically reset the
priority of the group to 255. The failover stays in effect until the new primary node becomes
unavailable, the threshold of the redundancy group reaches 0, or you use the request
chassis cluster failover reset command.

After a manual failover, you must use the request chassis cluster failover reset command
before initiating another failover.

Options • node node-number-Number of the chassis cluster node to which the redundancy group
fails over.

• Range: 0 through 1

• redundancy-group group-number —Number of the redundancy group on which to initiate

manual failover. Redundancy group 0 is a special group consisting of the two Routing
Engines in the chassis cluster.

Range: 0 through 255

Required Privilege maintenance

Level

Related • clear chassis cluster failover-count on page 309

Documentation
• request chassis cluster failover reset on page 317

• show chassis cluster status on page 350

List of Sample Output request chassis cluster failover node 0 redundancy-group 1 on page 315

Output Fields When you enter this command, you are provided feedback on the status of your request.

Sample Output
request chassis cluster failover node 0 redundancy-group 1
user@host> request chassis cluster failover node 0 redundancy-group 1
Initiated manual failover for redundancy group 1

Copyright © 2016, Juniper Networks, Inc. 315

Chassis Cluster Feature Guide for Branch SRX Series Devices

request chassis cluster failover redundancy-group

Supported Platforms

Syntax request chassis cluster failover redundancy-group redundancy-group-number

Release Information Command introduced in Junos OS Release 9.0.

Description For chassis cluster configurations, initiate manual failover in a redundancy group from
one node to the other, which becomes the primary node, and automatically reset the
priority of the group to 255. The failover stays in effect until the new primary node becomes
unavailable, the threshold of the redundancy group reaches 0, or you use the request
chassis cluster failover reset command.

After a manual failover, you must use the request chassis cluster failover reset command
before initiating another failover.

Options • node node-number-Number of the chassis cluster node to which the redundancy group
fails over.

• Range: 0 through 1

• redundancy-group group-number —Number of the redundancy group on which to initiate

manual failover. Redundancy group 0 is a special group consisting of the two Routing
Engines in the chassis cluster.

Range: 0 through 255

Required Privilege maintenance

Level

Related • Initiating a Chassis Cluster Manual Redundancy Group Failover on page 146
Documentation
• Verifying Chassis Cluster Failover Status on page 148

List of Sample Output request chassis cluster failover redundancy-group 0 node 1 on page 316

Output Fields When you enter this command, you are provided feedback on the status of your request.

Sample Output
request chassis cluster failover redundancy-group 0 node 1
user@host> request chassis cluster failover redundancy-group 0 node 1
{primary:node0}
user@host> request chassis cluster failover redundancy-group 0 node 1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Initiated manual failover for redundancy group 0

316 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

request chassis cluster failover reset

Supported Platforms SRX Series, vSRX

Syntax request chassis cluster failover reset

redundancy-group group-number

Release Information Command introduced in Junos OS Release 9.0.

Description In chassis cluster configurations, undo the previous manual failover and return the
redundancy group to its original settings.

Options redundancy-group group-number —Number of the redundancy group on which to reset

manual failover. Redundancy group 0 is a special group consisting of the two Routing
Engines in the chassis cluster.

Range: 0 through 255

Required Privilege maintenance

Level

Related • clear chassis cluster failover-count on page 309

Documentation
• request chassis cluster failover node on page 315

• show chassis cluster status on page 350

List of Sample Output request chassis cluster failover reset redundancy-group 0 on page 317

Output Fields When you enter this command, you are provided feedback on the status of your request.

Sample Output
request chassis cluster failover reset redundancy-group 0
user@host> request chassis cluster failover reset redundancy-group 0

Copyright © 2016, Juniper Networks, Inc. 317

Chassis Cluster Feature Guide for Branch SRX Series Devices

request chassis fpc

Supported Platforms SRX Series

Syntax request chassis fpc (offline | online | restart) slot slot-number

Release Information Command modified in Junos OS Release 9.2.

Description Control the operation of the Flexible PIC Concentrator (FPC).

NOTE: The SRX5K-SPC-2-10-40 (SPC1) and SRX5K-SPC-4-15-320 (SPC2)

does not support the request chassis fpc command.

Options offline—Take the FPC offline.

online—Bring the FPC online.

restart—Restart the FPC.

slot slot-number—Specify the FPC slot number.

Required Privilege maintenance

Level

Related • show chassis fpc (View)

Documentation

Output Fields When you enter this command, you are provided feedback on the status of your request.

Sample Output
request chassis fpc
user@host> request chassis fpc online slot 0
FPC 0 already online

318 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

request system software in-service-upgrade (Maintenance)

Supported Platforms SRX300, SRX320, SRX340, SRX345, SRX5400, SRX550, SRX5600, SRX5800

Syntax request system software in-service-upgrade image_name

<no-copy>
<no-sync>
<no-tcp-syn-check>
<no-validate>
<reboot>
<unlink>

Release Information For SRX5400, SRX5600, and SRX5800 devices, command introduced in Junos OS
Release 9.6 and support for reboot as a required parameter added in Junos OS Release
11.2R2. For SRX5400 devices, the command is introduced in Junos OS Release
12.1X46-D20. For SRX300, SRX320, SRX340, and SRX345 devices, command introduced
in Junos OS Release 15.1X49-D40.

Description The in-service software upgrade (ISSU) feature allows a chassis cluster pair to be
upgraded from supported Junos OS versions with a traffic impact similar to that of
redundancy group failovers. Before upgrading, you should perform failovers so that all
redundancy groups are active on only one device. We recommend that graceful restart
for routing protocols be enabled before you initiate an ISSU.

For SRX300, SRX320, SRX340, SRX345, and SRX550 devices, you must use the no-sync
parameter to perform an in-band cluster upgrade (ICU). This allows a chassis cluster
pair to be upgraded with a minimal service disruption of approximately 30 seconds.

Options • image_name—Location and name of the software upgrade package to be installed.

• no-copy—(Optional) Installs the software upgrade package but does not save the
copies of package files.

• no-sync—Stops the flow state from synchronizing when the old secondary node has
booted with a new Junos OS image.

This parameter applies to SRX300, SRX320, SRX340, SRX345, and SRX550 devices
only. It is required for an ICU.

• no-tcp-syn-check—(Optional) Creates a window wherein the TCP SYN check for the
incoming packets is disabled. The default value for the window is 7200 seconds (2
hours).

This parameter applies to SRX300, SRX320, SRX340, SRX345, and SRX550 devices
only.

• no-validate—(Optional) Disables the configuration validation step at installation. The

system behavior is similar to that of the request system software add command.

This parameter applies to SRX300, SRX320, SRX340, SRX345, and SRX550 devices
only.

• reboot—Reboots each device in the chassis cluster pair after installation is completed.

Copyright © 2016, Juniper Networks, Inc. 319

Chassis Cluster Feature Guide for Branch SRX Series Devices

This parameter applies to SRX5400, SRX5600, and SRX5800 devices only. It is required
for an ISSU. (The devices in a cluster are automatically rebooted following an ICU.)

• unlink—(Optional) Removes the software package after successful installation.

Required Privilege maintenance

Level

Related • Chassis Configuration Statement Hierarchy on page 264

Documentation

List of Sample Output request system software in-service-upgrade (High-End SRX Series Devices) on page 320
request system software in-service-upgrade (Branch SRX Series Devices) on page 321

Output Fields When you enter this command, you are provided feedback on the status of your request.

Sample Output
request system software in-service-upgrade (High-End SRX Series Devices)
user@host> request system software in-service-upgrade
/var/tmp/junos-srx1k3k-11.2R2.5-domestic.tgz no-copy reboot
Chassis ISSU Started
node0:
--------------------------------------------------------------------------
Chassis ISSU Started
ISSU: Validating Image
Inititating in-service-upgrade

node0:
--------------------------------------------------------------------------
Inititating in-service-upgrade
Checking compatibility with configuration
mgd: commit complete
Validation succeeded
ISSU: Preparing Backup RE
Finished upgrading secondary node node0
Rebooting Secondary Node

node0:
--------------------------------------------------------------------------
Shutdown NOW!
[pid 3257]
ISSU: Backup RE Prepare Done
Waiting for node0 to reboot.
node0 booted up.
Waiting for node0 to become secondary
node0 became secondary.
Waiting for node0 to be ready for failover
ISSU: Preparing Daemons
Secondary node0 ready for failover.
Failing over all redundancy-groups to node0
ISSU: Preparing for Switchover
Initiated failover for all the redundancy groups to node1
Waiting for node0 take over all redundancy groups

Exiting in-service-upgrade window

node0:

320 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

--------------------------------------------------------------------------
Exiting in-service-upgrade window
Exiting in-service-upgrade window
Chassis ISSU Aborted

node0:
--------------------------------------------------------------------------
Chassis ISSU Ended
ISSU completed successfully, rebooting...
Shutdown NOW!
[pid 4294]

Sample Output
request system software in-service-upgrade (Branch SRX Series Devices)
user@host> request system software in-service-upgrade
/var/tmp/junos-srxsme-11.2R2.2-domestic.tgz no-sync
ISSU: Validating package
WARNING: in-service-upgrade shall reboot both the nodes
in your cluster. Please ignore any subsequent
reboot request message
ISSU: start downloading software package on secondary node
Pushing bundle to node1
NOTICE: Validating configuration against junos-srxsme-11.2R2.2-domestic.tgz.
NOTICE: Use the 'no-validate' option to skip this if desired.
Formatting alternate root (/dev/ad0s1a)...
/dev/ad0s1a: 630.5MB (1291228 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 157.62MB, 10088 blks, 20224 inodes.
super-block backups (for fsck -b #) at:
32, 322848, 645664, 968480
Checking compatibility with configuration
Initializing...
Verified manifest signed by PackageProduction_11_2_0
Verified junos-11.2R2.2-domestic signed by PackageProduction_11_2_0
Using junos-11.2R2.2-domestic from
/altroot/cf/packages/install-tmp/junos-11.2R2.2-domestic
Copying package ...
Saving boot file package in /var/sw/pkg/junos-boot-srxsme-11.2R2.2.tgz
Verified manifest signed by PackageProduction_11_2_0
Hardware Database regeneration succeeded
Validating against /config/juniper.conf.gz
cp: /cf/var/validate/chroot/var/etc/resolv.conf and /etc/resolv.conf are identical
(not copied).
cp: /cf/var/validate/chroot/var/etc/hosts and /etc/hosts are identical (not
copied).
mgd: commit complete
Validation succeeded
Installing package '/altroot/cf/packages/install-tmp/junos-11.2R2.2-domestic' ...
Verified junos-boot-srxsme-11.2R2.2.tgz signed by PackageProduction_11_2_0
Verified junos-srxsme-11.2R2.2-domestic signed by PackageProduction_11_2_0
Saving boot file package in /var/sw/pkg/junos-boot-srxsme-11.2R2.2.tgz
JUNOS 11.2R2.2 will become active at next reboot
WARNING: A reboot is required to load this software correctly
WARNING: Use the 'request system reboot' command
WARNING: when software installation is complete
Saving state for rollback ...
ISSU: finished upgrading on secondary node node1
ISSU: start upgrading software package on primary node
NOTICE: Validating configuration against junos-srxsme-11.2R2.2-domestic.tgz.
NOTICE: Use the 'no-validate' option to skip this if desired.

Copyright © 2016, Juniper Networks, Inc. 321

Chassis Cluster Feature Guide for Branch SRX Series Devices

Formatting alternate root (/dev/ad0s1a)...

/dev/ad0s1a: 630.9MB (1292176 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 157.75MB, 10096 blks, 20224 inodes.
super-block backups (for fsck -b #) at:
32, 323104, 646176, 969248
Checking compatibility with configuration
Initializing...
Verified manifest signed by PackageProduction_11_2_0
Verified junos-11.2R2.2-domestic signed by PackageProduction_11_2_0
Using junos-11.2R2.2-domestic from
/altroot/cf/packages/install-tmp/junos-11.2R2.2-domestic
Copying package ...
Saving boot file package in /var/sw/pkg/junos-boot-srxsme-11.2R2.2.tgz
Verified manifest signed by PackageProduction_11_2_0
Hardware Database regeneration succeeded
Validating against /config/juniper.conf.gz
cp: /cf/var/validate/chroot/var/etc/resolv.conf and /etc/resolv.conf are identical
(not copied).
cp: /cf/var/validate/chroot/var/etc/hosts and /etc/hosts are identical (not
copied).
mgd: commit complete
Validation succeeded
Installing package '/altroot/cf/packages/install-tmp/junos-11.2R2.2-domestic' ...
Verified junos-boot-srxsme-11.2R2.2.tgz signed by PackageProduction_11_2_0
Verified junos-srxsme-11.2R2.2-domestic signed by PackageProduction_11_2_0
Saving boot file package in /var/sw/pkg/junos-boot-srxsme-11.2R2.2.tgz
JUNOS 11.2R2.2 will become active at next reboot
WARNING: A reboot is required to load this software correctly
WARNING: Use the 'request system reboot' command
WARNING: when software installation is complete
Saving state for rollback ...
ISSU: failover all redundancy-groups 1...n to primary node
node0:
--------------------------------------------------------------------------
Successfully reset all redundancy-groups priority back to configured ones.
Redundancy-groups-0 will not be reset and the primaryship remains unchanged.

node1:
--------------------------------------------------------------------------
Successfully reset all redundancy-groups priority back to configured ones.
Redundancy-groups-0 will not be reset and the primaryship remains unchanged.

node0:
--------------------------------------------------------------------------
Initiated manual failover for all redundancy-groups to node0
Redundancy-groups-0 will not failover and the primaryship remains unchanged.
ISSU: rebooting Secondary Node

node1:
--------------------------------------------------------------------------
Shutdown NOW!
[pid 7023]
ISSU: Waiting for secondary node node1 to reboot.
ISSU: node 1 went down
ISSU: Waiting for node 1 to come up
ISSU: node 1 came up
ISSU: secondary node node1 booted up.
Shutdown NOW!
[pid 45056]

322 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

set chassis cluster cluster-id node reboot

Supported Platforms SRX Series, vSRX

Syntax set chassis cluster cluster-id cluster-id node node reboot

Release Information Support for extended cluster identifiers (more than 15 identifiers) added in Junos OS
Release 12.1X45-D10.

Description This operational mode command sets the chassis cluster identifier (ID) and node ID on
each device, and reboots the devices to enable clustering. The system uses the chassis
cluster ID and chassis cluster node ID to apply the correct configuration for each node
(for example, when you use the apply-groups command to configure the chassis cluster
management interface). The chassis cluster ID and node ID statements are written to
the EPROM, and the statements take effect when the system is rebooted.

Setting a cluster ID to 0 is equivalent to disabling a cluster. A cluster ID greater than 15

can only be set when the fabric and control link interfaces are connected back-to-back.

NOTE: If you have a cluster set up and running with an earlier release of Junos
OS, you can upgrade to Junos OS Release 12.1X45-D10 or later and re-create
a cluster with cluster IDs greater than 16. If for any reason you decide to revert
to the previous version of Junos OS that did not support extended cluster
IDs, the system comes up with standalone devices after you reboot. If the
cluster ID set is less than 16 and you roll back to a previous release, the system
comes back with the previous setup.

Options cluster-id cluster-id —Identifies the cluster within the Layer 2 domain.
Range: 0 through 255

node node —Identifies a node within a cluster.

Range: 0 to 1

Required Privilege maintenance

Level

Related • Example: Setting the Chassis Cluster Node ID and Cluster ID for Branch SRX Series
Documentation Devices on page 51

• Example: Setting the Chassis Cluster Node ID and Cluster ID for High-End SRX Series
Devices

• Understanding the Interconnect Logical System and Logical Tunnel Interfaces

• Example: Configuring Logical Systems in an Active/Passive Chassis Cluster (Master

Administrators Only)

Output Fields When you enter this command, you are provided feedback on the status of your request.

Copyright © 2016, Juniper Networks, Inc. 323

Chassis Cluster Feature Guide for Branch SRX Series Devices

show chassis cluster control-plane statistics

Supported Platforms SRX Series, vSRX

Syntax show chassis cluster control-plane statistics

Release Information Command introduced in Junos OS Release 9.3. Output changed to support dual control
ports in Junos OS Release 10.0.

Description Display information about chassis cluster control plane statistics.

Required Privilege view

Level

Related • clear chassis cluster control-plane statistics on page 307

Documentation

List of Sample Output show chassis cluster control-plane statistics on page 325
show chassis cluster control-plane statistics (SRX5000 line devices) on page 325

Output Fields Table 27 on page 324 lists the output fields for the show chassis cluster control-plane
statistics command. Output fields are listed in the approximate order in which they appear.

Table 27: show chassis cluster control-plane statistics Output Fields

Field Name Field Description

Control link statistics Statistics of the control link used by chassis cluster traffic. Statistics for Control link 1 are
displayed when you use dual control links (SRX5000 lines only).

• Heartbeat packets sent—Number of heartbeat messages sent on the control link.

• Heartbeat packets received—Number of heartbeat messages received on the control
link.
• Heartbeat packet errors—Number of heartbeat packets received with errors on the
control link.

Fabric link statistics Statistics of the fabric link used by chassis cluster traffic. Statistics for Child Link 1 are
displayed when you use dual fabric links.

• Probes sent—Number of probes sent on the fabric link.

• Probes received—Number of probes received on the fabric link.

Switch fabric link statistics Statistics of the switch fabric link used by chassis cluster traffic.

• Probe state—State of the probe, UP or DOWN.

• Probes sent—Number of probes sent.
• Probes received—Number of probes received.
• Probe recv error —Error in receiving probe.
• Probe send error—Error in sending probe.

324 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Sample Output
show chassis cluster control-plane statistics
user@host> show chassis cluster control-plane statistics
Control link statistics:
Control link 0:
Heartbeat packets sent: 11646
Heartbeat packets received: 8343
Heartbeat packet errors: 0
Fabric link statistics:
Child link 0
Probes sent: 11644
Probes received: 8266
Switch fabric link statistics:
Probe state : DOWN
Probes sent: 8145
Probes received: 8013
Probe recv errors: 0
Probe send errors: 0

Sample Output
show chassis cluster control-plane statistics (SRX5000 line devices)
user@host> show chassis cluster control-plane statistics
Control link statistics:
Control link 0:
Heartbeat packets sent: 258698
Heartbeat packets received: 258693
Heartbeat packet errors: 0
Control link 1:
Heartbeat packets sent: 258698
Heartbeat packets received: 258693
Heartbeat packet errors: 0
Fabric link statistics:
Child link 0
Probes sent: 258690
Probes received: 258690
Child link 1
Probes sent: 258505
Probes received: 258505

Copyright © 2016, Juniper Networks, Inc. 325

Chassis Cluster Feature Guide for Branch SRX Series Devices

show chassis cluster data-plane interfaces

Supported Platforms SRX Series, vSRX

Syntax show chassis cluster data-plane interfaces

Release Information Command introduced in Junos OS Release 10.2.

Description Display the status of the data plane interface (also known as a fabric interface) in a
chassis cluster configuration.

Required Privilege view

Level

Related • cluster (Chassis) on page 270

Documentation

List of Sample Output show chassis cluster data-plane interfaces on page 326

Output Fields Table 28 on page 326 lists the output fields for the show chassis cluster data-plane
interfaces command. Output fields are listed in the approximate order in which they
appear.

Table 28: show chassis cluster data-plane interfaces Output Fields

Field Name Field Description

fab0/fab1 Name of the logical fabric interface.

• Name—Name of the physical Ethernet interface.

• Status—State of the fabric interface: up or down.

Sample Output
show chassis cluster data-plane interfaces
user@host> show chassis cluster data-plane interfaces
fab0:
Name Status
ge-2/1/9 up
ge-2/2/5 up
fab1:
Name Status
ge-8/1/9 up
ge-8/2/5 up

326 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

show chassis cluster data-plane statistics

Supported Platforms SRX Series, vSRX

Syntax show chassis cluster data-plane statistics

Release Information Command introduced in Junos OS Release 9.3.

Description Display information about chassis cluster data plane statistics.

Required Privilege view

Level

Related • clear chassis cluster data-plane statistics on page 308

Documentation

List of Sample Output show chassis cluster data-plane statistics on page 328

Output Fields Table 29 on page 327 lists the output fields for the show chassis cluster data-plane statistics
command. Output fields are listed in the approximate order in which they appear.

Table 29: show chassis cluster data-plane statistics Output Fields

Field Name Field Description

Services Synchronized • Service name—Name of the service.

• Rtos sent—Number of runtime objects (RTOs) sent.
• Rtos received—Number of RTOs received.
• Translation context—Messages synchronizing Network Address Translation (NAT)
translation context.
• Incoming NAT—Messages synchronizing incoming Network Address Translation (NAT)
service.
• Resource manager—Messages synchronizing resource manager groups and resources.
• Session create—Messages synchronizing session creation.
• Session close—Messages synchronizing session close.
• Session change—Messages synchronizing session change.
• Gate create—Messages synchronizing creation of pinholes (temporary openings in the
firewall).
• Session ageout refresh request—Messages synchronizing request session after age-out.
• Session ageout refresh reply—Messages synchronizing reply session after age-out.
• IPsec VPN—Messages synchronizing VPN session.
• Firewall user authentication—Messages synchronizing firewall user authentication
session.
• MGCP ALG—Messages synchronizing MGCP ALG sessions.
• H323 ALG—Messages synchronizing H.323 ALG sessions.
• SIP ALG—Messages synchronizing SIP ALG sessions.
• SCCP ALG—Messages synchronizing SCCP ALG sessions.
• PPTP ALG—Messages synchronizing PPTP ALG sessions.
• RTSP ALG—Messages synchronizing RTSP ALG sessions.

Copyright © 2016, Juniper Networks, Inc. 327

Chassis Cluster Feature Guide for Branch SRX Series Devices

Sample Output
show chassis cluster data-plane statistics
user@host> show chassis cluster data-plane statistics
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 0 0
Session create 0 0
Session close 0 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPsec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RTSP ALG 0 0

328 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

show chassis cluster ethernet-switching interfaces

Supported Platforms SRX1500, SRX550, vSRX

Syntax show chassis cluster ethernet-switching interfaces

Release Information Command introduced in Junos OS Release 11.1.

Description Display the status of the switch fabric interfaces (swfab) in a chassis cluster.

Required Privilege view

Level

Related • cluster (Chassis) on page 270

Documentation
• Layer 2 Bridging and Transparent Mode for Security Devices

List of Sample Output show chassis cluster ethernet-switching interfaces on page 329

Output Fields Table 30 on page 329 lists the output fields for the show chassis cluster ethernet-switching
interfaces command. Output fields are listed in the approximate order in which they
appear.

Table 30: show chassis cluster ethernet-switching interfaces Output Fields

Field Name Field Description

swfab0/swfab1 Name of the switch fabric interface.

• Name—Name of the physical interface.

• Status—State of the swfab interface: up or down.

Sample Output
show chassis cluster ethernet-switching interfaces
user@host> show chassis cluster ethernet-switching interfaces
swfab0:
Name Status
ge-0/0/9 up
ge-0/0/10 up
swfab1:
Name Status
ge-5/0/9 up
ge-5/0/10 up

Copyright © 2016, Juniper Networks, Inc. 329

Chassis Cluster Feature Guide for Branch SRX Series Devices

show chassis cluster ethernet-switching status

Supported Platforms SRX1500, SRX550, vSRX

Syntax show chassis cluster ethernet-switching status

Release Information Command introduced in Junos OS Release 11.1.

Description Display the Ethernet switching status of the chassis cluster.

Required Privilege view

Level

Related • cluster (Chassis) on page 270

Documentation
• Layer 2 Bridging and Transparent Mode for Security Devices

List of Sample Output show chassis cluster ethernet-switching status on page 331

Output Fields Table 31 on page 330 lists the output fields for the show chassis cluster ethernet-switching
status command. Output fields are listed in the approximate order in which they appear.

Table 31: show chassis cluster ethernet-switching status Output Fields

Field Name Field Description

Cluster ID ID number (1-255) of a cluster. Setting a cluster ID to 0 is equivalent to

disabling a cluster. More than 16 cluster IDs will work only if the fabric and
control link interfaces are connected back-to-back.

NOTE: If you create a cluster with cluster IDs greater than 16, and then
decide to roll back to a previous release image that does not support
extended cluster IDs, the system comes up as standalone.

NOTE: If you have a cluster set up and running with an earlier release of
Junos OS, you can upgrade to Junos OS Release 12.1X45-D10 and re-create
a cluster with cluster IDs greater than 16. However, if for any reason you
decide to revert to the previous version of Junos OS that did not support
extended cluster IDs, the system comes up with standalone devices after
you reboot.

Redundancy-Group ID number (1-255) of a redundancy group in the chassis cluster.

Node name Node (device) in the chassis cluster (node0 or node1).

Priority Assigned priority for the redundancy group on that node.

330 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Table 31: show chassis cluster ethernet-switching status Output Fields

(continued)
Field Name Field Description

Status State of the redundancy group (Primary, Secondary, Lost, or Unavailable).

• Primary—Redundancy group is active and passing traffic.

• Secondary—Redundancy group is passive and not passing traffic.
• Lost—Node loses contact with the other node through the control link.
Most likely to occur when both nodes are in a cluster and due to control
link failure, one node cannot exchange heartbeats, or when the other
node is rebooted.
• Unavailable—Node has not received a single heartbeat over the control
link from the other node since the other node booted up. Most likely to
occur when one node boots up before the other node, or if only one node
is present in the cluster.

Preempt • Yes: Mastership can be preempted based on priority.

• No: Change in priority will not preempt mastership.

Manual failover • Yes: If mastership is set manually through the CLI.

• No: Mastership is not set manually through the CLI.

Sample Output
show chassis cluster ethernet-switching status
user@host> show chassis cluster ethernet-switching status
Cluster ID: 10
Node Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 1

node0 1 primary no no
node1 0 lost n/a n/a

Switch fabric link statistics:

Probe state : DOWN
Probes sent: 8145
Probes received: 8013
Probe recv errors: 0
Probe send errors: 0

Copyright © 2016, Juniper Networks, Inc. 331

Chassis Cluster Feature Guide for Branch SRX Series Devices

show chassis cluster information

Supported Platforms SRX Series, vSRX

Syntax show chassis cluster information

Release Information Command introduced in Junos OS Release 12.1X47-D10.

Description Display chassis cluster messages. The messages indicate each node's health condition
and details of the monitored failure.

Required Privilege view

Level

Related • show chassis cluster status on page 350

Documentation

List of Sample Output show chassis cluster information on page 332

show chassis cluster information on page 333

Output Fields Table 32 on page 332 lists the output fields for the show chassis cluster information
command. Output fields are listed in the approximate order in which they appear.

Table 32: show chassis cluster information Output Fields

Field Name Field Description

Node Node (device) in the chassis cluster (node0 or node1).

Redundancy Group Information • Redundancy Group—ID number (0 - 255) of a redundancy group in the cluster.
• Current State—State of the redundancy group: primary, secondary, hold, or
secondary-hold.
• Weight—Relative importance of the redundancy group.
• Time—Time when the redundancy group changed the state.
• From—State of the redundancy group before the change.
• To—State of the redundancy group after the change.
• Reason—Reason for the change of state of the redundancy group.

Chassis cluster LED information • Current LED color—Current color state of the LED.
• Last LED change reason—Reason for change of state of the LED.

Sample Output
show chassis cluster information
user@host> show chassis cluster information

node0:
--------------------------------------------------------------------------
Redundancy Group Information:

Redundancy Group 0 , Current State: primary, Weight: 255

332 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Time From To Reason

Mar 27 17:44:19 hold secondary Hold timer expired
Mar 27 17:44:27 secondary primary Better priority (200/200)

Redundancy Group 1 , Current State: primary, Weight: 255

Time From To Reason

Mar 27 17:44:19 hold secondary Hold timer expired
Mar 27 17:44:27 secondary primary Remote yield (0/0)

Redundancy Group 2 , Current State: secondary, Weight: 255

Time From To Reason

Mar 27 17:44:19 hold secondary Hold timer expired
Mar 27 17:44:27 secondary primary Remote yield (0/0)
Mar 27 17:50:24 primary secondary-hold Preempt/yield(100/200)
Mar 27 17:50:25 secondary-hold secondary Ready to become secondary

Chassis cluster LED information:

Current LED color: Green
Last LED change reason: No failures

node1:
--------------------------------------------------------------------------
Redundancy Group Information:

Redundancy Group 0 , Current State: secondary, Weight: 255

Time From To Reason

Mar 27 17:44:27 hold secondary Hold timer expired

Redundancy Group 1 , Current State: secondary, Weight: 255

Time From To Reason

Mar 27 17:44:27 hold secondary Hold timer expired
Mar 27 17:50:23 secondary primary Remote yield (100/0)
Mar 27 17:50:24 primary secondary-hold Preempt/yield(100/200)
Mar 27 17:50:25 secondary-hold secondary Ready to become secondary

Redundancy Group 2 , Current State: primary, Weight: 255

Time From To Reason

Mar 27 17:44:27 hold secondary Hold timer expired
Mar 27 17:50:23 secondary primary Remote yield (200/0)

Chassis cluster LED information:

Current LED color: Green
Last LED change reason: No failures

Sample Output
show chassis cluster information
user@host> show chassis cluster information
The following output is specific to monitoring abnormal (unhealthy) case.

node0:
--------------------------------------------------------------------------
Redundancy Group Information:

Copyright © 2016, Juniper Networks, Inc. 333

Chassis Cluster Feature Guide for Branch SRX Series Devices

Redundancy Group 0 , Current State: secondary, Weight: 255

Time From To Reason

Apr 1 11:07:38 hold secondary Hold timer expired
Apr 1 11:07:41 secondary primary Only node present
Apr 1 11:29:20 primary secondary-hold Manual failover
Apr 1 11:34:20 secondary-hold secondary Ready to become secondary

Redundancy Group 1 , Current State: primary, Weight: 0

Time From To Reason

Apr 1 11:07:38 hold secondary Hold timer expired
Apr 1 11:07:41 secondary primary Only node present

Redundancy Group 2 , Current State: primary, Weight: 255

Time From To Reason

Apr 1 11:07:38 hold secondary Hold timer expired
Apr 1 11:07:41 secondary primary Only node present

Chassis cluster LED information:

Current LED color: Amber
Last LED change reason: Monitored objects are down

Failure Information:

IP Monitoring Failure Information:

Redundancy Group 1, Monitoring Status: Failed
IP Address Status Reason
1.1.1.1 Unreachable redundancy-group state unknown

node1:
--------------------------------------------------------------------------
Redundancy Group Information:

Redundancy Group 0 , Current State: primary, Weight: 255

Time From To Reason

Apr 1 11:08:40 hold secondary Hold timer expired
Apr 1 11:29:20 secondary primary Remote is in secondary hold

Redundancy Group 1 , Current State: secondary, Weight: 0

Time From To Reason

Apr 1 11:08:40 hold secondary Hold timer expired

Redundancy Group 2 , Current State: secondary, Weight: 255

Time From To Reason

Apr 1 11:08:40 hold secondary Hold timer expired

Chassis cluster LED information:

Current LED color: Amber
Last LED change reason: Monitored objects are down

Failure Information:

IP Monitoring Failure Information:

Redundancy Group 1, Monitoring Status: Failed

334 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

IP Address Status Reason

1.1.1.1 Unreachable redundancy-group state unknown

Copyright © 2016, Juniper Networks, Inc. 335

Chassis Cluster Feature Guide for Branch SRX Series Devices

show chassis cluster information configuration-synchronization

Supported Platforms SRX Series, vSRX

Syntax show chassis cluster information configuration-synchronization

Release Information Command introduced in Junos OS Release 12.1X47-D10.

Description Display chassis cluster messages. The messages indicate the redundancy mode,
automatic synchronization status, and if automatic synchronization is enabled on the
device.

Required Privilege view

Level

Related • Understanding Automatic Chassis Cluster Synchronization Between Primary and

Documentation Secondary Nodes on page 181

• NTP Time Synchronization on SRX Series Devices on page 183

• Simplifying Network Management by Synchronizing the Primary and Backup Routing

Engines with NTP on page 183

• request chassis cluster configuration-synchronize on page 314

List of Sample Output show chassis cluster information configuration-synchronization on page 336

Output Fields Table 33 on page 336 lists the output fields for the show chassis cluster information
configuration-synchronization command. Output fields are listed in the approximate order
in which they appear.

Table 33: show chassis cluster information configuration-synchronization Output Fields

Field Name Field Description

Node name Node (device) in the chassis cluster (node0 or node1).

Status • Activation status—State of automatic configuration synchronization: Enabled or

Disabled.
• Last sync operation—Status of the last synchronization.
• Last sync result—Result of the last synchronization.
• Last sync mgd messages—Management daemon messages of the last synchronization.

Events The timestamp of the event, the automatic configuration synchronization status, and
the number of synchronization attempts.

Sample Output
show chassis cluster information configuration-synchronization
user@host> show chassis cluster information configuration-synchronization

node0:

336 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

--------------------------------------------------------------------------
Configuration Synchronization:
Status:
Activation status: Enabled
Last sync operation: Auto-Sync
Last sync result: Not needed
Last sync mgd messages:
Events:
Feb 25 22:21:49.174 : Auto-Sync: Not needed
node1:
--------------------------------------------------------------------------
Configuration Synchronization:
Status:
Activation status: Enabled
Last sync operation: Auto-Sync
Last sync result: Succeeded
Last sync mgd messages:
mgd: rcp: /config/juniper.conf: No such file or directory
Network security daemon: warning: You have enabled/disabled inet6 flow.
Network security daemon: You must reboot the system for your change to
take effect.
Network security daemon: If you have deployed a cluster, be sure to reboot
all nodes.
mgd: commit complete
Events:
Feb 25 23:02:33.467 : Auto-Sync: In progress. Attempt: 1
Feb 25 23:03:13.200 : Auto-Sync: Succeeded. Attempt: 1

Copyright © 2016, Juniper Networks, Inc. 337

Chassis Cluster Feature Guide for Branch SRX Series Devices

show chassis cluster interfaces

Supported Platforms SRX Series, vSRX

Syntax show chassis cluster interfaces

Release Information Command modified in Junos OS Release 9.0. Output changed to support dual control
ports in Junos OS Release 10.0. Output changed to support control interfaces in Junos
OS Release 11.2. Output changed to support redundant pseudo interfaces in Junos OS
Release 12.1X44-D10. For high-end SRX Series devices, output changed to support the
internal security association (SA) option in Junos OS Release 12.1X45-D10.

Description Display the status of the control interface in a chassis cluster configuration.

Required Privilege view

Level

Related • cluster (Chassis) on page 270

Documentation

List of Sample Output show chassis cluster interfaces on page 339

show chassis cluster interfaces (SRX5000 line devices) on page 340
show chassis cluster interfaces on page 340
show chassis cluster interfaces(SRX5400, SRX5600, and SRX5800 devices with
SRX5000 line SRX5K-SCB3 (SCB3) with enhanced midplanes and
SRX5K-MPC3-100G10G (IOC3) or SRX5K-MPC3-40G10G (IOC3)) on page 341

Output Fields Table 34 on page 338 lists the output fields for the show chassis cluster interfaces
command. Output fields are listed in the approximate order in which they appear.

Table 34: show chassis cluster interfaces Output Fields

Field Name Field Description

Control link status State of the chassis cluster control interface: up or down.

Control interfaces • Index—Index number of the chassis cluster control interface.

• Name—Name of the chassis cluster control interface.
• Monitored-Status—Monitored state of the interface: up or down.
• Internal SA—State of the internal SA option on the chassis cluster control link: enabled
or disabled.

NOTE: This field is available only on high-end SRX Series devices.

Fabric link status State of the fabric interface: up or down.

Fabric interfaces • Name—Name of the fabric interface.

• Child-interface—Name of the child fabric interface.
• Status—State of the interface: up or down.

338 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Table 34: show chassis cluster interfaces Output Fields (continued)

Field Name Field Description

Redundant-ethernet Information • Name—Name of the redundant Ethernet interface.

• Status—State of the interface: up or down.
• Redundancy-group—Identification number (1–255) of the redundancy group associated
with the redundant Ethernet interface.

Redundant-pseudo-interface • Name—Name of the redundant pseudointerface.

Information • Status—State of the redundant pseudointerface: up or down.
• Redundancy-group—Identification number (1–255) of the redundancy group associated
with the redundant pseudointerface.

Interface Monitoring • Interface—Name of the interface to be monitored.

• Weight—Relative importance of the interface to redundancy group operation.
• Status—State of the interface: up or down.
• Redundancy-group—Identification number of the redundancy group associated with
the interface.

Sample Output
show chassis cluster interfaces
user@host> show chassis cluster interfaces
Control link status: Up

Control interfaces:
Index Interface Monitored-Status
0 em0 Up
1 em1 Down

Fabric link status: Up

Fabric interfaces:
Name Child-interface Status
fab0 ge-0/1/0 Up
fab0
fab1 ge-6/1/0 Up
fab1

Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
reth1 Up 2
reth2 Down Not configured
reth3 Down Not configured
reth4 Down Not configured
reth5 Down Not configured
reth6 Down Not configured
reth7 Down Not configured
reth8 Down Not configured
reth9 Down Not configured
reth10 Down Not configured
reth11 Down Not configured

Redundant-pseudo-interface Information:

Copyright © 2016, Juniper Networks, Inc. 339

Chassis Cluster Feature Guide for Branch SRX Series Devices

Name Status Redundancy-group

lo0 Up 1

Interface Monitoring:
Interface Weight Status Redundancy-group
ge-0/1/9 100 Up 0
ge-0/1/9 100 Up

Sample Output
show chassis cluster interfaces (SRX5000 line devices)
user@host> show chassis cluster interfaces
Control link status: Up

Control interfaces:
Index Interface Monitored-Status Internal SA
0 em0 Up enabled
1 em1 Down enabled

Fabric link status: Up

Fabric interfaces:
Name Child-interface Status
fab0 ge-0/1/0 Up
fab0
fab1 ge-6/1/0 Up
fab1

Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
reth1 Up 2
reth2 Down Not configured
reth3 Down Not configured
reth4 Down Not configured
reth5 Down Not configured
reth6 Down Not configured
reth7 Down Not configured
reth8 Down Not configured
reth9 Down Not configured
reth10 Down Not configured
reth11 Down Not configured

Redundant-pseudo-interface Information:
Name Status Redundancy-group
lo0 Up 1

Interface Monitoring:
Interface Weight Status Redundancy-group
ge-0/1/9 100 Up 0
ge-0/1/9 100 Up

Sample Output
show chassis cluster interfaces
user@host> show chassis cluster interfaces
The following output is specific to fabric monitoring failure:

340 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Control link status: Up

Control interfaces:
Index Interface Monitored-Status Internal-SA
0 fxp1 Up Disabled

Fabric link status: Down

Fabric interfaces:
Name Child-interface Status
(Physical/Monitored)
fab0 ge-0/0/2 Down / Down
fab0
fab1 ge-9/0/2 Up / Up
fab1

Redundant-pseudo-interface Information:
Name Status Redundancy-group
lo0 Up 0

Sample Output
show chassis cluster interfaces
(SRX5400, SRX5600, and SRX5800 devices with SRX5000 line SRX5K-SCB3 (SCB3) with enhanced midplanes
and SRX5K-MPC3-100G10G (IOC3) or SRX5K-MPC3-40G10G (IOC3))
user@host> show chassis cluster interfaces
The following output is specific to SRX5400, SRX5600, and SRX5800 devices in a
chassis cluster cluster, when the PICs containing fabric links on the SRX5K-MPC3-40G10G
(IOC3) are powered off to turn on alternate PICs. If no alternate fabric links are configured
on the PICs that are turned on, RTO synchronous communication between the two nodes
stops and the chassis cluster session state will not back up, because the fabric link is
missing.

Control link status: Up

Control interfaces:
Index Interface Monitored-Status Internal-SA
0 em0 Up Disabled
1 em1 Down Disabled

Fabric link status: Down

Fabric interfaces:
Name Child-interface Status
(Physical/Monitored)
fab0 <<< fab child missing once PIC off
lined
fab0
fab1 xe-10/2/7 Up / Down
fab1

Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up Not configured
reth1 Down 1

Copyright © 2016, Juniper Networks, Inc. 341

Chassis Cluster Feature Guide for Branch SRX Series Devices

Redundant-pseudo-interface Information:
Name Status Redundancy-group
lo0 Up 0

342 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

show chassis cluster ip-monitoring status redundancy-group

Supported Platforms SRX Series, vSRX

Syntax show chassis cluster ip-monitoring status

<redundancy-group group-number>

Release Information Command introduced in Junos OS Release 9.6. Support for global threshold, current
threshold, and weight of each monitored IP address added in Junos OS Release
12.1X47-D10.

Description Display the status of all monitored IP addresses for a redundancy group.

Options • none— Display the status of monitored IP addresses for all redundancy groups on the
node.

• redundancy-group group-number — Display the status of monitored IP addresses under

the specified redundancy group.

Required Privilege view

Level

Related • redundancy-group (Interfaces)

Documentation
• clear chassis cluster failover-count on page 309

• request chassis cluster failover node on page 315

• request chassis cluster failover reset on page 317

List of Sample Output show chassis cluster ip-monitoring status on page 344
show chassis cluster ip-monitoring status redundancy-group on page 345

Output Fields Table 35 on page 343 lists the output fields for the show chassis cluster ip-monitoring
status command.

Table 35: show chassis cluster ip-monitoring status Output Fields

Field Name Field Description

Redundancy-group ID number (0 - 255) of a redundancy group in the cluster.

Global threshold Failover value for all IP addresses monitored by the redundancy group.

Current threshold Value equal to the global threshold minus the total weight of the unreachable IP address.

IP Address Monitored IP address in the redundancy group.

Status Current reachability state of the monitored IP address.

Values for this field are: reachable, unreachable, and unknown. The status is “unknown”
if Packet Forwarding Engines (PFEs) are not yet up and running.

Copyright © 2016, Juniper Networks, Inc. 343

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 35: show chassis cluster ip-monitoring status Output Fields (continued)
Field Name Field Description

Failure count Number of attempts to reach an IP address.

Reason Explanation for the reported status. See Table 36 on page 344.

Weight Combined weight (0 - 255) assigned to all monitored IP addresses. A higher weight value
indicates greater importance.

Expanded reason output fields for unreachable IP addresses added in Junos OS Release
10.1. You might see any of the following reasons displayed.

Table 36: show chassis cluster ip-monitoring status redundancy group Reason Fields
Reason Reason Description

No route to host The router could not resolve the ARP, which is needed to send the ICMP packet to the
host with the monitored IP address.

No auxiliary IP found The redundant Ethernet interface does not have an auxiliary IP address configured.

Reth child not up A child interface of a redundant Ethernet interface is down.

redundancy-group state unknown Unable to obtain the state (primary, secondary, secondary-hold, disable) of a
redundancy-group.

No reth child MAC address Could not extract the MAC address of the redundant Ethernet child interface.

Secondary link not monitored The secondary link might be down (the secondary child interface of a redundant Ethernet
interface is either down or non-functional).

Unknown The IP address has just been configured and the router still does not know the status of
this IP.

or

Do not know the exact reason for the failure.

Sample Output
show chassis cluster ip-monitoring status
user@host> show chassis cluster ip-monitoring status
node0:
--------------------------------------------------------------------------

Redundancy group: 1
Global threshold: 200
Current threshold: -120

IP address Status Failure count Reason Weight

10.254.5.44 reachable 0 n/a 220
2.2.2.1 reachable 0 n/a 100

344 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

node1:
--------------------------------------------------------------------------

Redundancy group: 1
Global threshold: 200
Current threshold: -120

IP address Status Failure count Reason Weight

10.254.5.44 reachable 0 n/a 220
2.2.2.1 reachable 0 n/a 100

Sample Output
show chassis cluster ip-monitoring status redundancy-group
user@host> show chassis cluster ip-monitoring status redundancy-group 1
node0:
--------------------------------------------------------------------------

Redundancy group: 1

IP address Status Failure count Reason

10.254.5.44 reachable 0 n/a
2.2.2.1 reachable 0 n/a
1.1.1.5 reachable 0 n/a
1.1.1.4 reachable 0 n/a
1.1.1.1 reachable 0 n/a

node1:
--------------------------------------------------------------------------

Redundancy group: 1

IP address Status Failure count Reason

10.254.5.44 reachable 0 n/a
2.2.2.1 reachable 0 n/a
1.1.1.5 reachable 0 n/a
1.1.1.4 reachable 0 n/a
1.1.1.1 reachable 0 n/a

Copyright © 2016, Juniper Networks, Inc. 345

Chassis Cluster Feature Guide for Branch SRX Series Devices

show chassis cluster statistics

Supported Platforms SRX Series, vSRX

Syntax show chassis cluster statistics

Release Information Command modified in Junos OS Release 9.0. Output changed to support dual control
ports in Junos OS Release 10.0.

Description Display information about chassis cluster services and interfaces.

Required Privilege view

Level

Related • clear chassis cluster statistics on page 313

Documentation

List of Sample Output show chassis cluster statistics on page 347

show chassis cluster statistics (SRX5000 line devices) on page 348
show chassis cluster statistics (SRX5000 line devices) on page 349

Output Fields Table 37 on page 346 lists the output fields for the show chassis cluster statistics command.
Output fields are listed in the approximate order in which they appear.

Table 37: show chassis cluster statistics Output Fields

Field Name Field Description

Control link statistics Statistics of the control link used by chassis cluster traffic. Statistics for Control link 1 are
displayed when you use dual control links (SRX5000 lines only). Note that the output
for the SRX5000 lines will always show Control link 0 and Control link 1 statistics, even
though only one control link is active or working.

• Heartbeat packets sent—Number of heartbeat messages sent on the control link.

• Heartbeat packets received—Number of heartbeat messages received on the control
link.
• Heartbeat packet errors—Number of heartbeat packets received with errors on the
control link.

Fabric link statistics Statistics of the fabric link used by chassis cluster traffic. Statistics for Child Link 1 are
displayed when you use dual fabric links.

• Probes sent—Number of probes sent on the fabric link.

• Probes received—Number of probes received on the fabric link.

346 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Table 37: show chassis cluster statistics Output Fields (continued)

Field Name Field Description

Services Synchronized • Service name—Name of the service.

• Rtos sent—Number of runtime objects (RTOs) sent.
• Rtos received—Number of RTOs received.
• Translation context—Messages synchronizing Network Address Translation (NAT)
translation context.
• Incoming NAT—Messages synchronizing incoming Network Address Translation (NAT)
service.
• Resource manager—Messages synchronizing resource manager groups and resources.
• Session create—Messages synchronizing session creation.
• Session close—Messages synchronizing session close.
• Session change—Messages synchronizing session change.
• Gate create—Messages synchronizing creation of pinholes (temporary openings in the
firewall).
• Session ageout refresh request—Messages synchronizing request session after age-out.
• Session ageout refresh reply—Messages synchronizing reply session after age-out.
• IPsec VPN—Messages synchronizing VPN session.
• Firewall user authentication—Messages synchronizing firewall user authentication
session.
• MGCP ALG—Messages synchronizing MGCP ALG sessions.
• H323 ALG—Messages synchronizing H.323 ALG sessions.
• SIP ALG—Messages synchronizing SIP ALG sessions.
• SCCP ALG—Messages synchronizing SCCP ALG sessions.
• PPTP ALG—Messages synchronizing PPTP ALG sessions.
• RTSP ALG—Messages synchronizing RTSP ALG sessions.
• MAC address learning—Messages synchronizing MAC address learning.

Sample Output
show chassis cluster statistics
user@host> show chassis cluster statistics
Control link statistics:
Control link 0:
Heartbeat packets sent: 798
Heartbeat packets received: 784
Heartbeat packets errors: 0
Fabric link statistics:
Child link 0
Probes sent: 793
Probes received: 0
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 0 0
Session create 0 0
Session close 0 0
Session change 0 0
Gate create 0 0

Copyright © 2016, Juniper Networks, Inc. 347

Chassis Cluster Feature Guide for Branch SRX Series Devices

Session ageout refresh requests 0 0

Session ageout refresh replies 0 0
IPsec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RTSP ALG 0 0
MAC address learning 0 0

Sample Output
show chassis cluster statistics (SRX5000 line devices)
user@host> show chassis cluster statistics
Control link statistics:
Control link 0:
Heartbeat packets sent: 258689
Heartbeat packets received: 258684
Heartbeat packets errors: 0
Control link 1:
Heartbeat packets sent: 258689
Heartbeat packets received: 258684
Heartbeat packets errors: 0
Fabric link statistics:
Child link 0
Probes sent: 258681
Probes received: 258681
Child link 1
Probes sent: 258501
Probes received: 258501
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 0 0
Session create 1 0
Session close 1 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0
GPRS GTP 0 0

348 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Sample Output
show chassis cluster statistics (SRX5000 line devices)
user@host> show chassis cluster statistics
Control link statistics:
Control link 0:
Heartbeat packets sent: 82371
Heartbeat packets received: 82321
Heartbeat packets errors: 0
Control link 1:
Heartbeat packets sent: 0
Heartbeat packets received: 0
Heartbeat packets errors: 0
Fabric link statistics:
Child link 0
Probes sent: 258681
Probes received: 258681
Child link 1
Probes sent: 258501
Probes received: 258501
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 0 0
Session create 1 0
Session close 1 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0
GPRS GTP 0 0

Copyright © 2016, Juniper Networks, Inc. 349

Chassis Cluster Feature Guide for Branch SRX Series Devices

show chassis cluster status

Supported Platforms SRX Series, vSRX

Syntax show chassis cluster status

<redundancy-group group-number >

Release Information Command modified in Junos OS Release 9.2. Support for dual control ports added in
Junos OS Release 10.0. Support for monitoring failures added in Junos OS Release
12.1X47-D10.

Description Display the failover status of a chassis cluster.

Options • none—Display the status of all redundancy groups in the chassis cluster.

• redundancy-group group-number —(Optional) Display the status of the specified

redundancy group.

Required Privilege view

Level

Related • redundancy-group (Chassis Cluster) on page 290

Documentation
• clear chassis cluster failover-count on page 309

• request chassis cluster failover node on page 315

• request chassis cluster failover reset on page 317

List of Sample Output show chassis cluster status on page 351

show chassis cluster status redundancy-group 1 on page 352

Output Fields Table 38 on page 350 lists the output fields for the show chassis cluster status command.
Output fields are listed in the approximate order in which they appear.

Table 38: show chassis cluster status Output Fields

Field Name Field Description

Cluster ID ID number (1-15) of a cluster is applicable for releases upto 12.1X45-D10. ID number
(1-255) is applicable for releases 12.1X45-D10 and later. Setting a cluster ID to 0 is
equivalent to disabling a cluster.

Redundancy-Group ID number (1-128) of a redundancy group in the chassis cluster.

Node name Node (device) in the chassis cluster (node0 or node1).

Priority Assigned priority for the redundancy group on that node.

350 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Table 38: show chassis cluster status Output Fields (continued)

Field Name Field Description

Status State of the redundancy group (Primary, Secondary, Lost, or Unavailable).

• Primary—Redundancy group is active and passing traffic.

• Secondary—Redundancy group is passive and not passing traffic.
• Lost—Node loses contact with the other node through the control link. Most likely to
occur when both nodes are in a cluster and due to control link failure, one node cannot
exchange heartbeats, or when the other node is rebooted.
• Unavailable—Node has not received a single heartbeat over the control link from the
other node since the other node booted up. Most likely to occur when one node boots
up before the other node, or if only one node is present in the cluster.

Preempt • Yes: Mastership can be preempted based on priority.

• No: Change in priority will not preempt the mastership.

Manual failover • Yes: If the Mastership is set manually through the CLI with the request chassis cluster
failover node or request chassis cluster failover redundancy-group command. This
overrides Priority and Preempt.
• No: Mastership is not set manually through the CLI.

Monitor-failures • None: Cluster working properly.

• Monitor Failure code: Cluster is not working properly and the respective failure code is
displayed.

Sample Output
Displays chassis cluster status with all redundancy groups.

show chassis cluster status

user@host> show chassis cluster status

Monitor Failure codes:

CS Cold Sync monitoring FL Fabric Connection monitoring
GR GRES monitoring HW Hardware monitoring
IF Interface monitoring IP IP monitoring
LB Loopback monitoring MB Mbuf monitoring
NH Nexthop monitoring NP NPC monitoring
SP SPU monitoring SM Schedule monitoring
CF Config Sync monitoring

Cluster ID: 1
Node Priority Status Preempt Manual Monitor-failures

Redundancy group: 0 , Failover count: 1

node0 200 primary no no None
node1 1 secondary no no None

Redundancy group: 1 , Failover count: 1

node0 101 primary no no None
node1 1 secondary no no None

Copyright © 2016, Juniper Networks, Inc. 351

Chassis Cluster Feature Guide for Branch SRX Series Devices

Sample Output
Displays chassis cluster status with redundancy group 1 only.

show chassis cluster status redundancy-group 1

user@host> show chassis cluster status redundancy-group 1

Monitor Failure codes:

CS Cold Sync monitoring FL Fabric Connection monitoring
GR GRES monitoring HW Hardware monitoring
IF Interface monitoring IP IP monitoring
LB Loopback monitoring MB Mbuf monitoring
NH Nexthop monitoring NP NPC monitoring
SP SPU monitoring SM Schedule monitoring
CF Config Sync monitoring

Cluster ID: 1
Node Priority Status Preempt Manual Monitor-failures

Redundancy group: 1 , Failover count: 1

node0 101 primary no no None
node1 1 secondary no no None

352 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

show chassis environment (Security)

Supported Platforms SRX Series, vSRX

Syntax show chassis environment

Release Information Command introduced in Junos OS Release 9.2.

Description Display environmental information about the services gateway chassis, including the
temperature and information about the fans, power supplies, and Routing Engine.

Options none—Display environmental information about the device.

cb slot-number—Display chassis environmental information for the Control Board.

fpc fpc-slot—Display chassis environmental information for a specified Flexible PIC

Concentrator.

fpm—Display chassis environmental information for the craft interface (FPM).

pem slot-number—Display chassis environmental information for the specified Power

Entry Module.

routing-engine slot-number—Display chassis environmental information for the specified

Routing Engine.

Required Privilege view

Level

Related • show chassis hardware (View) on page 372

Documentation

List of Sample Output show chassis environment on page 353

Output Fields Table 39 on page 353 lists the output fields for the show chassis environment command.
Output fields are listed in the approximate order in which they appear.

Table 39: show chassis environment Output Fields

Field Name Field Description

Temp Temperature of air flowing through the chassis in degrees Celsius (C) and Fahrenheit (F).

Fan Fan status: OK, Testing (during initial power-on), Failed, or Absent.

Sample Output
show chassis environment
user@host> show chassis environment
user@host> show chassis environment
Class Item Status Measurement
Temp PEM 0 OK 40 degrees C / 104 degrees F

Copyright © 2016, Juniper Networks, Inc. 353

Chassis Cluster Feature Guide for Branch SRX Series Devices

PEM 1 OK 40 degrees C / 104 degrees F

PEM 2 OK 40 degrees C / 104 degrees F
PEM 3 OK 45 degrees C / 113 degrees F
Routing Engine 0 OK 31 degrees C / 87 degrees F
Routing Engine 0 CPU OK 27 degrees C / 80 degrees F
Routing Engine 1 Absent
Routing Engine 1 CPU Absent
CB 0 Intake OK 28 degrees C / 82 degrees F
CB 0 Exhaust A OK 27 degrees C / 80 degrees F
CB 0 Exhaust B OK 29 degrees C / 84 degrees F
CB 0 ACBC OK 29 degrees C / 84 degrees F
CB 0 SF A OK 36 degrees C / 96 degrees F
CB 0 SF B OK 31 degrees C / 87 degrees F
CB 1 Intake OK 27 degrees C / 80 degrees F
CB 1 Exhaust A OK 26 degrees C / 78 degrees F
CB 1 Exhaust B OK 29 degrees C / 84 degrees F
CB 1 ACBC OK 27 degrees C / 80 degrees F
CB 1 SF A OK 36 degrees C / 96 degrees F
CB 1 SF B OK 31 degrees C / 87 degrees F
CB 2 Intake Absent
CB 2 Exhaust A Absent
CB 2 Exhaust B Absent
CB 2 ACBC Absent
CB 2 XF A Absent
CB 2 XF B Absent
FPC 0 Intake OK 47 degrees C / 116 degrees F
FPC 0 Exhaust A OK 44 degrees C / 111 degrees F
FPC 0 Exhaust B OK 52 degrees C / 125 degrees F
FPC 0 xlp0 TSen OK 51 degrees C / 123 degrees F
FPC 0 xlp0 Chip OK 46 degrees C / 114 degrees F
FPC 0 xlp1 TSen OK 51 degrees C / 123 degrees F
FPC 0 xlp1 Chip OK 47 degrees C / 116 degrees F
FPC 0 xlp2 TSen OK 44 degrees C / 111 degrees F
FPC 0 xlp2 Chip OK 42 degrees C / 107 degrees F
FPC 0 xlp3 TSen OK 48 degrees C / 118 degrees F
FPC 0 xlp3 Chip OK 43 degrees C / 109 degrees F
FPC 1 Intake OK 41 degrees C / 105 degrees F
FPC 1 Exhaust A OK 41 degrees C / 105 degrees F
FPC 1 Exhaust B OK 51 degrees C / 123 degrees F
FPC 1 LU TSen OK 46 degrees C / 114 degrees F
FPC 1 LU Chip OK 45 degrees C / 113 degrees F
FPC 1 XM TSen OK 46 degrees C / 114 degrees F
FPC 1 XM Chip OK 52 degrees C / 125 degrees F
FPC 1 xlp0 TSen OK 49 degrees C / 120 degrees F
FPC 1 xlp0 Chip OK 42 degrees C / 107 degrees F
FPC 1 xlp1 TSen OK 49 degrees C / 120 degrees F
FPC 1 xlp1 Chip OK 44 degrees C / 111 degrees F
FPC 1 xlp2 TSen OK 38 degrees C / 100 degrees F
FPC 1 xlp2 Chip OK 39 degrees C / 102 degrees F
FPC 1 xlp3 TSen OK 44 degrees C / 111 degrees F
FPC 1 xlp3 Chip OK 42 degrees C / 107 degrees F
FPC 2 Intake OK 29 degrees C / 84 degrees F
FPC 2 Exhaust A OK 34 degrees C / 93 degrees F
FPC 2 Exhaust B OK 40 degrees C / 104 degrees F
FPC 2 I3 0 TSensor OK 42 degrees C / 107 degrees F
FPC 2 I3 0 Chip OK 41 degrees C / 105 degrees F
FPC 2 I3 1 TSensor OK 40 degrees C / 104 degrees F
FPC 2 I3 1 Chip OK 39 degrees C / 102 degrees F
FPC 2 I3 2 TSensor OK 38 degrees C / 100 degrees F
FPC 2 I3 2 Chip OK 37 degrees C / 98 degrees F
FPC 2 I3 3 TSensor OK 35 degrees C / 95 degrees F

354 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

FPC 2 I3 3 Chip OK 35 degrees C / 95 degrees F

FPC 2 IA 0 TSensor OK 45 degrees C / 113 degrees F
FPC 2 IA 0 Chip OK 42 degrees C / 107 degrees F
FPC 2 IA 1 TSensor OK 41 degrees C / 105 degrees F
FPC 2 IA 1 Chip OK 43 degrees C / 109 degrees F
FPC 9 Intake OK 29 degrees C / 84 degrees F
FPC 9 Exhaust A OK 41 degrees C / 105 degrees F
FPC 9 Exhaust B OK 48 degrees C / 118 degrees F
FPC 9 LU TSen OK 48 degrees C / 118 degrees F
FPC 9 LU Chip OK 47 degrees C / 116 degrees F
FPC 9 XM TSen OK 48 degrees C / 118 degrees F
FPC 9 XM Chip OK 54 degrees C / 129 degrees F
FPC 9 xlp0 TSen OK 45 degrees C / 113 degrees F
FPC 9 xlp0 Chip OK 42 degrees C / 107 degrees F
FPC 9 xlp1 TSen OK 49 degrees C / 120 degrees F
FPC 9 xlp1 Chip OK 46 degrees C / 114 degrees F
FPC 9 xlp2 TSen OK 37 degrees C / 98 degrees F
FPC 9 xlp2 Chip OK 40 degrees C / 104 degrees F
FPC 9 xlp3 TSen OK 45 degrees C / 113 degrees F
FPC 9 xlp3 Chip OK 41 degrees C / 105 degrees F
FPC 10 Intake OK 32 degrees C / 89 degrees F
FPC 10 Exhaust A OK 44 degrees C / 111 degrees F
FPC 10 Exhaust B OK 53 degrees C / 127 degrees F
FPC 10 LU 0 TSen OK 43 degrees C / 109 degrees F
FPC 10 LU 0 Chip OK 52 degrees C / 125 degrees F
FPC 10 LU 1 TSen OK 43 degrees C / 109 degrees F
FPC 10 LU 1 Chip OK 44 degrees C / 111 degrees F
FPC 10 LU 2 TSen OK 43 degrees C / 109 degrees F
FPC 10 LU 2 Chip OK 50 degrees C / 122 degrees F
FPC 10 LU 3 TSen OK 43 degrees C / 109 degrees F
FPC 10 LU 3 Chip OK 58 degrees C / 136 degrees F
FPC 10 XM 0 TSen OK 43 degrees C / 109 degrees F
FPC 10 XM 0 Chip OK 53 degrees C / 127 degrees F
FPC 10 XF 0 TSen OK 43 degrees C / 109 degrees F
FPC 10 XF 0 Chip OK 64 degrees C / 147 degrees F
FPC 10 PLX Switch TSen OK 43 degrees C / 109 degrees F
FPC 10 PLX Switch Chip OK 44 degrees C / 111 degrees F
FPC 11 Intake OK 32 degrees C / 89 degrees F
FPC 11 Exhaust A OK 41 degrees C / 105 degrees F
FPC 11 Exhaust B OK 56 degrees C / 132 degrees F
FPC 11 LU 0 TSen OK 45 degrees C / 113 degrees F
FPC 11 LU 0 Chip OK 50 degrees C / 122 degrees F
FPC 11 LU 1 TSen OK 45 degrees C / 113 degrees F
FPC 11 LU 1 Chip OK 47 degrees C / 116 degrees F
FPC 11 LU 2 TSen OK 45 degrees C / 113 degrees F
FPC 11 LU 2 Chip OK 52 degrees C / 125 degrees F
FPC 11 LU 3 TSen OK 45 degrees C / 113 degrees F
FPC 11 LU 3 Chip OK 60 degrees C / 140 degrees F
FPC 11 XM 0 TSen OK 45 degrees C / 113 degrees F
FPC 11 XM 0 Chip OK 56 degrees C / 132 degrees F
FPC 11 XF 0 TSen OK 45 degrees C / 113 degrees F
FPC 11 XF 0 Chip OK 65 degrees C / 149 degrees F
FPC 11 PLX Switch TSen OK 45 degrees C / 113 degrees F
FPC 11 PLX Switch Chip OK 46 degrees C / 114 degrees F
Fans Top Fan Tray Temp OK 34 degrees C / 93 degrees F
Top Tray Fan 1 OK Spinning at normal speed
Top Tray Fan 2 OK Spinning at normal speed
Top Tray Fan 3 OK Spinning at normal speed
Top Tray Fan 4 OK Spinning at normal speed
Top Tray Fan 5 OK Spinning at normal speed
Top Tray Fan 6 OK Spinning at normal speed

Copyright © 2016, Juniper Networks, Inc. 355

Chassis Cluster Feature Guide for Branch SRX Series Devices

Top Tray Fan 7 OK Spinning at normal speed

Top Tray Fan 8 OK Spinning at normal speed
Top Tray Fan 9 OK Spinning at normal speed
Top Tray Fan 10 OK Spinning at normal speed
Top Tray Fan 11 OK Spinning at normal speed
Top Tray Fan 12 OK Spinning at normal speed
Bottom Fan Tray Temp OK 31 degrees C / 87 degrees F
Bottom Tray Fan 1 OK Spinning at normal speed
Bottom Tray Fan 2 OK Spinning at normal speed
Bottom Tray Fan 3 OK Spinning at normal speed
Bottom Tray Fan 4 OK Spinning at normal speed
Bottom Tray Fan 5 OK Spinning at normal speed
Bottom Tray Fan 6 OK Spinning at normal speed
Bottom Tray Fan 7 OK Spinning at normal speed
Bottom Tray Fan 8 OK Spinning at normal speed
Bottom Tray Fan 9 OK Spinning at normal speed
Bottom Tray Fan 10 OK Spinning at normal speed
Bottom Tray Fan 11 OK Spinning at normal speed
Bottom Tray Fan 12 OK Spinning at normal speed
OK

356 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

show chassis ethernet-switch

Supported Platforms SRX Series, vSRX

Syntax show chassis ethernet-switch

Release Information Command introduced in Junos OS Release 9.2.

Description SRX Series devices display information about the ports on the Control Board (CB) Ethernet
switch.

Required Privilege view

Level

Related • cluster (Chassis) on page 270

Documentation

List of Sample Output show chassis ethernet-switch on page 357

Output Fields Table 40 on page 357 lists the output fields for the show chassis ethernet-switch command.
Output fields are listed in the approximate order in which they appear.

Table 40: show chassis ethernet-switch Output Fields

Field Name Field Description

Link is good on port n Information about the link between each port on the CB's Ethernet switch and one of the following
connected to device devices:

or • FPC0 (Flexible PIC Concentrator 0) through FPC7

• Local controller
Link is good on Fast
• Routing Engine
Ethernet port n
connected to device • Other Routing Engine (on a system with two Routing Engines)
• SPMB (Switch Processor Mezzanine Board)

Speed is Speed at which the Ethernet link is running.

Duplex is Duplex type of the Ethernet link: full or half.

Autonegotiate is By default, built-in Fast Ethernet ports on a PIC autonegotiate whether to operate at 10 Mbps or 100
Enabled (or Disabled) Mbps. All other interfaces automatically choose the correct speed based on the PIC type and whether
the PIC is configured to operate in multiplexed mode.

Sample Output
show chassis ethernet-switch
user@host> show chassis ethernet-switch
node0:
--------------------------------------------------------------------------
Displaying summary for switch 0
Link is good on GE port 0 connected to device: FPC0
Speed is 1000Mb
Duplex is full

Copyright © 2016, Juniper Networks, Inc. 357

Chassis Cluster Feature Guide for Branch SRX Series Devices

Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is good on GE port 1 connected to device: FPC1

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is good on GE port 2 connected to device: FPC2

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is good on GE port 3 connected to device: FPC3

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is good on GE port 4 connected to device: FPC4

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is down on GE port 5 connected to device: FPC5

Link is down on GE port 6 connected to device: FPC6

Link is good on GE port 7 connected to device: FPC7

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is good on GE port 8 connected to device: FPC8

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is good on GE port 9 connected to device: FPC9

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is down on GE port 10 connected to device: FPC10

Link is down on GE port 11 connected to device: FPC11

358 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Link is good on GE port 12 connected to device: Other RE

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is good on GE port 13 connected to device: RE-GigE

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is down on GE port 14 connected to device: Debug-GigE

node1:
--------------------------------------------------------------------------
Displaying summary for switch 0
Link is good on GE port 0 connected to device: FPC0
Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is good on GE port 1 connected to device: FPC1

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is good on GE port 2 connected to device: FPC2

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is good on GE port 3 connected to device: FPC3

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is good on GE port 4 connected to device: FPC4

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is down on GE port 5 connected to device: FPC5

Link is down on GE port 6 connected to device: FPC6

Link is good on GE port 7 connected to device: FPC7

Speed is 1000Mb
Duplex is full

Copyright © 2016, Juniper Networks, Inc. 359

Chassis Cluster Feature Guide for Branch SRX Series Devices

Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is good on GE port 8 connected to device: FPC8

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is good on GE port 9 connected to device: FPC9

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is down on GE port 10 connected to device: FPC10

Link is down on GE port 11 connected to device: FPC11

Link is good on GE port 12 connected to device: Other RE

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is good on GE port 13 connected to device: RE-GigE

Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled

Link is down on GE port 14 connected to device: Debug-GigE

360 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

show chassis fabric plane

Supported Platforms SRX Series, vSRX

Syntax show chassis fabric plane

Release Information Command introduced in Junos OS Release 9.2.

Description Show state of fabric management plane.

Required Privilege view

Level

Related • show chassis fabric plane-location on page 367

Documentation

List of Sample Output show chassis fabric plane(SRX5600 and SRX5800 devices with SRX5000 line SCB
II (SRX5K-SCBE) and SRX5K-RE-1800X4) on page 362

Output Fields Table 41 on page 361 lists the output fields for the show chassis fabric plane command.
Output fields are listed in the approximate order in which they appear.

Table 41: show chassis fabric plane Output Fields

Field Name Field Description Level of output

Plane Number of the plane. none

Plane state State of each plane: none

• ACTIVE—SIB is operational and running.

• FAULTY— SIB is in alarmed state where the SIB’s plane is not
operational for the following reasons:
• On-board fabric ASIC is not operational.
• Fiber-optic connector faults.
• FPC connector faults.
• SIB midplane connector faults.

FPC Slot number of each Flexible PIC Concentrator (FPC). none

PFE Slot number of each Packet Forwarding Engine and the state of the none
links to the FPC:

• Links ok: Link between SIB and FPC is active.

• Link error: Link between SIB and FPC is not operational.
• Unused: No FPC is present.

Copyright © 2016, Juniper Networks, Inc. 361

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 41: show chassis fabric plane Output Fields (continued)

Field Name Field Description Level of output

State State of the fabric plane: none

• Online: Fabric plane is operational and running and links on the

SIB are operational.
• Offline: Fabric plane state is Offline because the plane does not
have four or more F2S and one F13 online.
• Empty: Fabric plane state is Empty if all SIBs in the plane are
absent.
• Spare: Fabric plane is redundant and can be operational if the
operational fabric plane encounters an error.
• Check: Fabric plane is in alarmed state due to the following reason
and the cause of the error must be resolved:
• One or more SIBs (belonging to the fabric plane) in the Online
or Spare states has transitioned to the Check state.
Check state of the SIB can be caused by link errors or
destination errors.

• Fault: Fabric plane is in alarmed state if one or more SIBs

belonging to the plane are in the Fault state. A SIB can be in the
Fault state because of the following reasons:
• On-board fabric ASIC is not operational.
• Fiber-optic connector faults.
• FPC connector faults.
• SIB midplane connector faults.
• Link errors have exceeded the threshold.

Sample Output
show chassis fabric plane
(SRX5600 and SRX5800 devices with SRX5000 line SCB II (SRX5K-SCBE) and SRX5K-RE-1800X4)
user@host> show chassis fabric plane
node0:
--------------------------------------------------------------------------
Fabric management PLANE state
Plane 0
Plane state: ACTIVE
FPC 0
PFE 0 :Links ok
FPC 2
PFE 0 :Links ok
FPC 3
PFE 0 :Links ok
FPC 4
PFE 0 :Links ok
FPC 7
PFE 0 :Links ok
FPC 8
PFE 0 :Links ok
FPC 9
PFE 0 :Links ok
FPC 10
PFE 0 :Links ok

362 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Plane 1
Plane state: ACTIVE
FPC 0
PFE 0 :Links ok
FPC 2
PFE 0 :Links ok
FPC 3
PFE 0 :Links ok
FPC 4
PFE 0 :Links ok
FPC 7
PFE 0 :Links ok
FPC 8
PFE 0 :Links ok
FPC 9
PFE 0 :Links ok
FPC 10
PFE 0 :Links ok
Plane 2
Plane state: ACTIVE
FPC 0
PFE 0 :Links ok
FPC 2
PFE 0 :Links ok
FPC 3
PFE 0 :Links ok
FPC 4
PFE 0 :Links ok
FPC 7
PFE 0 :Links ok
FPC 8
PFE 0 :Links ok
FPC 9
PFE 0 :Links ok
FPC 10
PFE 0 :Links ok
Plane 3
Plane state: ACTIVE
FPC 0
PFE 0 :Links ok
FPC 2
PFE 0 :Links ok
FPC 3
PFE 0 :Links ok
FPC 4
PFE 0 :Links ok
FPC 7
PFE 0 :Links ok
FPC 8
PFE 0 :Links ok
FPC 9
PFE 0 :Links ok
FPC 10
PFE 0 :Links ok
Plane 4
Plane state: SPARE
FPC 0
PFE 0 :Links ok
FPC 2
PFE 0 :Links ok
FPC 3

Copyright © 2016, Juniper Networks, Inc. 363

Chassis Cluster Feature Guide for Branch SRX Series Devices

PFE 0 :Links ok
FPC 4
PFE 0 :Links ok
FPC 7
PFE 0 :Links ok
FPC 8
PFE 0 :Links ok
FPC 9
PFE 0 :Links ok
FPC 10
PFE 0 :Links ok
Plane 5
Plane state: SPARE
FPC 0
PFE 0 :Links ok
FPC 2
PFE 0 :Links ok
FPC 3
PFE 0 :Links ok
FPC 4
PFE 0 :Links ok
FPC 7
PFE 0 :Links ok
FPC 8
PFE 0 :Links ok
FPC 9
PFE 0 :Links ok
FPC 10
PFE 0 :Links ok

node1:
--------------------------------------------------------------------------
Fabric management PLANE state
Plane 0
Plane state: ACTIVE
FPC 0
PFE 0 :Links ok
FPC 1
PFE 0 :Links ok
FPC 2
PFE 0 :Links ok
FPC 3
PFE 0 :Links ok
FPC 4
PFE 0 :Links ok
FPC 7
PFE 0 :Links ok
FPC 8
PFE 0 :Links ok
FPC 10
PFE 0 :Links ok
Plane 1
Plane state: ACTIVE
FPC 0
PFE 0 :Links ok
FPC 1
PFE 0 :Links ok
FPC 2
PFE 0 :Links ok
FPC 3
PFE 0 :Links ok

364 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

FPC 4
PFE 0 :Links ok
FPC 7
PFE 0 :Links ok
FPC 8
PFE 0 :Links ok
FPC 10
PFE 0 :Links ok
Plane 2
Plane state: ACTIVE
FPC 0
PFE 0 :Links ok
FPC 1
PFE 0 :Links ok
FPC 2
PFE 0 :Links ok
FPC 3
PFE 0 :Links ok
FPC 4
PFE 0 :Links ok
FPC 7
PFE 0 :Links ok
FPC 8
PFE 0 :Links ok
FPC 10
PFE 0 :Links ok
Plane 3
Plane state: ACTIVE
FPC 0
PFE 0 :Links ok
FPC 1
PFE 0 :Links ok
FPC 2
PFE 0 :Links ok
FPC 3
PFE 0 :Links ok
FPC 4
PFE 0 :Links ok
FPC 7
PFE 0 :Links ok
FPC 8
PFE 0 :Links ok
FPC 10
PFE 0 :Links ok
Plane 4
Plane state: SPARE
FPC 0
PFE 0 :Links ok
FPC 1
PFE 0 :Links ok
FPC 2
PFE 0 :Links ok
FPC 3
PFE 0 :Links ok
FPC 4
PFE 0 :Links ok
FPC 7
PFE 0 :Links ok
FPC 8
PFE 0 :Links ok
FPC 10

Copyright © 2016, Juniper Networks, Inc. 365

Chassis Cluster Feature Guide for Branch SRX Series Devices

PFE 0 :Links ok
Plane 5
Plane state: SPARE
FPC 0
PFE 0 :Links ok
FPC 1
PFE 0 :Links ok
FPC 2
PFE 0 :Links ok
FPC 3
PFE 0 :Links ok
FPC 4
PFE 0 :Links ok
FPC 7
PFE 0 :Links ok
FPC 8
PFE 0 :Links ok
FPC 10
PFE 0 :Links ok

366 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

show chassis fabric plane-location

Supported Platforms SRX Series, vSRX

Syntax show chassis fabric plane-location

Release Information Command introduced in Junos OS Release 9.2.

Description Show fabric plane location.

Required Privilege view

Level

Related • show chassis fabric plane on page 361

Documentation

List of Sample Output show chassis fabric plane-location(SRX5600 and SRX5800 devices with SRX5000
line SCB II (SRX5K-SCBE) and SRX5K-RE-1800X4) on page 367

Output Fields Table 42 on page 367 lists the output fields for the show chassis fabric plane-location
command. Output fields are listed in the approximate order in which they appear.

Table 42: show chassis fabric plane-location Output Fields

Field Name Field Description

Plane n Plane number.

Control Board n Control Board number.

Sample Output
show chassis fabric plane-location
(SRX5600 and SRX5800 devices with SRX5000 line SCB II (SRX5K-SCBE) and SRX5K-RE-1800X4)
user@host> show chassis fabric plane-location
node0:
--------------------------------------------------------------------------
------------Fabric Plane Locations-------------
Plane 0 Control Board 0
Plane 1 Control Board 0
Plane 2 Control Board 1
Plane 3 Control Board 1
Plane 4 Control Board 2
Plane 5 Control Board 2

node1:
--------------------------------------------------------------------------
------------Fabric Plane Locations-------------
Plane 0 Control Board 0
Plane 1 Control Board 0
Plane 2 Control Board 1
Plane 3 Control Board 1
Plane 4 Control Board 2
Plane 5 Control Board 2

Copyright © 2016, Juniper Networks, Inc. 367

Chassis Cluster Feature Guide for Branch SRX Series Devices

368 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

show chassis fabric summary

Supported Platforms SRX Series, vSRX

Syntax show chassis fabric summary

Release Information Command introduced in Junos OS Release 9.2.

Description Show summary fabric management state.

Options This command has no options.

Required Privilege view

Level

Related • show chassis fabric plane on page 361

Documentation
• show chassis fabric plane-location on page 367

List of Sample Output show chassis fabric summary(SRX5600 and SRX5800 devices with SRX5000 line
SCB II (SRX5K-SCBE) and SRX5K-RE-1800X4) on page 370

Output Fields Table 43 on page 369 lists the output fields for the show chassis fabric summary command.
Output fields are listed in the approximate order in which they appear.

Table 43: show chassis fabric summary Output Fields

Field Name Field Description

Plane Plane number.

Copyright © 2016, Juniper Networks, Inc. 369

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 43: show chassis fabric summary Output Fields (continued)

Field Name Field Description

State State of the SIB or FPC:

• Online—Switch Interface Board (SIB) is operational and running.

• Empty—SIB is powered down.
• Check—SIB is in the Check state because of the following reasons:
• SIB is not inserted properly.
• Some destination errors are detected on the SIB. In this case,
the Packet Forwarding Engine stops using the SIB to send
traffic to the affected destination Packet Forwarding Engine.
• Some link errors are detected on the channel between the SIB
and a Packet Forwarding Engine. Link errors can be detected
at initialization time or runtime:
• Link errors caused by a link training failure at initialization
time—The Packet Forwarding Engine does not use the SIB
to send traffic. The show chassis fabric fpcs command shows
Plane disabled as status for this link.
• Link errors caused by CRC errors detected at runtime—The
Packet Forwarding Engine continues to use the SIB to send
traffic. The show chassis fabric fpcs command shows Link
error as the status for this link.

For information about link and destination errors, issue the show
chassis fabric fpcs commands.
• Spare—SIB is redundant and will move to active state if one of
the working SIBs fails.

Errors Indicates whether there is any error on the SIB.

• None—No errors
• Link Errors—Fabric link errors were found on the SIB RX link.
• Cell drops—Fabric cell drops were found on the SIB ASIC.
• Link, Cell drops—Both link errors and cell drops were detected on
at least one of the FPC’s fabric links.

NOTE: The Errors column is empty only when the FPC or SIB is
offline.

Uptime Elapsed time the plane has been online.

Sample Output
show chassis fabric summary
(SRX5600 and SRX5800 devices with SRX5000 line SCB II (SRX5K-SCBE) and SRX5K-RE-1800X4)
user@host> show chassis fabric summary
node0:
--------------------------------------------------------------------------
Plane State Uptime
0 Online 14 minutes, 10 seconds
1 Online 14 minutes, 5 seconds
2 Online 14 minutes
3 Online 13 minutes, 55 seconds

370 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

4 Spare 13 minutes, 50 seconds

5 Spare 13 minutes, 44 seconds

node1:
--------------------------------------------------------------------------
Plane State Uptime
0 Online 14 minutes, 7 seconds
1 Online 14 minutes, 2 seconds
2 Online 13 minutes, 57 seconds
3 Online 13 minutes, 51 seconds
4 Spare 13 minutes, 46 seconds
5 Spare 13 minutes, 41 seconds

Copyright © 2016, Juniper Networks, Inc. 371

Chassis Cluster Feature Guide for Branch SRX Series Devices

show chassis hardware (View)

Supported Platforms SRX Series

Syntax show chassis hardware

<clei-models | detail | extensive | models | node ( node-id | all | local | primary)>

Release Information Command introduced in Junos OS Release 9.2. Command modified in Junos OS Release
9.2 to include node option.

Description Display chassis hardware information.

Options • clei-models—(Optional) Display Common Language Equipment Identifier Code (CLEI)

barcode and model number for orderable field-replaceable units (FRUs).

• detail | extensive—(Optional) Display the specified level of output.

• models—(Optional) Display model numbers and part numbers for orderable FRUs.

• node—(Optional) For chassis cluster configurations, display chassis hardware

information on a specific node (device) in the cluster.

• node-id —Identification number of the node. It can be 0 or 1.

• local—Display information about the local node.

• primary—Display information about the primary node.

Required Privilege view

Level

Related • Juniper Networks Devices Processing Overview

Documentation
• Interface Naming Conventions

Output Fields Table 44 on page 372 lists the output fields for the show chassis hardware command.
Output fields are listed in the approximate order in which they appear.

Table 44: show chassis hardware Output Fields

Field Name Field Description

Item Chassis component—Information about the backplane; power supplies; fan trays; Routing
Engine; each Physical Interface Module (PIM)—reported as FPC and PIC—and each fan,
blower, and impeller.

Version Revision level of the chassis component.

Part Number Part number for the chassis component.

Serial Number Serial number of the chassis component. The serial number of the backplane is also the
serial number of the device chassis. Use this serial number when you need to contact
Juniper Networks Customer Support about the device chassis.

372 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Table 44: show chassis hardware Output Fields (continued)

Field Name Field Description

Assb ID or Assembly ID Identification number that describes the FRU hardware.

FRU model number Model number of FRU hardware component.

CLEI code Common Language Equipment Identifier code. This value is displayed only for hardware
components that use ID EEPROM format v2. This value is not displayed for components
that use ID EEPROM format v1.

EEPROM Version ID EEPROM version used by hardware component: 0x01 (version 1) or 0x02 (version 2).

Copyright © 2016, Juniper Networks, Inc. 373

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 44: show chassis hardware Output Fields (continued)

Field Name Field Description

Description Brief description of the hardware item:

• Type of power supply.

• Switch Control Board (SCB)
Starting with Junos OS Release 12.1X47-D15, the SRX5K-SCBE (SCB2) is introduced.

• There are three SCB slots in SRX5800 devices. The third slot can be used for an
SCB or an FPC. When an SRX5K-SCB was used , the third SCB slot was used as an
FPC. SCB redundancy is provided in chassis cluster mode.
• With an SCB2, a third SCB is supported. If a third SCB is plugged in, it provides
intra-chassis fabric redundancy.
• The Ethernet switch in the SCB2 provides the Ethernet connectivity among all the
FPCs and the Routing Engine. The Routing Engine uses this connectivity to distribute
forwarding and routing tables to the FPCs. The FPCs use this connectivity to send
exception packets to the Routing Engine.
• Fabric connects all FPCs in the data plane. The Fabric Manager executes on the
Routing Engine and controls the fabric system in the chassis. Packet Forwarding
Engines on the FPC and fabric planes on the SCB are connected through HSL2
channels.
• SCB2 supports HSL2 with both 3.11 Gbps and 6.22 Gbps (SerDes) link speed and
various HSL2 modes. When an FPC is brought online, the link speed and HSL2 mode
are determined by the type of FPC.
Starting with Junos OS Release 15.1X49-D10, the SRX5K-SCB3 (SCB3) with enhanced
midplanes is introduced.

• All existing SCB software that is supported by SCB2 is supported on SCB3.

• SRX5K-RE-1800X4 (RE2). Mixed Routing Engine use is not supported.
• SCB3 works with the SRX5K-MPC (IOC2), SRX5K-MPC3-100G10G (IOC3),
SRX5K-MPC3-40G10G (IOC3), and SRX5K-SPC-4-15-320 (SPC2) with current
midplanes and the new enhanced midplanes.
• Mixed SCB use is not supported. If an SCB2 and an SCB3 are used, the system will
only power on the master Routing Engine's SCB and will power off the other SCBs.
Only the SCB in slot 0 will be powered on and a system log is generated.
• SCB3 supports up to 400 Gbps per slot with old midplanes and up to 500 Gbps
per slot with new midplanes.
• SCB3 supports fabric intra-chassis redundancy.
• SCB3 supports the same chassis cluster function as the SRX5K-SCB (SCB1) and
the SRX5K-SCBE (SCB2), except for in-service software upgrade (ISSU) and
in-service hardware upgrade (ISHU).
• SCB3 has a second external Ethernet port.
• Fabric bandwidth increasing mode is not supported.

374 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Table 44: show chassis hardware Output Fields (continued)

Field Name Field Description

• Type of Flexible PIC Concentrator (FPC), Physical Interface Card (PIC), Modular
Interface Cards (MICs), and PIMs.
• IOCs
Starting with Junos OS Release 15.1X49-D10, the SRX5K-MPC3-100G10G (IOC3) and
the SRX5K-MPC3-40G10G (IOC3) are introduced.

• IOC3 has two types of IOC3 MPCs, which have different built-in MICs: the 24x10GE
+ 6x40GE MPC and the 2x100GE + 4x10GE MPC.
• IOC3 supports SCB3 and SRX5000 line backplane and enhanced backplane.
• IOC3 can only work with SRX5000 line SCB2 and SCB3. If an SRX5000 line SCB is
detected, IOC3 will be offline, an FPC misconfiguration alarm will be raised, and a
system log message is generated.
• IOC3 interoperates with SCB2 and SCB3.
• IOC3 interoperates with the SRX5K-SPC-4-15-320 (SPC2) and the SRX5K-MPC
(IOC2).
• The maximum power consumption for one IOC3 is 645W. An enhanced power
module must be used.
• The IOC3 does not support the following command to set a PIC to go offline or
online:
request chassis pic fpc-slot <fpc-slot> pic-slot <pic-slot> <offline | online> .
• IOC3 supports 240 Gbps of throughput with the enhanced SRX5000 line backplane.
• Chassis cluster functions the same as for the SRX5000 line IOC2.
• IOC3 supports intra-chassis and inter-chassis fabric redundancy mode.
• IOC3 supports ISSU and ISHU in chassis cluster mode.
• IOC3 supports intra-FPC and and Inter-FPC Express Path (previously known as
services offloading) with IPv4.
• NAT of IPv4 and IPv6 in normal mode and IPv4 for Express Path mode.
• All four PICs on the 24x10GE + 6x40GE cannot be powered on. A maximum of two
PICs can be powered on at the same time.
Use the set chassis fpc <slot> pic <pic> power off command to choose the PICs you
want to power on.

NOTE: Fabric bandwidth increasing mode is not supported on IOC3.

• SRX Clustering Module (SCM)

• Fan tray
• For hosts, the Routing Engine type.
• Starting with Junos OS Release 12.1X47-D15, the SRX5K-RE-1800X4 (RE2) Routing
Engine is introduced.
• The RE2 has an Intel Quad core Xeon processor, 16 GB of DRAM, and a 128-GB
solid-state drive (SSD).
The number 1800 refers to the speed of the processor (1.8 GHz). The maximum
required power for this Routing Engine is 90W.

NOTE: The RE2 provides significantly better performance than the previously used
Routing Engine, even with a single core.

Copyright © 2016, Juniper Networks, Inc. 375

Chassis Cluster Feature Guide for Branch SRX Series Devices

show chassis hardware

show chassis hardware
user@host> show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
Chassis CM0715AK0021 SRX1500
Midplane REV 08 750-058562 ACMA4255 SRX1500
CB 0 REV 08 711-053838 ACMA7529 CPU Board SRX700E
Routing Engine 0 BUILTIN BUILTIN SRX Routing Engine
FPC 0 REV 07 711-053832 ACMA3311 FEB
PIC 0 BUILTIN BUILTIN 12x1G-T-4x1G-SFP-4x10G
Xcvr 12 REV 01 740-014132 61521013 SFP-T
Xcvr 13 REV 02 740-013111 A281604 SFP-T
Xcvr 14 REV 02 740-011613 NRN30NV SFP-SX
Xcvr 15 REV 02 740-011613 NRN2PWV SFP-SX
Xcvr 16 REV 01 740-021308 AJA17B5 SFP+-10G-SR
Xcvr 17 REV 01 740-021308 MSP056B SFP+-10G-SR
Xcvr 18 REV 01 740-031980 AS920WJ SFP+-10G-SR
Xcvr 19 REV 01 740-031980 AS92W5N SFP+-10G-SR
Power Supply 0 REV 01 740-055217 1EDP42500JZ PS 400W 90-264V AC in
Fan Tray 0 SRX1500 0, Front to Back
Airflow - AFO
Fan Tray 1 SRX1500 1, Front to Back
Airflow - AFO
Fan Tray 2 SRX1500 2, Front to Back
Airflow - AFO
Fan Tray 3 SRX1500 3, Front to Back
Airflow - AFO

show chassis hardware (SRX5600 and SRX5800 devices for SRX5K-MPC)

user@host> show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN12170EAAGA SRX 5800
Midplane REV 01 710-041799 ACAX3849 SRX 5800 Backplane
FPM Board REV 01 710-024632 CAAX7297 Front Panel Display
PDM Rev 03 740-013110 QCS170250DU Power Distribution Modu
le
PEM 0 Rev 03 740-034724 QCS17020203F PS 4.1kW; 200-240V AC i
n
PEM 1 Rev 03 740-034724 QCS17020203C PS 4.1kW; 200-240V AC i
n
PEM 2 Rev 04 740-034724 QCS17100200A PS 4.1kW; 200-240V AC i
n
PEM 3 Rev 03 740-034724 QCS17080200M PS 4.1kW; 200-240V AC i
n
Routing Engine 0 REV 11 740-023530 9012047437 SRX5k RE-13-20
CB 0 REV 09 710-024802 CAAX7202 SRX5k SCB
CB 1 REV 09 710-024802 CAAX7157 SRX5k SCB
FPC 0 REV 07 750-044175 CAAD0791 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Cp
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 1 REV 07 750-044175 CAAD0751 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow

376 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

PIC 1 BUILTIN BUILTIN SPU Flow

PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 2 REV 28 750-020751 CAAW1817 SRX5k DPC 4X 10GE
CPU REV 04 710-024633 CAAZ5269 SRX5k DPC PMB
PIC 0 BUILTIN BUILTIN 1x 10GE(LAN/WAN) RichQ
Xcvr 0 REV 02 740-014289 T10A00404 XFP-10G-SR
PIC 1 BUILTIN BUILTIN 1x 10GE(LAN/WAN) RichQ
PIC 2 BUILTIN BUILTIN 1x 10GE(LAN/WAN) RichQ
PIC 3 BUILTIN BUILTIN 1x 10GE(LAN/WAN) RichQ
FPC 6 REV 02 750-044175 ZY2552 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
FPC 9 REV 10 750-044175 CAAP5932 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 10 REV 22 750-043157 ZH8192 SRX5k IOC II CPU
REV 08 711-043360 YX3879 SRX5k MPC PMB
MIC 0 REV 01 750-049488 YZ2084 10x 10GE SFP+
PIC 0 BUILTIN BUILTIN 10x 10GE SFP+
Xcvr 0 REV 01 740-031980 AMB0HG3 SFP+-10G-SR
Xcvr 1 REV 01 740-031980 AM20B6F SFP+-10G-SR
MIC 1 REV 19 750-049486 CAAH3504 1x 100GE CFP
PIC 2 BUILTIN BUILTIN 1x 100GE CFP
Xcvr 0 REV 01 740-035329 X000D375 CFP-100G-SR10
FPC 11 REV 07.04.07 750-043157 CAAJ8771 SRX5k IOC II CPU
REV 08 711-043360 CAAJ3881 SRX5k MPC PMB
MIC 0 REV 19 750-049486 CAAH0979 1x 100GE CFP
PIC 0 BUILTIN BUILTIN 1x 100GE CFP
Xcvr 0 REV 01 740-035329 UP1020Z CFP-100G-SR10
MIC 1 REV 08 750-049487 CAAM1160 2x 40GE QSFP+
PIC 2 BUILTIN BUILTIN 2x 40GE QSFP+
Xcvr 0 REV 01 740-032986 QB151094 QSFP+-40G-SR4
Xcvr 1 REV 01 740-032986 QB160509 QSFP+-40G-SR4
Fan Tray 0 REV 04 740-035409 ACAE0875 Enhanced Fan Tray
Fan Tray 1 REV 04 740-035409 ACAE0876 Enhanced Fan Tray

show chassis hardware (with 20-Gigabit Ethernet MIC with SFP)

user@host> show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN108DA5AAGA SRX 5800
Midplane REV 02 710-013698 TR0037 SRX 5600 Midplane
FPM Board REV 02 710-014974 JY4635 Front Panel Display
PDM Rev 02 740-013110 QCS10465005 Power Distribution Module
PEM 0 Rev 03 740-023514 QCS11154040 PS 1.7kW; 200-240VAC in
PEM 2 Rev 02 740-023514 QCS10504014 PS 1.7kW; 200-240VAC in
Routing Engine 0 REV 05 740-015113 1000681023 RE-S-1300
CB 0 REV 05 710-013385 JY4775 SRX5k SCB
FPC 1 REV 17 750-020751 WZ6349 SRX5k DPC 4X 10GE
CPU REV 02 710-024633 WZ0718 SRX5k DPC PMB
PIC 0 BUILTIN BUILTIN 1x 10GE(LAN/WAN) RichQ
Xcvr 0 NON-JNPR C724XM088 XFP-10G-SR
PIC 1 BUILTIN BUILTIN 1x 10GE(LAN/WAN) RichQ
Xcvr 0 REV 02 740-011571 C831XJ08S XFP-10G-SR
PIC 2 BUILTIN BUILTIN 1x 10GE(LAN/WAN) RichQ
PIC 3 BUILTIN BUILTIN 1x 10GE(LAN/WAN) RichQ
FPC 3 REV 22 750-043157 ZH8189 SRX5k IOC II

Copyright © 2016, Juniper Networks, Inc. 377

Chassis Cluster Feature Guide for Branch SRX Series Devices

CPU REV 06 711-043360 YX3912 SRX5k MPC PMB

MIC 0 REV 01 750-055732 CACF9115 20x 1GE(LAN) SFP
PIC 0 BUILTIN BUILTIN 10x 1GE(LAN) SFP
Xcvr 2 REV 02 740-013111 B358549 SFP-T
Xcvr 9 REV 02 740-011613 PNB1FQS SFP-SX
PIC 1 BUILTIN BUILTIN 10x 1GE(LAN) SFP
Xcvr 9 REV 02 740-011613 PNB1FFF SFP-SX
FPC 5 REV 01 750-027945 JW9665 SRX5k FIOC
CPU
FPC 8 REV 08 750-023996 XA7234 SRX5k SPC
CPU REV 02 710-024633 XA1599 SRX5k DPC PMB
PIC 0 BUILTIN BUILTIN SPU Cp-Flow
PIC 1 BUILTIN BUILTIN SPU Flow
Fan Tray 0 REV 03 740-014971 TP0902 Fan Tray
Fan Tray 1 REV 01 740-014971 TP0121 Fan Tray

show chassis hardware

(SRX5600 and SRX5800 devices with SRX5000 line SRX5K-SCBE (SCB2) and SRX5K-RE-1800X4 (RE2))
user@host> show chassis hardware
node0:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN122A040AGA SRX5800
Midplane REV 01 710-041799 ACRA7817 SRX5800 Backplane
FPM Board REV 01 760-058099 CACA2100 Front Panel Display
PDM Rev 03 740-013110 QCS1739517Z Power Distribution Modu

le
PEM 0 Rev 05 740-034724 QCS17460203K PS 4.1kW; 200-240V AC i

n
PEM 1 Rev 04 740-034724 QCS172302017 PS 4.1kW; 200-240V AC i

n
Routing Engine 0 REV 01 740-056658 9013040855 SRX5k RE-1800X4
Routing Engine 1
CB 0 REV 01 750-056587 CACG1424 SRX5k SCB II
CB 1 REV 01 750-056587 CACC9307 SRX5k SCB II
CB 2 REV 01 750-056587 CAAZ1128 SRX5k SCB II
FPC 0 REV 10 750-056758 CACS2667 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Cp
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 1 REV 18 750-054877 CACH4092 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 2 REV 10 750-056758 CACV0038 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 3 REV 10 750-043157 CACB6877 SRX5k IOC II
CPU REV 04 711-043360 CACH6074 SRX5k MPC PMB

378 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

MIC 0 REV 19 750-049486 CAAH3504 1x 100GE CFP

PIC 0 BUILTIN BUILTIN 1x 100GE CFP
Xcvr 0 REV 01 740-035329 UP1020Z CFP-100G-SR10
MIC 1 REV 04 750-049488 CACB6429 10x 10GE SFP+
PIC 2 BUILTIN BUILTIN 10x 10GE SFP+
Xcvr 0 REV 01 740-031980 AP21RJ5 SFP+-10G-SR
Xcvr 1 REV 01 740-031980 AP21RLJ SFP+-10G-SR
Xcvr 2 REV 01 740-030658 AD1148A0AYC SFP+-10G-USR
Xcvr 3 REV 01 740-031980 B11E02718 SFP+-10G-SR
FPC 4 REV 10 750-056758 CACW0706 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 7 REV 10 750-056758 CACS2725 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 8 REV 11 750-043157 CABN4955 SRX5k IOC II
CPU REV 04 711-043360 CACT9926 SRX5k MPC PMB
MIC 0 REV 19 750-049486 CAAH0979 1x 100GE CFP
PIC 0 BUILTIN BUILTIN 1x 100GE CFP
Xcvr 0 REV 01 740-035329 UP2077V CFP-100G-SR10
FPC 9 REV 10 750-056758 CACW0755 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 10 REV 07 750-044175 CAAD0747 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
Fan Tray 0 REV 04 740-035409 ACAE2294 Enhanced Fan Tray
Fan Tray 1 REV 04 740-035409 ACAE2099 Enhanced Fan Tray

node1:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN1235BC7AGA SRX5800
Midplane REV 01 710-024803 ACRC3244 SRX5800 Backplane
FPM Board REV 01 710-024632 CACA2108 Front Panel Display
PDM Rev 03 740-013110 QCS1739519B Power Distribution Module
PEM 0 Rev 04 740-034724 QCS17230201Z PS 4.1kW; 200-240V AC
in
PEM 1 Rev 05 740-034724 QCS174502014 PS 4.1kW; 200-240V AC
in
Routing Engine 0 REV 01 740-056658 9009153221 SRX5k RE-1800X4
Routing Engine 1
CB 0 REV 01 750-056587 CACC9541 SRX5k SCB II
CB 1 REV 01 750-056587 CACG1447 SRX5k SCB II
CB 2 REV 01 750-056587 CACH9058 SRX5k SCB II
FPC 0 REV 18 750-054877 CACH4004 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Cp
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 1 REV 18 750-054877 CACH4082 SRX5k SPC II

Copyright © 2016, Juniper Networks, Inc. 379

Chassis Cluster Feature Guide for Branch SRX Series Devices

CPU BUILTIN BUILTIN SRX5k DPC PPC

PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 2 REV 10 750-056758 CACW0713 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 3 REV 11 750-043157 CACA8792 SRX5k IOC II
CPU REV 04 711-043360 CACA8809 SRX5k MPC PMB
MIC 0 REV 19 750-049486 CAAH3485 1x 100GE CFP
PIC 0 BUILTIN BUILTIN 1x 100GE CFP
Xcvr 0 REV 01 740-035329 UNM0G3C CFP-100G-SR10
MIC 1 REV 04 750-049488 CABX0782 10x 10GE SFP+
PIC 2 BUILTIN BUILTIN 10x 10GE SFP+
Xcvr 0 REV 01 740-031980 AMB0HX3 SFP+-10G-SR
Xcvr 1 REV 01 740-031980 ANT0E6V SFP+-10G-SR
Xcvr 2 REV 01 740-031980 ANR0ZVY SFP+-10G-SR
Xcvr 3 REV 01 740-031980 AP308ZU SFP+-10G-SR
FPC 4 REV 10 750-044175 CAAS8024 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 7 REV 10 750-056758 CACS5126 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 8 REV 11 750-043157 CACA8798 SRX5k IOC II
CPU REV 04 711-043360 CACA8826 SRX5k MPC PMB
MIC 0 REV 19 750-049486 CAAH0996 1x 100GE CFP
PIC 0 BUILTIN BUILTIN 1x 100GE CFP
Xcvr 0 REV 01 740-035329 UP30A6N CFP-100G-SR10
FPC 9 REV 07 750-044175 CAAD0745 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 10 REV 18 750-054877 CACD2570 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
Fan Tray 0 REV 04 740-035409 ACAE2122 Enhanced Fan Tray
Fan Tray 1 REV 04 740-035409 ACAE2254 Enhanced Fan Tray

show chassis hardware

(SRX5400, SRX5600, and SRX5800 devices with SRX5000 line SRX5K-SCB3 (SCB3) with enhanced midplanes
and SRX5K-MPC3-100G10G (IOC3) or SRX5K-MPC3-40G10G (IOC3)
user@host> show chassis hardware
node0:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN1250870AGB SRX5600
Midplane REV 01 760-063936 ACRE2578 Enhanced SRX5600 Midplane

380 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

FPM Board REV 02 710-017254 KD9027 Front Panel Display

PEM 0 Rev 03 740-034701 QCS13090900T PS 1.4-2.6kW; 90-264V A

C in
PEM 1 Rev 03 740-034701 QCS13090904T PS 1.4-2.6kW; 90-264V A

C in
Routing Engine 0 REV 01 740-056658 9009196496 SRX5k RE-1800X4
CB 0 REV 01 750-062257 CAEC2501 SRX5k SCB3
FPC 0 REV 10 750-056758 CADC8067 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Cp
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 2 REV 01 750-062243 CAEE5924 SRX5k IOC3 24XGE+6XLG
CPU REV 01 711-062244 CAEB4890 SRX5k IOC3 PMB
PIC 0 BUILTIN BUILTIN 12x 10GE SFP+
PIC 1 BUILTIN BUILTIN 12x 10GE SFP+
PIC 2 BUILTIN BUILTIN 3x 40GE QSFP+
Xcvr 0 REV 01 740-038623 MOC13156230449 QSFP+-40G-CU1M
Xcvr 2 REV 01 740-038623 MOC13156230449 QSFP+-40G-CU1M
PIC 3 BUILTIN BUILTIN 3x 40GE QSFP+
WAN MEZZ REV 01 750-062682 CAEE5817 24x 10GE SFP+ Mezz
FPC 4 REV 11 750-043157 CACY1595 SRX5k IOC II
CPU REV 04 711-043360 CACZ8879 SRX5k MPC PMB
MIC 1 REV 04 750-049488 CACM6062 10x 10GE SFP+
PIC 2 BUILTIN BUILTIN 10x 10GE SFP+
Xcvr 7 REV 01 740-021308 AD1439301TU SFP+-10G-SR
Xcvr 8 REV 01 740-021308 AD1439301SD SFP+-10G-SR
Xcvr 9 REV 01 740-021308 AD1439301TS SFP+-10G-SR
FPC 5 REV 05 750-044175 ZZ1371 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
Fan Tray Enhanced Fan Tray

node1:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN124FEC0AGB SRX5600
Midplane REV 01 760-063936 ACRE2946 Enhanced SRX5600 Midplane
FPM Board test 710-017254 test Front Panel Display
PEM 0 Rev 01 740-038514 QCS114111003 DC 2.6kW Power Entry
Module
PEM 1 Rev 01 740-038514 QCS12031100J DC 2.6kW Power Entry
Module
Routing Engine 0 REV 01 740-056658 9009186342 SRX5k RE-1800X4
CB 0 REV 01 750-062257 CAEB8178 SRX5k SCB3
FPC 0 REV 07 750-044175 CAAD0769 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Cp
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 4 REV 11 750-043157 CACY1592 SRX5k IOC II

Copyright © 2016, Juniper Networks, Inc. 381

Chassis Cluster Feature Guide for Branch SRX Series Devices

CPU REV 04 711-043360 CACZ8831 SRX5k MPC PMB

MIC 1 REV 04 750-049488 CACN0239 10x 10GE SFP+
PIC 2 BUILTIN BUILTIN 10x 10GE SFP+
Xcvr 7 REV 01 740-031980 ARN23HW SFP+-10G-SR
Xcvr 8 REV 01 740-031980 ARN2FVW SFP+-10G-SR
Xcvr 9 REV 01 740-031980 ARN2YVM SFP+-10G-SR
FPC 5 REV 10 750-056758 CADA8736 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
Fan Tray Enhanced Fan Tray

show chassis hardware detail

show chassis hardware detail
(SRX5600 and SRX5800 devices with SRX5000 line SRX5K-SCBE (SCB2) and (SRX5K-RE-1800X4 (RE2)
user@host> show chassis hardware detail
node0:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN122A040AGA SRX5800
Midplane REV 01 710-041799 ACRA7817 SRX5800 Backplane
FPM Board REV 01 760-058099 CACA2100 Front Panel Display
PDM Rev 03 740-013110 QCS1739517Z Power Distribution Module
PEM 0 Rev 05 740-034724 QCS17460203K PS 4.1kW; 200-240V AC
in
PEM 1 Rev 04 740-034724 QCS172302017 PS 4.1kW; 200-240V AC
in
Routing Engine 0 REV 01 740-056658 9013040855 SRX5k RE-1800X4
ad0 3998 MB Virtium - TuffDrive VCF P1T0200269450529 741 Compact Flash
ad1 114304 MB VSFA18PI128G-KC 32779-073 Disk 1
usb0 (addr 1) EHCI root hub 0 Intel uhub0
usb0 (addr 2) product 0x0020 32 vendor 0x8087 uhub1
DIMM 0 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80
DIMM 1 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80
DIMM 2 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80
DIMM 3 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80
Routing Engine 1
CB 0 REV 01 750-056587 CACG1424 SRX5k SCB II
CB 1 REV 01 750-056587 CACC9307 SRX5k SCB II
CB 2 REV 01 750-056587 CAAZ1128 SRX5k SCB II
FPC 0 REV 10 750-056758 CACS2667 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Cp
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 1 REV 18 750-054877 CACH4092 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 2 REV 10 750-056758 CACV0038 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow

382 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

PIC 2 BUILTIN BUILTIN SPU Flow

PIC 3 BUILTIN BUILTIN SPU Flow
FPC 3 REV 10 750-043157 CACB6877 SRX5k IOC II
CPU REV 04 711-043360 CACH6074 SRX5k MPC PMB
MIC 0 REV 19 750-049486 CAAH3504 1x 100GE CFP
PIC 0 BUILTIN BUILTIN 1x 100GE CFP
Xcvr 0 REV 01 740-035329 UP1020Z CFP-100G-SR10
MIC 1 REV 04 750-049488 CACB6429 10x 10GE SFP+
PIC 2 BUILTIN BUILTIN 10x 10GE SFP+
Xcvr 0 REV 01 740-031980 AP21RJ5 SFP+-10G-SR
Xcvr 1 REV 01 740-031980 AP21RLJ SFP+-10G-SR
Xcvr 2 REV 01 740-030658 AD1148A0AYC SFP+-10G-USR
Xcvr 3 REV 01 740-031980 B11E02718 SFP+-10G-SR
FPC 4 REV 10 750-056758 CACW0706 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 7 REV 10 750-056758 CACS2725 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 8 REV 11 750-043157 CABN4955 SRX5k IOC II
CPU REV 04 711-043360 CACT9926 SRX5k MPC PMB
MIC 0 REV 19 750-049486 CAAH0979 1x 100GE CFP
PIC 0 BUILTIN BUILTIN 1x 100GE CFP
Xcvr 0 REV 01 740-035329 UP2077V CFP-100G-SR10
FPC 9 REV 10 750-056758 CACW0755 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 10 REV 07 750-044175 CAAD0747 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
Fan Tray 0 REV 04 740-035409 ACAE2294 Enhanced Fan Tray
Fan Tray 1 REV 04 740-035409 ACAE2099 Enhanced Fan Tray

node1:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN1235BC7AGA SRX5800
Midplane REV 01 710-024803 ACRC3244 SRX5800 Backplane
FPM Board REV 01 710-024632 CACA2108 Front Panel Display
PDM Rev 03 740-013110 QCS1739519B Power Distribution Module
PEM 0 Rev 04 740-034724 QCS17230201Z PS 4.1kW; 200-240V AC
in
PEM 1 Rev 05 740-034724 QCS174502014 PS 4.1kW; 200-240V AC
in
Routing Engine 0 REV 01 740-056658 9009153221 SRX5k RE-1800X4
ad0 3998 MB Virtium - TuffDrive VCF P1T0200298450703 72 Compact Flash
ad1 114304 MB VSFA18PI128G-KC 32779-073 Disk 1
usb0 (addr 1) EHCI root hub 0 Intel uhub0
usb0 (addr 2) product 0x0020 32 vendor 0x8087 uhub1
DIMM 0 VL31B5263F-F8SD DIE REV-0 PCB REV-0 MFR ID-ce80
DIMM 1 VL31B5263F-F8SD DIE REV-0 PCB REV-0 MFR ID-ce80
DIMM 2 VL31B5263F-F8SD DIE REV-0 PCB REV-0 MFR ID-ce80

Copyright © 2016, Juniper Networks, Inc. 383

Chassis Cluster Feature Guide for Branch SRX Series Devices

DIMM 3 VL31B5263F-F8SD DIE REV-0 PCB REV-0 MFR ID-ce80

Routing Engine 1
CB 0 REV 01 750-056587 CACC9541 SRX5k SCB II
CB 1 REV 01 750-056587 CACG1447 SRX5k SCB II
CB 2 REV 01 750-056587 CACH9058 SRX5k SCB II
FPC 0 REV 18 750-054877 CACH4004 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Cp
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 1 REV 18 750-054877 CACH4082 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 2 REV 10 750-056758 CACW0713 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 3 REV 11 750-043157 CACA8792 SRX5k IOC II
CPU REV 04 711-043360 CACA8809 SRX5k MPC PMB
MIC 0 REV 19 750-049486 CAAH3485 1x 100GE CFP
PIC 0 BUILTIN BUILTIN 1x 100GE CFP
Xcvr 0 REV 01 740-035329 UNM0G3C CFP-100G-SR10
MIC 1 REV 04 750-049488 CABX0782 10x 10GE SFP+
PIC 2 BUILTIN BUILTIN 10x 10GE SFP+
Xcvr 0 REV 01 740-031980 AMB0HX3 SFP+-10G-SR
Xcvr 1 REV 01 740-031980 ANT0E6V SFP+-10G-SR
Xcvr 2 REV 01 740-031980 ANR0ZVY SFP+-10G-SR
Xcvr 3 REV 01 740-031980 AP308ZU SFP+-10G-SR
FPC 4 REV 10 750-044175 CAAS8024 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 7 REV 10 750-056758 CACS5126 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 8 REV 11 750-043157 CACA8798 SRX5k IOC II
CPU REV 04 711-043360 CACA8826 SRX5k MPC PMB
MIC 0 REV 19 750-049486 CAAH0996 1x 100GE CFP
PIC 0 BUILTIN BUILTIN 1x 100GE CFP
Xcvr 0 REV 01 740-035329 UP30A6N CFP-100G-SR10
FPC 9 REV 07 750-044175 CAAD0745 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 10 REV 18 750-054877 CACD2570 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
Fan Tray 0 REV 04 740-035409 ACAE2122 Enhanced Fan Tray
Fan Tray 1 REV 04 740-035409 ACAE2254 Enhanced Fan Tray

384 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

show chassis hardware detail

(SRX5400, SRX5600, and SRX5800 devices with SRX5000 line SRX5K-SCB3 SCB3 with enhanced midplanes
and (SRX5K-MPC3-100G10G (IOC3) or SRX5K-MPC3-40G10G (IOC3))
user@host> show chassis hardware detail
node0:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN1250870AGB SRX5600
Midplane REV 01 760-063936 ACRE2578 Enhanced SRX5600 Midplane
FPM Board REV 02 710-017254 KD9027 Front Panel Display
PEM 0 Rev 03 740-034701 QCS13090900T PS 1.4-2.6kW; 90-264V
AC in
PEM 1 Rev 03 740-034701 QCS13090904T PS 1.4-2.6kW; 90-264V
AC in
Routing Engine 0 REV 01 740-056658 9009196496 SRX5k RE-1800X4
ad0 3831 MB UGB30SFA4000T2 SFA4000T2 000027A0 Compact Flash
ad1 114304 MB VSFA18PI128G-KC 32779-043 Disk 1
usb0 (addr 1) product 0x0000 0 vendor 0x0000 uhub0
usb0 (addr 2) product 0x0020 32 vendor 0x8087 uhub1
DIMM 0 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80
DIMM 1 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80
DIMM 2 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80
DIMM 3 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80
CB 0 REV 01 750-062257 CAEC2501 SRX5k SCB3
FPC 0 REV 10 750-056758 CADC8067 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Cp
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 2 REV 01 750-062243 CAEE5924 SRX5k IOC3 24XGE+6XLG
CPU REV 01 711-062244 CAEB4890 SRX5k IOC3 PMB
PIC 0 BUILTIN BUILTIN 12x 10GE SFP+
PIC 1 BUILTIN BUILTIN 12x 10GE SFP+
PIC 2 BUILTIN BUILTIN 3x 40GE QSFP+
Xcvr 0 REV 01 740-038623 MOC13156230449 QSFP+-40G-CU1M
Xcvr 2 REV 01 740-038623 MOC13156230449 QSFP+-40G-CU1M
PIC 3 BUILTIN BUILTIN 3x 40GE QSFP+
WAN MEZZ REV 01 750-062682 CAEE5817 24x 10GE SFP+ Mezz
FPC 4 REV 11 750-043157 CACY1595 SRX5k IOC II
CPU REV 04 711-043360 CACZ8879 SRX5k MPC PMB
MIC 1 REV 04 750-049488 CACM6062 10x 10GE SFP+
PIC 2 BUILTIN BUILTIN 10x 10GE SFP+
Xcvr 7 REV 01 740-021308 AD1439301TU SFP+-10G-SR
Xcvr 8 REV 01 740-021308 AD1439301SD SFP+-10G-SR
Xcvr 9 REV 01 740-021308 AD1439301TS SFP+-10G-SR
FPC 5 REV 05 750-044175 ZZ1371 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
Fan Tray Enhanced Fan Tray

node1:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN124FEC0AGB SRX5600

Copyright © 2016, Juniper Networks, Inc. 385

Chassis Cluster Feature Guide for Branch SRX Series Devices

Midplane REV 01 760-063936 ACRE2946 Enhanced SRX5600 Midplane

FPM Board test 710-017254 test Front Panel Display
PEM 0 Rev 01 740-038514 QCS114111003 DC 2.6kW Power Entry
Module
PEM 1 Rev 01 740-038514 QCS12031100J DC 2.6kW Power Entry
Module
Routing Engine 0 REV 01 740-056658 9009186342 SRX5k RE-1800X4
ad0 3998 MB Virtium - TuffDrive VCF P1T0200313161216 109 Compact Flash
ad1 28843 MB UGB94BPH32H0S2-KCI 11000160387 Disk 1
usb0 (addr 1) product 0x0000 0 vendor 0x0000 uhub0
usb0 (addr 2) product 0x0020 32 vendor 0x8087 uhub1
DIMM 0 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80
DIMM 1 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80
DIMM 2 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80
DIMM 3 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80
CB 0 REV 01 750-062257 CAEB8178 SRX5k SCB3
FPC 0 REV 07 750-044175 CAAD0769 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Cp
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
FPC 4 REV 11 750-043157 CACY1592 SRX5k IOC II
CPU REV 04 711-043360 CACZ8831 SRX5k MPC PMB
MIC 1 REV 04 750-049488 CACN0239 10x 10GE SFP+
PIC 2 BUILTIN BUILTIN 10x 10GE SFP+
Xcvr 7 REV 01 740-031980 ARN23HW SFP+-10G-SR
Xcvr 8 REV 01 740-031980 ARN2FVW SFP+-10G-SR
Xcvr 9 REV 01 740-031980 ARN2YVM SFP+-10G-SR
FPC 5 REV 10 750-056758 CADA8736 SRX5k SPC II
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Flow
PIC 1 BUILTIN BUILTIN SPU Flow
PIC 2 BUILTIN BUILTIN SPU Flow
PIC 3 BUILTIN BUILTIN SPU Flow
Fan Tray Enhanced Fan Tray

show chassis hardware extensive node 1

show chassis hardware extensive node 1
(SRX5600 and SRX5800 devices with SRX5000 line SRX5K-SCBE (SCB2) and SRX5K-RE-1800X4)
user@host> show chassis hardware extensive node 1
node1:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN1235BC7AGA SRX5800
Jedec Code: 0x7fb0 EEPROM Version: 0x02
S/N: JN1235BC7AGA
Assembly ID: 0x051a Assembly Version: 00.00
Date: 00-00-0000 Assembly Flags: 0x00
ID: SRX5800
Board Information Record:
Address 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I2C Hex Data:
Address 0x00: 7f b0 02 ff 05 1a 00 00 00 00 00 00 00 00 00 00
Address 0x10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x20: 4a 4e 31 32 33 35 42 43 37 41 47 41 00 00 00 00
Address 0x30: 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

386 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Address 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Midplane REV 01 710-024803 ACRC3244 SRX5800 Backplane
Jedec Code: 0x7fb0 EEPROM Version: 0x01
P/N: 710-024803 S/N: S/N ACRC3244
Assembly ID: 0x091a Assembly Version: 01.01
Date: 02-26-2014 Assembly Flags: 0x00
Version: REV 01
ID: SRX5800 Backplane FRU Model Number: SRX5800-BP-A
Board Information Record:
Address 0x00: ad 01 08 00 4c 96 14 d3 28 00 00 ff ff ff ff ff
I2C Hex Data:
Address 0x00: 7f b0 01 ff 09 1a 01 01 52 45 56 20 30 31 00 00
Address 0x10: 00 00 00 00 37 31 30 2d 30 32 34 38 30 33 00 00
Address 0x20: 53 2f 4e 20 41 43 52 43 33 32 34 34 00 1a 02 07
Address 0x30: de ff ff ff ad 01 08 00 4c 96 14 d3 28 00 00 ff
Address 0x40: ff ff ff ff 01 00 00 00 00 00 00 00 00 00 00 53
Address 0x50: 52 58 35 38 30 30 2d 42 50 2d 41 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff
Address 0x70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
FPM Board REV 01 710-024632 CACA2108 Front Panel Display
Jedec Code: 0x7fb0 EEPROM Version: 0x01
P/N: 710-024632 S/N: S/N CACA2108
Assembly ID: 0x096f Assembly Version: 01.01
Date: 02-05-2014 Assembly Flags: 0x00
Version: REV 01
ID: Front Panel Display FRU Model Number: SRX5800-CRAFT-A
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
I2C Hex Data:
Address 0x00: 7f b0 01 ff 09 6f 01 01 52 45 56 20 30 31 00 00
Address 0x10: 00 00 00 00 37 31 30 2d 30 32 34 36 33 32 00 00
Address 0x20: 53 2f 4e 20 43 41 43 41 32 31 30 38 00 05 02 07
Address 0x30: de ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x40: ff ff ff ff 01 00 00 00 00 00 00 00 00 00 00 53
Address 0x50: 52 58 35 38 30 30 2d 43 52 41 46 54 2d 41 00 00
Address 0x60: 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff
Address 0x70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
PDM Rev 03 740-013110 QCS1739519B Power Distribution Module

Jedec Code: 0x7fb0 EEPROM Version: 0x01

P/N: 740-013110 S/N: QCS1739519B
Assembly ID: 0x0416 Assembly Version: 01.03
Date: 10-26-2013 Assembly Flags: 0x00
Version: Rev 03
ID: Power Distribution Module
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00
I2C Hex Data:
Address 0x00: 7f b0 01 ff 04 16 01 03 52 65 76 20 30 33 00 00
Address 0x10: 00 00 00 00 37 34 30 2d 30 31 33 31 31 30 00 00
Address 0x20: 51 43 53 31 37 33 39 35 31 39 42 00 00 1a 0a 07
Address 0x30: dd ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x40: ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PEM 0 Rev 04 740-034724 QCS17230201Z PS 4.1kW; 200-240V AC
in
Jedec Code: 0x7fb0 EEPROM Version: 0x01

Copyright © 2016, Juniper Networks, Inc. 387

Chassis Cluster Feature Guide for Branch SRX Series Devices

P/N: 740-034724 S/N: QCS17230201Z

Assembly ID: 0x044b Assembly Version: 01.04
Date: 06-04-2013 Assembly Flags: 0x00
Version: Rev 04
ID: PS 4.1kW; 200-240V AC in FRU Model Number: SRX5800-PWR-4100-AC
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00
I2C Hex Data:
Address 0x00: 7f b0 01 ff 04 4b 01 04 52 65 76 20 30 34 00 00
Address 0x10: 00 00 00 00 37 34 30 2d 30 33 34 37 32 34 00 00
Address 0x20: 51 43 53 31 37 32 33 30 32 30 31 5a 00 04 06 07
Address 0x30: dd ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x40: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 53
Address 0x50: 52 58 35 38 30 30 2d 50 57 52 2d 34 31 30 30 2d
Address 0x60: 41 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PEM 1 Rev 05 740-034724 QCS174502014 PS 4.1kW; 200-240V AC
in
Jedec Code: 0x7fb0 EEPROM Version: 0x01
P/N: 740-034724 S/N: QCS174502014
Assembly ID: 0x044b Assembly Version: 01.05
Date: 11-06-2013 Assembly Flags: 0x00
Version: Rev 05
ID: PS 4.1kW; 200-240V AC in FRU Model Number: SRX5800-PWR-4100-AC
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00
I2C Hex Data:
Address 0x00: 7f b0 01 ff 04 4b 01 05 52 65 76 20 30 35 00 00
Address 0x10: 00 00 00 00 37 34 30 2d 30 33 34 37 32 34 00 00
Address 0x20: 51 43 53 31 37 34 35 30 32 30 31 34 00 06 0b 07
Address 0x30: dd ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x40: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 53
Address 0x50: 52 58 35 38 30 30 2d 50 57 52 2d 34 31 30 30 2d
Address 0x60: 41 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Routing Engine 0 REV 01 740-056658 9009153221 SRX5k RE-1800X4
Jedec Code: 0x7fb0 EEPROM Version: 0x02
P/N: 740-056658 S/N: 9009153221
Assembly ID: 0x0c1a Assembly Version: 01.01
Date: 07-22-2013 Assembly Flags: 0x00
Version: REV 01 CLEI Code: PROTOXCLEI
ID: SRX5k RE-1800X4 FRU Model Number: SRX5K-RE-1800X4
Board Information Record:
Address 0x00: 54 32 30 32 37 45 43 2d 34 34 47 42 00 00 00 00
I2C Hex Data:
Address 0x00: 7f b0 02 ff 0c 1a 01 01 52 45 56 20 30 31 00 00
Address 0x10: 00 00 00 00 37 34 30 2d 30 35 36 36 35 38 00 00
Address 0x20: 39 30 30 39 31 35 33 32 32 31 00 00 00 16 07 07
Address 0x30: dd ff ff ff 54 32 30 32 37 45 43 2d 34 34 47 42
Address 0x40: 00 00 00 00 01 50 52 4f 54 4f 58 43 4c 45 49 53
Address 0x50: 52 58 35 4b 2d 52 45 2d 31 38 30 30 58 34 00 00
Address 0x60: 00 00 00 00 00 00 41 30 30 ff ff ff ff ff ff ff
Address 0x70: ff ff ff 64 ff ff ff ff ff ff ff ff ff ff ff ff
ad0 3998 MB Virtium - TuffDrive VCF P1T0200298450703 72 Compact Flash
ad1 114304 MB VSFA18PI128G-KC 32779-073 Disk 1
usb0 (addr 1) EHCI root hub 0 Intel uhub0
usb0 (addr 2) product 0x0020 32 vendor 0x8087 uhub1
DIMM 0 VL31B5263F-F8SD DIE REV-0 PCB REV-0 MFR ID-ce80
DIMM 1 VL31B5263F-F8SD DIE REV-0 PCB REV-0 MFR ID-ce80
DIMM 2 VL31B5263F-F8SD DIE REV-0 PCB REV-0 MFR ID-ce80
DIMM 3 VL31B5263F-F8SD DIE REV-0 PCB REV-0 MFR ID-ce80

388 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Routing Engine 1
CB 0 REV 01 750-056587 CACC9541 SRX5k SCB II
Jedec Code: 0x7fb0 EEPROM Version: 0x02
P/N: 750-056587 S/N: S/N CACC9541
Assembly ID: 0x0c19 Assembly Version: 01.01
Date: 03-07-2014 Assembly Flags: 0x00
Version: REV 01 CLEI Code: PROTOXCLEI
ID: SRX5k SCB II FRU Model Number: SRX5K-SCBE
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
I2C Hex Data:
Address 0x00: 7f b0 02 fe 0c 19 01 01 52 45 56 20 30 31 00 00
Address 0x10: 00 00 00 00 37 35 30 2d 30 35 36 35 38 37 00 00
Address 0x20: 53 2f 4e 20 43 41 43 43 39 35 34 31 00 07 03 07
Address 0x30: de ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x40: ff ff ff ff 01 50 52 4f 54 4f 58 43 4c 45 49 53
Address 0x50: 52 58 35 4b 2d 53 43 42 45 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 41 00 00 ff ff ff ff ff ff ff
Address 0x70: ff ff ff 08 ff ff ff ff ff ff ff ff ff ff ff ff
CB 1 REV 01 750-056587 CACG1447 SRX5k SCB II
Jedec Code: 0x7fb0 EEPROM Version: 0x02
P/N: 750-056587 S/N: S/N CACG1447
Assembly ID: 0x0c19 Assembly Version: 01.01
Date: 03-07-2014 Assembly Flags: 0x00
Version: REV 01 CLEI Code: PROTOXCLEI
ID: SRX5k SCB II FRU Model Number: SRX5K-SCBE
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
I2C Hex Data:
Address 0x00: 7f b0 02 fe 0c 19 01 01 52 45 56 20 30 31 00 00
Address 0x10: 00 00 00 00 37 35 30 2d 30 35 36 35 38 37 00 00
Address 0x20: 53 2f 4e 20 43 41 43 47 31 34 34 37 00 07 03 07
Address 0x30: de ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x40: ff ff ff ff 01 50 52 4f 54 4f 58 43 4c 45 49 53
Address 0x50: 52 58 35 4b 2d 53 43 42 45 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 41 00 00 ff ff ff ff ff ff ff
Address 0x70: ff ff ff 08 ff ff ff ff ff ff ff ff ff ff ff ff
CB 2 REV 01 750-056587 CACH9058 SRX5k SCB II
Jedec Code: 0x7fb0 EEPROM Version: 0x02
P/N: 750-056587 S/N: S/N CACH9058
Assembly ID: 0x0c19 Assembly Version: 01.01
Date: 03-06-2014 Assembly Flags: 0x00
Version: REV 01 CLEI Code: PROTOXCLEI
ID: SRX5k SCB II FRU Model Number: SRX5K-SCBE
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
I2C Hex Data:
Address 0x00: 7f b0 02 fe 0c 19 01 01 52 45 56 20 30 31 00 00
Address 0x10: 00 00 00 00 37 35 30 2d 30 35 36 35 38 37 00 00
Address 0x20: 53 2f 4e 20 43 41 43 48 39 30 35 38 00 06 03 07
Address 0x30: de ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x40: ff ff ff ff 01 50 52 4f 54 4f 58 43 4c 45 49 53
Address 0x50: 52 58 35 4b 2d 53 43 42 45 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 41 00 00 ff ff ff ff ff ff ff
Address 0x70: ff ff ff 08 ff ff ff ff ff ff ff ff ff ff ff ff

show chassis hardware extensive node 1

(SRX5400, SRX5600, and SRX5800 devices with SRX5000 line SRX5K-SCB3 (SCB3) with enhanced midplanes
and SRX5K-MPC3-100G10G (IOC3) or SRX5K-MPC3-40G10G (IOC3))
user@host> show chassis hardware extensive node 1

Copyright © 2016, Juniper Networks, Inc. 389

Chassis Cluster Feature Guide for Branch SRX Series Devices

node1:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN124FEC0AGB SRX5600
Jedec Code: 0x7fb0 EEPROM Version: 0x02
S/N: JN124FEC0AGB
Assembly ID: 0x051b Assembly Version: 00.00
Date: 00-00-0000 Assembly Flags: 0x08
ID: SRX5600
Board Information Record:
Address 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I2C Hex Data:
Address 0x00: 7f b0 02 ff 05 1b 00 00 00 00 00 00 00 00 00 00
Address 0x10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x20: 4a 4e 31 32 34 46 45 43 30 41 47 42 08 00 00 00
Address 0x30: 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Midplane REV 01 760-063936 ACRE2946 Enhanced SRX5600 Midpla

ne
Jedec Code: 0x7fb0 EEPROM Version: 0x02
P/N: 760-063936 S/N: ACRE2946
Assembly ID: 0x0914 Assembly Version: 01.01
Date: 03-19-2015 Assembly Flags: 0x08
Version: REV 01 CLEI Code: CLEI-CODE
ID: SRX5600 Midplane FRU Model Number: SRX5600X-CHAS
Board Information Record:
Address 0x00: ad 01 08 00 88 a2 5e 12 68 00 ff ff ff ff ff ff
I2C Hex Data:
Address 0x00: 7f b0 02 ff 09 14 01 01 52 45 56 20 30 31 00 00
Address 0x10: 00 00 00 00 37 36 30 2d 30 36 33 39 33 36 00 00
Address 0x20: 53 2f 4e 20 41 43 52 45 32 39 34 36 08 13 03 07
Address 0x30: df ff ff ff ad 01 08 00 88 a2 5e 12 68 00 ff ff
Address 0x40: ff ff ff ff 01 43 4c 45 49 2d 43 4f 44 45 20 53
Address 0x50: 52 58 35 36 30 30 58 2d 43 48 41 53 20 20 20 20
Address 0x60: 20 20 20 20 20 20 31 30 31 ff ff ff ff ff ff ff
Address 0x70: ff ff ff ba ff ff ff ff ff ff ff ff ff ff ff ff
FPM Board test 710-017254 test Front Panel Display
Jedec Code: 0x7fb0 EEPROM Version: 0x02
P/N: 710-017254 S/N: test
Assembly ID: 0x01ff Assembly Version: 01.00
Date: 06-18-2007 Assembly Flags: 0x00
Version: test
ID: Front Panel Display
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
I2C Hex Data:
Address 0x00: 7f b0 02 ff 01 ff 01 00 74 65 73 74 00 00 00 00
Address 0x10: 00 00 00 00 37 31 30 2d 30 31 37 32 35 34 00 00
Address 0x20: 74 65 73 74 00 00 00 00 00 00 00 00 00 12 06 07
Address 0x30: d7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x40: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x70: 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff
PEM 0 Rev 01 740-038514 QCS114111003 DC 2.6kW Power Entry
Module

390 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Jedec Code: 0x7fb0 EEPROM Version: 0x01

P/N: 740-038514 S/N: QCS114111003
Assembly ID: 0x044c Assembly Version: 01.01
Date: 10-14-2011 Assembly Flags: 0x00
Version: Rev 01
ID: DC 2.6kW Power Entry Module FRU Model Number: SRX5600-PWR-2400-DC-S
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00
I2C Hex Data:
Address 0x00: 7f b0 01 ff 04 4c 01 01 52 65 76 20 30 31 00 00
Address 0x10: 00 00 00 00 37 34 30 2d 30 33 38 35 31 34 00 00
Address 0x20: 51 43 53 31 31 34 31 31 31 30 30 33 00 0e 0a 07
Address 0x30: db ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x40: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 53
Address 0x50: 52 58 35 36 30 30 2d 50 57 52 2d 32 34 30 30 2d
Address 0x60: 44 43 2d 53 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PEM 1 Rev 01 740-038514 QCS12031100J DC 2.6kW Power Entry
Module
Jedec Code: 0x7fb0 EEPROM Version: 0x01
P/N: 740-038514 S/N: QCS12031100J
Assembly ID: 0x044c Assembly Version: 01.01
Date: 01-17-2012 Assembly Flags: 0x00
Version: Rev 01
ID: DC 2.6kW Power Entry Module FRU Model Number: SRX5600-PWR-2400-DC-S
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00
I2C Hex Data:
Address 0x00: 7f b0 01 ff 04 4c 01 01 52 65 76 20 30 31 00 00
Address 0x10: 00 00 00 00 37 34 30 2d 30 33 38 35 31 34 00 00
Address 0x20: 51 43 53 31 32 30 33 31 31 30 30 4a 00 11 01 07
Address 0x30: dc ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x40: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 53
Address 0x50: 52 58 35 36 30 30 2d 50 57 52 2d 32 34 30 30 2d
Address 0x60: 44 43 2d 53 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Routing Engine 0 REV 01 740-056658 9009186342 SRX5k RE-1800X4
Jedec Code: 0x7fb0 EEPROM Version: 0x02
P/N: 740-056658 S/N: 9009186342
Assembly ID: 0x0c1a Assembly Version: 01.01
Date: 02-05-2014 Assembly Flags: 0x00
Version: REV 01 CLEI Code: COUCATTBAA
ID: SRX5k RE-1800X4 FRU Model Number: SRX5K-RE-1800X4
Board Information Record:
Address 0x00: 54 32 30 32 37 45 43 2d 34 34 47 42 00 00 00 00
I2C Hex Data:
Address 0x00: 7f b0 02 ff 0c 1a 01 01 52 45 56 20 30 31 00 00
Address 0x10: 00 00 00 00 37 34 30 2d 30 35 36 36 35 38 00 00
Address 0x20: 39 30 30 39 31 38 36 33 34 32 00 00 00 05 02 07
Address 0x30: de ff ff ff 54 32 30 32 37 45 43 2d 34 34 47 42
Address 0x40: 00 00 00 00 01 43 4f 55 43 41 54 54 42 41 41 53
Address 0x50: 52 58 35 4b 2d 52 45 2d 31 38 30 30 58 34 00 00
Address 0x60: 00 00 00 00 00 00 41 30 30 ff ff ff ff ff ff ff
Address 0x70: ff ff ff 64 ff ff ff ff ff ff ff ff ff ff ff ff
ad0 3998 MB Virtium - TuffDrive VCF P1T0200313161216 109 Compact Flash
ad1 28843 MB UGB94BPH32H0S2-KCI 11000160387 Disk 1
usb0 (addr 1) product 0x0000 0 vendor 0x0000 uhub0
usb0 (addr 2) product 0x0020 32 vendor 0x8087 uhub1
DIMM 0 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80
DIMM 1 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80
DIMM 2 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80

Copyright © 2016, Juniper Networks, Inc. 391

Chassis Cluster Feature Guide for Branch SRX Series Devices

DIMM 3 SGU04G72H1BD2SA-BB DIE REV-52 PCB REV-54 MFR ID-ce80

CB 0 REV 01 750-062257 CAEB8178 SRX5k SCB3
Jedec Code: 0x7fb0 EEPROM Version: 0x02
P/N: 750-062257 S/N: CAEB8178
Assembly ID: 0x0c59 Assembly Version: 01.01
Date: 03-19-2015 Assembly Flags: 0x00
Version: REV 01 CLEI Code: CLEI-CODE
ID: SRX5k SCB3 FRU Model Number: SRX5K-SCB3
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
I2C Hex Data:
Address 0x00: 7f b0 02 ff 0c 59 01 01 52 45 56 20 30 31 00 00
Address 0x10: 00 00 00 00 37 35 30 2d 30 36 32 32 35 37 00 00
Address 0x20: 53 2f 4e 20 43 41 45 42 38 31 37 38 00 13 03 07
Address 0x30: df ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x40: ff ff ff ff 01 43 4c 45 49 2d 43 4f 44 45 20 53
Address 0x50: 52 58 35 4b 2d 53 43 42 33 20 20 20 20 20 20 20
Address 0x60: 20 20 20 20 20 20 31 30 31 ff ff ff ff ff ff ff
Address 0x70: ff ff ff 63 ff ff ff ff ff ff ff ff ff ff ff ff
FPC 2 REV 01 750-062243 CAED0386 SRX5k IOC3 24XGE+6XLG
Jedec Code: 0x7fb0 EEPROM Version: 0x01
P/N: 750-062243 S/N: CAED0386
Assembly ID: 0x0c57 Assembly Version: 01.01
Date: 04-28-2015 Assembly Flags: 0x00
Version: REV 01
ID: SRX5k IOC3 24XGE+6XLG
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ae 01 f2 06 00 ff
I2C Hex Data:
Address 0x00: 7f b0 01 fe 0c 57 01 01 52 45 56 20 30 31 00 00
Address 0x10: 00 00 00 00 37 35 30 2d 30 36 32 32 34 33 00 00
Address 0x20: 53 2f 4e 20 43 41 45 44 30 33 38 36 00 1c 04 07
Address 0x30: df ff ff ff ff ff ff ff ff ff ff ff ff ff ae 01
Address 0x40: f2 06 00 ff 01 00 00 00 00 00 00 00 00 00 00 00
Address 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff
Address 0x70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
CPU REV 01 711-062244 CADX8554 SRX5k IOC3 PMB
Jedec Code: 0x7fb0 EEPROM Version: 0x01
P/N: 711-062244 S/N: CADX8554
Assembly ID: 0x0c5a Assembly Version: 01.01
Date: 04-28-2015 Assembly Flags: 0x00
Version: REV 01
ID: SRX5k IOC3 PMB
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
I2C Hex Data:
Address 0x00: 7f b0 01 ff 0c 5a 01 01 52 45 56 20 30 31 00 00
Address 0x10: 00 00 00 00 37 31 31 2d 30 36 32 32 34 34 00 00
Address 0x20: 53 2f 4e 20 43 41 44 58 38 35 35 34 00 1c 04 07
Address 0x30: df ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x40: ff ff ff ff 00 ff ff ff ff ff ff ff ff ff ff ff
Address 0x50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x70: ff ff ff ff 00 00 00 00 2a 47 7e 50 10 05 76 5c
PIC 0 BUILTIN BUILTIN 12x 10GE SFP+
Jedec Code: 0x0000 EEPROM Version: 0x00
P/N: BUILTIN S/N: BUILTIN
Assembly ID: 0x0ab5 Assembly Version: 00.00
Date: 00-00-0000 Assembly Flags: 0x00
ID: 12x 10GE SFP+

392 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Board Information Record:

Address 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I2C Hex Data:
Address 0x00: 00 00 00 00 0a b5 00 00 00 00 00 00 00 00 00 00
Address 0x10: 00 00 00 00 42 55 49 4c 54 49 4e 00 25 73 3a 20
Address 0x20: 42 55 49 4c 54 49 4e 00 25 73 3a 20 00 00 00 00
Address 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x70: 00 00 00 00 c0 02 a9 3c 00 00 00 00 0a b6 00 00
PIC 1 BUILTIN BUILTIN 12x 10GE SFP+
Jedec Code: 0x0000 EEPROM Version: 0x00
P/N: BUILTIN S/N: BUILTIN
Assembly ID: 0x0ab5 Assembly Version: 00.00
Date: 00-00-0000 Assembly Flags: 0x00
ID: 12x 10GE SFP+
Board Information Record:
Address 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I2C Hex Data:
Address 0x00: 00 00 00 00 0a b5 00 00 00 00 00 00 00 00 00 00
Address 0x10: 00 00 00 00 42 55 49 4c 54 49 4e 00 25 73 3a 20
Address 0x20: 42 55 49 4c 54 49 4e 00 25 73 3a 20 00 00 00 00
Address 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x70: 00 00 00 00 c0 02 e9 b4 00 00 00 00 0a b5 00 00
PIC 2 BUILTIN BUILTIN 3x 40GE QSFP+
Jedec Code: 0x0000 EEPROM Version: 0x00
P/N: BUILTIN S/N: BUILTIN
Assembly ID: 0x0ab6 Assembly Version: 00.00
Date: 00-00-0000 Assembly Flags: 0x00
ID: 3x 40GE QSFP+
Board Information Record:
Address 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I2C Hex Data:
Address 0x00: 00 00 00 00 0a b6 00 00 00 00 00 00 00 00 00 00
Address 0x10: 00 00 00 00 42 55 49 4c 54 49 4e 00 25 73 3a 20
Address 0x20: 42 55 49 4c 54 49 4e 00 25 73 3a 20 00 00 00 00
Address 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x70: 00 00 00 00 c0 03 e8 c4 33 24 3a 38 00 00 00 02
PIC 3 BUILTIN BUILTIN 3x 40GE QSFP+
Jedec Code: 0x0000 EEPROM Version: 0x00
P/N: BUILTIN S/N: BUILTIN
Assembly ID: 0x0ab6 Assembly Version: 00.00
Date: 00-00-0000 Assembly Flags: 0x00
ID: 3x 40GE QSFP+
Board Information Record:
Address 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I2C Hex Data:
Address 0x00: 00 00 00 00 0a b6 00 00 00 00 00 00 00 00 00 00
Address 0x10: 00 00 00 00 42 55 49 4c 54 49 4e 00 25 73 3a 20
Address 0x20: 42 55 49 4c 54 49 4e 00 25 73 3a 20 00 00 00 00
Address 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Copyright © 2016, Juniper Networks, Inc. 393

Chassis Cluster Feature Guide for Branch SRX Series Devices

Address 0x70: 00 00 00 00 c0 02 ab 1c 00 00 00 00 0a b5 00 00
WAN MEZZ REV 01 750-062682 CAEA4788 24x 10GE SFP+ Mezz
Jedec Code: 0x7fb0 EEPROM Version: 0x01
P/N: 750-062682 S/N: CAEA4788
Assembly ID: 0x0c76 Assembly Version: 01.01
Date: 04-28-2015 Assembly Flags: 0x00
Version: REV 01
ID: 24x 10GE SFP+ Mezz
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
I2C Hex Data:
Address 0x00: 7f b0 01 ff 0c 76 01 01 52 45 56 20 30 31 00 00
Address 0x10: 00 00 00 00 37 35 30 2d 30 36 32 36 38 32 00 00
Address 0x20: 53 2f 4e 20 43 41 45 41 34 37 38 38 00 1c 04 07
Address 0x30: df ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x40: ff ff ff ff 00 ff ff ff ff ff ff ff ff ff ff ff
Address 0x50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x70: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00
FPC 4 REV 11 750-043157 CACY1592 SRX5k IOC II
Jedec Code: 0x7fb0 EEPROM Version: 0x02
P/N: 750-043157 S/N: CACY1592
Assembly ID: 0x0bd1 Assembly Version: 04.11
Date: 07-30-2014 Assembly Flags: 0x00
Version: REV 11 CLEI Code: COUIBCWBAA
ID: SRX5k IOC II FRU Model Number: SRX5K-MPC
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ae 01 f2 06 00 ff
I2C Hex Data:
Address 0x00: 7f b0 02 ff 0b d1 04 0b 52 45 56 20 31 31 00 00
Address 0x10: 00 00 00 00 37 35 30 2d 30 34 33 31 35 37 00 00
Address 0x20: 53 2f 4e 20 43 41 43 59 31 35 39 32 00 1e 07 07
Address 0x30: de ff ff ff ff ff ff ff ff ff ff ff ff ff ae 01
Address 0x40: f2 06 00 ff 01 43 4f 55 49 42 43 57 42 41 41 53
Address 0x50: 52 58 35 4b 2d 4d 50 43 00 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 41 00 00 ff ff ff ff ff ff ff
Address 0x70: ff ff ff 92 ff ff ff ff ff ff ff ff ff ff ff ff
CPU REV 04 711-043360 CACZ8831 SRX5k MPC PMB
Jedec Code: 0x7fb0 EEPROM Version: 0x01
P/N: 711-043360 S/N: CACZ8831
Assembly ID: 0x0bd2 Assembly Version: 01.04
Date: 07-28-2014 Assembly Flags: 0x00
Version: REV 04
ID: SRX5k MPC PMB
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
I2C Hex Data:
Address 0x00: 7f b0 01 ff 0b d2 01 04 52 45 56 20 30 34 00 00
Address 0x10: 00 00 00 00 37 31 31 2d 30 34 33 33 36 30 00 00
Address 0x20: 53 2f 4e 20 43 41 43 5a 38 38 33 31 00 1c 07 07
Address 0x30: de ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x40: ff ff ff ff 00 ff ff ff ff ff ff ff ff ff ff ff
Address 0x50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Address 0x70: ff ff ff ff 00 00 00 00 49 fa 60 10 40 05 76 5c
MIC 1 REV 04 750-049488 CACN0239 10x 10GE SFP+
Jedec Code: 0x7fb0 EEPROM Version: 0x02
P/N: 750-049488 S/N: CACN0239
Assembly ID: 0x0a88 Assembly Version: 02.04
Date: 02-26-2014 Assembly Flags: 0x00
Version: REV 04 CLEI Code: COUIBCXBAA

394 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

ID: 10x 10GE SFP+ FRU Model Number: SRX-MIC-10XG-SFPP

Board Information Record:
Address 0x00: 34 01 03 03 ff ff ff ff ff ff ff ff ff ff ff ff
I2C Hex Data:
Address 0x00: 7f b0 02 ff 0a 88 02 04 52 45 56 20 30 34 00 00
Address 0x10: 00 00 00 00 37 35 30 2d 30 34 39 34 38 38 00 00
Address 0x20: 53 2f 4e 20 43 41 43 4e 30 32 33 39 00 1a 02 07
Address 0x30: de ff ff ff 34 01 03 03 ff ff ff ff ff ff ff ff
Address 0x40: ff ff ff ff 01 43 4f 55 49 42 43 58 42 41 41 53
Address 0x50: 52 58 2d 4d 49 43 2d 31 30 58 47 2d 53 46 50 50
Address 0x60: 00 00 00 00 00 00 41 00 00 ff ff ff ff ff ff ff
Address 0x70: ff ff ff 9f c0 03 e4 14 55 8a 95 a8 00 00 00 02
PIC 2 BUILTIN BUILTIN 10x 10GE SFP+
Xcvr 7 REV 01 740-031980 ARN23HW SFP+-10G-SR
Xcvr 8 REV 01 740-031980 ARN2FVW SFP+-10G-SR
Xcvr 9 REV 01 740-031980 ARN2YVM SFP+-10G-SR
FPC 5 REV 10 750-056758 CADA8736 SRX5k SPC II
Jedec Code: 0x7fb0 EEPROM Version: 0x02
P/N: 750-056758 S/N: CADA8736
Assembly ID: 0x0b4f Assembly Version: 01.10
Date: 09-01-2014 Assembly Flags: 0x00
Version: REV 10 CLEI Code: COUCATLBAB
ID: SRX5k SPC II FRU Model Number: SRX5K-SPC-4-15-320
Board Information Record:
Address 0x00: ff ff ff ff ff ff ff ff ff ff ae 01 f2 06 00 ff
I2C Hex Data:
Address 0x00: 7f b0 02 ff 0b 4f 01 0a 52 45 56 20 31 30 00 00
Address 0x10: 00 00 00 00 37 35 30 2d 30 35 36 37 35 38 00 00
Address 0x20: 53 2f 4e 20 43 41 44 41 38 37 33 36 00 01 09 07
Address 0x30: de ff ff ff ff ff ff ff ff ff ff ff ff ff ae 01
Address 0x40: f2 06 00 ff 01 43 4f 55 43 41 54 4c 42 41 42 53
Address 0x50: 52 58 35 4b 2d 53 50 43 2d 34 2d 31 35 2d 33 32
Address 0x60: 30 00 00 00 00 00 43 00 00 ff ff ff ff ff ff ff
Address 0x70: ff ff ff 50 ff ff ff ff ff ff ff ff ff ff ff ff
CPU BUILTIN BUILTIN SRX5k DPC PPC
PIC 0 BUILTIN BUILTIN SPU Cp
Jedec Code: 0x0000 EEPROM Version: 0x00
P/N: BUILTIN S/N: BUILTIN
Assembly ID: 0x0a20 Assembly Version: 00.00
Date: 00-00-0000 Assembly Flags: 0x00
ID: SPU Cp
Board Information Record:
Address 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I2C Hex Data:
Address 0x00: 00 00 00 00 0a 20 00 00 00 00 00 00 00 00 00 00
Address 0x10: 00 00 00 00 42 55 49 4c 54 49 4e 00 41 73 73 65
Address 0x20: 42 55 49 4c 54 49 4e 00 41 73 73 65 00 00 00 00
Address 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x70: 00 00 00 00 de ad be ef 46 10 f0 d8 40 43 43 c0
PIC 1 BUILTIN BUILTIN SPU Flow
Jedec Code: 0x0000 EEPROM Version: 0x00
P/N: BUILTIN S/N: BUILTIN
Assembly ID: 0x0a21 Assembly Version: 00.00
Date: 00-00-0000 Assembly Flags: 0x00
ID: SPU Flow
Board Information Record:
Address 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I2C Hex Data:

Copyright © 2016, Juniper Networks, Inc. 395

Chassis Cluster Feature Guide for Branch SRX Series Devices

Address 0x00: 00 00 00 00 0a 21 00 00 00 00 00 00 00 00 00 00
Address 0x10: 00 00 00 00 42 55 49 4c 54 49 4e 00 41 73 73 65
Address 0x20: 42 55 49 4c 54 49 4e 00 41 73 73 65 00 00 00 00
Address 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x70: 00 00 00 00 de ad be ef 46 13 5b d0 40 43 43 c0
PIC 2 BUILTIN BUILTIN SPU Flow
Jedec Code: 0x0000 EEPROM Version: 0x00
P/N: BUILTIN S/N: BUILTIN
Assembly ID: 0x0a21 Assembly Version: 00.00
Date: 00-00-0000 Assembly Flags: 0x00
ID: SPU Flow
Board Information Record:
Address 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I2C Hex Data:
Address 0x00: 00 00 00 00 0a 21 00 00 00 00 00 00 00 00 00 00
Address 0x10: 00 00 00 00 42 55 49 4c 54 49 4e 00 41 73 73 65
Address 0x20: 42 55 49 4c 54 49 4e 00 41 73 73 65 00 00 00 00
Address 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Address 0x70: 00 00 00 00 de ad be ef 46 0c 66 40 40 43 43 c0
PIC 3 BUILTIN BUILTIN SPU Flow
Jedec Code: 0x0000 EEPROM Version: 0x00
P/N: BUILTIN S/N: BUILTIN
Assembly ID: 0x0a21 Assembly Version: 00.00
Date: 00-00-0000 Assembly Flags: 0x00
ID: SPU Flow
Board Information Record:
Address 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I2C Hex Data:
Address 0x00: 00 00 00 00 0a 21 00 00 00 00 00 00 00 00
00 00
Address 0x10: 00 00 00 00 42 55 49 4c 54 49 4e 00 41 73
73 65
Address 0x20: 42 55 49 4c 54 49 4e 00 41 73 73 65 00 00
00 00
Address 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
Address 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
Address 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
Address 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
Address 0x70: 00 00 00 00 de ad be ef 46 0e db 00 40 43
43 c0
Fan Tray Enhanced Fan Tray
FRU Model Number: SRX5600-HC-FAN

show chassis hardware clei-models

show chassis hardware clei-models
(SRX5600 and SRX5800 devices with SRX5000 line SRX5K-SCBE (SCB2) and SRX5K-RE-1800X4 (RE2)
user@host> show chassis hardware clei-models node 1
node1:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number CLEI code FRU model number
Midplane REV 01 710-024803 SRX5800-BP-A
FPM Board REV 01 710-024632 SRX5800-CRAFT-A
PEM 0 Rev 04 740-034724 SRX5800-PWR-4100-AC
PEM 1 Rev 05 740-034724 SRX5800-PWR-4100-AC
Routing Engine 0 REV 01 740-056658 COUCATTBAA SRX5K-RE-1800X4
CB 0 REV 01 750-056587 COUCATSBAA SRX5K-SCBE

396 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

CB 1 REV 01 750-056587 COUCATSBAA SRX5K-SCBE

CB 2 REV 01 750-056587 COUCATSBAA SRX5K-SCBE
FPC 0 REV 18 750-054877 COUCATLBAA SRX5K-SPC-4-15-320
CPU BUILTIN
FPC 1 REV 18 750-054877 COUCATLBAA SRX5K-SPC-4-15-320
CPU BUILTIN
FPC 2 REV 18 750-054877 COUCATLBAA SRX5K-SPC-4-15-320
CPU BUILTIN
FPC 3 REV 11 750-043157 COUIBCWBAA SRX5K-MPC
MIC 0 REV 05 750-049486 COUIBCYBAA SRX-MIC-1X100G-CFP
MIC 1 REV 04 750-049488 COUIBCXBAA SRX-MIC-10XG-SFPP
FPC 4 REV 18 750-054877 COUCATLBAA SRX5K-SPC-4-15-320
CPU BUILTIN
FPC 7 REV 18 750-054877 COUCATLBAA SRX5K-SPC-4-15-320
CPU BUILTIN
FPC 8 REV 11 750-043157 COUIBCWBAA SRX5K-MPC
MIC 0 REV 05 750-049486 COUIBCYBAA SRX-MIC-1X100G-CFP
FPC 9 REV 18 750-054877 COUCATLBAA SRX5K-SPC-4-15-320
CPU BUILTIN
FPC 10 REV 18 750-054877 COUCATLBAA SRX5K-SPC-4-15-320
CPU BUILTIN
Fan Tray 0 REV 04 740-035409 SRX5800-HC-FAN
Fan Tray 1 REV 04 740-035409 SRX5800-HC-FAN

show chassis hardware clei-models

(SRX5400, SRX5600, and SRX5800 devices with SRX5000 line SRX5K-SCB3 (SCB3) with enhanced midplanes
and SRX5K-MPC3-100G10G (IOC3) or SRX5K-MPC3-40G10G (IOC3))
user@host> show chassis hardware clei-models
node0:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number CLEI code FRU model number
Midplane REV 01 760-063936 CLEI-CODE SRX5600X-CHAS
FPM Board REV 02 710-017254 CRAFT-MX480-S
PEM 0 Rev 03 740-034701 SRX5600-PWR-2520-AC-S
PEM 1 Rev 03 740-034701 SRX5600-PWR-2520-AC-S
Routing Engine 0 REV 01 740-056658 COUCATTBAA SRX5K-RE-1800X4
CB 0 REV 01 750-062257 CLEI-CODE SRX5K-SCB3
FPC 0 REV 10 750-056758 COUCATLBAB SRX5K-SPC-4-15-320
CPU BUILTIN
FPC 2 REV 01 750-062243
FPC 4 REV 11 750-043157 COUIBCWBAA SRX5K-MPC
MIC 1 REV 04 750-049488 COUIBCXBAA SRX-MIC-10XG-SFPP
FPC 5 REV 05 750-044175 PROTOXCLEI 750-044175
CPU BUILTIN
Fan Tray SRX5600-HC-FAN

node1:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number CLEI code FRU model number
Midplane REV 01 760-063936 CLEI-CODE SRX5600X-CHAS
PEM 0 Rev 01 740-038514 SRX5600-PWR-2400-DC-S
PEM 1 Rev 01 740-038514 SRX5600-PWR-2400-DC-S
Routing Engine 0 REV 01 740-056658 COUCATTBAA SRX5K-RE-1800X4
CB 0 REV 01 750-062257 CLEI-CODE SRX5K-SCB3
FPC 0 REV 07 750-044175 COUCASFBAA SRX5K-SPC-4-15-320
CPU BUILTIN
FPC 4 REV 11 750-043157 COUIBCWBAA SRX5K-MPC
MIC 1 REV 04 750-049488 COUIBCXBAA SRX-MIC-10XG-SFPP

Copyright © 2016, Juniper Networks, Inc. 397

Chassis Cluster Feature Guide for Branch SRX Series Devices

FPC 5 REV 10 750-056758 COUCATLBAB SRX5K-SPC-4-15-320

CPU BUILTIN
Fan Tray SRX5600-HC-FAN

398 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

show chassis routing-engine (View)

Supported Platforms SRX Series, vSRX

Syntax show chassis routing-engine

Release Information Command introduced in Junos OS Release 9.5.

Description Display the Routing Engine status of the chassis cluster.

Required Privilege view

Level

Related • cluster (Chassis) on page 270

Documentation
• request system snapshot (Maintenance)

List of Sample Output show chassis routing-engine (Sample 1 - SRX550) on page 400
show chassis routing-engine (Sample 2- vSRX) on page 400

Output Fields Table 45 on page 399 lists the output fields for the show chassis routing-engine command.
Output fields are listed in the approximate order in which they appear.

Table 45: show chassis routing-engine Output Fields

Field Name Field Description

Temperature Routing Engine temperature. (Not available for vSRX deployments.)

CPU temperature CPU temperature. (Not available for vSRX deployments.)

Total memory Total memory available on the system.

Control plane memory Memory available for the control plane.

Data plane memory Memory reserved for data plane processing.

CPU utilization Current CPU utilization statistics on the control plane core.

User Current CPU utilization in user mode on the control plane core.

Background Current CPU utilization in nice mode on the control plane core.

Kernel Current CPU utilization in kernel mode on the control plane core.

Interrupt Current CPU utilization in interrupt mode on the control plane core.

Idle Current CPU utilization in idle mode on the control plane core.

Model Routing Engine model.

Copyright © 2016, Juniper Networks, Inc. 399

Chassis Cluster Feature Guide for Branch SRX Series Devices

Table 45: show chassis routing-engine Output Fields (continued)

Field Name Field Description

Start time Routing Engine start time.

Uptime Length of time the Routing Engine has been up (running) since the last start.

Last reboot reason Reason for the last reboot of the Routing Engine.

Load averages The average number of threads waiting in the run queue or currently executing over 1-,
5-, and 15-minute periods.

Sample Output
show chassis routing-engine (Sample 1 - SRX550)
user@host> show chassis routing-engine
Routing Engine status:
Temperature 38 degrees C / 100 degrees F
CPU temperature 36 degrees C / 96 degrees F
Total memory 512 MB Max 435 MB used ( 85 percent)
Control plane memory 344 MB Max 296 MB used ( 86 percent)
Data plane memory 168 MB Max 138 MB used ( 82 percent)
CPU utilization:
User 8 percent
Background 0 percent
Kernel 4 percent
Interrupt 0 percent
Idle 88 percent
Model RE-SRX5500-LOWMEM
Serial ID AAAP8652
Start time 2009-09-21 00:04:54 PDT
Uptime 52 minutes, 47 seconds
Last reboot reason 0x200:chassis control reset
Load averages: 1 minute 5 minute 15 minute
0.12 0.15 0.10

Sample Output
show chassis routing-engine (Sample 2- vSRX)
user@host> show chassis routing-engine
Routing Engine status:
Total memory 1024 MB Max 358 MB used ( 35 percent)
Control plane memory 1024 MB Max 358 MB used ( 35 percent)
5 sec CPU utilization:
User 2 percent
Background 0 percent
Kernel 4 percent
Interrupt 6 percent
Idle 88 percent
Model VSRX RE
Start time 2015-03-03 07:04:18 UTC
Uptime 2 days, 11 hours, 51 minutes, 11 seconds
Last reboot reason Router rebooted after a normal shutdown.
Load averages: 1 minute 5 minute 15 minute
0.07 0.04 0.06

400 Copyright © 2016, Juniper Networks, Inc.

 Chapter 25: Operational Commands

Copyright © 2016, Juniper Networks, Inc. 401

Chassis Cluster Feature Guide for Branch SRX Series Devices

show configuration chassis cluster traceoptions

Supported Platforms SRX Series, vSRX

Syntax show configuration chassis cluster traceoptions

Release Information Command introduced in Junos OS Release 12.1.

Description Display tracing options for the chassis cluster redundancy process.

Required Privilege view

Level

Related • cluster (Chassis) on page 270

Documentation
• traceoptions (Chassis Cluster) on page 302

List of Sample Output show configuration chassis cluster traceoptions on page 402

Output Fields Table 46 on page 402 lists the output fields for the show configuration chassis cluster
traceoptions command. Output fields are listed in the approximate order in which they
appear.

Table 46: show configuration chassis cluster traceoptions Output Fields

Field Name Field Description

file Name of the file that receives the output of the tracing operation.

size Size of each trace file.

files Maximum number of trace files.

Sample Output
show configuration chassis cluster traceoptions
user@host> show configuration chassis cluster traceoptions
file chassis size 10k files 300;
level all;

402 Copyright © 2016, Juniper Networks, Inc.

PART 7

Index
• Index on page 405

Copyright © 2016, Juniper Networks, Inc. 403

Chassis Cluster Feature Guide for Branch SRX Series Devices

404 Copyright © 2016, Juniper Networks, Inc.

 hardware setup for SRX Series devices................43
interface monitoring example.................................106
LAG and LACP configuration example...............248
layer 2 Ethernet switching........................................243
management interface configuration
Index example.........................................................................53
management interfaces on SRX Series
devices...........................................................................53
Symbols minimum links configuration example.................178
#, comments in configuration statements...................xvi node interfaces on SRX Series devices..................47
( ), in syntax descriptions....................................................xvi ntp time synchronization...........................................183
< >, in syntax descriptions...................................................xvi number of redundant Ethernet interfaces
[ ], in configuration statements.........................................xvi configuration example............................................84
{ }, in configuration statements........................................xvi redundancy group configuration..............................73
| (pipe), in syntax descriptions..........................................xvi redundancy group IP address monitoring
configuration example...........................................136
A redundancy groups.......................................................69
aborting redundant Ethernet interface configuration
chassis cluster ICU......................................................255 example.........................................................................79
ICU upgrade...................................................................257 redundant Ethernet interface link aggregation
group configuration example...............................167
B redundant Ethernet interfaces.................................173
braces, in configuration statements................................xvi switching fabric interfaces configuration
brackets example......................................................................245
angle, in syntax descriptions.....................................xvi synchronizing network time protocol...................183
square, in configuration statements.......................xvi understanding LACP....................................................173
verifying.............................................................................99
C verifying statistics..........................................................99
chassis verifying status..............................................................148
environmental information, displaying...............353 VLAN and IRB configuration example.................246
chassis cluster Chassis Configuration Statement Hierarchy.............264
configuration synchronization..................................181 clear chassis cluster control-plane statistics
ICU aborting...................................................................255 command............................................................................307
ICU upgrading...............................................................255 clear chassis cluster data-plane statistics
Chassis cluster configuration synchronization...........181 command...........................................................................308
chassis cluster configuration synchronization clear chassis cluster failover-count
verifying............................................................................182 command...........................................................................309
chassis clusters clear chassis cluster ip-monitoring
aggregated Ethernet interfaces...............................173 failure-count........................................................................311
cluster ID and node ID configuration clear chassis cluster ip-monitoring failure-count
example..........................................................................51 ip-address............................................................................312
conditional route advertising configuration clear chassis cluster statistics command....................313
example......................................................................160 cluster statement.................................................................270
configuring LACP...........................................................175 cluster-id..................................................................................323
creating an SRX Series cluster..................................36 comments, in configuration statements.......................xvi
dampening time configuration example.............142 conditional route advertising configuration................159
disabling..........................................................................259
fabric configuration example.....................................61
formation...........................................................................35

Copyright © 2016, Juniper Networks, Inc. 405

Chassis Cluster Feature Guide for Branch SRX Series Devices

configuring I
conditional route advertising...................................159 in-band cluster upgrade
interface monitoring...................................................106 aborting...........................................................................257
redundant Ethernet interfaces..................................79 chassis cluster..............................................................255
control link.................................................................................65 using FTP Server..........................................................256
control-link-recovery statement.....................................272 using local build...........................................................256
conventions Index is the statement name. Example - action
text and syntax................................................................xv statement...........................................................................287
creating an SRX Series chassis cluster...........................36 initiating manual redundancy group failover.............146
curly braces, in configuration statements.....................xvi interface monitoring configuration................................106
customer support..................................................................xvii interface statement.............................................................282
contacting JTAC.............................................................xvii interface-monitor statement...........................................283
interfaces
D redundant Ethernet......................................................173
data interfaces on SRX Series devices
fabric (dual).....................................................................151 management...................................................................53
forwarding........................................................................59 node.....................................................................................47
plane....................................................................................57 ip-monitoring statement...................................................284
device-count statement.....................................................272
disabling L
chassis clusters............................................................259 LACP (Link Aggregation Control Protocol)
documentation configuring on chassis clusters................................175
comments on.................................................................xvii understanding in chassis cluster mode................173
lacp statement......................................................................285
E link-protection statement................................................286
environmental information
chassis, displaying.......................................................353 M
management interfaces.......................................................53
F manuals
fabric data link (dual)...........................................................151 comments on.................................................................xvii
fabric data-link failure...........................................................59 member-interfaces statement.......................................286
fabric monitoring....................................................................59
fabric-options statement..................................................274 N
font conventions......................................................................xv node interfaces on SRX Series devices...........................47
FPC node statement
operation of, controlling............................................318 (Cluster)....................................269, 271, 273, 275, 288
(Redundancy-Group)................................................288
G
global-threshold statement.............................................276 P
global-weight statement...................................................277 parentheses, in syntax descriptions................................xvi
gratuitous-arp-count statement....................................278 preempt statement.............................................................289
priority statement................................................................289
H
hardware setup, chassis cluster........................................43 R
heartbeat-interval statement..........................................279 redundancy group
heartbeat-threshold statement.....................................280 initiating manual failover...........................................146
hold-down-interval statement........................................281

406 Copyright © 2016, Juniper Networks, Inc.

 Index

redundancy groups show chassis cluster information

about..................................................................................69 configuration-synchronization....................................336
interface monitoring....................................................105 show chassis cluster interfaces command................338
IP address monitoring.................................................133 show chassis cluster ip-monitoring status
redundancy-group statement........................................290 redundancy-group command.....................................343
redundant Ethernet interface LAG.................................165 show chassis cluster statistics command.................346
redundant Ethernet interfaces show chassis cluster status command.......................350
configuring........................................................................79 show chassis environment command.........................353
understanding..........................................................77, 173 show chassis fabric plane command............................361
redundant-ether-options statement...........................292 show chassis hardware command................................372
redundant-parent show chassis routing-engine command.....................399
interfaces........................................................................293 show configuration chassis cluster traceoptions
redundant-pseudo-interface-options.........................293 command...........................................................................402
request chassis cluster configuration-synchronize SNMP failover traps.............................................................145
command............................................................................314 support, technical See technical support
request chassis cluster failover node syntax conventions.................................................................xv
command............................................................................315
request chassis cluster failover redundancy-group T
command............................................................................316 technical support
request chassis cluster failover reset contacting JTAC.............................................................xvii
command.............................................................................317 traceoptions statement.....................................................302
request chassis fpc command.........................................318
request system software in-service-upgrade U
command............................................................................319 upgrading
reth build on FTP Server....................................................256
link aggregation group................................................165 chassis cluster ICU......................................................255
reth statement primary node of cluster.............................................256
interfaces........................................................................295
reth-count statement.........................................................294 V
retry-count statement.......................................................300 verifying
retry-interval statement.....................................................301 chassis cluster configuration
route-active-on statement...............................................301 synchronization.........................................................182
chassis cluster statistics.............................................99
S chassis cluster status.................................................148
Security Configuration Statement Hierarchy.............267 chassis clusters..............................................................99
set chassis cluster cluster-id node reboot command
.................................................................................................323 W
show chassis cluster control-plane statistics weight statement................................................................304
command............................................................................324
show chassis cluster data-plane interfaces
command...........................................................................326
show chassis cluster data-plane statistics
command............................................................................327
show chassis cluster ethernet-switching interfaces
command...........................................................................329
show chassis cluster ethernet-switching status
command...........................................................................330
show chassis cluster information...................................332

Copyright © 2016, Juniper Networks, Inc. 407

Chassis Cluster Feature Guide for Branch SRX Series Devices

408 Copyright © 2016, Juniper Networks, Inc.