Juniper Interchassis Redundancy Using Virtual User Manual

Junos® OS

Interchassis Redundancy Using Virtual Chassis User Guide for MX Series Routers

Published

2021-04-18

ii

Juniper Networks, Inc. 1133 nn v n Way Sunnyvale, California 94089 USA

408-745-2000 www.juniper.net

Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their r s c v 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 b c n without n c

Junos® OS Interchassis Redundancy Using Virtual Chassis User Guide for MX Series Routers

Copyright © 2021 Juniper Networks, Inc. All rights reserved.

The n rm n in this document is current as of the date on the page.

YEAR 2000 NOTICE

Juniper Networks hardware and s ftw r products are Year 2000 compliant. Junos OS has no known m r

m ns through the year 2038. However, the NTP c n is known to have some c y in the year 2036.

END USER LICENSE AGREEMENT

The Juniper Networks product that is the subject of this technical						c m n	n consists of (or is intended for use
with) Juniper Networks s ftw r	Use of such s		ftw r	is subject to the terms and c n				ns of the End User License
Agreement ("EULA") posted at	s s	r	n r n	s	r	. By downloading, installing or using such
s ftw r you agree to the terms and c n		ns of that EULA.

iii

Table of Contents

About This Guide | x

1Understanding How Virtual Chassis Provides Interchassis Redundancy

Interchassis Redundancy and Virtual Chassis Overview | 2

2Understanding How a Virtual Chassis Works

Virtual Chassis Components Overview | 7
Global Roles and Local Roles in a Virtual Chassis | 15
C n	r n a Virtual Chassis Heartbeat C nn c n | 18
Primary-role		c n in a Virtual Chassis | 26
Switchover Behavior in an MX Series Virtual Chassis | 28
Command Forwarding in a Virtual Chassis | 32
Split	c	n Behavior in a Virtual Chassis | 52

3	C	n	r n a Virtual Chassis
	C	n	r n	Interchassis Redundancy for MX Series 5G Universal R				n	rms
		Using a Virtual Chassis | 61
	Preparing for a Virtual Chassis C n					r	n | 62
	Cr		n and Applying C n r			n Groups for a Virtual Chassis | 65
	C	n	r n	Preprovisioned Member n			rm n for a Virtual Chassis | 67
	C	n	r n	Enhanced IP Network Services for a Virtual Chassis | 70
	C n		r n	Enhanced LAN Mode for a Virtual Chassis | 72
	Enabling Graceful R				n Engine Switchover and Nonstop c v R			n for a Virtual
		Chassis | 74
	C	n	r n	Member IDs for a Virtual Chassis | 76
	Example: C			n r n	Interchassis Redundancy for MX Series 5G Universal R				n
			rms Using a Virtual Chassis | 80

iv

Requirements | 81

Overview and Topology | 82

C n

r

n | 86

V r

c

n | 99

C n

r n

an MX2020 Member Router in an

x s

n

MX Series Virtual Chassis | 104

Switching the Global Primary and Backup Roles in a Virtual Chassis C

n

r

n | 107

n

Member IDs in a Virtual Chassis C

n

r

n | 109

Disabling Split

c n in a Virtual Chassis C

n

r

n | 110

Example: Replacing a R

n Engine in a Virtual Chassis C n r

n for MX Series 5G

Universal R

n

rms | 112

Requirements | 112

Overview and Topology | 113

C n

r

n | 117

V r

c

n | 121

n

a Virtual Chassis C n

r n for MX Series 5G Universal R

n

rms | 126

Example:

n

a Virtual Chassis C n

r

n for MX Series 5G Universal R

n

rms | 128

Requirements | 128

Overview and Topology | 129

C n

r

n | 133

V r

c

n | 142

Upgrading an MX Virtual Chassis SCB or SCBE to SCBE2 | 146

Preparing for the SCBE2 Upgrade | 146

Powering

the MX Series Router | 147

Removing an MX Series R

n

Engine from an SCB or SCBE | 148

Replacing the SCB or SCBE with SCBE2 | 148

Installing the MX Series R

n

Engine into an SCBE2 | 148

4

5

6

7

v

Powering On the MX Series Router | 149
C	n	r n	Member IDs for the Virtual Chassis | 150
C	n	r n	Virtual Chassis Ports | 151
C m		n	the SCBE2 Upgrade | 153

C	n	r n Virtual Chassis Ports to Interconnect Member Devices
Guidelines for C n r n Virtual Chassis Ports | 156
C	n	r n Virtual Chassis Ports to Interconnect Member Routers or Switches | 158
	n	Virtual Chassis Ports in a Virtual Chassis C n r n | 161

C n	r n Locality Bias to Conserve Bandwidth on Virtual Chassis Ports
Locality Bias in a Virtual Chassis | 165
Guidelines for C n r n Locality Bias in a Virtual Chassis | 167
C n	r n Locality Bias for a Virtual Chassis | 168

C n		r n	Class of Service for Virtual Chassis Ports
Class of Service Overview for Virtual Chassis Ports | 171
Guidelines for C				n r n	Class of Service for Virtual Chassis Ports | 177
Example: C n				r n Class of Service for Virtual Chassis Ports on MX Series 5G
	Universal R			n	rms | 178
	Requirements | 178
	Overview | 178
	C n	r	n | 180
C n		r n	Redundancy Mechanisms on Aggregated Ethernet Interfaces

in a Virtual Chassis

Redundancy Mechanisms on Aggregated Ethernet Interfaces in a Virtual Chassis | 186

C	n	r n	Module Redundancy for a Virtual Chassis | 188
C	n	r n	Chassis Redundancy for a Virtual Chassis | 190
M		c ss s Link		r	n in a Virtual Chassis | 192

vi

Targeted r c s r b	n on Aggregated	Ethernet Interfaces in a Virtual Chassis | 193
Understanding Support for Targeted s r b		n of Logical Interface Sets of S c

VLANs over Aggregated Ethernet Logical Interfaces | 194

8

9

Upgrading Junos OS in a Virtual Chassis C					n		r	n for MX Series 5G
Universal R		n	rms by R b	n	the R			n Engines
Example: Upgrading Junos OS in a Virtual Chassis C						n	r n for MX Series 5G
	Universal R	n	rms by R b n	the R		n	Engines | 199
	Requirements | 199
	Overview and Topology | 200
	C n r	n | 204

Upgrading Junos OS in an MX Series Virtual Chassis by Performing a n In-Service S ftw r Upgrade (ISSU)

nISSU in a Virtual Chassis | 209

Preparing for a n	ISSU in an MX Series Virtual Chassis | 213
Upgrading Junos OS in an MX Series Virtual Chassis by Performing a n		ISSU | 214

10	Upgrading Junos OS in an MX Series Virtual Chassis by Performing a
	S q n			Upgrade
	How to Use S q				n	Upgrade in an MX Series Virtual Chassis | 219
		S q	n	Upgrade Overview | 219
		B n	s of Performing a S q n				Upgrade in a MX Series Virtual Chassis | 219
		Prerequisites for Performing a S q					n Upgrade in a MX Series Virtual Chassis | 220
		Performing a S q n				Upgrade in a MX Series Virtual Chassis | 221
		How S q		n	Upgrade Works in a MX Series Virtual Chassis | 221
11	Monitoring an MX Series Virtual Chassis

Accessing the Virtual Chassis Through the Management Interface | 225

Verifying the Status of Virtual Chassis Member Routers or Switches | 226

Verifying the r n of Virtual Chassis Ports | 227

Verifying Neighbor Reachability for Member Routers or Switches in a Virtual Chassis | 228

vii

Verifying Neighbor Reachability for Hardware Devices in a Virtual Chassis | 230

Determining GRES Readiness in a Virtual Chassis C n r				n | 231
Viewing n		rm	n in the Virtual Chassis Control Protocol Adjacency Database | 233
Viewing	n	rm	n in the Virtual Chassis Control Protocol Link-State Database | 234
Viewing	n	rm	n About Virtual Chassis Port Interfaces in the Virtual Chassis Control

	Protocol Database | 236
Viewing Virtual Chassis Control Protocol R				n Tables | 237
Viewing Virtual Chassis Control Protocol S				s cs for Member Devices and Virtual
	Chassis Ports | 239
Verifying and Managing the Virtual Chassis Heartbeat C nn c n | 240
Inline Flow Monitoring for Virtual Chassis Overview | 242
Managing Files on Virtual Chassis Member Routers or Switches | 244
Virtual Chassis SNMP Traps | 246
Virtual Chassis Slot Number Mapping for Use with SNMP | 246
Example: Determining Member Health Using an MX Series Virtual Chassis Heartbeat
	C nn c		n with Member Routers in the Same Subnet | 249
	Requirements | 249
	Overview | 251
	C n	r	n | 253
	V r	c	n | 259
Example: Determining Member Health Using an MX Series Virtual Chassis Heartbeat
	C nn c		n with Member Routers in	r n Subnets | 263
	Requirements | 264
	Overview | 265
	C n	r	n | 268
	V r	c	n | 279

12

Tracing Virtual Chassis

r

ns for r b s

n Purposes

viii

Tracing Virtual Chassis				r	ns for MX Series 5G Universal R	n	rms | 285
C	n	r n	the Name of the Virtual Chassis Trace Log File | 286
C	n	r n	C r c r s	cs of the Virtual Chassis Trace Log File | 286
C	n	r n	Access to the Virtual Chassis Trace Log File | 288
Using Regular Expressions to R					n the Output of the Virtual Chassis Trace Log File | 289
C	n	r n	the Virtual Chassis		r ns to Trace | 289

13	C n r	n Statements
	r	r	ns | 295

heartbeat-address (MX Series Virtual Chassis) | 297

r b	m	(MX Series Virtual Chassis) | 299
heartbeat-tos (MX Series Virtual Chassis)			| 301
locality-bias (MX Series Virtual Chassis) |			304

logical-interface-chassis-redundancy (MX Series Virtual Chassis) | 305

logical-interface-fpc-redundancy (Aggregated Ethernet Subscriber Interfaces) | 307 member (MX Series Virtual Chassis) | 308

network-services | 310

n s c n (MX Series Virtual Chassis) | 312

preprovisioned (MX Series Virtual Chassis) | 314 role (MX Series Virtual Chassis) | 316 sampling-instance | 318

serial-number (MX Series Virtual Chassis) | 319

r	s r b	n (S c Interfaces over Aggregated Ethernet) | 321
r c	ns (MX Series Virtual Chassis) |		323
virtual-chassis (MX Series Virtual Chassis)			| 326
weight | 328

14	r	n	Commands
	clear virtual-chassis heartbeat (MX Series Virtual Chassis) | 333
	request system s ftw r				in-service-upgrade (MX Series 5G Universal R n
	and EX9200 Switches) | 336
	request virtual-chassis member-id delete (MX Series Virtual Chassis) | 360
	request virtual-chassis member-id set | 362
	request virtual-chassis r				n	n n master switch | 365
	request virtual-chassis vc-port delete (MX Series Virtual Chassis) | 368
	request virtual-chassis vc-port set (MX Series Virtual Chassis) | 370
	show chassis network-services | 373
	show interfaces vcp | 377
	show services		cc	n n	status | 408
	show virtual-chassis			c	v	y (MX Series Virtual Chassis) | 414
	show virtual-chassis device-topology (MX Series Virtual Chassis) | 417
	show virtual-chassis heartbeat (MX Series Virtual Chassis) | 421
	show virtual-chassis protocol adjacency (MX Series Virtual Chassis) | 427
	show virtual-chassis protocol database (MX Series Virtual Chassis) | 434
	show virtual-chassis protocol interface (MX Series Virtual Chassis) | 444
	show virtual-chassis protocol route (MX Series Virtual Chassis) | 449
	show virtual-chassis protocol s					s cs (MX Series Virtual Chassis) | 454
	show virtual-chassis status (MX Series Virtual Chassis) | 459
	show virtual-chassis vc-port (MX Series Virtual Chassis) | 463

ix

rms

x

About This Guide

Use this guide to c n r a virtual chassis using MX Series routers.

1

CHAPTER

Understanding How Virtual Chassis

Provides Interchassis Redundancy

Interchassis Redundancy and Virtual Chassis Overview | 2

2

Interchassis Redundancy and Virtual Chassis

Overview

IN THIS SECTION

Interchassis Redundancy Overview | 2

Virtual Chassis Overview | 3

B n s of C	n	r n a Virtual Chassis | 3
Supported R	n	rms for MX Series Virtual Chassis | 4

As more high-priority voice and video r c is carried on the network, interchassis redundancy has become a baseline requirement for providing stateful redundancy on broadband subscriber management equipment such as broadband services routers, broadband network gateways, and broadband remote

access servers. To provide a stateful interchassis redundancy s				n for MX Series 5G Universal
R	n	rms you can c n	r a Virtual Chassis.

This topic provides an overview of interchassis redundancy and the Virtual Chassis, and explains the b n s of c n r n a Virtual Chassis on supported MX Series routers.

Interchassis Redundancy Overview

r n y redundancy in broadband edge equipment has used an intrachassis approach, which focuses on providing redundancy within a single system. However, a single-system redundancy mechanism no longer provides the degree of high availability required by service providers who must

carry m ss n cr c voice and video r	c on their network. Consequently, service providers are
requiring interchassis redundancy s	ns that can span m	systems that are colocated or
geographically dispersed.

Interchassis redundancy is a high availability feature that prevents network outages and protects routers

against access link failures, uplink failures, and wholesale chassis failures without visibly sr		n the
c	subscribers or increasing the network management burden for service providers. Network

outages can cause service providers to lose revenues and require them to register formal reports with

government agencies. A robust interchassis redundancy m m n	n enables service providers to
strict service-level agreements (SLAs) and avoid unplanned network outages to b		r meet the
needs of their customers.

3

Virtual Chassis Overview

One approach to providing interchassis redundancy is the Virtual Chassis model. In general terms, a

Virtual Chassis c n r	n enables a c c	n of member routers to nc	n as a single virtual
router, and extends the features available on a single router to the member routers in the Virtual
Chassis. The interconnected member routers in a Virtual Chassis are managed as a single network
element that appears to the network administrator as a single chassis with			n line card slots, and
to the access network as a single system.
To provide a stateful interchassis redundancy s		n for MX Series 5G Universal R		n	rms

you can c n r a Virtual Chassis. An MX Series Virtual Chassis interconnects two MX Series routers into a logical system that you can manage as a single network element. The member routers in a Virtual Chassis are designated as the Virtual Chassis primary router (also known as the protocol primary) and the Virtual Chassis backup router (also known as the protocol backup). The member routers are interconnected by means of dedicated Virtual Chassis ports that you c n r on Modular Port Concentrator/Modular Interface Card (MPC/MIC) interfaces.

An MX Series Virtual Chassis is managed by the Virtual Chassis Control Protocol (VCCP), which is a dedicated control protocol based on IS-IS. VCCP runs on the Virtual Chassis port interfaces and is

responsible for building the Virtual Chassis topology,		c n the Virtual Chassis primary router, and
establishing the interchassis r	n table to route r	c within the Virtual Chassis.

NOTE: MX Series Virtual Chassis does not support Ethernet OAM, distributed inline c nn c v y

fault management, Ethernet frame delay measurement, loss measurement, syn		c loss
measurement, and Ethernet alarm n c	n signal (ETH-AIS).

B n	s of C n	r n a Virtual Chassis
C n	r n a Virtual Chassis for MX Series routers provides the following b n s

•S m s network management of two routers that are either colocated or geographically dispersed across a Layer 2 point-to-point network.

•Provides resiliency against network outages and protects member routers against access link failures,

uplink failures, and chassis failures without visibly sr	n	c	subscribers or increasing the
network management burden for service providers.

•Extends the high availability c (GRES) and nonstop c v r the Virtual Chassis.

b s of c ns such as graceful R n Engine switchover n (NSR) beyond a single MX Series router to both member routers in

4

• Enables service providers to

strict service level agreements (SLAs) and avoid unplanned

network outages to b r meet their customers’ needs.

•Provides the ability to scale bandwidth and service capacity as more high-priority voice and video r c is carried on the network.

Supported R		n		rms for MX Series Virtual Chassis
You can c n r		a Virtual Chassis on the following MX Series 5G Universal R n			rms with
MPC/MIC interfaces:
•	MX240 Universal R		n	rm
•	MX480 Universal R		n	rm
•	MX960 Universal R		n	rm
•	MX2010 Universal R		n	rm
•	MX2020 Universal R		n	rm
•	MX10003 Universal R		n	rm

NOTE:	rm support depends on the Junos OS release in your ns							n
Graceful R	n	Engine switchover (GRES) and nonstop c v r					n (NSR) must be enabled on both
member routers in the Virtual Chassis.
Supported Member Router C mb n					ns
A two-member MX Series Virtual Chassis supports the member router c mb n								ns marked as Yes in
Table 1 on page 4.
Table 1: MX Series Virtual Chassis Supported Member Router C mb n ns
Member Router			MX240		MX480	MX960	MX2010	MX2020	MX1000
Type									3
MX240			Yes		Yes	Yes	No	No	No

5

Table 1: MX Series Virtual Chassis Supported Member Router C mb n ns (C					n n )
Member Router	MX240	MX480	MX960	MX2010	MX2020	MX1000
Type						3
MX480	Yes	Yes	Yes	No	No	No
MX960	Yes	Yes	Yes	Yes	Yes	No
MX2010	No	No	Yes	Yes	Yes	No
MX2020	No	No	Yes	Yes	Yes	No
MX10003	No	No	No	No	No	Yes

R n Engine Requirements

Each member router in the Virtual Chassis must have dual R	n Engines installed, and all four R		n
Engines in the Virtual Chassis must be the same model. For example, you cannot c n		r a Virtual

Chassis if one member router has two RE-S-2000 R	n Engines installed and the other member
router has two RE-S-1800 R n Engines installed.
NOTE: For an MX Series Virtual Chassis c n r	n that includes an MX2020 router, all four

Rn Engines in the Virtual Chassis must have at least 16 gigabytes of memory.

RELATED DOCUMENTATION

Virtual Chassis Components Overview | 7

C n r n Interchassis Redundancy for MX Series 5G Universal R n	rms Using a Virtual
Chassis | 61
Example: C n r n Interchassis Redundancy for MX Series 5G Universal R	n	rms Using a
Virtual Chassis | 80

2

CHAPTER

Understanding How a Virtual Chassis

Works

Virtual Chassis Components Overview | 7
Global Roles and Local Roles in a Virtual Chassis |				15
C n	r n a Virtual Chassis Heartbeat C		nn c	n | 18
Primary-role		c n in a Virtual Chassis |	26
Switchover Behavior in an MX Series Virtual Chassis | 28
Command Forwarding in a Virtual Chassis | 32
Split	c	n Behavior in a Virtual Chassis | 52

7

Virtual Chassis Components Overview

IN THIS SECTION
	Virtual Chassis Primary Router |	8
	Virtual Chassis Backup Router |	8
	Virtual Chassis Line-Card Router | 9
	Virtual Chassis Ports | 9
	Virtual Chassis Port Trunks | 10
	Slot Numbering in the Virtual Chassis | 11
	C n r n of Chassis r r	s for MPCs in the Virtual Chassis | 13

Virtual Chassis Control Protocol | 13

Member IDs, Roles, and Serial Numbers | 14

A Virtual Chassis c n r n for MX Series 5G Universal R n rms interconnects two MX Series routers into a logical system that you can manage as a single network element.Figure 1 on page 7 illustrates a typical topology for a two-member MX Series Virtual Chassis.

Figure 1: Sample Topology for MX Series Virtual Chassis

8

This overview describes the basic hardware and s ftw r components of the Virtual Chassis c n r n illustrated in Figure 1 on page 7, and covers the following topics:

Virtual Chassis Primary Router

One of the two member routers in the Virtual Chassis becomes the primary router, also known as the protocol primary. The Virtual Chassis primary router maintains the global c n r n and state

n	rm	n for both member routers, and runs the chassis management processes. The primary R		n
Engine that resides in the Virtual Chassis primary router becomes the global primary for the Virtual
Chassis.
S	c c	y the primary R	n Engine that resides in the Virtual Chassis primary router performs the
following		nc ns in a Virtual Chassis:

•Manages both the primary and backup member routers

•Runs the chassis management processes and control protocols

• Receives and processes all incoming and				xc	n path	r c s n for the Virtual Chassis
• Propagates the Virtual Chassis c n r				n (including member IDs, roles, and c n			r	n group
n	ns and	c	ns) to the members of the Virtual Chassis
The rs	member of the Virtual Chassis becomes the n					primary router by default.	ft r the Virtual
Chassis is formed with both member routers, the Virtual Chassis Control Protocol (VCCP) s								ftw r runs
a primary-role c		n algorithm to elect the primary router for the Virtual Chassis c n					r	n
NOTE: You cannot c n			r primary-role		c n for an MX Series Virtual Chassis in the current
release.

Virtual Chassis Backup Router

The member router in the Virtual Chassis that is not designated as the primary router becomes the backup router, also known as the protocol backup. The Virtual Chassis backup router takes over the

primary role of the Virtual Chassis if the primary router is unavailable, and synchronizes r			n and
state n rm	n with the primary router. The primary R	n Engine that resides in the Virtual Chassis
backup router becomes the global backup for the Virtual Chassis.

9

S c c	y the primary R	n Engine that resides in the Virtual Chassis backup router performs the
following	nc ns in a Virtual Chassis:

• If the primary router fails or is unavailable, takes over the primary role of the Virtual Chassis in order

	to preserve r	n	n rm	n and maintain network c		nn c v y without sr	n
•	Synchronizes r	n	and	c	n state, including r	n tables and subscriber state n rm		n
	with the primary R		n Engine that resides in the Virtual Chassis primary router
•	Relays chassis control n rm				n such as line card presence and alarms, to the primary router

Virtual Chassis Line-Card Router

NOTE: The line-card role is not supported in the preprovisioned c			n r n for a two-member
MX Series Virtual Chassis. In this release, the line-card role applies only in the context of split
c n behavior.
A member router nc	n n in the line-card role runs only a minimal set of chassis management
processes required to relay chassis control n rm		n such as line card presence and alarms, to the
Virtual Chassis primary router.
You cannot explicitly c n	r a member router with the line-card role in the current release. However,
if the backup router fails in a two-member Virtual Chassis c n r			n and split	c n is enabled

(the default behavior), the primary router takes a line-card role, and line cards (FPCs) that do not host

Virtual Chassis ports go			ffl n	This state	c v y isolates the primary router and removes it from the
Virtual Chassis n c nn			c v	y is restored. As a result, r		n is halted and the Virtual Chassis
c n	r	n is disabled.

Virtual Chassis Ports

Virtual Chassis ports are special Ethernet interfaces that form a point-to-point c nn	c	n between the
member routers in a Virtual Chassis. When you create a Virtual Chassis, you must c	n	r	the Virtual
Chassis ports on Modular Port Concentrator/Modular Interface Card (MPC/MIC) interfaces.			ft r you

c n r a Virtual Chassis port, it is renamed vcp-slot/pic/port (for example, vcp-2/2/0), and the line card associated with that port comes online. For example, the sample Virtual Chassis topology shown in Figure 1 on page 7 has a total of four Virtual Chassis ports (represented by the blue dots), two on each of the two member routers.

10

ft

r a Virtual Chassis port is c

n

r

it is dedicated to the task of n

rc nn c n member routers,

and is no longer available for c

n

r

n as a standard network port. To restore this port to the global

c n

r

n and make it available to

nc

n as a standard network port, you must delete the Virtual

Chassis port from the Virtual Chassis c

n

r

n

NOTE: The Junos OS s ftw r

enables you to

r c

n

r ports that are currently unavailable

for use. Although a Virtual Chassis port is unavailable for use as a standard network port, you can

c n

r

this port as a standard network port even

ft

r you c

n

r it as a Virtual Chassis

port. However, the router does not apply the c

n

r

n n

you delete the Virtual Chassis

port from the Virtual Chassis c

n

r

n

You can c

n

r a Virtual Chassis port on either a 1-Gigabit Ethernet (ge) interface, a 10-Gigabit

Ethernet (xe) interface, a 40-Gigabit Ethernet (et) interface, or a 100-Gigabit Ethernet (et) interface. 40-

Gigabit and 100-Gigabit Virtual Chassis ports can only be c

n

r on MPC3, MPC4, or later line

cards. (Interface support depends on the Junos OS release in your ns

n ) You cannot c n

r

a

c

mb n

n of 1-Gigabit Ethernet Virtual Chassis ports and 10-Gigabit Ethernet Virtual Chassis ports in

the same Virtual Chassis. You must c n

r either all 10-Gigabit Virtual Chassis ports or all 1-Gigabit

Virtual Chassis ports in the same Virtual Chassis. We recommend that you c n

r

Virtual Chassis

ports on 10-Gigabit Ethernet (xe) interfaces. In

n to minimize network

sr

n in the event of

a router or link failure, c

n

r redundant Virtual Chassis ports that reside on

r

n

line cards in

each member router.

Virtual Chassis port interfaces carry both VCCP packets and internal control and data

r

c Because

the internal control

r

c is neither encrypted nor

n c

make sure the Virtual Chassis port

interfaces are properly secured to prevent malicious third-party

c

s on the data.

Virtual Chassis ports use a default class of service (CoS) c n

r

n that applies equally to all Virtual

Chassis port interfaces c

n

r in a Virtual Chassis.

n y you can create a customized CoS

r

c c

n r r

and apply it to all Virtual Chassis port interfaces. For example, you might want to

create a nondefault

r

c c

n r

r

that allocates more than the default 5 percent of the Virtual

Chassis port bandwidth to control

r

c or that assigns

r n

r

r s and excess rates to

r n

forwarding classes.

Virtual Chassis Port Trunks

If two or more Virtual Chassis ports of the same type and speed are c n r between the same two member routers in an MX Series Virtual Chassis, the Virtual Chassis Control Protocol (VCCP) bundles these Virtual Chassis port interfaces into a trunk, reduces the r n cost accordingly, and performs

r c load balancing across all of the Virtual Chassis port interfaces (also referred to as Virtual Chassis port links) in the trunk.

11

A Virtual Chassis port trunk must include only Virtual Chassis ports of the same type and speed. For example, a Virtual Chassis port trunk can include either all 10-Gigabit Ethernet (xe media type) Virtual Chassis ports or all 1-Gigabit Ethernet (ge media type) Virtual Chassis ports. An MX Series Virtual Chassis does not support a c mb n n of 1-Gigabit Ethernet Virtual Chassis ports and 10-Gigabit Ethernet Virtual Chassis ports in the same Virtual Chassis port trunk.

The router uses the following formula to determine the cost metric of a Virtual Chassis port link in a Virtual Chassis port trunk:

Cost = (300 * 1,000,000,000) / port-speed

where port-speed is the aggegate speed, in bits per second, of the Virtual Chassis port.

For example, a 10-Gigabit Ethernet Virtual Chassis port link has a cost metric of 30 (300 * 1,000,000,000 / 10,000,000,000). A 1-Gigabit Ethernet Virtual Chassis port link has a cost metric of 300 (300 * 1,000,000,000 / 1,000,000,000). Virtual Chassis port links with a lower cost metric are preferred over those with a higher cost metric.

An MX Series Virtual Chassis supports up to 16 Virtual Chassis ports per trunk.

Slot Numbering in the Virtual Chassis

ft r you c n	r the member ID and,		n y slot count for each router that you want to add to an
MX Series Virtual Chassis, the R		n Engines in that chassis reboot and the slots for line cards (FPCs)

are renumbered. The FPC slot numbering used for each member router is based on the slot count and s s used in the Virtual Chassis instead of the physical slot numbers where the line card is actually

installed.

Table 2 on page 11 shows the valid slot count values for each supported member router type, and the slot numbering used for member 0 and member 1 when the s c slot count value is c n r either explicitly or by default.

Table 2: Slot Count and Slot Numbering for MX Series Virtual Chassis Supported Member Routers

Member Router	Slot Count	FPC Slot Numbers on member 0			FPC Slot Numbers on member 1
Type
MX240	N/A	0 through 11 (no	s	)	12 through 23 (	s	12)
MX480	N/A	0 through 11 (no	s	)	12 through 23 (	s	12)

12

Table 2: Slot Count and Slot Numbering for MX Series Virtual Chassis Supported Member Routers

(C n n )
Member Router	Slot Count	FPC Slot Numbers on member 0			FPC Slot Numbers on member 1
Type
MX960	12 (default)	0 through 11 (no	s	)	12 through 23 (	s	12)
MX960	20	0 through 19 (no	s	)	20 through 39 (	s	20)
MX2010	12 (default)	0 through 11 (no	s	)	12 through 23 (	s	12)
MX2010	20	0 through 19 (no	s	)	20 through 39 (	s	20)
MX2020	20 (default)	0 through 19 (no	s	)	20 through 39 (	s	20)

For example, assume that in your Virtual Chassis c n r n member 0 is an MX960 router and
member 1 is an MX2010 router, with the default slot count (12) in	c on both routers. In this

topology, a 10-Gigabit Ethernet interface that appears as xe-14/2/2 (FPC slot 14, PIC slot 2, port 2) in the show interfaces command output is actually physical interface xe-2/2/2 (FPC slot 2, PIC slot 2, port

2) on member 1	ft r	c	n the	s of 12 for member 1.
Building on this example, assume that you replace member 1 with an MX2020 member router, r s							n
in a Virtual Chassis with an MX960 router c n					r	as member 0 and an MX2020 router c n r	as
member 1. To ensure that a Virtual Chassis c ns s					n	of an MX2020 router and either an MX960 router
or MX2010 router forms properly, you must explicitly set the slot count for the MX960 router or
MX2010 router to 20 to match the slot count of the MX2020 router. When the FPC slots are
renumbered in this topology, physical interface xe-2/2/2 on member 1 becomes xe-22/2/2 on
member 1 ft r adding the			s of 20 for member 1. Similarly, the show interfaces command displays
xe-22/2/2 as the interface name.
NOTE: Slot renumbering does not				c the names of Virtual Chassis ports. The Virtual Chassis
port name, in the format vcp-slot/pic/port, is derived from the physical slot number where the
port is c n	r	For example, vcp-3/2/0 is c n				r on FPC physical slot 3, PIC slot 2, port 0.

13

C n	r	n of Chassis	r	r s for MPCs in the Virtual Chassis
When you c n		r chassis r r	s for MPCs installed in a member router in an MX Series Virtual
Chassis, keep the following points in mind:

• Statements included at the [edit chassis member member-id fpc slot slot-number] hierarchy level apply to the MPC (FPC) in the s c slot number only on the s c member router in the Virtual Chassis.

For example, if you issue the set chassis member 0 fpc slot 1 power statement, only the MPC installed in slot 1 of member ID 0 in the Virtual Chassis is powered

•Statements included at the [edit chassis fpc slot slot-number] hierarchy level should be relocated to the [edit chassis member member-id fpc slot slot-number] hierarchy level to avoid errors.

BEST PRACTICE: To ensure that the statement you use to c n r MPC chassis r r s in a Virtual Chassis applies to the intended member router and MPC, always include the member member-ID n before the fpc keyword, where member-id is 0 or 1 for a two-member

MX Series Virtual Chassis.

Virtual Chassis Control Protocol

An MX Series Virtual Chassis is managed by the Virtual Chassis Control Protocol (VCCP), which is a dedicated control protocol based on IS-IS. VCCP runs on the Virtual Chassis port interfaces and

performs the following nc		ns in the Virtual Chassis:
• Discovers and builds the Virtual Chassis topology
•	Runs the primary-role	c	n algorithm to determine the Virtual Chassis primary router
•	Establishes the interchassis r		n table to route r c within the Virtual Chassis

Like IS-IS, VCCP exchanges link-state PDUs for each member router to construct a shortest path rs (SPF) topology and to determine each member router’s role (primary or backup) in the Virtual Chassis. Because VCCP supports only point-to-point c nn c ns no more than two member routers can be connected on any given Virtual Chassis port interface.

14

Member IDs, Roles, and Serial Numbers

To c n	r	an MX Series Virtual Chassis, you must create a preprovisioned c n r n that provides
the following required n rm n for each member router:
• Member ID—A numeric value (0 or 1) that n s the member router in a Virtual Chassis
c n	r	n

• Role—The role to be performed by each member router in the Virtual Chassis. In a two-member MX Series Virtual Chassis, you must assign both member routers the r n n n role, which enables either router to nc n as the primary router or backup router of the Virtual Chassis.

• Serial number—The chassis serial number of each member router in the Virtual Chassis. To obtain the router’s serial number, n the label x to the side of the MX Series chassis, or issue the show chassis hardware command on the router to display the serial number in the command output.

The preprovisioned c n r n permanently associates the member ID and role with the member

router’s chassis serial number. When a new member router joins the Virtual Chassis, the VCCP s		ftw r
compares the router’s serial number against the values s c	in the preprovisioned c n r	n If
the serial number of a joining router does not match any of the c	n r serial numbers, the VCCP

s ftw r prevents that router from becoming a member of the Virtual Chassis.

RELATED DOCUMENTATION

Interchassis Redundancy and Virtual Chassis Overview | 2

Guidelines for C n			r n Virtual Chassis Ports | 156
Global Roles and Local Roles in a Virtual Chassis | 15
Split	c	n Behavior in a Virtual Chassis | 52
Virtual Chassis Slot Number Mapping for Use with SNMP | 246
Example: C n		r n	Interchassis Redundancy for MX Series 5G Universal R n	rms Using a
Virtual Chassis | 80

15

Global Roles and Local Roles in a Virtual Chassis

IN THIS SECTION

Role Name Format | 15

Global Role and Local Role scr

ns | 16

In a Virtual Chassis c n	r n for MX Series 5G Universal R		n	rms or EX9200 switches,
each of the two member devices and each of the two R		n Engines in each member device has a
s nc role. A global role	n s the nc n of each member device in the Virtual Chassis, and applies
globally across the n r	Virtual Chassis. A local role	n s the	nc	n of each R n Engine in the

member device, and applies locally only to that member device.

Global roles change when you switch the Virtual Chassis primary role, and both global roles and local roles change when you switch the R n Engine primary role in one of the member devices. In

n the line-card global role, though not supported in a preprovisioned c n	r n for a two-
member MX Series or EX9200 Virtual Chassis, applies in the context of split	c n behavior.

This topic describes the global roles and local roles in a MX Series or EX9200 Virtual Chassis so you can

b	r understand how the Virtual Chassis behaves during a global primary role switch, a local R		n
Engine switchover, or when split		c n is enabled.

Role Name Format

The global and local role names in an MX Series or EX9200 Virtual Chassis use the following format:

VC-GlobalRole<LocalRole>

where:

• GlobalRole applies to the global nc n of the member device for the n r Virtual Chassis, and can be one of the following:

•M—Virtual Chassis primary device, also referred to as the protocol primary.

•B—Virtual Chassis backup device, also referred to as the protocol backup.

16

• L—Virtual Chassis line-card device. The line-card role is not supported in the preprovisioned

	c n r	n for a two-member Virtual Chassis. The line-card role applies only in the context of
	split	c n behavior.
• LocalRole (		n	) applies to the nc n of the R		n Engine in the local member device, and
can be one of the following:
•	m—Primary R		n	Engine
•	s—Standby R		n	Engine

Global Role and Local Role scr

ns

Table 3 on page 16 describes the global roles and local roles in an MX Series or EX9200 Virtual Chassis.

Table 3: Global Roles and Local Roles

Virtual Chassis Role	Type of Role	scr	n
VC-P	Global	Primary device for the Virtual Chassis
VC-B	Global	Backup device for the Virtual Chassis
VC-L	Global	Line-card device for the Virtual Chassis
		NOTE: The line-card role is not supported in the
		preprovisioned c		n r	n for a two-member
		MX Series or EX9200 Virtual Chassis. The line-
		card role applies only in the context of split
		c n behavior.
VC-Pp	Local	Primary R	n	Engine in the Virtual Chassis
		primary device
VC-Ps	Local	Standby R	n	Engine in the Virtual Chassis
		primary device

17

Table 3: Global Roles and Local Roles (C n n		)
Virtual Chassis Role	Type of Role		scr		n
VC-Bp	Local		Primary R		n	Engine in the Virtual Chassis
			backup device
VC-Bs	Local		Standby R		n	Engine in the Virtual Chassis
			backup device
VC-Lm	Local		Primary R		n	Engine in the Virtual Chassis line-
			card device
			NOTE: The line-card role is not supported in the
			preprovisioned c			n	r	n for a two-member
			MX Series or EX9200 Virtual Chassis. The line-
			card role applies only in the context of split
			c	n behavior.
VC-Ls	Local		Standby R		n	Engine in the Virtual Chassis
			line-card device
			NOTE: The line-card role is not supported in the
			preprovisioned c			n	r	n for a two-member
			MX Series or EX9200 Virtual Chassis. The line-
			card role applies only in the context of split
			c	n behavior.

RELATED DOCUMENTATION

Virtual Chassis Components Overview | 7

Primary-role c n in a Virtual Chassis | 26

Switching the Global Primary and Backup Roles in a Virtual Chassis C n r n | 107

Disabling Split

c n in a Virtual Chassis C n r n | 110

18

C n r n a Virtual Chassis Heartbeat C nn c n

IN THIS SECTION
	B n	s of C	n	r n a Virtual Chassis Heartbeat C nn c n | 18
	C n	r n Requirements for the Heartbeat C				nn c	n | 19
	How the Heartbeat C nn c n Works | 22						ns | 22
	Heartbeat C		nn c	n and Virtual Chassis Failure C n
	Heartbeat C		nn c	n Compared to Split	c	n | 23

S	r n	in Junos OS Release 14.1, you must c n		r an IP-based, b r c n	“heartbeat” packet
c	nn c	n between the primary router and backup router in an MX Series Virtual Chassis. The
heartbeat c nn c			n determines the health and availability of member routers in the Virtual Chassis.
The member routers forming this heartbeat c nn c				n exchange heartbeat packets that provide cr c
n	rm	n about the availability and health of each member router. During a			sr	n or split in the
Virtual Chassis c n			r n the heartbeat c nn c	n prevents the member routers from changing

primary role roles unnecessarily. Without the heartbeat c nn c n a change in primary role roles in such a s n can produce undesirable results, such as having two Virtual Chassis primary routers or no Virtual Chassis primary router.

B n	s of C n		r n a Virtual Chassis Heartbeat C	nn c n
C n	r n a Virtual Chassis heartbeat c nn c n provides the following b			n s for an MX Series
Virtual Chassis:
• Improved resiliency during failure scenarios
C n	r n	the heartbeat c nn c n improves resiliency of the Virtual Chassis in the event of an
adjacency		sr	n or split caused by a failure of the Virtual Chassis port interfaces, or when one of

the member routers goes out of service. If the heartbeat c nn c n detects that the Virtual Chassis

primary router (VC-P) is s	r n and able to respond during a split, the s ftw r	maintains
primary role on the x s n	VC-P, isolates the Virtual Chassis backup router (VC-B) n	the Virtual

Chassis recovers, and resumes the backup role on the VC-B when the Virtual Chassis forms again. As a result, the heartbeat c nn c n prevents the member routers from unnecessarily changing primary role roles, which consumes system resources and causes unexpected and undesirable results.

19

When the VC-B is isolated during a

sr

n the s ftw r

immediately restarts all line cards and

powers

all network ports

n

the

sr

n is resolved and the Virtual Chassis forms again. This

behavior supports network

c

ns with external equipment that requires a physical link-down

c n

n to switch the

r

c paths to other c nn c

ns

• Enhanced primary-role

c

n process

The Virtual Chassis Control Protocol (VCCP) controls primary-role

c

n in a Virtual Chassis. When

you c n

r

the heartbeat c nn c

n in an MX Series Virtual Chassis, the VCCP s ftw r

assesses

the health n

rm

n collected from the heartbeat c

nn c

n to help determine which member

router should become the global primary (VC-P) in the event of an adjacency sr

n or split.

When the heartbeat c nn c

n detects that the peer member router is responsive, the VCCP

s ftw r

suppresses unnecessary changes in primary role roles.

By contrast, when the heartbeat c

nn c

n is not c n

r

the VCCP s ftw r

does not have this

n health n

rm

n when determining the appropriate primary role roles

ft r a

sr

n

or split.

• Ability to easily view and clear s

s

cs related to the heartbeat c

nn c

n

rn commands for the Virtual Chassis enable you to display the status of the heartbeat

c nn c n review detailed s and clear heartbeat-related s

s	cs and latency measurements related to the heartbeat c nn c n
s	cs counters and m s m	s for one or both member routers.

C n

r

n Requirements for the Heartbeat C nn c

n

To establish a heartbeat c nn

c n for an MX Series Virtual Chassis, you must c

n

r

a secure and

reliable route between the primary router and backup router for the exchange of TCP/IP heartbeat

packets. S

c c

y you must ensure that the primary R

n Engine in the Virtual Chassis backup

router (VC-Bp) can make a TCP/IP c

nn c

n to the master-only IP address of the primary R

n

Engine in the Virtual Chassis primary router (VC-Pp).

The following

n requirements apply when you c n

r

the heartbeat c

nn c

n

• C n

r the heartbeat c

nn c

n only between Virtual Chassis member routers eligible to become

the Virtual Chassis primary router, also known as the protocol primary or global primary.

In a two-member MX Series Virtual Chassis c n

r

n you assign the r

n

n

n role to each

router as part of the preprovisioned c n

r

n The r

n

n n role enables the router to

nc

n either as the primary router or backup router of the Virtual Chassis as needed. As a result,

you can c n

r the heartbeat c nn c

n between both member routers in a two-member MX

Series Virtual Chassis c n

r

n

• Use the router’s Ethernet management interface (fxp0) as the heartbeat path.

20

The management interface is generally available earlier than the line card interfaces, and is typically connected to a more secure network than the other interfaces.

• C n r a master-only IP address for the fxp0 management interface to ensure consistent access to the VC-Pp, regardless of which R n Engine is currently c v

The master-only address is c v only on the management interface for the VC-Pp. During a switchover, the master-only address moves to the new R n Engine currently nc n n as the VC-Pp.

• Ensure TCP c nn c v y between the VC-Pp and VC-Bp member routers

The Virtual Chassis heartbeat c nn c n opens a proprietary TCP port numbered 33087 on the VCPp to listen for heartbeat messages. If your network design includes r w s or rs make sure the network allows r c between TCP port 33087 on the VC-Pp and the dynamically allocated TCP port on the VC-Bp.

• When using a heartbeat c

nn c

n do not c

n

r

the n

s

c

n statement as part of the

preprovisioned Virtual Chassis c

n

r

n

The n

s

c

n statement suppresses any

c

n when a split is detected in the Virtual

Chassis. Using the n

s

c

n statement is prohibited when you c n

r

a heartbeat

c

nn c

n and the s

ftw r

prevents you from c

n

r n

both the n

s

c

n and

heartbeat-address statements at the same m

If you

m to do so, the s

ftw r

displays an

error message and causes the commit

r

n to fail.

In a two-member MX Series Virtual Chassis, you can c

n

r

a heartbeat c

nn c

n with both

member routers in the same subnet, or with each member router in a

r n subnet. Table 4 on page

20 summarizes the important

r nc s between the c

n

r

n procedures for member routers in

the same subnet and member routers in

r n

subnets.

Table 4: Comparison of Heartbeat C nn c

n C n

r

n Tasks for Member Routers in Same

Subnet and Member Routers in

r n

Subnets

Task

Heartbeat C nn c

n for Member

Heartbeat C nn c

n for Member

Routers in Same Subnet

Routers in

r n

Subnets

C n

r

the

C n

r the same fxp0 master-only

C n

r

two

r n master-only

master-only IP

IP address for all four member

IP addresses for the fxp0

address for fxp0

R

n

Engines.

management interface: one address

management

for the subnet in which the Virtual

interface.

Chassis primary router resides, and

one for the subnet in which the

backup router resides.