Documente Academic
Documente Profesional
Documente Cultură
13.a
Lab Guide
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known
time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement
executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its
license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain
prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.
Contents
Lab 1: Zero Touch Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Part 1: Logging In Using the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Part 2: Downgrading Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Part 3: Verifying Services and DHCP Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-14
Part 4: Performing and Monitoring ZTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-21
This two-day course is designed to introduce the features introduced by the QFX5100 and EX4300 Series Ethernet
Switches including, but not limited to, zero touch provisioning (ZTP), unified in-service software upgrade (ISSU),
multichassis link aggregation (MC-LAG), mixed Virtual Fabric, and Virtual Chassis Fabric (VCF). Students will learn to
configure and monitor these features that exist on the Junos operating system running on the QFX5100 and
EX4300 Series platform.
Through demonstrations and hands-on labs, students will gain experience configuring, monitoring, and analyzing the
above features of the Junos OS. This course is based on Junos OS Release 13.2X51-D21.1.
Objectives
After successfully completing this course:
• Identify current challenges in today’s data center environments and explain how the QFX5100 system
solves some of those challenges.
• List the various models of QFX5100 Series switches.
• List some data center architecture options.
• Explain the purpose and value of ZTP.
• Describe the components and operations of ZTP.
• Deploy a QFX5100 Series switch using ZTP.
• Explain the purpose and value of ISSU.
• Describe the components and operations of ISSU.
• Upgrade a QFX5100 Series switch using ISSU.
• Explain the purpose and value of MC-LAG.
• Describe the components and operations of MC-LAG.
• Implement an MC-LAG on QFX5100 Series Switches.
• Describe key concepts and components of a mixed Virtual Chassis.
• Explain the operational details of a mixed Virtual Chassis.
• Implement a mixed Virtual Chassis and verify its operations.
• Describe key concepts and components of a Virtual Chassis Fabric.
• Describe the control plane and forwarding plane of a Virtual Chassis Fabric.
• Describe how to use the CLI to configure and monitor a Virtual Chassis Fabric.
• Describe how to provision a Virtual Chassis Fabric using nonprovisioning, preprovisioning, and
autoprovisioning.
• Describe the software requirements and upgrade procedure of Virtual Chassis Fabric.
• Describe how to manage a Virtual Chassis Fabric with Junos Space.
Intended Audience
This course benefits individuals responsible for configuring and monitoring switching features that exist on the Junos OS
running on the QFX5100 and EX4300 Series platforms, including individuals in professional services, sales and support
organizations, and the end users.
Course Level
Data Center Switching (DCX) is an intermediate-level course.
Day 1
Chapter 1: Course Introduction
Chapter 2: System Overview
Chapter 3: Zero Touch Provisioning
Zero Touch Provisioning Lab
Chapter 4: In-Service Software Upgrades
In-Service Software Upgrade Lab
Chapter 5: Multichassis Link Aggregation
Multichassis Link Aggregation Lab
Day 2
Chapter 6: Mixed Virtual Chassis
Answers to Review Questions
Chapter 7: Virtual Chassis Fabric
Chapter 8: Virtual Chassis Fabric Management
Virtual Chassis Fabric Lab
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config.ini in the Filename field.
CLI Undefined Text where the variable’s value is Type set policy policy-name.
the user’s discretion or text where
ping 10.0.x.y
the variable’s value as shown in
GUI Undefined the lab guide might differ from the Select File > Save, and type
value the user must input filename in the Filename field.
according to the lab topology.
Overview
In this lab, you provision QFX5100 Series switches using the zero touch provisioning (ZTP)
process.
By completing this lab, you will perform the following tasks:
• Access your assigned QFX5100 switches.
• Verify communications between your switches and the server.
• Downgrade your QFX5100 switches to an earlier software version.
• Modify DHCP server configuration and ensure services are running.
• Initiate the ZTP process on your QFX5100 switches and monitor its progress.
In this lab part, you become familiar with the access details used to connect to the lab
equipment. Once you are familiar with the access details, you will use the CLI to log in to your
team’s designated switches. Once you have logged in to your device you will make sure your
devices are running the appropriate starting configurations for this lab.
Step 1.1
Ensure that you know to which switches you have been assigned. Check with your instructor if
you are not certain. Consult the management network diagram to determine your switches’
management addresses.
login: lab
Password:
{master:0}[edit]
lab@qfx1# load override dcx/lab1-start.config
load complete
{master:0}[edit]
lab@qfx1# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@qfx1>
Step 1.4
Open a new and separate console session to your qfx2 switch and perform the same steps
previously completed on qfx1 ensuring that the lab1-start.config configuration file is
ultimately loaded on both qfx1 and qfx2.
qfx2 (ttyd0)
login: lab
Password:
{master:0}[edit]
lab@qfx2# load override dcx/lab1-start.config
load complete
{master:0}[edit]
lab@qfx2# commit and-quit
{master:0}
lab@qfx2>
Step 1.5
On qfx2, issue the show vlans extensive command to determine the current VLAN details
and assignments.
{master:0}
lab@qfx2> show vlans extensive
Step 1.6
Issue the show interfaces irb command to view the details associated with the
integrated routing and bridging (IRB) interface.
www.juniper.net Zero Touch Provisioning • Lab 1–3
Data Center Switching
{master:0}
lab@qfx2> show interfaces irb
Physical interface: irb, Enabled, Physical link is Up
Interface index: 640, SNMP ifIndex: 502
Type: Ethernet, Link-level type: Ethernet, MTU: 1514
Device flags : Present Running
Interface flags: SNMP-Traps
Link type : Full-Duplex
Link flags : None
Current address: dc:38:e1:5d:1c:00, Hardware address: dc:38:e1:5d:1c:00
Last flapped : Never
Input packets : 0
Output packets: 0
Note
Please make sure you document the hardware
address in this step as it will be needed in a
subsequent lab part (Part 3 Step 4).
Step 1.7
Issue the ping 172.25.10.1 rapid count 5 command to verify communications and
reachability between qfx2 and the DHCP/FTP server.
Step 1.8
Return to the console session opened to your qfx1 switch.
On your qfx1 switch, issue the show vlans extensive command to determine the current
VLAN details and assignments.
{master:0}
lab@qfx1> show vlans extensive
Answer: Your qfx1 switch should have a single active VLAN in the
form of the default VLAN, which uses the VLAN ID or tag value of
1.
Step 1.9
Issue the show interfaces irb command to view the details associated with the integrated
routing and bridging (IRB) interface.
{master:0}
lab@qfx1> show interfaces irb
Physical interface: irb, Enabled, Physical link is Up
Interface index: 640, SNMP ifIndex: 502
Type: Ethernet, Link-level type: Ethernet, MTU: 1514
Device flags : Present Running
Interface flags: SNMP-Traps
Link type : Full-Duplex
Link flags : None
Current address: dc:38:e1:5e:48:00, Hardware address: dc:38:e1:5e:48:00
Last flapped : Never
Input packets : 0
Output packets: 0
Note
Please make sure you document the hardware
address in this step as it will be needed in a
subsequent lab part (Part 3 Step 4).
Step 1.10
Issue the ping 172.25.10.1 rapid count 5 command to verify communications and
reachability between qfx1 and the DHCP/FTP server.
{master:0}
lab@qfx1> ping 172.25.10.1 rapid count 5
PING 172.25.10.1 (172.25.10.1): 56 data bytes
!!!!!
--- 172.25.10.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.733/26.329/44.413/9.043 ms
Note
Do not proceed until you have documented the MAC addresses
assigned to the IRB interfaces on both qfx1 and qfx2 and
confirmed reachability between those switches and the DHCP/FTP
server as illustrated on the diagram associated with this lab.
In this lab part, you downgrade the software on both of your assigned QFX Series switches to an
earlier version in preparation of provisioning them from a zeroized state using ZTP.
Step 2.1
On qfx1, verify the software version running on the system using the show version command.
{master:0}
lab@qfx1> show version
fpc0:
--------------------------------------------------------------------------
Hostname: qfx1
Model: qfx5100-48s-6q
JUNOS Base OS Software Suite [13.2X51-D21.1]
JUNOS Base OS boot [13.2X51-D21.1]
JUNOS Crypto Software Suite [13.2X51-D21.1]
JUNOS Online Documentation [13.2X51-D21.1]
JUNOS Kernel Software Suite [13.2X51-D21.1]
JUNOS Packet Forwarding Engine Support (qfx-ex-x86-32) [13.2X51-D21.1]
JUNOS Routing Software Suite [13.2X51-D21.1]
JUNOS Enterprise Software Suite [13.2X51-D21.1]
JUNOS py-base-i386 [13.2X51-D21.1]
JUNOS Host Software [13.2X51-D21.1]
Step 2.2
Use secure copy to download the 13.2X51-D15.5 Junos OS image from the server (172.25.10.1)
to the /var/tmp directory on qfx1. If prompted for a security authorization, type yes. When
prompted for a password, use lab123.
{master:0}
lab@qfx1> file copy scp://172.25.10.1/home/lab/
jinstall-qfx-5-13.2X51-D15.5-domestic-signed.tgz /var/tmp/
The authenticity of host '172.25.10.1 (172.25.10.1)' can't be established.
RSA key fingerprint is 01:f0:61:09:8d:e3:2e:a1:a6:ac:fe:a5:cf:8c:38:3c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.25.10.1' (RSA) to the list of known hosts.
lab@172.25.10.1's password:
jinstall-qfx-5-13.2X51-D15.5-domestic-signed. 100% 395MB 1.4MB/s 04:49
Step 2.3
Once the 13.2X51-D15.5 Junos OS image has been downloaded to qfx1, use the file
checksum md5 command and ensure the MD5 checksum matches the
bf4d1adc93ca922233aa0024dd7e3c32 value.
{master:0}
lab@qfx1> file checksum md5 /var/tmp/
jinstall-qfx-5-13.2X51-D15.5-domestic-signed.tgz
MD5 (/var/tmp/jinstall-qfx-5-13.2X51-D15.5-domestic-signed.tgz) =
bf4d1adc93ca922233aa0024dd7e3c32
Step 2.4
Use the request system software add /var/tmp/
jinstall-qfx-5-13.2X51-D15.5-domestic-signed.tgz reboot command to
perform a software downgrade to the referenced software version. Once the downgrade is
complete, log in using the lab and lab123 login credentials and verify the software version
using the show version command.
{master:0}
lab@qfx1> request system software add /var/tmp/
jinstall-qfx-5-13.2X51-D15.5-domestic-signed.tgz reboot
Verified jinstall-vjunos-13.2X51-D15.5-domestic.tgz signed by
PackageProductionVJunos_13_2_0
Adding vjunos...
Saving contents of boot area prior to installation
POST-INSTALL...
Saving the config files ...
...TRIMMED...
qfx1 (ttyd0)
login: lab
Password:
Note
The JUNOS Host Software package is the underlying host
operating system and is based on centOS. It is through
this host operating system and some key processes that
the virtual Junos OS switch instances are managed. Note
that there should not be any negative consequence of
having this package different from the other packages.
Step 2.5
Move to the console session opened for your qfx2 switch.
On qfx2, verify the software version running on the system using the show version
command.
{master:0}
lab@qfx2> show version
fpc0:
--------------------------------------------------------------------------
Hostname: qfx2
Model: qfx5100-48s-6q
JUNOS Base OS Software Suite [13.2X51-D21.1]
JUNOS Base OS boot [13.2X51-D21.1]
JUNOS Crypto Software Suite [13.2X51-D21.1]
JUNOS Online Documentation [13.2X51-D21.1]
JUNOS Kernel Software Suite [13.2X51-D21.1]
JUNOS Packet Forwarding Engine Support (qfx-ex-x86-32) [13.2X51-D21.1]
JUNOS Routing Software Suite [13.2X51-D21.1]
JUNOS Enterprise Software Suite [13.2X51-D21.1]
JUNOS py-base-i386 [13.2X51-D21.1]
JUNOS Host Software [13.2X51-D21.1]
Step 2.7
Once the 13.2X51-D15.5 Junos OS image has been downloaded to qfx2, use the file
checksum md5 command and ensure the MD5 checksum matches the
bf4d1adc93ca922233aa0024dd7e3c32 value.
{master:0}
lab@qfx2> file checksum md5 /var/tmp/
jinstall-qfx-5-13.2X51-D15.5-domestic-signed.tgz
MD5 (/var/tmp/jinstall-qfx-5-13.2X51-D15.5-domestic-signed.tgz) =
bf4d1adc93ca922233aa0024dd7e3c32
Step 2.8
Use the request system software add /var/tmp/
jinstall-qfx-5-13.2X51-D15.5-domestic-signed.tgz reboot command to
perform a software downgrade to the referenced software version. Once the downgrade is
complete, log in using the lab and lab123 login credentials and verify the software version
using the show version command.
{master:0}
lab@qfx2> request system software add /var/tmp/
jinstall-qfx-5-13.2X51-D15.5-domestic-signed.tgz reboot
Verified jinstall-vjunos-13.2X51-D15.5-domestic.tgz signed by
PackageProductionVJunos_13_2_0
POST-INSTALL...
Saving the config files ...
NOTICE: uncommitted changes have been saved in /var/db/config/
juniper.conf.pre-install
Pushing installation package to host...
Extracting jinstall-qfx-5-13.2X51-D15.5-domestic ...
Install jinstall-qfx-5-13.2X51-D15.5-domestic completed
Install jinstall-vjunos completed
login: lab
Password:
In this lab part, you log in to your designated DHCP/FTP server to perform some verification
tasks. Specifically you will verify that the required services are running on the server and that the
configuration file for the DHCP service is properly configured.
Step 3.1
Open a session to the DHCP/FTP server (172.25.10.1) as directed by your instructor and log in
using the lab and lab123 login credentials.
Note that the access method used may vary between delivery environments!
Welcome to the Juniper Networks Education Services Lab
Rack
Main Menu
Select an option: 3
sh-3.2$
Step 3.2
From the shell of your assigned DHCP/FTP server, issue the service dhcpd status
command to determine if the DHCP service is running.
sh-3.2$ service dhcpd status
dhcpd (pid 3105) is running...
Note
Make sure the DHCP service is running on
your assigned server before proceeding!
Step 3.3
Issue the cat /etc/dhcpd.conf command to view the DHCP server configuration.
sh-3.2$ cat /etc/dhcpd.conf
#
# DHCP Server Configuration file.
# see /usr/share/doc/dhcp*/dhcpd.conf.sample
#
host qfx1 {
hardware ethernet aa:bb:aa:bb:aa:00;
fixed-address 172.25.10.111;
option option-150 172.25.10.1;# Define FTP Server Address
host qfx2 {
hardware ethernet bb:aa:bb:aa:bb:00;
fixed-address 172.25.10.222;
option option-150 172.25.10.1;# Define FTP Server Address
option SUNW.server-image "/var/ftp/pub/
jinstall-qfx-5-13.2X51-D21.1-domestic-signed.tgz";
option SUNW.server-file "/var/ftp/pub/qfx2-ZTP.config";
Step 3.4
Using the details logged in Part 1 (Steps 1.6 and 1.9) of this lab, locate the hardware addresses
assigned to the qfx1 and qfx2 IRB interfaces. Once located, note the hardware addresses in the
following spaces:
qfx1
qfx2
Note
If needed, return to the console opened to qfx1 and qfx2 and
locate the hardware addresses of the IRBs associated with
each switch using the show interfaces irb command.
Step 3.5
Update the hardware addresses in the DHCP configuration file as outlined:
1. Issue the vi /etc/dhcpd.conf command to open the configuration file using the
vi editing utility:
sh-3.2$ vi /etc/dhcpd.conf
#
# DHCP Server Configuration file.
# see /usr/share/doc/dhcp*/dhcpd.conf.sample
#
2. Using your arrow keys, navigate to the end of the aa:bb:aa:bb:aa:00 MAC address
referenced in the static mapping definition associated with qfx1.
option space SUNW;
option SUNW.server-image code 4 = text;
option SUNW.server-image code 0 = text;
option SUNW.server-file code 1 = text;
option SUNW.image-file-type code 2 = text;
option SUNW.transfer-mode code 3 = text;
option SUNW-encapsulation code 43 = encapsulate SUNW;
host qfx1 {
hardware ethernet aa:bb:aa:bb:aa:00;<<<<<<< Place Cursor Here
fixed-address 172.25.10.111;
option option-150 172.25.10.1;# Define FTP Server Address
option SUNW.server-image "/var/ftp/pub/
jinstall-qfx-5-13.2X51-D21.1-domestic-signed.tgz";
option SUNW.server-file "/var/ftp/pub/qfx1-ZTP.config";
3. Type the letter ‘i’ to start the insert mode in the vi editor utility. Once in insert mode,
press the Delete key as needed to remove the current MAC address. Once the
current MAC address is removed, enter the hardware address associated with the IRB
interface on qfx1.
host qfx1 {
hardware ethernet place:mac:address:here:xx:xx;
fixed-address 172.25.10.111;
option option-150 172.25.10.1;# Define FTP Server Address
option SUNW.server-image "/var/ftp/pub/
jinstall-qfx-5-13.2X51-D21.1-domestic-signed.tgz";
option SUNW.server-file "/var/ftp/pub/qfx1-ZTP.config";
-- INSERT --
-- INSERT --
5. Once the correct hardware addresses are entered, press the Esc key to leave the
insert mode in the vi editor utility. Note that once you stop insert mode you should no
longer see the -- INSERT -- indicator at the bottom of the screen. Next, save the
changes and exit the vi editor using the :wq! key sequence followed by pressing the
Enter key.
host qfx1 {
hardware ethernet dc:38:e1:5e:48:00;
fixed-address 172.25.10.111;
option option-150 172.25.10.1;# Define FTP Server Address
option SUNW.server-image "/var/ftp/pub/
jinstall-qfx-5-13.2X51-D21.1-domestic-signed.tgz";
option SUNW.server-file "/var/ftp/pub/qfx1-ZTP.config";
host qfx2 {
hardware ethernet dc:38:e1:5d:1c:00;
fixed-address 172.25.10.222;
option option-150 172.25.10.1;# Define FTP Server Address
option SUNW.server-image "/var/ftp/pub/
jinstall-qfx-5-13.2X51-D21.1-domestic-signed.tgz";
option SUNW.server-file "/var/ftp/pub/qfx2-ZTP.config";
:wq!
"/etc/dhcpd.conf" 56L, 1714C written
sh-3.2$
Step 3.6
Issue the sudo service dhcpd restart command to restart the DHCP service. Next,
issue the service dhcpd status command to verify the DHCP service is running.
sh-3.2$ sudo service dhcpd restart
Shutting down dhcpd: [ OK ]
Starting dhcpd: [ OK ]
Note
Make sure the DHCP service is running on
your assigned server before proceeding!
Step 3.7
Issue the sudo service vsftpd status command to verify that the FTP service is
running.
sh-3.2$ sudo service vsftpd status
vsftpd (pid 3094) is running...
Note
Make sure the FTP service is running on
your assigned server before proceeding!
Step 3.8
Test anonymous FTP access to your server using the ftp 172.25.10.1 command. When
prompted for a user name, enter anonymous. When prompted for a password, simply press the
Enter key.
sh-3.2$ ftp 172.25.10.1
Connected to 172.25.10.1.
220 Welcome Guardians of the Galaxy!
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name (172.25.10.1:lab): anonymous
331 Please specify the password.
Password:
Step 3.9
Issue the bye command to close the FTP session on your server.
ftp> bye
221 Goodbye.
sh-3.2$
In this lab part, you initiate ZTP on qfx1 and qfx2 and monitor the results.
Step 4.1
Return to the session opened for qfx1.
On qfx1, issue the request system zeroize command. When prompted with the warning
and asked if the system should proceed, type yes and press Enter.
{master:0}
lab@qfx1> request system zeroize
warning: System will be rebooted and may not boot without configuration
Erase all data, including configuration and log files? [yes,no] (no) yes
{master:0}
lab@qfx1> Aug 23 02:42:05 init: tnp-process (PID 1240) stopped by signal 17
Terminated
.
Aug 23 02:42:11 init: event-processing (PID 1007) exited with status=0 Normal Exit
Waiting (max 60 seconds) for system process `vnlru_mem' to stop...done
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 0 done
...TRIMMED...
Step 4.2
Once the system boots, login using the root account and no password. Once you have logged in
enter operational mode using the cli command and monitor the activity on the console. Note
that you will need to monitor the console for several minutes!
Amnesiac (ttyd0)
login: root
Auto Image Upgrade: No DHCP Client in bound state, reset all enabled DHCP clients
Auto Image Upgrade: No DHCP Client in bound state, reset all enabled DHCP clients
Auto Image Upgrade: DHCP Client Unbound interfaces: vme.0 ge-0/0/0.0 et-0/0/48.0
et-0/0/49.0 et-0/0/50.0 et-0/0/51.0
Step 4.3
Once the system reboots, log in using the lab and lab123 login credentials to verify the software
has been upgraded and the designated configuration is applied.
...TRIMMED...
Amnesiac (ttyd0)
login: lab
Password:
{master:0}
lab@qfx1-ZTP> show configuration system
host-name qfx1-ZTP;
arp {
aging-timer 5;
}
root-authentication {
encrypted-password "$1$kBv/jxIX$wCC5Jz8C5p0GuTbFK7MHJ."; ## SECRET-DATA
}
login {
user lab {
uid 2001;
class super-user;
authentication {
encrypted-password "$1$i38TAAb5$.9O8J9f2GGJUh5pdS5eC70"; ## SECRET-DATA
}
}
{master:0}
lab@qfx1-ZTP>
{master:0}
lab@qfx2> Aug 25 21:50:40 init: tnp-process (PID 1240) stopped by signal 17
Terminated
.
Aug 25 21:50:46 init: event-processing (PID 1007) exited with status=0 Normal Exit
Waiting (max 60 seconds) for system process `vnlru_mem' to stop...done
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 0 done
...TRIMMED...
Amnesiac (ttyd0)
login: root
Auto Image Upgrade: No DHCP Client in bound state, reset all enabled DHCP clien
ts
Auto Image Upgrade: No DHCP Client in bound state, reset all enabled DHCP clien
ts
Auto Image Upgrade: DHCP Client Unbound interfaces: vme.0 ge-0/0/0.0 et-0/0/4
8.0 et-0/0/49.0 et-0/0/50.0 et-0/0/51.0
Auto Image Upgrade: Start fetching qfx2-ZTP.config file from server 172.25.10.1
through irb using ftp
Auto Image Upgrade: File qfx2-ZTP.config fetched from server 172.25.10.1 throug
h irb
...TRIMMED...
Amnesiac (ttyd0)
login: lab
Password:
{master:0}
lab@qfx2-ZTP> show configuration system
host-name qfx2-ZTP;
arp {
{master:0}
lab@qfx2-ZTP>
Step 4.5
On qfx2, enter configuration mode and load the lab1-start.config configuration file from
the /var/home/lab/dcx directory. Commit your changes, return to operational mode, and
log out of the switch.
{master:0}
lab@qfx2-ZTP> configure
Entering configuration mode
{master:0}[edit]
lab@qfx2-ZTP# load override dcx/lab1-start.config
load complete
{master:0}[edit]
lab@qfx2-ZTP# commit and-quit
configuration check succeeds
commit complete
{master:0}
lab@qfx2> exit
qfx2 (ttyd0)
login:
Step 4.6
Return to the console session opened for qfx1.
On qfx1, enter configuration mode and load the lab1-start.config configuration file from
the /var/home/lab/dcx directory. Commit your changes, return to operational mode, and
log out of the switch.
{master:0}
lab@qfx1-ZTP> configure
Entering configuration mode
{master:0}[edit]
lab@qfx1-ZTP# load override dcx/lab1-start.config
load complete
{master:0}[edit]
lab@qfx1-ZTP# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@qfx1> exit
qfx1 (ttyd0)
login:
STOP Tell your instructor that you have completed this lab.
Overview
In this lab, you perform an in-service software upgrade to upgrade the software running on one
of your QFX5100 Series switches with minimal traffic disruption during the upgrade.
By completing this lab, you will perform the following tasks:
• Access your assigned QFX5100 switches.
• Load starting configurations and verify connectivity.
• Downgrade qfx1 to an earlier software version.
• Perform an in-service software upgrade on qfx1.
In this lab part, you become familiar with the access details used to connect to the lab
equipment. Once you are familiar with the access details, you will use the CLI to log in to your
team’s designated switches. Once you have logged in to your device you will make sure your
devices are running the appropriate starting configurations for this lab.
Step 1.1
Ensure that you know to which switches you have been assigned. Check with your instructor if
you are not certain. Consult the management network diagram to determine your switches’
management addresses.
Step 1.2
Using console access, connect to your qfx1 switch and log in using the lab and lab123 login
credentials.
login: lab
Password:
{master:0}[edit]
lab@qfx1# load override dcx/lab2-start.config
load complete
{master:0}[edit]
lab@qfx1# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@qfx1>
Step 1.4
Open a new and separate console session to your qfx2 switch and perform the same steps
previously completed on qfx1 ensuring that the lab2-start.config configuration file is
ultimately loaded on both qfx1 and qfx2.
qfx2 (ttyd0)
login: lab
Password:
{master:0}[edit]
lab@qfx2# load override dcx/lab2-start.config
load complete
{master:0}[edit]
lab@qfx2# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
In this lab part, you perform a standard downgrade of the software on qfx1 in preparation of an
in-service software upgrade performed in a subsequent lab part.
Step 2.1
Return to the console session opened for qfx1.
On qfx1, verify the software version running on the system using the show version
command.
{master:0}
lab@qfx1> show version
fpc0:
--------------------------------------------------------------------------
Hostname: qfx1
Model: qfx5100-48s-6q
JUNOS Base OS Software Suite [13.2X51-D21.1]
JUNOS Base OS boot [13.2X51-D21.1]
JUNOS Crypto Software Suite [13.2X51-D21.1]
JUNOS Online Documentation [13.2X51-D21.1]
JUNOS Kernel Software Suite [13.2X51-D21.1]
JUNOS Packet Forwarding Engine Support (qfx-ex-x86-32) [13.2X51-D21.1]
JUNOS Routing Software Suite [13.2X51-D21.1]
JUNOS Enterprise Software Suite [13.2X51-D21.1]
JUNOS py-base-i386 [13.2X51-D21.1]
JUNOS Host Software [13.2X51-D21.1]
Step 2.2
Use secure copy to download the 13.2X51-D15.5 Junos OS image from the server (172.25.10.1)
to the /var/tmp directory on qfx1. If prompted for a security authorization, type yes. When
prompted for a password, use lab123.
{master:0}
lab@qfx1> file copy scp://172.25.10.1/home/lab/
jinstall-qfx-5-13.2X51-D15.5-domestic-signed.tgz /var/tmp/
lab@172.25.10.1's password:
jinstall-qfx-5-13.2X51-D15.5-domestic-signed. 100% 395MB 1.4MB/s 04:49
Step 2.3
Once the 13.2X51-D15.5 Junos OS image has been downloaded to qfx1, use the file
checksum md5 command and ensure the MD5 checksum matches the
bf4d1adc93ca922233aa0024dd7e3c32 value.
{master:0}
lab@qfx1> file checksum md5 /var/tmp/
jinstall-qfx-5-13.2X51-D15.5-domestic-signed.tgz
MD5 (/var/tmp/jinstall-qfx-5-13.2X51-D15.5-domestic-signed.tgz) =
bf4d1adc93ca922233aa0024dd7e3c32
Step 2.4
Use the request system software add /var/tmp/
jinstall-qfx-5-13.2X51-D15.5-domestic-signed.tgz reboot command to
perform a software downgrade to the referenced software version. Once the downgrade is
complete, log in using the lab and lab123 login credentials and verify the software version
using the show version command.
{master:0}
lab@qfx1> request system software add /var/tmp/
jinstall-qfx-5-13.2X51-D15.5-domestic-signed.tgz reboot
Verified jinstall-vjunos-13.2X51-D15.5-domestic.tgz signed by
PackageProductionVJunos_13_2_0
Adding vjunos...
Saving contents of boot area prior to installation
POST-INSTALL...
Saving the config files ...
...TRIMMED...
qfx1 (ttyd0)
login: lab
Password:
Note
The JUNOS Host Software package is the underlying host
operating system and is based on centOS. It is through
this host operating system and some key processes that
the virtual Junos OS switch instances are managed. Note
that there should not be any negative consequence of
having this package different from the other packages.
Note
You cannot use the force-host option when
performing an in-service software upgrade!
In this lab part, you become familiar with the environment and verify operations. Specifically, you
verify that the virtual routers configured on qfx2 can communicate through qfx1 and that the
expected OSPF neighbor adjacencies are BGP peering sessions are up and operational.
Step 3.1
On qfx1, issue the show ethernet-switching interface command to verify the state and
VLAN assignments of the Layer 2 interfaces used to interconnect the virtual routers (vr1 and vr2)
configured on qfx2.
Refer to the diagram for this lab for a visual of the topological details.
{master:0}
lab@qfx1> show ethernet-switching interface
Routing Instance Name : default-switch
Logical Interface flags (DL - disable learning, AD - packet action drop,
LH - MAC limit hit, DN - interface down )
Logical Vlan TAG MAC STP Logical Tagging
interface members limit state interface flags
et-0/0/48.0 294912 untagged
v15 15 294912 Forwarding untagged
Routing Instance Name : default-switch
Logical Interface flags (DL - disable learning, AD - packet action drop,
Step 3.2
Return to the console session opened for qfx2.
On qfx2, issue the show configuration routing-instances command to determine
the current routing instance configuration details on qfx2.
{master:0}
lab@qfx2> show configuration routing-instances
vr1 {
instance-type virtual-router;
interface et-0/0/48.0;
interface lo0.1;
routing-options {
autonomous-system 65535;
}
protocols {
bgp {
group ibgp {
type internal;
neighbor 192.168.100.2 {
local-address 192.168.100.1;
}
}
}
ospf {
area 0.0.0.0 {
interface lo0.1;
interface et-0/0/48.0;
Step 3.3
Issue the ping routing-instance vr1 192.168.100.2 rapid count 10
command to verify reachability between vr1 and vr2.
{master:0}
lab@qfx2> ping routing-instance vr1 192.168.100.2 rapid count 10
PING 192.168.100.2 (192.168.100.2): 56 data bytes
!!!!!!!!!!
Step 3.4
Issue the show ospf neighbor instance vr1 and show bgp summary instance
vr1 commands to verify the state of the OSPF adjacency and BGP peering session that rely on
the connections passing through qfx1.
{master:0}
lab@qfx2> show ospf neighbor instance vr1
Address Interface State ID Pri Dead
172.25.15.2 et-0/0/48.0 Full 192.168.100.2 128 38
{master:0}
lab@qfx2> show bgp summary instance vr1
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
vr1.inet.0
0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
192.168.100.2 65535 2068 2072 0 3 7:57 Establ
vr1.inet.0: 0/0/0/0
In this lab part, you perform an in-service software upgrade and verify its impact on transit
traffic and the protocol adjacency and peering sessions that are established using connections
that pass through the switch being upgraded.
www.juniper.net In-Service Software Upgrade • Lab 2–9
Data Center Switching
Step 4.1
On qfx2, issue the ping routing-instance vr1 192.168.100.2 command to
generate an ongoing flow of traffic between vr1 and vr2.
Note
Ensure you let the ping operation continue for now. In a later
step, you will stop this ping operation. After stopping the ping
operation, you will verify the impact an ISSU performed on qfx1
had on the traffic flowing between the two virtual routers.
...
Step 4.2
Return to the console opened for qfx1.
On qfx1, use secure copy to download the 13.2X51-D21.1 Junos OS image from the server
(172.25.10.1) to the /var/tmp directory on qfx1. If prompted for a security authorization, type
yes. When prompted for a password, use lab123.
{master:0}
lab@qfx1> file copy scp://172.25.10.1/home/lab/
jinstall-qfx-5-13.2X51-D21.1-domestic-signed.tgz /var/tmp/
lab@172.25.10.1's password:
jinstall-qfx-5-13.2X51-D21.1-domestic-signed. 100% 393MB 1.4MB/s 04:49
Step 4.3
Once the 13.2X51-D21.1 Junos OS image has been downloaded to qfx1, use the file
checksum md5 command and ensure the MD5 checksum matches the
42b7ceba290aaf121bddbedb55bb3a05 value.
{master:0}
lab@qfx1> file checksum md5 /var/tmp/
jinstall-qfx-5-13.2X51-D21.1-domestic-signed.tgz
MD5 (/var/tmp/jinstall-qfx-5-13.2X51-D21.1-domestic-signed.tgz) =
42b7ceba290aaf121bddbedb55bb3a05
Step 4.4
Issue the request system software in-service-upgrade /var/tmp/
jinstall-qfx-5-13.2X51-D21.1-domestic-signed.tgz command to attempt an
in-service software upgrade.
{master:0}
lab@qfx1> request system software in-service-upgrade /var/tmp/
jinstall-qfx-5-13.2X51-D21.1-domestic-signed.tgz
warning: GRES not configured
{master:0}
lab@qfx1>
Step 4.5
Enter configuration mode and enable GRES under the [edit chassis redundancy]
hierarchy.
{master:0}
lab@qfx1> configure
Entering configuration mode
{master:0}[edit]
lab@qfx1# set chassis redundancy graceful-switchover
{master:0}[edit]
lab@qfx1# set routing-options nonstop-routing
Step 4.7
Issue the set system commit synchronize command from the root hierarchy level to
enable commit synchronization for the system. Once commit synchronization is enabled, activate
the changes and return to operational mode.
{master:0}[edit]
lab@qfx1# set system commit synchronize
{master:0}[edit]
lab@qfx1# commit and-quit
{master:0}
lab@qfx1>
Step 4.8
Issue the request system software in-service-upgrade /var/tmp/
jinstall-qfx-5-13.2X51-D21.1-domestic-signed.tgz command to perform an
in-service software upgrade.
{master:0}
lab@qfx1> request system software in-service-upgrade /var/tmp/
jinstall-qfx-5-13.2X51-D21.1-domestic-signed.tgz
warning: Do NOT use /user during ISSU. Changes to /user during ISSU may get lost!
ISSU: Validating Image
ISSU: Preparing Backup RE
Prepare for ISSU
ISSU: Backup RE Prepare Done
Note
At this point you will need to press the Enter
key as there is a soft reset of the console
connection that occurs during the ISSU.
Step 4.9
Once you see the login prompt, log in using the lab and lab123 login credentials. Next, issue
the show version command to confirm the software has been upgraded to the 13.2X51-21.1
version.
qfx1 (ttyd0)
login: lab
Password:
{master:0}
lab@qfx1>
Step 4.10
Return to the console session of your qfx2 switch.
On qfx2, break the continuous ping operation by issuing the Ctrl + C key sequence and
assess the resulting statistics presented at the bottom of the output.
...
64 bytes from 192.168.100.2: icmp_seq=1717 ttl=64 time=44.039 ms
64 bytes from 192.168.100.2: icmp_seq=1718 ttl=64 time=33.037 ms
64 bytes from 192.168.100.2: icmp_seq=1719 ttl=64 time=44.040 ms
64 bytes from 192.168.100.2: icmp_seq=1720 ttl=64 time=44.040 ms
64 bytes from 192.168.100.2: icmp_seq=1721 ttl=64 time=44.038 ms
64 bytes from 192.168.100.2: icmp_seq=1722 ttl=64 time=44.039 ms
64 bytes from 192.168.100.2: icmp_seq=1723 ttl=64 time=33.037 ms
64 bytes from 192.168.100.2: icmp_seq=1724 ttl=64 time=44.040 ms
64 bytes from 192.168.100.2: icmp_seq=1725 ttl=64 time=44.038 ms
64 bytes from 192.168.100.2: icmp_seq=1726 ttl=64 time=44.039 ms
64 bytes from 192.168.100.2: icmp_seq=1727 ttl=64 time=33.037 ms
^C
--- 192.168.100.2 ping statistics ---
1728 packets transmitted, 1728 packets received, 0% packet loss
round-trip min/avg/max/stddev = 16.060/42.770/96.070/9.138 ms
{master:0}
lab@qfx2>
Answer: While your statistics may vary from that shown in the
sample output, you should not see much if any impact to the
transit traffic passing through qfx1 during the time of the ISSU.
In the sample output, you can see that there was no impact and
we see a 0% packet loss.
{master:0}
lab@qfx2> show bgp summary instance vr1
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
vr1.inet.0
0 0 0 0 0 0
vr1.mdt.0
0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
192.168.100.2 65535 68 68 0 0 29:38 Establ
vr1.inet.0: 0/0/0/0
Step 4.12
Log out of your switches and close the console sessions.
{master:0}
lab@qfx2> exit
login:
{master:0}
lab@qfx1> exit
qfx1 (ttyd0)
login:
STOP Tell your instructor that you have completed this lab.
Overview
In this lab, you configure Multichassis Link Aggregation groups (MC-LAGs) between your
QFX5100 Series switches. You then perform monitoring and verification tasks to ensure proper
operations.
By completing this lab, you will perform the following tasks:
• Access your assigned QFX5100 and EX4300 switches.
• Load starting configurations and verify connectivity.
• Configure Multichassis Link Aggregation on QFX5100 switches.
• Verify proper operations for Layer 2 traffic within a VLAN.
• Enable Layer 3 gateway services on the MC-LAG peers.
• Verify proper operations for Layer 3 traffic between VLANs.
In this lab part, you become familiar with the access details used to connect to the lab
equipment. Once you are familiar with the access details, you will use the CLI to log in to your
team’s designated switches. Once you have logged in, you will make sure your devices are
running the appropriate starting configurations for this lab.
Step 1.1
Ensure that you know to which switches you have been assigned. Check with your instructor if
you are not certain. Consult the management network diagram to determine your switches’
management addresses.
login: lab
Password:
{master:0}[edit]
lab@qfx1# load override dcx/lab3-start.config
load complete
{master:0}[edit]
lab@qfx1# commit
configuration check succeeds
commit complete
{master:0}[edit]
lab@qfx1#
Step 1.4
Open a new and separate console session to your qfx2 switch and log in using the lab and
lab123 login credentials. Once logged in, enter configuration mode and load the
lab3-start.config configuration file from the /var/home/lab/dcx directory.
Commit your changes and commit your changes and remain in configuration mode.
qfx2 (ttyd0)
login: lab
Password:
{master:0}[edit]
lab@qfx2# load override dcx/lab3-start.config
load complete
{master:0}[edit]
lab@qfx2#
Step 1.5
Issue the show interfaces and show routing-instances commands.
{master:0}[edit]
lab@qfx2# show interfaces
ge-0/0/0 {
description "HostX-VR Interface - Do Not Delete!";
vlan-tagging;
mac dc:38:e1:5e:11:22;
unit 15 {
vlan-id 15;
family inet {
address 172.25.15.100/24;
}
}
unit 20 {
vlan-id 20;
family inet {
address 172.25.20.100/24;
}
}
}
em0 {
unit 0 {
family inet {
address 10.210.14.154/26;
}
}
}
{master:0}[edit]
lab@qfx2# show routing-instances
HostX-VR {
instance-type virtual-router;
interface ge-0/0/0.15;
interface ge-0/0/0.20;
}
Step 1.6
Open a new and separate console session to your ex1 switch and log in using the lab and
lab123 login credentials. Once logged in, enter configuration mode and load the
lab3-start.config configuration file from the /var/home/lab/dcx directory. Commit
your changes and return to operational mode.
ex1 (ttyu0)
login: lab
Password:
{master:0}[edit]
lab@ex1# load override dcx/lab3-start.config
load complete
{master:0}[edit]
lab@ex1# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@ex1-ServerA>
Note
The ex1 switch serves as the Server A device
illustrated on the diagram associated with this lab.
Step 1.7
Open a new and separate console session to your ex2 switch and log in using the lab and
lab123 login credentials. Once logged in, enter configuration mode and load the
lab3-start.config configuration file from the /var/home/lab/dcx directory. Commit
your changes and return to operational mode.
login: lab
Password:
{master:0}[edit]
lab@ex2# load override dcx/lab3-start.config
load complete
{master:0}[edit]
lab@ex2# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@ex2-ServerB>
Note
The ex2 switch serves as the Server B device
illustrated on the diagram associated with this lab.
In this lab part, you configure Multichassis Link Aggregation on qfx1 and qfx2 to support the
connections from the attached Server A and Server B devices. Once configured, you will perform
some basic verification steps to ensure Layer 2 operations between devices on the same VLAN.
Step 2.1
Return to the console session opened for qfx1.
On qfx1, issue the run show interfaces terse | match ae command to determine if
any aggregated Ethernet interfaces currently exist.
{master:0}[edit]
lab@qfx1# run show interfaces terse | match ae
{master:0}[edit]
lab@qfx1#
{master:0}[edit]
lab@qfx1# commit
configuration check succeeds
commit complete
{master:0}[edit]
lab@qfx1# run show interfaces terse | match ae
ae0 up down
ae1 up down
ae2 up down
Step 2.3
Configure ae0 for Layer 2 operations as a trunk port. Associate ae0 with the v100 VLAN, which
will be configured in a subsequent step. Note that ae0 will serve as the interchassis
link-protection link (ICL-PL) for the MC-LAGs, which you configure later in this lab part.
{master:0}[edit]
lab@qfx1# set interfaces ae0 unit 0 family ethernet-switching
{master:0}[edit]
lab@qfx1# set interfaces ae0.0 family ethernet-switching interface-mode trunk
{master:0}[edit]
lab@qfx1# set interfaces et-0/0/49 ether-options 802.3ad ae0
{master:0}[edit]
lab@qfx1# commit
configuration check succeeds
commit complete
{master:0}[edit]
lab@qfx1# run show interfaces terse | match ae0
et-0/0/48.0 up up aenet --> ae0.0
et-0/0/49.0 up up aenet --> ae0.0
ae0 up up
ae0.0 up up eth-switch
Step 2.6
Enable ae0 to support LACP and to actively initiate LACP communications. Once LACP has been
enabled, activate the configuration change and verify ae0’s interface status once again with the
run show interfaces terse | match ae0 command.
{master:0}[edit]
lab@qfx1# set interfaces ae0 aggregated-ether-options lacp active
{master:0}[edit]
lab@qfx1# commit
configuration check succeeds
commit complete
{master:0}[edit]
lab@qfx1# run show interfaces terse | match ae0
et-0/0/48.0 up up aenet --> ae0.0
et-0/0/49.0 up up aenet --> ae0.0
ae0 up down
ae0.0 up down eth-switch
Question: What is the current state of ae0? Can you explain the
current status of the ae0 interface?
Step 2.7
Return to the console connection opened for qfx2.
On qfx2, perform the following tasks:
1. Create three aggregated Ethernet interfaces.
{master:0}[edit]
lab@qfx2# set chassis aggregated-devices ethernet device-count 3
{master:0}[edit]
lab@qfx2# set interfaces ae0.0 family ethernet-switching interface-mode trunk
{master:0}[edit]
lab@qfx2# set interfaces ae0.0 family ethernet-switching vlan members v100
{master:0}[edit]
lab@qfx2# set interfaces et-0/0/49 ether-options 802.3ad ae0
{master:0}[edit]
lab@qfx2# run show interfaces terse | match ae0
et-0/0/48.0 up up aenet --> ae0.0
et-0/0/49.0 up up aenet --> ae0.0
ae0 up up
ae0.0 up up eth-switch
Step 2.9
Issue the run show lacp statistics interface ae0 command to determine if the
member links associated with ae0 are sending and receiving LACP traffic.
{master:0}[edit]
lab@qfx2# run show lacp statistics interfaces ae0
Aggregated interface: ae0
LACP Statistics: LACP Rx LACP Tx Unknown Rx Illegal Rx
et-0/0/48 246 248 0 0
et-0/0/49 246 248 0 0
Step 2.10
Continue configuring the required infrastructure elements required to support MC-LAGs on qfx2
by performing the following tasks:
{master:0}[edit]
lab@qfx2# set interfaces irb unit 100 family inet address 10.0.0.2/30
{master:0}[edit]
lab@qfx2# set vlans v100 l3-interface irb.100
2. Configure ICCP on qfx2 using 10.0.0.2 as the local IP address and 10.0.0.1, which will
soon be assigned to qfx1, as the peer IP address. Assign the following details to the
peering session with qfx1:
– Session establishment hold time: 50
– Backup Peer IP address: Management address of qfx1
– Liveness detection minimum receive interval: 1000
– Liveness detection transmit interval: 1000
{master:0}[edit]
lab@qfx2# edit protocols iccp
{master:0}[edit]
lab@qfx2# set multi-chassis multi-chassis-protection 10.0.0.1 interface ae0
{master:0}[edit]
lab@qfx2#
{master:0}[edit]
lab@qfx2# run show iccp
Step 2.12
Return to the console session opened for qfx1.
On qfx1, continue configuring the required infrastructure elements required to support MC-LAGs
on qfx1 by performing the following tasks:
1. Configure irb.100 (10.0.0.1/30) and associate it with VLAN v100.
{master:0}[edit]
lab@qfx1# set interfaces irb unit 100 family inet address 10.0.0.1/30
{master:0}[edit]
lab@qfx1# set vlans v100 l3-interface irb.100
2. Configure ICCP on qfx1 using 10.0.0.1 as the local IP address and 10.0.0.2, which is
assigned to qfx2, as the peer IP address. Assign the following details to the peering
session with qfx2:
– Session establishment hold time: 50
– Backup Peer IP address: Management address of qfx2
– Liveness detection minimum receive interval: 1000
– Liveness detection transmit interval: 1000
www.juniper.net Multichassis Link Aggregation • Lab 3–11
Data Center Switching
{master:0}[edit]
lab@qfx1# edit protocols iccp
{master:0}[edit]
lab@qfx1# set multi-chassis multi-chassis-protection 10.0.0.2 interface ae0
{master:0}[edit]
lab@qfx1#
Step 2.13
Activate the configuration changes and view the ICCP details using the run show iccp
command.
{master:0}[edit]
lab@qfx1# commit
configuration check succeeds
commit complete
{master:0}[edit]
lab@qfx1# run show iccp
Step 2.14
Configure ae1 as an MC-LAG for Server A (ex1), which is associated with the v15 VLAN, by
performing the following tasks:
1. Define the v15 VLAN with a VLAN ID value of 15.
{master:0}[edit]
lab@qfx1# set vlans v15 vlan-id 15
4. Associate ae1 with the MC-LAG role using the following details:
– mc-ae-id: 1
– chassis-id: 0
– mode: active-active
– status-control: active
{master:0}[edit interfaces ae1]
lab@qfx1# set aggregated-ether-options mc-ae mc-ae-id 1
Step 2.15
Attempt to activate the configuration changes by issuing the commit command.
{master:0}[edit interfaces ae1]
lab@qfx1# commit
[edit interfaces ae1 aggregated-ether-options]
'mc-ae'
LACP admin-key must be configured for MC-AE
[edit interfaces ae1 aggregated-ether-options]
'mc-ae'
LACP system-id must be configured for MC-AE
error: commit failed: (statements constraint check failed)
Step 2.16
Configure ae1 as an active LACP participant with an admin-key value of 1 and a system-id
value of 01:01:01:01:01:01. Once configured, activate the configuration changes using the
commit command.
{master:0}[edit interfaces ae1]
lab@qfx1# set aggregated-ether-options lacp active
{master:0}[edit]
lab@qfx1# set vlans v20 vlan-id 20
{master:0}[edit]
lab@qfx1#
4. Associate ae2 with the MC-LAG role using the following details:
– mc-ae-id: 2
– chassis-id: 1
– mode: active-active
– status-control: standby
{master:0}[edit interfaces ae2]
lab@qfx1# set aggregated-ether-options mc-ae mc-ae-id 2
Step 2.18
Activate the configuration changes and return to the operational mode by issuing the commit
and-quit command.
{master:0}[edit interfaces ae2]
lab@qfx1# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@qfx1>
Step 2.19
Issue the show interfaces terse | match ae command to determine the state of ae1
and ae2.
{master:0}
lab@qfx1> show interfaces terse | match ae
et-0/0/48.0 up up aenet --> ae0.0
et-0/0/49.0 up up aenet --> ae0.0
et-0/0/50.0 up up aenet --> ae1.0
et-0/0/51.0 up up aenet --> ae2.0
ae0 up up
ae0.0 up up eth-switch
ae1 up down
ae1.0 up down eth-switch
ae2 up down
ae2.0 up down eth-switch
Step 2.20
Issue the show interfaces mc-ae command to gather more detailed information on the
state of ae1 and ae2.
{master:0}
lab@qfx1> show interfaces mc-ae
Member Link : ae1
Current State Machine's State: mcae application connect error
Local Status : standby
Local State : up
Step 2.21
Return to the console opened for qfx2.
On qfx2, configure ae1 as an MC-LAG for Server A (ex1), which is associated with the v15 VLAN,
by performing the following tasks:
1. Define the v15 VLAN with a VLAN ID value of 15.
{master:0}[edit]
lab@qfx2# set vlans v15 vlan-id 15
2. Configure et-0/0/51 as a member link assigned to ae1.
{master:0}[edit]
lab@qfx2# set interfaces et-0/0/51 ether-options 802.3ad ae1
4. Associate ae1 with the MC-LAG role using the following details:
– mc-ae-id: 1
– chassis-id: 1
– mode: active-active
– status-control: standby
{master:0}[edit interfaces ae1]
lab@qfx2# set aggregated-ether-options mc-ae mc-ae-id 1
Step 2.22
Configure ae2 as an MC-LAG for Server B (ex2), which is associated with the v20 VLAN, by
performing the following tasks:
1. Define the v20 VLAN with a VLAN ID value of 20.
{master:0}[edit interfaces ae1]
lab@qfx2# top
{master:0}[edit]
lab@qfx2# set vlans v20 vlan-id 20
{master:0}[edit]
lab@qfx2#
4. Associate ae2 with the MC-LAG role using the following details:
– mc-ae-id: 2
– chassis-id: 0
– mode: active-active
– status-control: active
{master:0}[edit interfaces ae2]
lab@qfx2# set aggregated-ether-options mc-ae mc-ae-id 2
Step 2.25
Issue the show interfaces mc-ae command to gather more detailed information on the
state of ae1 and ae2.
{master:0}
lab@qfx2> show interfaces mc-ae
Member Link : ae1
Current State Machine's State: mcae active state
Local Status : active
Local State : up
Peer Status : active
Peer State : up
Logical Interface : ae1.0
Topology Type : bridge
Local State : up
Peer State : up
Peer Ip/MCP/State : 10.0.0.1 ae0.0 up
Step 2.26
Return to the console session opened to ex1.
On ex1, which is functioning as Server A, attempt to ping Host X device (172.25.15.100).
{master:0}
lab@ex1-ServerA> ping 172.25.15.100 rapid count 25
PING 172.25.15.100 (172.25.15.100): 56 data bytes
.........................
--- 172.25.15.100 ping statistics ---
25 packets transmitted, 0 packets received, 100% packet loss
{master:0}
lab@ex1-ServerA>
Step 2.27
Return to the console for qfx2.
On qfx2, enter configuration mode and associate the ae0 trunk port with the v15 and v20
VLANs. Once the configuration has been updated, commit the change.
{master:0}
lab@qfx2> configure
Entering configuration mode
{master:0}[edit]
lab@qfx2# set interfaces ae0.0 family ethernet-switching vlan members v15
{master:0}[edit]
lab@qfx2# set interfaces ae0.0 family ethernet-switching vlan members v20
{master:0}[edit]
lab@qfx2# show interfaces ae0
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members [ v100 v15 v20 ];
}
}
}
{master:0}[edit]
lab@qfx2# commit
configuration check succeeds
commit complete
{master:0}[edit]
lab@qfx2#
Step 2.28
Issue the run show vlans command to determine the current VLAN assignments.
{master:0}[edit]
lab@qfx2# run show vlans
Step 2.29
Return to the console for qfx1.
On qfx1, enter configuration mode and associate the ae0 trunk port with the v15 and v20
VLANs.
{master:0}
lab@qfx1> configure
Entering configuration mode
{master:0}[edit]
lab@qfx1# show interfaces ae0
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members v100;
}
}
}
{master:0}[edit]
lab@qfx1# set interfaces ae0.0 family ethernet-switching vlan members v15
{master:0}[edit]
lab@qfx1# set interfaces ae0.0 family ethernet-switching vlan members v20
{master:0}[edit]
lab@qfx1# show interfaces ae0
aggregated-ether-options {
lacp {
{master:0}[edit]
lab@qfx1# commit
configuration check succeeds
commit complete
{master:0}[edit]
lab@qfx1#
Step 2.31
Issue the run show vlans command to determine the current VLAN assignments.
{master:0}[edit]
lab@qfx1# run show vlans
Step 2.32
Return to the console session opened to ex1.
On ex1, which is functioning as Server A, attempt to ping Host X device (172.25.15.100) once
again.
{master:0}
lab@ex1-ServerA> ping 172.25.15.100 rapid count 25
PING 172.25.15.100 (172.25.15.100): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.25.15.100 ping statistics ---
25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.714/22.469/36.724/3.091 ms
In this lab part, you enable Layer 3 gateway services on qfx1 and qfx2 for the subnets
associated with the v15 and v20 VLANs. You will then verify reachability between Server A and
Server B, which reside on different Layer 3 subnets.
Step 3.1
On ex1, which is functioning as Server A, attempt to ping ex2, which is functioning as Server B,
using the 172.25.20.22 destination address.
{master:0}
lab@ex1-ServerA> ping 172.25.20.22 rapid count 25
www.juniper.net Multichassis Link Aggregation • Lab 3–25
Data Center Switching
PING 172.25.20.22 (172.25.20.22): 56 data bytes
.........................
--- 172.25.20.22 ping statistics ---
25 packets transmitted, 0 packets received, 100% packet loss
Step 3.2
Return to the console connection opened to qfx1.
On qfx1, configure Layer 3 gateway services for the 172.25.15.0/24 subnet as follows:
1. Configure irb.15 as a Layer 3 interface with the 172.25.15.101/24 IP address.
{master:0}[edit]
lab@qfx1# edit interfaces irb unit 15
2. Enable VRRP under irb.15’s newly defined IP address with the following values:
– vrrp-group: 15
– virtual-address: 172.25.15.1
– priority: 200
{master:0}[edit interfaces irb unit 15]
lab@qfx1# edit family inet address 172.25.15.101/24
{master:0}[edit]
lab@qfx1# set vlans v15 l3-interface irb.15
2. Enable VRRP under irb.20’s newly defined IP address with the following values:
– vrrp-group: 20
– virtual-address: 172.25.20.1
– priority: 100
{master:0}[edit interfaces irb unit 20]
lab@qfx1# edit family inet address 172.25.20.101/24
{master:0}[edit]
lab@qfx1# set vlans v20 l3-interface irb.20
{master:0}[edit]
lab@qfx1#
Step 3.4
Activate the configuration changes using the commit command. Next, issue the run show
vrrp summary command to determine the current state of VRRP.
{master:0}[edit]
lab@qfx1# commit
configuration check succeeds
commit complete
Note
The intended design goal is to have qfx1 serve as master for VRRP
group 15 and qfx2 to serve as master for VRRP group 20. The VRRP
master for a given group is determined by the priority setting, where
the higher value is preferred over the lower value. We configure
qfx2 to support this design goal in subsequent lab steps.
Step 3.5
Return to the console connection opened to qfx2.
On qfx2, configure Layer 3 gateway services for the 172.25.15.0/24 subnet as follows:
1. Configure irb.15 as a Layer 3 interface with the 172.25.15.102/24 IP address.
{master:0}[edit]
lab@qfx2# edit interfaces irb unit 15
2. Enable VRRP under irb.15’s newly defined IP address with the following values:
– vrrp-group: 15
– virtual-address: 172.25.15.1
– priority: 100
{master:0}[edit interfaces irb unit 15]
lab@qfx2# edit family inet address 172.25.15.102/24
{master:0}[edit]
lab@qfx2# set vlans v15 l3-interface irb.15
{master:0}[edit]
lab@qfx2#
Step 3.6
Configure Layer 3 gateway services for the 172.25.20.0/24 subnet as follows:
1. Configure irb.20 as a Layer 3 interface with the 172.25.20.102/24 IP address.
{master:0}[edit]
lab@qfx2# edit interfaces irb unit 20
2. Enable VRRP under irb.20’s newly defined IP address with the following values:
– vrrp-group: 20
– virtual-address: 172.25.20.1
– priority: 200
{master:0}[edit interfaces irb unit 20]
lab@qfx2# edit family inet address 172.25.20.102/24
{master:0}[edit]
lab@qfx2# set vlans v20 l3-interface irb.20
{master:0}[edit]
{master:0}[edit]
lab@qfx2# run show vrrp summary
Interface State Group VR state VR Mode Type Address
irb.15 up 15 backup Active lcl 172.25.15.102
vip 172.25.15.1
irb.20 up 20 master Active lcl 172.25.20.102
vip 172.25.20.1
Step 3.8
Return to the console connection opened for ex1.
On ex1, which is functioning as Server A, attempt to ping ex2, which is functioning as Server B,
using the 172.25.20.22 destination address once again.
{master:0}
lab@ex1-ServerA> ping 172.25.20.22 rapid count 25
PING 172.25.20.22 (172.25.20.22): 56 data bytes
..!!!!!!!!!!!!!!!!!!!!!!!
--- 172.25.20.22 ping statistics ---
25 packets transmitted, 23 packets received, 8% packet loss
round-trip min/avg/max/stddev = 1.810/2.041/3.207/0.299 ms
{master:0}
lab@ex1-ServerA> ping 172.25.20.22 rapid count 25
PING 172.25.20.22 (172.25.20.22): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.25.20.22 ping statistics ---
25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.871/2.298/3.988/0.621 ms
Step 3.9
Log out of your switches and close the console sessions.
{master:0}
lab@ex1-ServerA> exit
ex1-ServerA (ttyu0)
login:
{master:0}
lab@ex2-ServerB> exit
ex2-ServerB (ttyu0)
login:
{master:0}[edit]
lab@qfx1# exit configuration-mode
Exiting configuration mode
{master:0}
lab@qfx1> exit
qfx1 (ttyd0)
login:
{master:0}[edit]
lab@qfx2# exit configuration-mode
Exiting configuration mode
qfx2 (ttyd0)
login:
STOP Tell your instructor that you have completed this lab.
Overview
In this lab, you provision a mixed Virtual Chassis using a combination of two QFX5100 Series
switches and two EX4300 Series switches. The QFX5100 Series switches will act as master and
backup Routing Engines (REs). The EX4300 Series switches will act as linecards for the Virtual
Chassis.
By completing this lab, you will perform the following tasks:
• Access your assigned switches.
• Configure the master RE for dynamic provisioning of the Virtual Chassis.
• Enable the Virtual Chassis Ports (VCPs) on each of the switches.
• Verify that each member switch has taken on the appropriate role.
• Configure network interfaces on the Virtual Chassis.
• Verify that the Virtual Chassis appears to act as a single switch.
• Reset the members of the Virtual Chassis into individual standalone switches.
In this lab part, you will review the lab diagram to determine the roles that each switch will take
as part of the Virtual Chassis. Use the lab diagram titled “Network Diagram: Mixed Virtual
Chassis Lab” for this part of the lab.
Step 1.1
Take a look at the diagram labeled “Network Diagram: Mixed Virtual Chassis Lab”.
Answer: ex1 and ex2 will be linecards for the Virtual Chassis.
In this lab part, you become familiar with the access details used to connect to the lab
equipment. Once you are familiar with the access details, you will use the CLI to log in to your
team’s designated switches. Once you have logged in to your devices you will make sure your
devices are running the appropriate starting configurations for this lab. Use the lab diagram
titled “Network Diagram: Mixed Virtual Chassis Lab” for this part of the lab.
Step 2.1
Ensure that you know to which switches you have been assigned. Check with your instructor if
you are not certain. Consult the management network diagram to determine your switches’
management addresses.
Step 2.2
Using console access, connect to your qfx1 switch and log in using the lab and lab123 login
credentials.
qfx1 (ttyd0)
login: lab
Password:
Step 2.3
View the status of the Virtual Chassis by issuing the show virtual-chassis status
command.
{master:0}
lab@qfx1> show virtual-chassis status
Step 2.4
View the status of the Virtual Chassis’ VCPs by issuing the show virtual-chassis
vc-port command.
{master:0}
lab@qfx1>
Step 2.5
Issue the show chassis hardware command to determine the serial number for qfx1. Write
the serial number on the appropriate line on your lab diagram.
{master:0}
lab@qfx1> show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
Chassis VF3714170305 QFX5100-48S-6Q
Pseudo CB 0
Routing Engine 0 BUILTIN BUILTIN QFX Routing Engine
FPC 0 REV 05 650-056264 VF3714170305 QFX5100-48S-6Q
CPU BUILTIN BUILTIN FPC CPU
PIC 0 BUILTIN BUILTIN 48x10G-6x40G
Xcvr 0 REV 02 740-013111 D275324 SFP-T
Xcvr 48 REV 01 740-038623 MOC14136231262 QSFP+-40G-CU1M
Xcvr 49 REV 01 740-038623 MOC14136231597 QSFP+-40G-CU1M
Xcvr 50 REV 01 740-038624 141460MJ QSFP+-40G-CU3M
Xcvr 51 REV 01 740-038624 1412603F QSFP+-40G-CU3M
Power Supply 0 REV 03 740-041741 1GA24110534 JPSU-650W-AC-AFO
Power Supply 1 REV 03 740-041741 1GA24110529 JPSU-650W-AC-AFO
Fan Tray 0 QFX5100 Fan Tray 0, Front
to Back Airflow - AFO
Fan Tray 1 QFX5100 Fan Tray 1, Front
to Back Airflow - AFO
Fan Tray 2 QFX5100 Fan Tray 2, Front
to Back Airflow - AFO
Fan Tray 3 QFX5100 Fan Tray 3, Front
to Back Airflow - AFO
Fan Tray 4 QFX5100 Fan Tray 4, Front
to Back Airflow - AFO
Step 2.6
Enter configuration mode and load the lab4-start.config configuration file from the /
var/home/lab/dcx/ directory. Commit your changes and return to operational mode.
{master:0}
lab@qfx1> configure
Entering configuration mode
{master:0}[edit]
lab@qfx1# load override dcx/lab4-start.config
load complete
{master:0}[edit]
lab@qfx1# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@qfx1>
Step 2.7
View the configuration for qfx1 by issuing the show configuration command.
{master:0}
lab@qfx1> show configuration
system {
host-name qfx1;
root-authentication {
encrypted-password "$1$KI99zGk6$MbYFuBbpLffu9tn2.sI7l1"; ## SECRET-DATA
ssh-dsa "ssh-dss AAAAB3NzaC1kc3MAAACBAMQrfP2bZyBXJ6PC7XXZ+MzErI8Jl6jah5L4/
O8BsfP2hC7EvRfNoX7MqbrtCX/9gUH9gChVuBCB+ERULMdgRvM5uGhC/
gs4UX+4dBbfBgKYYwgmisM8EoT25m7qI8ybpl2YZvHNznvO8h7kr4kpYuQEpKvgsTdH/
Jle4Uqnjv7DAAAAFQDZaqA6QAgbW3O/
zveaLCIDj6p0dwAAAIB1iL+krWrXiD8NPpY+w4dWXEqaV3bnobzPC4eyxQKBUCOr80Q5YBlWXVBHx9
elwBWZwj0SF4hLKHznExnLerVsMuTMA846RbQmSz62vM6kGM13HFonWeQvWia0TDr78+rOEgWF2KHB
SIxL51lmIDW8Gql9hJfD/Dr/
NKP97w3L0wAAAIEAr3FkWU8XbYytQYEKxsIN9P1UQ1ERXB3G40YwqFO484SlyKyYCfaz+yNsaAJu2C
8UebDIR3GieyNcOAKf3inCG8jQwjLvZskuZwrvlsz/xtcxSoAh9axJcdUfSJYMW/
g+mD26JK1Cliw5rwp2nH9kUrJxeI7IReDp4egNkM4i15o= configurator@server1.he"; ##
SECRET-DATA
}
login {
user lab {
uid 2000;
class super-user;
authentication {
encrypted-password "$1$81ZPtsPx$2db9wN8zaZ4nFtk1qAuDe1"; ##
SECRET-DATA
Step 2.8
Open a new and separate console session to your qfx2 switch and log in using the lab and
lab123 login credentials.
qfx2 (ttyd0)
login: lab
Password:
Step 2.9
View the status of the Virtual Chassis by issuing the show virtual-chassis status
command.
{master:0}
lab@qfx2> show virtual-chassis status
Step 2.10
View the status of the Virtual Chassis’ VCPs by issuing the show virtual-chassis
vc-port command.
{master:0}
lab@qfx2> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
{master:0}
lab@qfx2>
Step 2.11
Issue the show chassis hardware command to determine the serial number for qfx2. Write
the serial number on the appropriate line on your lab diagram.
{master:0}
lab@qfx2> show chassis hardware
Step 2.12
Enter configuration mode and load the lab4-start.config configuration file from the /
var/home/lab/dcx/ directory. Commit your changes and return to operational mode.
{master:0}
lab@qfx2> configure
Entering configuration mode
{master:0}[edit]
lab@qfx2# load override dcx/lab4-start.config
load complete
{master:0}[edit]
lab@qfx2# commit and-quit
configuration check succeeds
commit complete
{master:0}
lab@qfx2>
Step 2.13
View the configuration for qfx2 by issuing the show configuration command.
{master:0}
lab@qfx2> show configuration
## Last commit: 2014-09-26 19:47:17 UTC by lab
version 13.2X51-D21.1;
system {
host-name qfx2;
root-authentication {
encrypted-password "$1$KI99zGk6$MbYFuBbpLffu9tn2.sI7l1"; ## SECRET-DATA
ssh-dsa "ssh-dss AAAAB3NzaC1kc3MAAACBAMQrfP2bZyBXJ6PC7XXZ+MzErI8Jl6jah5L4/
O8BsfP2hC7EvRfNoX7MqbrtCX/9gUH9gChVuBCB+ERULMdgRvM5uGhC/
gs4UX+4dBbfBgKYYwgmisM8EoT25m7qI8ybpl2YZvHNznvO8h7kr4kpYuQEpKvgsTdH/
Jle4Uqnjv7DAAAAFQDZaqA6QAgbW3O/
zveaLCIDj6p0dwAAAIB1iL+krWrXiD8NPpY+w4dWXEqaV3bnobzPC4eyxQKBUCOr80Q5YBlWXVBHx9e
lwBWZwj0SF4hLKHznExnLerVsMuTMA846RbQmSz62vM6kGM13HFonWeQvWia0TDr78+rOEgWF2KHBSI
xL51lmIDW8Gql9hJfD/Dr/
NKP97w3L0wAAAIEAr3FkWU8XbYytQYEKxsIN9P1UQ1ERXB3G40YwqFO484SlyKyYCfaz+yNsaAJu2C8
UebDIR3GieyNcOAKf3inCG8jQwjLvZskuZwrvlsz/xtcxSoAh9axJcdUfSJYMW/
g+mD26JK1Cliw5rwp2nH9kUrJxeI7IReDp4egNkM4i15o= configurator@server1.he"; ##
SECRET-DATA
}
login {
user lab {
uid 2000;
class super-user;
authentication {
encrypted-password "$1$81ZPtsPx$2db9wN8zaZ4nFtk1qAuDe1"; ##
SECRET-DATA
}
}
}
services {
ftp;
ssh {
max-sessions-per-connection 32;
}
telnet;
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
file interactive-commands {
interactive-commands any;
Step 2.14
Open a new and separate console session to your ex1 switch and log in using the lab and
lab123 login credentials.
ex1-ServerA (ttyu0)
login: lab
Password:
Step 2.15
View the status of the Virtual Chassis by issuing the show virtual-chassis status
command.
Step 2.16
View the status of the Virtual Chassis’ VCPs by issuing the show virtual-chassis
vc-port command.
{master:0}
lab@ex1-ServerA> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
{master:0}
lab@ex1-ServerA>
Step 2.17
Issue the show chassis hardware command to determine the serial number for ex1. Write
the serial number on the appropriate line on your lab diagram.
{master:0}
lab@ex1-ServerA> show chassis hardware
Hardware inventory:
Step 2.18
Enter configuration mode and load the lab4-start.config configuration file from the /
var/home/lab/dcx/ directory. Commit your changes and return to operational mode.
{master:0}
lab@ex1-ServerA> configure
Entering configuration mode
{master:0}[edit]
lab@ex1-ServerA# load override dcx/lab4-start.config
load complete
{master:0}[edit]
lab@ex1-ServerA# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@ex1>
Step 2.19
View the configuration for ex1 by issuing the show configuration command.
{master:0}
lab@ex1> show configuration
## Last commit: 2014-09-26 19:48:31 UTC by lab
Step 2.20
Open a new and separate console session to your ex2 switch and log in using the lab and
lab123 login credentials.
ex2-ServerB (ttyu0)
login: lab
Password:
Step 2.21
View the status of the Virtual Chassis by issuing the show virtual-chassis status
command.
{master:0}
lab@ex2-ServerB> show virtual-chassis status
Step 2.22
View the status of the Virtual Chassis’ VCPs by issuing the show virtual-chassis
vc-port command.
{master:0}
lab@ex2-ServerB> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
{master:0}
lab@ex2>
Step 2.23
Issue the show chassis hardware command to determine the serial number for ex2. Write
the serial number on the appropriate line on your lab diagram.
{master:0}
lab@ex2-ServerB> show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
Chassis PG3713330145 EX4300-24T
Routing Engine 0 REV 06 650-044936 PG3713330145 EX4300-24T
FPC 0 REV 06 650-044936 PG3713330145 EX4300-24T
CPU BUILTIN BUILTIN FPC CPU
PIC 0 REV 06 BUILTIN BUILTIN 24x 10/100/1000 Base-T
PIC 1 REV 06 BUILTIN BUILTIN 4x 40GE QSFP+
Xcvr 0 REV 01 740-044512 MOC13405122192 QSFP+-40G-CU50CM
Xcvr 1 REV 01 740-044512 MOC13405122146 QSFP+-40G-CU50CM
Xcvr 2 REV 01 740-038624 14146087 QSFP+-40G-CU3M
Xcvr 3 REV 01 740-038624 1412603F QSFP+-40G-CU3M
Power Supply 0 REV 01 740-046873 1EDE3290261 JPSU-350-AC-AFO-A
Step 2.24
Enter configuration mode and load the lab4-start.config configuration file from the /
var/home/lab/dcx/ directory. Commit your changes and return to operational mode.
{master:0}
lab@ex2-ServerB> configure
Entering configuration mode
{master:0}[edit]
lab@ex2-ServerB# load override dcx/lab4-start.config
load complete
{master:0}[edit]
lab@ex2-ServerB# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@ex2>
Step 2.25
View the configuration for ex2 by issuing the show configuration command.
{master:0}
lab@ex2> show configuration
## Last commit: 2014-09-26 19:49:30 UTC by lab
version 13.2X51-D21.1;
system {
host-name ex2;
root-authentication {
encrypted-password "$1$KI99zGk6$MbYFuBbpLffu9tn2.sI7l1"; ## SECRET-DATA
In this lab part, you will preprovision a mixed Virtual Chassis consisting of two REs and two
linecards. The QFX5100 Series switches will act as master (qfx1) and backup (qfx2) REs. The
EX4300 Series switches will act as line cards. Configuration of a preprovisioned Virtual Chassis
must be performed on the master RE. That means that all Virtual Chassis configuration will be
performed on qfx1. Use the lab diagram titled “Network Diagram: Mixed Virtual Chassis Lab” for
this part of the lab.
Step 3.1
Return to the console session opened for qfx1.
On qfx1, enter configuration mode and navigate to the [edit virtual-chassis]
hierarchy. Configure the Virtual Chassis as a preprovisioned Virtual Chassis.
{master:0}
lab@qfx1> configure
Entering configuration mode
{master:0}[edit]
lab@qfx1# edit virtual-chassis
{master:0}[edit virtual-chassis]
lab@qfx1# set preprovisioned
{master:0}[edit virtual-chassis]
lab@qfx1#
Step 3.2
Configure member (qfx1) to take on the RE role. Make sure to specify the serial number for qfx1
that you determined in the previous part of the lab.
{master:0}[edit virtual-chassis]
lab@qfx1# set member 0 role routing-engine
{master:0}[edit virtual-chassis]
lab@qfx1# set member 0 serial-number serial-qfx1
Step 3.3
Configure member 1 to take on the linecard role. Make sure to specify the serial number for ex1
that you determined in the previous part of the lab.
{master:0}[edit virtual-chassis]
lab@qfx1# set member 1 serial-number serial-ex1
Step 3.4
Configure member 2 to take on the linecard role. Make sure to specify the serial number for ex2
that you determined in the previous part of the lab.
{master:0}[edit virtual-chassis]
lab@qfx1# set member 2 role line-card
{master:0}[edit virtual-chassis]
lab@qfx1# set member 2 serial-number serial-ex2
Step 3.5
Configure member 3 to take on the RE role. Make sure to specify the serial number for qfx2 that
you determined in the previous part of the lab.
{master:0}[edit virtual-chassis]
lab@qfx1# set member 3 role routing-engine
{master:0}[edit virtual-chassis]
lab@qfx1# set member 3 serial-number serial-qfx2
Step 3.6
View your configuration so far and if you are satisfied commit your configuration and exit to
operational mode.
{master:0}[edit virtual-chassis]
lab@qfx1# show
preprovisioned;
member 0 {
role routing-engine;
serial-number VF3714170305;
}
member 1 {
role line-card;
serial-number PG3713360118;
}
member 2 {
role line-card;
serial-number PG3713330145;
}
member 3 {
role routing-engine;
serial-number VF3714170306;
}
{master:0}[edit virtual-chassis]
lab@qfx1# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
Step 3.8
View the status of the VCPs by issuing the show virtual-chassis vc-port command.
lab@qfx1> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
{master:0}
lab@qfx1>
Step 3.9
Look at the diagram for this part of the lab.
Step 3.10
Enable vcp-255/0/50 and vcp-255/0/51 on qfx1 by issuing the request
virtual-chassis vc-port set pic-slot 0 port port-number command for
each VCP.
{master:0}
lab@qfx1> request virtual-chassis vc-port set pic-slot 0 port 50
Port conversion initiated, use show virtual-chassis vc-port to verify
{master:0}
lab@qfx1> request virtual-chassis vc-port set pic-slot 0 port 51
Port conversion initiated, use show virtual-chassis vc-port to verify
{master:0}
lab@qfx1>
Step 3.11
View the status of the VCPs by issuing the show virtual-chassis vc-port command.
{master:0}
lab@qfx1> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
Interface Type Trunk Status Speed Neighbor
or ID (mbps) ID Interface
PIC / Port
0/50 Configured -1 Down 40000
0/51 Configured -1 Down 40000
In this lab part, you will add the remaining member switches to the Virtual Chassis. To add a
member to an existing preprovisioned Virtual Chassis you simply enable the appropriate VCP
interfaces. Use the lab diagram titled “Network Diagram: Mixed Virtual Chassis Lab” for this part
of the lab.
Step 4.1
Return to the console session opened for ex1.
On ex1, enable vcp-255/1/3 by issuing the request virtual-chassis vc-port set
pic-slot 1 port 3 command.
{master:0}
lab@ex1> request virtual-chassis vc-port set pic-slot 1 port 3
Port conversion initiated, use show virtual-chassis vc-port to verify
{master:0}
lab@ex1>
Step 4.2
Enable vcp-255/1/2 on ex1 by issuing the request virtual-chassis vc-port set
pic-slot 1 port 2 command. After issuing the command you will be logged out of ex1.
Wait 60 seconds before moving to the next step.
{master:0}
lab@ex1> request virtual-chassis vc-port set pic-slot 1 port 2
Port conversion initiated, use show virtual-chassis vc-port to verify
{master:0}
lab@ex1>
login:
Step 4.3
Login to ex1 using the lab and lab123 login credentials.
ex1 (ttyu0)
login: lab
Logging to master
Password:
Answer: Once you have logged in you should notice that your
session has been redirected to qfx1. This means that ex1 has
become a member of the Virtual Chassis.
Step 4.4
View the status of the Virtual Chassis by issuing the show virtual-chassis status
command.
{master:0}
lab@qfx1> show virtual-chassis status
Step 4.5
View the configuration of the Virtual Chassis using the show configuration command.
{master:0}
lab@qfx1> show configuration
## Last commit: 2014-09-25 04:22:48 UTC by lab
version 13.2X51-D21.1;
system {
host-name qfx1;
root-authentication {
encrypted-password "$1$ZBczLr53$0ocGXc4o4GS9tCSikhcm3/"; ## SECRET-DATA
}
login {
user lab {
uid 2000;
class super-user;
authentication {
encrypted-password "$1$81ZPtsPx$2db9wN8zaZ4nFtk1qAuDe1"; ##
SECRET-DATA
}
}
}
services {
ftp;
ssh {
max-sessions-per-connection 32;
}
telnet;
}
syslog {
user * {
Step 4.6
Return to the console session opened for qfx2.
On qfx2, enable vcp-255/0/51 on qfx2 by issuing the request virtual-chassis
vc-port set pic-slot 0 port 51 command. After issuing the command you will be
logged out of qfx2. Wait 60 seconds before moving to the next step.
{master:0}
lab@qfx2> request virtual-chassis vc-port set pic-slot 0 port 51
Port conversion initiated, use show virtual-chassis vc-port to verify
qfx2 (ttyd0)
login:
Step 4.7
Login to qfx2 using the lab and lab123 login credentials.
qfx2 (ttyd0)
login: lab
Logging to master
Password:
Answer: Once you have logged in you should notice that your
session has been redirected to qfx1. This means that qfx2 has
become a member of the Virtual Chassis.
Step 4.8
View the status of the Virtual Chassis by issuing the show virtual-chassis status
command.
{master:0}
lab@qfx1> show virtual-chassis status
Step 4.9
Enable vcp-255/0/50 on member 3 by issuing the request virtual-chassis vc-port
set pic-slot 0 port 50 member 3 command.
{master:0}
lab@qfx1> request virtual-chassis vc-port set pic-slot 0 port 50 member 3
fpc3:
--------------------------------------------------------------------------
Port conversion initiated, use show virtual-chassis vc-port to verify
{master:0}
lab@ex2>
ex2 (ttyu0)
login:
Step 4.11
Login to ex2 using the lab and lab123 login credentials.
ex2 (ttyu0)
login: lab
Logging to master
Password:
Answer: Once you have logged in you should notice that your
session has been redirected to qfx1. This means that ex2 has
become a member of the Virtual Chassis.
Step 4.12
View the status of the Virtual Chassis by issuing the show virtual-chassis status
command.
{master:0}
lab@qfx1> show virtual-chassis status
Step 4.13
Enable vcp-255/1/3 on member 2 by issuing the request virtual-chassis vc-port
set pic-slot 1 port 3 member 2 command.
{master:0}
lab@qfx1> request virtual-chassis vc-port set pic-slot 1 port 3 member 2
fpc2:
--------------------------------------------------------------------------
Port conversion initiated, use show virtual-chassis vc-port to verify
As you have seen so far, only the master RE is in the Prsnt (or active) state. All other members
are Inactive because the master RE has detected at least one member that is a different
chassis than itself (a QFX5100 Series switch). In this lab part you will enable a mixed Virtual
Chassis so that all members of the Virtual Chassis will show as Prsnt. Use the lab diagram
titled “Network Diagram: Mixed Virtual Chassis Lab” for this part of the lab.
Step 5.1
View the status of the Virtual Chassis by issuing the show virtual-chassis status
command. Take a moment to view all the things that appear to be a problem with the Virtual
Chassis.
{master:0}
lab@qfx1> show virtual-chassis status
Question: List all of the problems that you see in the output of
this command?
Step 5.2
Change the mode of all members of the Virtual Chassis by issuing the request
virtual-chassis mode mixed reboot all-members. This command will also cause
all members to reboot. Wait for the reboot to complete before moving on to the next step.
{master:0}
lab@qfx1> request virtual-chassis mode mixed reboot all-members
fpc1:
--------------------------------------------------------------------------
Mode set to 'Virtual Chassis with mixed devices'. Rebooting system...
fpc2:
--------------------------------------------------------------------------
Mode set to 'Virtual Chassis with mixed devices'. Rebooting system...
fpc3:
--------------------------------------------------------------------------
Mode set to 'Virtual Chassis with mixed devices'. Rebooting system...
fpc0:
{master:0}
lab@qfx1>
*** System shutdown message from root@qfx1 ***
login: lab
Logging to master
Password:
In this lab part you will configure a few of the interfaces for Ethernet switching. You will use the
member number to help determine the interfaces names. Use the lab diagram titled “Network
Diagram: Mixed Virtual Chassis Lab” for this part of the lab.
Step 6.1
Look at the diagram for this part of the lab. Notice the two interfaces on the Virtual Chassis that
are connected to the two virtual routers. Use your knowledge of member IDs to determine the
name of the interfaces. Fill in the spaces provided on the diagram.
Step 6.2
Enter configuration mode and navigate to the [edit vlans] hierarchy. Configure a VLAN
called vlan_301 using a VLAN ID of 301.
{master:0}
lab@qfx1> configure
Entering configuration mode
{master:0}[edit]
lab@qfx1# edit vlans
{master:0}[edit vlans]
lab@qfx1# set vlan_301 vlan-id 301
Step 6.3
Navigate to the [edit interfaces] hierarchy and configure each of the virtual router-facing
interfaces to perform Ethernet switching as trunk interfaces for VLAN 301 only. Commit your
configuration and exit to operational mode.
{master:0}[edit vlans]
lab@qfx1# top edit interfaces
{master:0}[edit interfaces]
lab@qfx1# set ge-1/0/15 unit 0 family ethernet-switching interface-mode trunk
{master:0}[edit interfaces]
lab@qfx1# set ge-1/0/15 unit 0 family ethernet-switching vlan members vlan_301
{master:0}[edit interfaces]
lab@qfx1# set ge-2/0/6 unit 0 family ethernet-switching interface-mode trunk
{master:0}[edit interfaces]
lab@qfx1# set ge-2/0/6 unit 0 family ethernet-switching vlan members vlan_301
{master:0}[edit interfaces]
lab@qfx1# commit and-quit
configuration check succeeds
fpc1:
commit complete
fpc2:
commit complete
fpc3:
commit complete
commit complete
Exiting configuration mode
{master:0}
lab@qfx1>
Step 6.4
View the configured VLANs by issuing the show vlans command.
{master:0}
lab@qfx1> show vlans
Step 6.5
Verify proper operation by sending ICMP traffic from vr1 to vr2 using the ping 172.16.1.2
routing-instance vr1 count 5 command.
{master:0}
lab@qfx1> ping 172.16.1.2 routing-instance vr1 count 5
PING 172.16.1.2 (172.16.1.2): 56 data bytes
64 bytes from 172.16.1.2: icmp_seq=0 ttl=64 time=61.719 ms
64 bytes from 172.16.1.2: icmp_seq=1 ttl=64 time=41.115 ms
64 bytes from 172.16.1.2: icmp_seq=2 ttl=64 time=33.014 ms
64 bytes from 172.16.1.2: icmp_seq=3 ttl=64 time=29.075 ms
64 bytes from 172.16.1.2: icmp_seq=4 ttl=64 time=33.030 ms
Step 6.6
View the MAC table of the Virtual Chassis by issuing the show ethernet-switching
table command to see if MAC addresses are being learned by the Virtual Chassis.
{master:0}
lab@qfx1> show ethernet-switching table
In this lab part you will remove each of the members from the Virtual Chassis and return them to
a standalone state. Use the lab diagram titled “Network Diagram: Mixed Virtual Chassis Lab” for
this part of the lab.
Step 7.1
Delete each of the VCPs of ex2 by issuing the request virtual-chassis vc-port
delete pic-slot 1 port port-number member 2 command for each VCP. You will be
logged out of the Virtual Chassis.
{master:0}
lab@qfx1> request virtual-chassis vc-port delete pic-slot 1 port port-number
member 2
fpc2:
--------------------------------------------------------------------------
vc-port successfully deleted
{master:0}
lab@qfx1> request virtual-chassis vc-port delete pic-slot 1 port port-number
member 2
qfx1 (ttyu0)
login:
Step 7.2
Attempt to log back into ex2 using the lab and lab123 login credentials. ex2 will attempt to log
into the Virtual Chassis. After 10 attempts, it will allow you to log directly into the ex2 switch.
qfx1 (ttyu0)
login: lab
Logging to master
..........
Connection to master failed, enabling local login
Password:
{linecard:2}[edit]
lab@qfx1# load override dcx/lab4-start.config
load complete
{linecard:2}[edit]
lab@qfx1# commit and-quit
commit complete
Exiting configuration mode
{linecard:2}
lab@ex2>
{linecard:2}
lab@ex2>
Step 7.5
Log back into ex2 using the lab and lab123 login credentials. ex2 will attempt to log into the
Virtual Chassis. After 10 attempts, it will allow you to log directly into the ex2 switch. View the
status of the Virtual Chassis by issuing the show virtual-chassis status command.
ex2 (ttyu0)
login: lab
Logging to master
..........
Connection to master failed, enabling local login
Password:
{linecard:2}
lab@ex2> show virtual-chassis status
Step 7.6
Reactivate member 2 by issuing the request virtual-chassis reactivate command.
You will be logged out of ex2.
{linecard:2}
lab@ex2> request virtual-chassis reactivate
This member split from a virtual chassis. Please make sure that no active
switch belonging to this virtual chassis has conflicting configuration.
{linecard:2}
lab@ex2>
ex2 (ttyu0)
login:
Step 7.7
Log back into ex2 using the lab and lab123 login credentials. View the status of the Virtual
Chassis by issuing the show virtual-chassis status command.
ex2 (ttyu0)
login: lab
Password:
Step 7.8
Although not required, the final step in converting ex2 back to standalone mode is to renumber
its member ID to 0. Perform this step by issuing the request virtual-chassis
renumber member-id 2 new-member-id 0 command. You will be automatically logged
out of ex2.
{master:2}
lab@ex2> request virtual-chassis renumber member-id 2 new-member-id 0
{master:2}
lab@ex2>
ex2 (ttyu0)
login:
Step 7.9
Log back into ex2 using the lab and lab123 login credentials. View the status of the Virtual
Chassis by issuing the show virtual-chassis status command. Log out of ex2 when
complete.
ex2 (ttyu0)
login: lab
Password:
ex2 (ttyu0)
login:
Step 7.10
Return to the console session opened for qfx2.
On qfx2, attempt to log back into qfx2 using the lab and lab123 login credentials. Delete
vcp-255/0/50 of qfx2 by issuing the request virtual-chassis vc-port delete
pic-slot 0 port 50 member 3 command.
qfx1 (ttyd0)
login: lab
Logging to master
Password:
qfx1 (ttyu0)
login:
login: lab
Password:
{linecard:3}[edit]
lab@qfx1# load override dcx/lab4-start.config
load complete
{linecard:3}[edit]
lab@qfx1# commit and-quit
{linecard:3}
lab@qfx2>
Step 7.14
Change the mode of qfx2 so that it operates in non-mixed Virtual Chassis mode. Also, make sure
that it reboots immediately. Wait for qfx2 to reboot before continuing.
{linecard:3}
lab@qfx2> request virtual-chassis mode mixed disable reboot
fpc3:
--------------------------------------------------------------------------
Mode set to 'Virtual Chassis with similar devices'. Rebooting system...
{linecard:3}
lab@qfx2>
Step 7.15
Log back into qfx2 using the lab and lab123 login credentials. View the status of the Virtual
Chassis by issuing the show virtual-chassis status command.
qfx2 (ttyd0)
login: lab
Password:
Step 7.16
Reactivate member 3 by issuing the request virtual-chassis reactivate command.
You will be logged out of qfx2.
{linecard:3}
lab@qfx2> request virtual-chassis reactivate
{linecard:3}
lab@qfx2>
qfx2 (ttyd0)
login:
Step 7.17
Log back into qfx2 using the lab and lab123 login credentials. View the status of the Virtual
Chassis by issuing the show virtual-chassis status command.
qfx2 (ttyd0)
login: lab
Password:
Step 7.18
Although not required, the final step in converting qfx2 back to standalone mode is to renumber
its member ID to 0. Perform this step by issuing the request virtual-chassis
renumber member-id 3 new-member-id 0 command. You will be automatically logged
out of qfx2.
{master:3}
lab@qfx2> request virtual-chassis renumber member-id 3 new-member-id 0
{master:3}
lab@qfx2>
qfx2 (ttyd0)
login:
Step 7.19
Log back into qfx2 using the lab and lab123 login credentials. View the status of the Virtual
Chassis by issuing the show virtual-chassis status command. Log out of qfx2 when
complete.
qfx2 (ttyd0)
login: lab
Password:
qfx2 (ttyu0)
login:
Step 7.20
Return to the console session opened for ex1.
On ex1,. attempt to log back in using the lab and lab123 login credentials. Delete vcp-255/1/
3 of ex1 by issuing the request virtual-chassis vc-port delete pic-slot 1
port 3 member 1 command.
login: lab
Password:
{linecard:1}
lab@qfx1>
Step 7.21
Delete vcp-255/1/2 of ex1 by issuing the request virtual-chassis vc-port delete
pic-slot 1 port 2 member 1 command. You will be logged out of the Virtual Chassis.
{linecard:1}
lab@qfx1> request virtual-chassis vc-port delete pic-slot 1 port 2 member 1
qfx1 (ttyu0)
login:
Step 7.22
Attempt to log back into ex1 using the lab and lab123 login credentials. Enter configuration
mode and load the lab4-start.config configuration file from the /var/home/lab/
dcx/ directory. Commit your changes and return to operational mode.
qfx1 (ttyu0)
login: lab
Password:
{linecard:1}[edit]
lab@qfx1# load override dcx/lab4-start.config
load complete
{linecard:1}[edit]
lab@qfx1# commit and-quit
commit complete
Exiting configuration mode
{linecard:1}
lab@ex1>
Step 7.23
Change the mode of ex1 so that it operates in non-mixed Virtual Chassis mode. Also, make sure
that it reboots immediately. Wait for ex1 to reboot before continuing.
lab@ex1> request virtual-chassis mode mixed disable reboot
fpc1:
--------------------------------------------------------------------------
Mode set to 'Virtual Chassis with similar devices'. Rebooting system...
{linecard:1}
lab@ex1>
Step 7.24
Log back into ex1 using the lab and lab123 login credentials. ex1 will attempt to log into the
Virtual Chassis. After 10 attempts, it will allow you to log directly into the ex1 switch.View the
status of the Virtual Chassis by issuing the show virtual-chassis status command.
ex1 (ttyu0)
login: lab
Logging to master
..........
Connection to master failed, enabling local login
Password:
Step 7.25
Reactivate member 1 by issuing the request virtual-chassis reactivate command.
You will be logged out of ex1.
lab@ex1> request virtual-chassis reactivate
This member split from a virtual chassis. Please make sure that no active
switch belonging to this virtual chassis has conflicting configuration.
{linecard:1}
lab@ex1>
ex1 (ttyu0)
login:
Step 7.26
Log back into ex1 using the lab and lab123 login credentials. View the status of the Virtual
Chassis by issuing the show virtual-chassis status command.
{linecard:1}
lab@ex1>
ex1 (ttyu0)
login: lab
Password:
Step 7.27
Although not required, the final step in converting ex1 back to standalone mode is to renumber
its member ID to 0. Perform this step by issuing the request virtual-chassis
renumber member-id 1 new-member-id 0 command. You will be automatically logged
out of ex1.
{master:1}
lab@ex1> request virtual-chassis renumber member-id 1 new-member-id 0
{master:1}
lab@ex1>
ex1 (ttyu0)
login:
Step 7.28
Log back into ex1 using the lab and lab123 login credentials. View the status of the Virtual
Chassis by issuing the show virtual-chassis status command. Log out of ex1 when
complete.
ex1 (ttyu0)
login: lab
Password:
{master:0}
lab@ex1> exit
ex1 (ttyu0)
login:
Step 7.29
Return to the console session opened for qfx1.
On qfx1, attempt to login using the lab and lab123 login credentials. Delete vcp-255/0/50 of
qfx1 by issuing the request virtual-chassis vc-port delete pic-slot 0 port
50 command.
qfx1 (ttyd0)
login: lab
Password:
{linecard:0}[edit]
lab@qfx1# load override dcx/lab4-start.config
load complete
{linecard:0}[edit]
lab@qfx1# commit and-quit
{linecard:0}
lab@qfx1>
Step 7.32
Change the mode of qfx1 so that it operates in non-mixed Virtual Chassis mode. Also, make sure
that it reboots immediately. Wait for qfx1 to reboot before continuing.
{linecard:0}
lab@qfx1> request virtual-chassis mode mixed disable reboot
fpc0:
--------------------------------------------------------------------------
Mode set to 'Virtual Chassis with similar devices'. Rebooting system...
{linecard:0}
login: lab
Logging to master
{linecard:0}
lab@qfx1>
Step 7.34
Reactivate member 0 by issuing the request virtual-chassis reactivate command.
You will be logged out of qfx1.
lab@qfx1> request virtual-chassis reactivate
This member split from a virtual chassis. Please make sure that no active
switch belonging to this virtual chassis has conflicting configuration.
{linecard:0}
lab@qfx1>
qfx1 (ttyd0)
login:
login: lab
Password:
{master:0}
lab@qfx1> exit
qfx1 (ttyu0)
login:
STOP Tell your instructor that you have completed this lab.
Overview
In this lab, you provision a mixed Virtual Chassis Fabric (VCF) using a combination of two
QFX5100 Series switches and two EX4300 Series switches. The QFX5100 Series switches will
act as spines as well as master and backup Routing Engines (REs). The EX4300 Series switches
will act as leafs as well as linecards for the VCF.
By completing this lab, you will perform the following tasks:
• Access your assigned switches.
• Configure the master RE for auto-provisioning of the VCF.
• Enable the Virtual Chassis Ports (VCPs) on each of the switches.
• Verify that each member switch has taken on the appropriate role.
• Configure network interfaces on the VCF.
• Verify that the VCF appears to act as a single switch.
• Add a VCF into Junos Space for management purposes.
• Reset the members of the VCF into individual standalone switches.
In this lab part, you will review the lab diagram to determine the roles that each switch will take
as part of the VCF. Use the lab diagram titled “Network Diagram: Virtual Chassis Fabric Lab” for
this part of the lab.
Step 1.1
Take a look at the diagram labeled “Network Diagram: Virtual Chassis Fabric Lab.”
Answer: ex1 and ex2 will be both leafs and linecards for the VCF.
In this lab part, you become familiar with the access details used to connect to the lab
equipment. Once you are familiar with the access details, you will use the CLI to log in to your
team’s designated switches. Once you have logged in to your devices you will make sure your
devices are running the appropriate starting configurations for this lab. Use the lab diagram
titled “Network Diagram: Virtual Chassis Fabric Lab” for this part of the lab.
Step 2.1
Ensure that you know to which switches you have been assigned. Check with your instructor if
you are not certain. Consult the management network diagram to determine your switches’
management addresses.
Step 2.2
Using console access, connect to your qfx1 switch and log in using the lab and lab123 login
credentials.
qfx1 (ttyd0)
login: lab
Password:
Step 2.3
View the status of the Virtual Chassis by issuing the show virtual-chassis status
command.
{master:0}
lab@qfx1> show virtual-chassis status
Step 2.4
View the status of the Virtual Chassis’ VCPs by issuing the show virtual-chassis
vc-port command.
{master:0}
lab@qfx1> show virtual-chassis vc-port
fpc0:
{master:0}
lab@qfx1>
Step 2.5
Issue the show chassis hardware command to determine the serial number for qfx1. Write
the serial number on the appropriate line on your lab diagram.
{master:0}
lab@qfx1> show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
Chassis VF3714170305 QFX5100-48S-6Q
Pseudo CB 0
Routing Engine 0 BUILTIN BUILTIN QFX Routing Engine
FPC 0 REV 05 650-056264 VF3714170305 QFX5100-48S-6Q
CPU BUILTIN BUILTIN FPC CPU
PIC 0 BUILTIN BUILTIN 48x10G-6x40G
Xcvr 0 REV 02 740-013111 D275324 SFP-T
Xcvr 48 REV 01 740-038623 MOC14136231262 QSFP+-40G-CU1M
Xcvr 49 REV 01 740-038623 MOC14136231597 QSFP+-40G-CU1M
Xcvr 50 REV 01 740-038624 141460MJ QSFP+-40G-CU3M
Xcvr 51 REV 01 740-038624 1412603F QSFP+-40G-CU3M
Power Supply 0 REV 03 740-041741 1GA24110534 JPSU-650W-AC-AFO
Power Supply 1 REV 03 740-041741 1GA24110529 JPSU-650W-AC-AFO
Fan Tray 0 QFX5100 Fan Tray 0, Front
to Back Airflow - AFO
Fan Tray 1 QFX5100 Fan Tray 1, Front
to Back Airflow - AFO
Fan Tray 2 QFX5100 Fan Tray 2, Front
to Back Airflow - AFO
Fan Tray 3 QFX5100 Fan Tray 3, Front
to Back Airflow - AFO
Fan Tray 4 QFX5100 Fan Tray 4, Front
to Back Airflow - AFO
Step 2.6
Enter configuration mode and load the lab5-start.config configuration file from the /
var/home/lab/dcx/ directory. Commit your changes and return to operational mode.
{master:0}
lab@qfx1> configure
Entering configuration mode
{master:0}[edit]
lab@qfx1# load override dcx/lab5-start.config
load complete
{master:0}[edit]
lab@qfx1# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@qfx1>
Step 2.7
View the configuration for qfx1 by issuing the show configuration command.
{master:0}
lab@qfx1> show configuration
system {
host-name qfx1;
root-authentication {
encrypted-password "$1$KI99zGk6$MbYFuBbpLffu9tn2.sI7l1"; ## SECRET-DATA
ssh-dsa "ssh-dss AAAAB3NzaC1kc3MAAACBAMQrfP2bZyBXJ6PC7XXZ+MzErI8Jl6jah5L4/
O8BsfP2hC7EvRfNoX7MqbrtCX/9gUH9gChVuBCB+ERULMdgRvM5uGhC/
gs4UX+4dBbfBgKYYwgmisM8EoT25m7qI8ybpl2YZvHNznvO8h7kr4kpYuQEpKvgsTdH/
Jle4Uqnjv7DAAAAFQDZaqA6QAgbW3O/
zveaLCIDj6p0dwAAAIB1iL+krWrXiD8NPpY+w4dWXEqaV3bnobzPC4eyxQKBUCOr80Q5YBlWXVBHx9
elwBWZwj0SF4hLKHznExnLerVsMuTMA846RbQmSz62vM6kGM13HFonWeQvWia0TDr78+rOEgWF2KHB
SIxL51lmIDW8Gql9hJfD/Dr/
NKP97w3L0wAAAIEAr3FkWU8XbYytQYEKxsIN9P1UQ1ERXB3G40YwqFO484SlyKyYCfaz+yNsaAJu2C
8UebDIR3GieyNcOAKf3inCG8jQwjLvZskuZwrvlsz/xtcxSoAh9axJcdUfSJYMW/
g+mD26JK1Cliw5rwp2nH9kUrJxeI7IReDp4egNkM4i15o= configurator@server1.he"; ##
SECRET-DATA
}
login {
user lab {
uid 2000;
class super-user;
authentication {
encrypted-password "$1$81ZPtsPx$2db9wN8zaZ4nFtk1qAuDe1"; ##
SECRET-DATA
Step 2.8
Open a new and separate console session to your qfx2 switch and log in using the lab and
lab123 login credentials.
qfx2 (ttyd0)
login: lab
Password:
Step 2.9
View the status of the Virtual Chassis by issuing the show virtual-chassis status
command.
{master:0}
lab@qfx2> show virtual-chassis status
Step 2.10
View the status of the Virtual Chassis’ VCPs by issuing the show virtual-chassis
vc-port command.
{master:0}
lab@qfx2> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
{master:0}
lab@qfx2>
Step 2.11
Issue the show chassis hardware command to determine the serial number for qfx2. Write
the serial number on the appropriate line on your lab diagram.
{master:0}
lab@qfx2> show chassis hardware
Hardware inventory:
Step 2.12
Enter configuration mode and load the lab5-start.config configuration file from the /
var/home/lab/dcx/ directory. Commit your changes and return to operational mode.
{master:0}
lab@qfx2> configure
Entering configuration mode
{master:0}[edit]
lab@qfx2# load override dcx/lab5-start.config
load complete
{master:0}[edit]
lab@qfx2# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@qfx2>
Step 2.13
View the configuration for qfx2 by issuing the show configuration command.
{master:0}
lab@qfx2> show configuration
## Last commit: 2014-09-26 19:47:17 UTC by lab
version 13.2X51-D21.1;
system {
host-name qfx2;
root-authentication {
encrypted-password "$1$KI99zGk6$MbYFuBbpLffu9tn2.sI7l1"; ## SECRET-DATA
ssh-dsa "ssh-dss AAAAB3NzaC1kc3MAAACBAMQrfP2bZyBXJ6PC7XXZ+MzErI8Jl6jah5L4/
O8BsfP2hC7EvRfNoX7MqbrtCX/9gUH9gChVuBCB+ERULMdgRvM5uGhC/
gs4UX+4dBbfBgKYYwgmisM8EoT25m7qI8ybpl2YZvHNznvO8h7kr4kpYuQEpKvgsTdH/
Jle4Uqnjv7DAAAAFQDZaqA6QAgbW3O/
zveaLCIDj6p0dwAAAIB1iL+krWrXiD8NPpY+w4dWXEqaV3bnobzPC4eyxQKBUCOr80Q5YBlWXVBHx9e
lwBWZwj0SF4hLKHznExnLerVsMuTMA846RbQmSz62vM6kGM13HFonWeQvWia0TDr78+rOEgWF2KHBSI
xL51lmIDW8Gql9hJfD/Dr/
NKP97w3L0wAAAIEAr3FkWU8XbYytQYEKxsIN9P1UQ1ERXB3G40YwqFO484SlyKyYCfaz+yNsaAJu2C8
UebDIR3GieyNcOAKf3inCG8jQwjLvZskuZwrvlsz/xtcxSoAh9axJcdUfSJYMW/
g+mD26JK1Cliw5rwp2nH9kUrJxeI7IReDp4egNkM4i15o= configurator@server1.he"; ##
SECRET-DATA
}
login {
user lab {
uid 2000;
class super-user;
authentication {
encrypted-password "$1$81ZPtsPx$2db9wN8zaZ4nFtk1qAuDe1"; ##
SECRET-DATA
}
}
}
services {
ftp;
ssh {
max-sessions-per-connection 32;
}
telnet;
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
Step 2.14
Open a new and separate console session to your ex1 switch and log in using the lab and
lab123 login credentials.
ex1 (ttyu0)
login: lab
Password:
Step 2.15
View the status of the Virtual Chassis by issuing the show virtual-chassis status
command.
Step 2.16
View the status of the Virtual Chassis’ VCPs by issuing the show virtual-chassis
vc-port command.
{master:0}
lab@ex1> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
{master:0}
lab@ex1>
Step 2.17
Issue the show chassis hardware command to determine the serial number for ex1. Write
the serial number on the appropriate line on your lab diagram.
{master:0}
lab@ex1> show chassis hardware
Hardware inventory:
Step 2.18
Enter configuration mode and load the lab5-start.config configuration file from the /
var/home/lab/dcx/ directory. Commit your changes and return to operational mode.
{master:0}
lab@ex1> configure
Entering configuration mode
{master:0}[edit]
lab@ex1# load override dcx/lab5-start.config
load complete
{master:0}[edit]
lab@ex1# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@ex1>
Step 2.19
View the configuration for ex1 by issuing the show configuration command.
{master:0}
lab@ex1> show configuration
## Last commit: 2014-09-26 19:48:31 UTC by lab
Step 2.20
Open a new and separate console session to your ex2 switch and log in using the lab and
lab123 login credentials.
ex2 (ttyu0)
login: lab
Password:
Step 2.21
View the status of the Virtual Chassis by issuing the show virtual-chassis status
command.
{master:0}
lab@ex2> show virtual-chassis status
Step 2.22
View the status of the Virtual Chassis’ VCPs by issuing the show virtual-chassis
vc-port command.
{master:0}
lab@ex2> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
{master:0}
lab@ex2>
Step 2.23
Issue the show chassis hardware command to determine the serial number for ex2. Write
the serial number on the appropriate line on your lab diagram.
{master:0}
lab@ex2> show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
Chassis PG3713330145 EX4300-24T
Routing Engine 0 REV 06 650-044936 PG3713330145 EX4300-24T
FPC 0 REV 06 650-044936 PG3713330145 EX4300-24T
CPU BUILTIN BUILTIN FPC CPU
Step 2.24
Enter configuration mode and load the lab5-start.config configuration file from the /
var/home/lab/dcx/ directory. Commit your changes and return to operational mode.
{master:0}
lab@ex2> configure
Entering configuration mode
{master:0}[edit]
lab@ex2# load override dcx/lab5-start.config
load complete
{master:0}[edit]
lab@ex2# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@ex2>
Step 2.25
View the configuration for ex2 by issuing the show configuration command.
{master:0}
lab@ex2> show configuration
## Last commit: 2014-09-26 19:49:30 UTC by lab
version 13.2X51-D21.1;
system {
host-name ex2;
root-authentication {
encrypted-password "$1$KI99zGk6$MbYFuBbpLffu9tn2.sI7l1"; ## SECRET-DATA
In this lab part, you will auto-provision a mixed VCF consisting of two REs and two linecards. The
QFX5100 Series switches (spines) will act as master (qfx1) and backup (qfx2) REs. The EX4300
Series switches (leafs) will act as line cards. Configuration of an auto-provisioned VCF must be
performed on the master RE. That means that all VCF configuration will be performed on qfx1.
Use the lab diagram titled “Network Diagram: Virtual Chassis Fabric Lab” for this part of the lab.
Step 3.1
Return to the console session opened for qfx1.
On qfx1, set the Virtual Chassis mode to a mixed VCF by issuing the request
virtual-chassis mode fabric mixed reboot command. qfx1 will reboot after this
command is issued. Wait until qfx1 has finished rebooting before continuing to the next step.
{master:0}
lab@qfx1> request virtual-chassis mode fabric mixed reboot
fpc0:
--------------------------------------------------------------------------
WARNING, Virtual Chassis Fabric mode enabled without a valid software license.
Answer: The mixed modifier was specified so that the VCF will
support the combination of QFX5100 and EX4300 Series in
your lab environment.
Step 3.2
Login to qfx1 using the lab and lab123 login credentials and view the status of the VCF by
issuing the show virtual-chassis status command.
login: lab
Password:
Question: What fabric mode is qfx1 currently in? What does that
mean?
Step 3.3
Enter configuration mode and navigate to the [edit virtual-chassis] hierarchy.
Configure the VCF as an autoprovisioned VCF.
{master:0}
lab@qfx1> configure
Entering configuration mode
{master:0}[edit]
lab@qfx1# edit virtual-chassis
{master:0}[edit virtual-chassis]
lab@qfx1# set auto-provisioned
{master:0}[edit virtual-chassis]
lab@qfx1# set member 0 serial-number serial-qfx1
Step 3.5
Configure member 1 to take on the RE role. Make sure to specify the serial number for qfx2 that
you determined in the previous part of the lab.
{master:0}[edit virtual-chassis]
lab@qfx1# set member 1 role routing-engine
{master:0}[edit virtual-chassis]
lab@qfx1# set member 1 serial-number serial-qfx2
Step 3.6
View your configuration so far and if you are satisfied commit your configuration and exit to
operational mode.
{master:0}[edit virtual-chassis]
lab@qfx1# show
auto-provisioned;
member 0 {
role routing-engine;
serial-number VF3714170305;
}
member 1 {
role routing-engine;
serial-number VF3714170306;
}
{master:0}[edit virtual-chassis]
lab@qfx1# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@qfx1>
Step 3.7
View the status of the VCF by issuing the show virtual-chassis status command.
{master:0}
lab@qfx1> show virtual-chassis status
Question: Are all members of the VCF listed in the output of the
command? Why?
Step 3.8
View the status of the VCPs by issuing the show virtual-chassis vc-port command.
lab@qfx1> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
{master:0}
lab@qfx1>
Step 3.10
Enable vcp-255/0/50 and vcp-255/0/51 on qfx1 by issuing the request
virtual-chassis vc-port set pic-slot 0 port port-number command for
each VCP.
{master:0}
lab@qfx1> request virtual-chassis vc-port set pic-slot 0 port 50
Port conversion initiated, use show virtual-chassis vc-port to verify
{master:0}
lab@qfx1> request virtual-chassis vc-port set pic-slot 0 port 51
Port conversion initiated, use show virtual-chassis vc-port to verify
Step 3.11
View the status of the VCPs by issuing the show virtual-chassis vc-port command.
{master:0}
lab@qfx1> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
Interface Type Trunk Status Speed Neighbor
or ID (mbps) ID Interface
PIC / Port
0/50 Configured -1 Down 40000
0/51 Configured -1 Down 40000
In this lab part you will add the remaining member switches to the VCF. To add a member to an
existing auto-provisioned VCF, you simply enable the appropriate VCP interfaces. Use the lab
diagram titled “Network Diagram: Virtual Chassis Fabric Lab” for this part of the lab.
Step 4.1
Return to the console session opened for ex1.
On ex1, enable vcp-255/1/3 by issuing the request virtual-chassis vc-port set
pic-slot 1 port 3 command.
{master:0}
lab@ex1> request virtual-chassis vc-port set pic-slot 1 port 3
Port conversion initiated, use show virtual-chassis vc-port to verify
{master:0}
lab@ex1>
Step 4.2
Enable vcp-255/1/2 on ex1 by issuing the request virtual-chassis vc-port set
pic-slot 1 port 2 command.
{master:0}
lab@ex1> request virtual-chassis vc-port set pic-slot 1 port 2
Port conversion initiated, use show virtual-chassis vc-port to verify
Step 4.3
Set the Virtual Chassis mode on ex1 to a mixed VCF by issuing the request
virtual-chassis mode fabric mixed reboot command. ex1 will reboot after this
command is issued. Wait until ex1 has finished rebooting before continuing to the next step.
{master:0}
lab@ex1> request virtual-chassis mode fabric mixed reboot
fpc0:
--------------------------------------------------------------------------
Mode set to 'Fabric with mixed devices'. Rebooting system...
{master:0}
lab@ex1>
*** System shutdown message from root@ex1 ***
login: lab
Logging to master
Password:
Answer: Once you have logged in you should notice that your
session has been redirected to qfx1. This means that ex1 has
become a member of the VCF.
Step 4.5
View the status of the VCF by issuing the show virtual-chassis status command.
{master:0}
lab@qfx1> show virtual-chassis status
Question: What member ID and role does ex1 have in the VCF?
Step 4.6
View the configuration of the VCF using the show configuration command.
{master:0}
lab@qfx1> show configuration
## Last commit: 2014-09-26 20:50:12 UTC by lab
version 13.2X51-D21.1;
system {
host-name qfx1;
root-authentication {
encrypted-password "$1$KI99zGk6$MbYFuBbpLffu9tn2.sI7l1"; ## SECRET-DATA
Step 4.7
Return to the console session opened for qfx2.
On qfx2, set the Virtual Chassis mode to a mixed VCF by issuing the request
virtual-chassis mode fabric mixed reboot command. qfx2 will reboot after this
command is issued. Wait until qfx2 has finished rebooting before continuing to the next step.
{master:0}
lab@qfx2>
*** System shutdown message from root@qfx2 ***
login: lab
Password:
Step 4.9
First, enable vcp-255/0/50 on qfx2 by issuing the request virtual-chassis vc-port
set pic-slot 0 port 50 command.
{master:0}
lab@qfx2> request virtual-chassis vc-port set pic-slot 0 port 50
Port conversion initiated, use show virtual-chassis vc-port to verify
Step 4.10
Enable vcp-255/0/51 on qfx2 by issuing the request virtual-chassis vc-port set
pic-slot 0 port 51 command. After issuing the command you will be logged out of qfx2.
Wait 60 seconds before moving to the next step.
{master:0}
lab@qfx2> request virtual-chassis vc-port set pic-slot 0 port 51
Port conversion initiated, use show virtual-chassis vc-port to verify
login:
Step 4.11
Login to qfx2 using the lab and lab123 login credentials.
qfx2 (ttyd0)
login: lab
Logging to master
Password:
Answer: Once you have logged in you should notice that your
session has been redirected to qfx1. This means that qfx2 has
become a member of the VCF.
Step 4.12
View the status of the VCF by issuing the show virtual-chassis status command.
{master:0}
lab@qfx1> show virtual-chassis status
{master:0}
lab@ex2> request virtual-chassis vc-port set pic-slot 1 port 3
Port conversion initiated, use show virtual-chassis vc-port to verify
Step 4.14
Set the Virtual Chassis mode on ex2 to a mixed VCF by issuing the request
virtual-chassis mode fabric mixed reboot command. ex2 will reboot after this
command is issued. Wait until ex2 has finished rebooting before continuing to the next step.
{master:0}
lab@ex2> request virtual-chassis mode fabric mixed reboot
fpc0:
--------------------------------------------------------------------------
Mode set to 'Fabric with mixed devices'. Rebooting system...
{master:0}
lab@ex2>
*** System shutdown message from root@ex2 ***
login: lab
Logging to master
Password:
Answer: Once you have logged in you should notice that your
session has been redirected to qfx1. This means that ex2 has
become a member of the VCF.
In this lab part you will configure a few of the interfaces for Ethernet switching. You will use the
member number to help determine the interfaces names. Use the lab diagram titled “Network
Diagram: Virtual Chassis Fabric Lab” for this part of the lab.
Step 5.2
Enter configuration mode and navigate to the [edit vlans] hierarchy. Configure a VLAN
called vlan_301 using a VLAN ID of 301.
{master:0}
lab@qfx1> configure
Entering configuration mode
{master:0}[edit]
lab@qfx1# edit vlans
{master:0}[edit vlans]
lab@qfx1# set vlan_301 vlan-id 301
Step 5.3
Navigate to the [edit interfaces] hierarchy and configure each of the virtual router-facing
interfaces to perform Ethernet switching as trunk interfaces for VLAN 301 only. Commit your
configuration and exit to operational mode.
{master:0}[edit vlans]
lab@qfx1# top edit interfaces
{master:0}[edit interfaces]
lab@qfx1# set ge-3/0/15 unit 0 family ethernet-switching interface-mode trunk
{master:0}[edit interfaces]
lab@qfx1# set ge-3/0/15 unit 0 family ethernet-switching vlan members vlan_301
{master:0}[edit interfaces]
lab@qfx1# set ge-2/0/6 unit 0 family ethernet-switching interface-mode trunk
{master:0}[edit interfaces]
lab@qfx1# set ge-2/0/6 unit 0 family ethernet-switching vlan members vlan_301
{master:0}[edit interfaces]
lab@qfx1# commit and-quit
configuration check succeeds
fpc1:
commit complete
fpc2:
commit complete
fpc3:
Step 5.5
Verify proper operation by sending ICMP traffic from vr1 to vr2 using the ping 172.16.1.2
routing-instance vr1 count 5 command.
{master:0}
lab@qfx1> ping 172.16.1.2 routing-instance vr1 count 5
PING 172.16.1.2 (172.16.1.2): 56 data bytes
64 bytes from 172.16.1.2: icmp_seq=0 ttl=64 time=61.719 ms
64 bytes from 172.16.1.2: icmp_seq=1 ttl=64 time=41.115 ms
64 bytes from 172.16.1.2: icmp_seq=2 ttl=64 time=33.014 ms
64 bytes from 172.16.1.2: icmp_seq=3 ttl=64 time=29.075 ms
64 bytes from 172.16.1.2: icmp_seq=4 ttl=64 time=33.030 ms
Step 5.6
View the MAC table of the VCF by issuing the show ethernet-switching table command
to see if MAC addresses are being learned by the VCF.
{master:0}
lab@qfx1> show ethernet-switching table
In this lab part, you perform basic management operations for your VCF using Junos Space.
Specifically, you will perform the discovery task and add your VCF in the Network Director
application. You then navigate the user interface and explore some of the management
functions. Use the lab diagram titled “Network Diagram: Virtual Chassis Fabric Lab” for this part
of the lab.
Step 6.1
Take a look at the diagram and notice the location of the Junos Space server.
Step 6.2
Enter configuration mode and issue show system services and answer the following
questions.
{master:0}
lab@qfx1> configure
Entering configuration mode
{master:0}[edit]
lab@qfx1# show system services
ftp;
ssh {
max-sessions-per-connection 32;
}
telnet;
Step 6.3
Enable the NETCONF service with SSH.
{master:0}[edit]
lab@qfx1# set system services netconf ssh
Step 6.4
Enable SNMP version 2 with a defined community of public in order for the SNMP probe and
topology discovery operation performed through SNMP to work properly.
{master:0}[edit]
lab@qfx1# set snmp community public
Step 6.5
Navigate to the [edit interfaces] hierarchy and configure the ge-0/0/0 interface with the
addressing shown in the lab diagram. Once enabled, activate the configuration changes using
the commit command.
{master:0}[edit]
lab@qfx1# edit interfaces
{master:0}[edit interfaces]
lab@qfx1# set ge-0/0/0 unit 0 family inet address 172.25.10.21/24
{master:0}[edit interfaces]
lab@qfx1# commit
configuration check succeeds
fpc1:
commit complete
fpc2:
commit complete
fpc3:
commit complete
commit complete
{master:0}[edit interfaces]
lab@qfx1#
Step 6.6
Verify the ability to communicate between the VCF and the Space server by issuing the command
run ping 172.25.10.136 count 5 command.
{master:0}[edit interfaces]
lab@qfx1# run ping 172.25.10.136 count 5
PING 172.25.10.136 (172.25.10.136): 56 data bytes
64 bytes from 172.25.10.136: icmp_seq=0 ttl=64 time=41.107 ms
Lab 5–36 • Virtual Chassis Fabric www.juniper.net
Data Center Switching
64 bytes from 172.25.10.136: icmp_seq=1 ttl=64 time=22.033 ms
64 bytes from 172.25.10.136: icmp_seq=2 ttl=64 time=22.042 ms
64 bytes from 172.25.10.136: icmp_seq=3 ttl=64 time=22.158 ms
64 bytes from 172.25.10.136: icmp_seq=4 ttl=64 time=22.162 ms
Step 6.7
From your landing pad VM, open the FireFox browser located under the Applications >
Internet menu.
Step 6.8
Open the Junos Space login page by entering 172.25.10.136 in the address bar. When
prompted, enter super and lab123 as the username and password and click the Log In
button to login to the Junos Space GUI.
Note
Add and accept any security exceptions that may pop up
when accessing the Junos Space Management Platform!
Answer: Yes, as shown in the sample output you should now see
the Network Director application interface. If not, check your
work and, if needed, consult with your instructor.
Step 6.10
Once the Network Director application opens. From the Views drop-down menu, select
Logical View and examine the resulting web page.
Note
Alternatively, you could navigate to the Network Director application interface
directly using https://address/networkdirector/ in your browser.
Step 6.11
Under the Tasks pane, click on the Discover Devices option. Next, in the main window,
click the Add button to add a new device target.
Step 6.12
In the Add Device Target dialogue box, use the IP option and enter the IP address
assigned to your VCF’s ge-0/0/0 interface (172.25.10.21). Next, click Add to continue.
Step 6.13
Back in the main pane, ensure the newly added device target entry associated with your VCF is
selected and click Next to continue.
Step 6.14
For the Discovery Options step, ensure the Use Ping and Use SNMP options are
selected. Next, click Add to add the credentials associated with your VCF.
Step 6.15
In the Add Device Credentials dialogue box, enter lab and lab123 as the username
and password and click Add to continue.
Step 6.16
Back in the main pane, ensure the newly added device credentials entry associated with your
VCF is selected and click Next to continue.
Step 6.17
For the Schedule Options step, ensure the Run Now option is selected and click Next to
continue.
Step 6.18
For the Review step, review the discovery details associated with the target device and, once
you are comfortable with the specified variables, click Finish. Note that, if needed, you can
click Edit to change a defined value.
Step 6.19
When prompted with the Job Status message, click OK to close the message box. Next, view the
job details shown on the resulting screen for the job that just finished.
Step 6.20
In the Logical View pane on the left-hand side of the web page, expand the newly added
Fabric folder and VCF to inspect which elements have been discovered.
Step 6.21
Select the qfx1 folder > View VC/VCF Connectivity and mouse over each of the members in the
diagram.
Answer: Both Spine devices have a star. The master RE will have
a yellow star and the backup RE will have a gray star. In the
diagram, member 0 is the master RE.
Step 6.22
Explore the Network Director user interface on your own and discover some of its management
and monitoring capabilities. Some sample objectives include:
• Locate the serial numbers of the system components.
• Display the current configuration on the VCF.
• Determine the status of all logical interfaces.
• Verify reachability to a known host (e.g. 10.210.14.130).
Note
In some cases there may be multiple
ways to accomplish the same task!
Note
Configuration management is outside the scope
of this class. To learn more about Junos Space
and Network Director, please consider attending
the courses dedicated to those topics.
In this lab part, you will remove each of the members from the VCF and return them to a
standalone, Virtual Chassis state (the default state). Use the lab diagram titled “Network
Diagram: Virtual Chassis Fabric Lab” for this part of the lab.
Step 7.1
Return to the console session opened for ex2.
If necessary on ex2, enter configuration mode. Delete the netconf service as well as the snmp
configuration. Commit you configuration and exit to operational mode.
{master:0}[edit]
lab@qfx1# delete system services netconf
{master:0}[edit]
lab@qfx1# delete snmp
{master:0}
lab@qfx1>
Step 7.2
Delete each of the VCPs of ex2 by issuing the request virtual-chassis vc-port
delete pic-slot 1 port port-number member 3 command for each VCP. You will be
logged out of the VCF.
{master:0}
lab@qfx1> request virtual-chassis vc-port delete pic-slot 1 port port-number
member 3
fpc2:
--------------------------------------------------------------------------
vc-port successfully deleted
{master:0}
lab@qfx1> request virtual-chassis vc-port delete pic-slot 1 port port-number
member 3
qfx1 (ttyu0)
login:
Step 7.3
Attempt to log back into ex2 using the lab and lab123 login credentials. ex2 will attempt to log
you into master RE of the VCF. After 10 attempts, it will allow you to log directly into the ex2
switch.
qfx1 (ttyu0)
login: lab
Logging to master
..........
Connection to master failed, enabling local login
Password:
{linecard:3}[edit]
lab@qfx1# load override dcx/lab5-start.config
load complete
{linecard:3}[edit]
lab@qfx1# commit and-quit
commit complete
Exiting configuration mode
{linecard:3}
lab@ex2>
Step 7.5
Change the mode of ex2 so that it operates in non-mixed Virtual Chassis mode by disabling
mixed and fabric mode. Also, make sure that it reboots immediately. Wait for ex2 to reboot
before continuing.
{linecard:3}
lab@ex2> request virtual-chassis mode mixed fabric disable reboot
fpc3:
--------------------------------------------------------------------------
Mode set to 'Virtual Chassis with similar devices'. Rebooting system...
{linecard:3}
lab@ex2>
*** System shutdown message from root@ex2 ***
login: lab
Logging to master
..........
Step 7.7
Reactivate member 3 by issuing the request virtual-chassis reactivate command.
You will be logged out of ex2.
{linecard:3}
lab@ex2> request virtual-chassis reactivate
This member split from a virtual chassis. Please make sure that no active
switch belonging to this virtual chassis has conflicting configuration.
{linecard:3}
lab@ex2>
login:
Step 7.8
Log back into ex2 using the lab and lab123 login credentials. View the status of the Virtual
Chassis by issuing the show virtual-chassis status command.
ex2 (ttyu0)
login: lab
Password:
Step 7.9
Although not required, the final step in converting ex2 back to standalone mode is to renumber
its member ID to 0. Perform this step by issuing the request virtual-chassis
renumber member-id 3 new-member-id 0 command. You will be automatically logged
out of ex2.
{master:3}
lab@ex2> request virtual-chassis renumber member-id 3 new-member-id 0
{master:3}
lab@ex2>
login:
Step 7.10
Log back into ex2 using the lab and lab123 login credentials. View the status of the Virtual
Chassis by issuing the show virtual-chassis status command. Log out of ex2 when
complete.
ex2 (ttyu0)
login: lab
Password:
{master:0}
lab@ex2> exit
ex2 (ttyu0)
login:
Answer: Yes, ex2 has been successfully removed from the VCF.
Step 7.11
Return to the console session opened for qfx2.
On qfx2, attempt to log back in using the lab and lab123 login credentials. Delete vcp-255/0/
50 of qfx2 by issuing the request virtual-chassis vc-port delete pic-slot 0
port 50 member 1 command.
{master:0}
lab@qfx1> request virtual-chassis vc-port delete pic-slot 0 port 50 member 1
fpc1:
--------------------------------------------------------------------------
vc-port successfully deleted
qfx1 (ttyu0)
login:
Step 7.13
Attempt to log back into qfx2 using the lab and lab123 login credentials. Since qfx2 was the
backup RE and detected a VCF split it becomes the master RE for its local VCF.
qfx1 (ttyd0)
login: lab
Password:
{master:1}[edit]
lab@qfx1# load override dcx/lab5-start.config
load complete
{master:1}[edit]
lab@qfx1# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:1}
lab@qfx2>
login: lab
Password:
Step 7.17
Since member 0 (qfx1) is being removed from the topology, use the request
virtual-chassis recycle member-id 0 command to allow for another switch to be
assigned member ID 0.
{master:1}
lab@qfx2> request virtual-chassis recycle member-id 0
{master:3}
lab@qfx2>
qfx2 (ttyd0)
login:
Step 7.19
Log back into qfx2 using the lab and lab123 login credentials. View the status of the Virtual
Chassis by issuing the show virtual-chassis status command. Log out of qfx2 when
complete.
qfx2 (ttyd0)
login: lab
Password:
{master:0}
lab@qfx2> exit
qfx2 (ttyu0)
login:
Answer: Yes, qfx2 has been successfully removed from the VCF.
Step 7.20
Return to the console session opened for ex1.
On ex1, attempt to log back in using the lab and lab123 login credentials. Delete vcp-255/1/
3 of ex1 by issuing the request virtual-chassis vc-port delete pic-slot 1
port 3 member 2 command.
qfx1 (ttyu0)
login: lab
Password:
{linecard:2}
lab@qfx1>
Step 7.21
Delete vcp-255/1/2 of ex1 by issuing the request virtual-chassis vc-port delete
pic-slot 1 port 2 member 1 command. You will be logged out of the Virtual Chassis.
{linecard:1}
lab@qfx1> request virtual-chassis vc-port delete pic-slot 1 port 2 member 2
qfx1 (ttyu0)
login:
Step 7.22
Attempt to log back into ex1 using the lab and lab123 login credentials. Enter configuration
mode and load the lab5-start.config configuration file from the /var/home/lab/
dcx/ directory. Commit your changes and return to operational mode.
qfx1 (ttyu0)
login: lab
www.juniper.net Virtual Chassis Fabric • Lab 5–59
Data Center Switching
Password:
{linecard:2}[edit]
lab@qfx1# load override dcx/lab5-start.config
load complete
{linecard:2}[edit]
lab@qfx1# commit and-quit
commit complete
Exiting configuration mode
{linecard:2}
lab@ex1>
Step 7.23
Change the mode of ex1 so that it operates in non-mixed Virtual Chassis mode by disabling
mixed and fabric mode. Also, make sure that it reboots immediately. Wait for ex1 to reboot
before continuing.
{linecard:2}
lab@ex1> request virtual-chassis mode mixed fabric disable reboot
fpc2:
--------------------------------------------------------------------------
Mode set to 'Virtual Chassis with similar devices'. Rebooting system...
{linecard:2}
lab@ex1>
Step 7.24
Log back into ex1 using the lab and lab123 login credentials. View the status of the Virtual
Chassis by issuing the show virtual-chassis status command.
ex1 (ttyu0)
login: lab
Password:
Step 7.25
Reactivate member 2 by issuing the request virtual-chassis reactivate command.
You will be logged out of ex1.
{linecard:2}
lab@ex1> request virtual-chassis reactivate
This member split from a virtual chassis. Please make sure that no active
switch belonging to this virtual chassis has conflicting configuration.
{linecard:2}
lab@ex1>
ex1 (ttyu0)
login:
Step 7.26
Log back into ex1 using the lab and lab123 login credentials. View the status of the Virtual
Chassis by issuing the show virtual-chassis status command.
ex1 (ttyu0)
login: lab
Step 7.27
Although not required, the final step in converting ex1 back to standalone mode is to renumber
its member ID to 0. Perform this step by issuing the request virtual-chassis
renumber member-id 2 new-member-id 0 command. You will be automatically logged
out of ex1.
{master:2}
lab@ex1> request virtual-chassis renumber member-id 2 new-member-id 0
{master:2}
lab@ex1>
ex1 (ttyu0)
login:
Step 7.28
Log back into ex1 using the lab and lab123 login credentials. View the status of the Virtual
Chassis by issuing the show virtual-chassis status command. Log out of ex1 when
complete.
ex1 (ttyu0)
login: lab
Password:
{master:0}
lab@ex1> exit
ex1 (ttyu0)
login:
Answer: Yes, ex1 has been successfully removed from the VCF.
Step 7.29
Return to the console session opened for qfx1.
On qfx1, attempt to log back in using the lab and lab123 login credentials. Delete vcp-255/0/
50 of qfx1 by issuing the request virtual-chassis vc-port delete pic-slot 0
port 50 command.
qfx1 (ttyd0)
login: lab
Password:
{linecard:0}
lab@qfx1>
Step 7.31
Enter configuration mode and load the lab5-start.config configuration file from the /
var/home/lab/dcx/ directory. Commit your changes and return to operational mode.
{linecard:0}
lab@qfx1> configure
Entering configuration mode
{linecard:0}[edit]
lab@qfx1# load override dcx/lab5-start.config
load complete
{linecard:0}[edit]
lab@qfx1# commit and-quit
{linecard:0}
lab@qfx1>
Step 7.32
Change the mode of qfx1 so that it operates in non-mixed Virtual Chassis mode by disabling
mixed and fabric mode. Also, make sure that it reboots immediately. Wait for qfx1 to reboot
before continuing.
{linecard:0}
lab@qfx1> request virtual-chassis mode mixed fabric disable reboot
fpc0:
--------------------------------------------------------------------------
Mode set to 'Virtual Chassis with similar devices'. Rebooting system...
{linecard:0}
login: lab
Logging to master
..........
Connection to master failed, enabling local login
Password:
{linecard:0}
lab@qfx1>
Step 7.34
Reactivate member 0 by issuing the request virtual-chassis reactivate command.
You will be logged out of qfx1.
lab@qfx1> request virtual-chassis reactivate
This member split from a virtual chassis. Please make sure that no active
switch belonging to this virtual chassis has conflicting configuration.
{linecard:0}
lab@qfx1>
qfx1 (ttyd0)
login:
Step 7.35
Log back into qfx1 using the lab and lab123 login credentials. View the status of the Virtual
Chassis by issuing the show virtual-chassis status command. Log out of qfx1 when
complete.
qfx1 (ttyd0)
login: lab
Password:
{master:0}
lab@qfx1> exit
qfx1 (ttyu0)
login:
Answer: Yes, qfx1 has been successfully removed from the VCF.
STOP Tell your instructor that you have completed this lab.