JNCIS-ENT

High Availability (HA)

1
 Virtual Chassis
4 Modular highly available hardware

2
What is Virtual Chassis?
• Virtual Chassis, also known as a switch stack by many, allows for the
combination of multiple EX series switches into a single logical device
• All control plane functions are handled by an elected routing engine
• Virtual Chassis are managed as a single logical chassis
• Configurations applied to the RE will control all line cards
• Software upgrades applied to the RE will be distributed to all line cards
• To create a virtual chassis, EX series switches must be physically connected
by VC ports
• A virtual chassis may be formed through the dedicated QSFP+ Virtual Chassis Ports (VCPs) or
by configuring 10G uplink ports to function as a VCP

Ring Braided Ring

3
Properties of a Virtual Chassis
• The first switch powered on will assume the member ID of 0 unless pre-
provisioned
• The member ID will function as the slot number when applying interface configuration
• Pre-provisioning involves setting a specific member ID to a VC member using the serial number

• When a virtual chassis is created, one of the switches will be elected as the
primary routing engine (RE0) and another as the backup (RE1). The
remaining switches will act as line cards
• The REs have PFEs built-in and will continue to perform forwarding functions as well
• Maximum of 10 member switches in a VC (Member ID 0-9)
Member 0 RE0
Member 1 RE1
Member 2 LC0
Member 3 LC1

4
Dynamic Virtual Chassis
• No configuration is necessary to form a virtual chassis
• Simply Connect the EX series switches VC ports and power on the switch intended to be the primary
• Once the primary is booted, power on the intended backup RE
• Once the backup is booted, power on the remaining switches
• The switches will dynamically discover the VC
• It is recommended best practice to at least explicitly configure the primary
and backup RE
• Configure using the following command
• set virtual-chassis member {member-id} mastership-priority {priority#}
• The primary will be member 0 and the backup member 1. Recommended priority is 255
• All switches in a VC must be running the same version of Junos
• This may be bypassed by configuring a feature that will automatically update switches with a software mismatch
• set virtual-chassis auto-sw-update

• Adding a standalone switch to a VC is as simple as connecting the VC ports

• The new switch will be inactive if not running the same Junos version and auto-sw-update is not enabled

5
Configuring Virtual Chassis
• By default, the QSFP+ ports on the back of the switch are configured as VCPs
• These are present on the EX4300 and EX3400 models
• The EX2300 does not have any VCPs configured by default
• The EX4100 uses SFP28 ports on the front as VCPs by default
• 10G/40G uplink ports may be configured as additional VCPs using below
command

request virtual-chassis vc-port set pic-slot # port #

show virtual-chassis vc-port

6
Configuring a Virtual Chassis
cont.
• Switches may be pre-provisioned in a VC by specifying the member’s serial number and role
in the primary RE’s configuration
• set virtual-chassis member # role [line-card routing-engine] serial-number PG0123456789

• When configuring the VC as pre-provisioned, power on and configure the primary RE

first with the pre-provisioned members and then connect and power on the member
switches
• When configuring a VC with only 2 members, recommended best practice to enable no-split-
detection
• set virtual-chassis no-split-detection
• Split detection allows the VC to detect when a section of the VC has been separated
• Disabling no-split-detection when configuring a 2 member VC ensures the members will maintain the correct roles if a split and re-
merge occur

Split Merge
PG0123456789 {0} routing-engine PG0123456789 PG0123456789
PG0293847561 {1} routing-engine PG0293847561 PG0293847561
PG1324576890 {2} line-card PG1324576890 PG1324576890
PG9786352410 {3} line-card PG9786352410 PG9786352410
7
Managing a Virtual Chassis
• All member switches run the virtual console process that will forward the console
port to the primary RE
• Connecting a console cable to any of the member switches will provide console access to the
current RE of the VC
• The OOB Management ports on each participating switch will go to a virtual
management interface with the vme prefix.
• All switches in the VC are managed by the single IP, which will provide a management session to
the current RE
• Any switch in the stack may respond on the vme interface and forward the session to the RE

PG0123456789 {0} routing-engine

PG0293847561 {1} routing-engine
PG1324576890 {2} line-card
PG9786352410 {3} line-card

8
NSSU
• Nonstop Software Upgrade is essentially the same concept as ISSU for redundant
RE routers though is for redundant RE switches
• More configuration requirements for NSSU than ISSU

• Must satisfy the following configuration requirements

• VC must be connected in a ring, as opposed to a braided ring
• RE0 and RE1 must be adjacent switches, directly connected to one another in the VC
• Line cards must be pre-provisioned as opposed to dynamically provisioned
• In a 2 member VC, no-split-detection must be configured
• All members must be running same version of Junos
• NSR and GRES must be running, optionally also NSB

request system software nonstop-upgrade

9
Virtual Chassis Traffic Flow
• When a VC is formed, each switch in the VC creates a shortest-path map
• Based on bandwidth of VCPs and hop count
• Packets will always take the shortest path through the VC links to the
destination

PG0123456789 {0} routing-engine

PG0293847561 {1} routing-engine
PG1324576890 {2} line-card egress
ingress PG9786352410 {3} line-card

10