Juniper Cloud Labs User Guide

Juniper Cloud Labs Version 3.0

Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. and/or its affiliates in the United States and other
countries. All other trademarks may be property of their respective owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this
publication without notice.
The information in this document is current as of the date on the title page.

END USER LICENSE AGREEMENT

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

YEAR 2000 NOTICE

Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the year 2038. However, the NTP
application is known to have some difficulty in the year 2036.

Juniper Networks, Inc.

1133 Innovation Way
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net

Juniper Cloud Labs User Guide

Copyright © 2018 Juniper Networks, Inc. All rights reserved.
Table of Contents
Table of Contents

About This Guide

Chapter 1: Juniper Cloud Labs Overview

Juniper Cloud Labs (JCL) Introduction
JCL Terminology
Prerequisites
JCL Prerequisites
Build Your Own Topology Prerequisites
Juniper Cloud Labs Resources
What’s New in Juniper Cloud Labs 3.0?

Chapter 2: Accessing Topologies

Logging into JCL
Creating a Sandbox from an Existing Blueprint

Chapter 3: Working in the Sandbox

Accessing and Managing Resources in a Sandbox
Accessing a Resource in a Sandbox
Connecting Resources in a Blueprint or Sandbox
Adding IP Address Prefixes to Share User Access in a Sandbox
Creating VM Console Access to a Resource
Managing the Sandbox Reservation
Renaming a Sandbox
Extending a Sandbox Reservation
Ending a Sandbox Reservation
Monitoring Resources in the Sandbox
Monitoring the Activity Feed and Output
Power Cycling and Restarting Resources
Monitoring Resource Health
Changing Presentation Settings in a Sandbox
Moving a Resource in the Sandbox
Changing Icon Sizes
Changing the Zoom Level
Rearranging the Resource Presentation
Changing the View Mode
Navigating the Canvas in a Sandbox
 Using the Instructions Help

Chapter 4: Building Your Own Juniper Cloud Labs Topology

Getting Build Your Own Topology Access
Building Your Own Topology
Modifying Resource Attributes
Understanding Blueprint Dropdown Menu Options
Updating Blueprint Properties

Chapter 5: Automating Processes with the HelperVM and the JCL Git Server
Adding the HelperVM to a Blueprint
Creating and Accessing an Account on the JCL Git Server
Saving a Snapshot to the JCL Git Server
Updating a Snapshot Configuration
Making a Snapshot Shareable
Loading a Snapshot from the JCL Git Server
Opening an Inventory File

Chapter 6: Setting up and Generating Traffic with Spirent Resources

Getting Juniper Cloud Labs Technical Support

Gathering Information for Technical Support
Running Troubleshooting Tests
Contacting Technical Support
About This Guide
The purpose of this guide is to provide Juniper Cloud Labs (JCL) users with the concepts and instructions
needed to perform common tasks within JCL 3.0. The intended audience for this guide includes any
Juniper employee or partner that is currently using or considering using JCL 3.0 to build a network
topology.
JCL provides users with a platform to use a variety of resources in a topology. Prior knowledge on the
usage of the resources in your topology is helpful and often necessary for effective usage in any network
topology. The documentation for most individual resources is available outside of the JCL context and
In-depth documentation about the usage of every resource option within JCL is beyond the scope of this
guide.
JCL 3.0 is an evolution of JCL 2.0 and some tasks are similar between the versions. This guide is written
to directly support JCL 3.0 users exclusively, although it can be used as an indirect resource in some JCL
2.0 contexts.

Chapter 1: Juniper Cloud Labs Overview

This section covers the following topics:

❏ Juniper Cloud Labs (JCL) Introduction

❏ JCL Terminology
❏ Prerequisites
❏ Juniper Cloud Labs Resources
❏ What’s New in Juniper Cloud Labs 3.0?

Juniper Cloud Labs (JCL) Introduction

Juniper Cloud Labs (JCL) is a cloud-based, self-service portal that provides Juniper employees and
partners with web-based, reservable access to a shared pool of dynamically configured Juniper products,
solutions, servers, and testing resources. The JCL graphical user interface is available over the web and
allows users to create active network topologies without the laborious and time-intensive processes
required to set up a new network.

A JCL topology is created by assembling resources into a blueprint using the JCL graphical user
interface. A resource in JCL is broadly defined and can be many things, including a router, a switch, a
virtual machine, a traffic generator, a port, or any other number of assets. A blueprint topology can include
specific concrete resources—for instance, the vMX virtual router named VM1—and generic abstract
resources—for instance, any available vMX virtual router. Resources are interconnected in a blueprint
using connections.

A blueprint becomes an active topology—called a sandbox—upon reservation. A sandbox is a topology

with active resources that can be individually accessed and configured, and resources in a sandbox can
pass traffic over connections. The JCL automated setup process—which takes a variable amount of time
between topologies but is often completed in 30 minutes or less—runs when a blueprint is reserved and
handles many of the initial device configuration processes for each resource in the sandbox. JCL makes
topologies that used to take days to configure available in minutes.

The JCL ecosystem includes a pool of concrete and abstract resources that can be added to any
blueprint. The ecosystem includes a HelperVM resource, for instance, that assists with automating tasks
between sandboxes. The HelperVM resource can, among other things, communicate with the JCL Git
server and run Ansible playbooks that save and load snapshot configurations between sandboxes. JCL
topologies can be accessed from anywhere and augmented with learning aids, making JCL an ideal
choice for showcasing Juniper equipment in customer demonstrations or highlighting Juniper technology
for technical audiences.

If you have a need to access or demonstrate Juniper equipment, try JCL!

JCL Terminology
This section provides a summary of commonly-used JCL terms.

● Abstract Resource​—a generic representation of a ​resource​. For example, any vMX virtual router.
Abstract resources​ are included in ​blueprints​ and give the JCL automated setup process the
flexibility to choose any available ​concrete resource​ when creating a ​sandbox​. For instance, a
blueprint​ that includes a vMX virtual router is reserved and the JCL automated setup process
uses the virtual router named vMX-0123 to represent the ​resource​ in the ​sandbox​. The vMX
virtual router is the ​abstract resource​ and vMX-0123 is the ​concrete resource​.
● Automated Setup Procedure— ​ a procedure that runs when a ​blueprint​ is reserved to instantiate
the ​blueprint​ into a ​sandbox.​ The ​automated setup procedure​ creates VMs of virtual resources,
powers on virtual resources, configures management interfaces, connects interfaces, and creates
inventory files for the ​sandbox​ that can be accessed using the HelperVM, among other things.
● Blueprint​—a JCL topology template where networks in JCL are created. ​Blueprints​ are used to
collect ​resources​ into a topology. ​Blueprints​ becomes active topologies with active resources
when they are reserved and instantiated into ​sandboxes.​
● Build Your Own topology​—The ​Build Your Own topology​ feature allows users to create topologies
by dragging and dropping resources onto a ​blueprint​ using the JCL graphical user interface. ​Build
Your Own topologies​ are built in the ​Build-Your-Own domain.​ ​Blueprints​ designed using the ​Build
Your Own topology​ feature become active topologies upon reservation. These active topologies
are called ​sandboxes​.
● Concrete Resource​—a specific representation of a ​resource.​ For example, a vMX virtual router
named vMX-0123.
Concrete resources​ can be added to b ​ lueprints​ or used in ​sandboxes​ to instantiate ​abstract
resources​. For instance, a ​blueprint​ that includes a vMX virtual router ​abstract resource​ is
reserved and the JCL automated setup process uses the virtual router named vMX-0123 to
represent that ​abstract resource​ in the ​sandbox.​ The vMX virtual router is the ​abstract resource
and vMX-0123 is the ​concrete resource​.
Concrete resources​ should only be added to ​blueprints​ when there is a specific need for the
concrete resource. Use ​abstract resources​ to ensure resource availability whenever possible.
 ● Connection​—any link that connects devices. A connection can be a physical link between
physical devices or a virtual link between virtual machines.
● Demonstrations​—a domain in JCL. The demonstrations ​domain​ contains ​blueprints​ that are
typically purpose-built and enhanced with learning aids to walk users through a specific network
design or a set of tasks.
● Domain— ​ an area within JCL. ​Domains​ logically group ​resources​ and b ​ lueprints​. ​Domains​ are
selected in the top right corner of the JCL graphical user interface and currently include
Build-Your-Own,​ ​Demonstrations,​ and ​vLabs.​ A JCL user has different permissions to edit or
create blueprints depending on their permissions in a domain.
● Guided demonstration​—A guided demonstration is a fully-configured topology that is enhanced
with learning aids, such as demonstration scripts, presentations, videos, or other information
assets.
● JCL Git Server​—a Git Server that is only accessible to JCL users. The ​JCL Git Server​ interacts
with the ​HelperVM​ resource and is primarily used to store and load snapshot configurations onto
sandboxes​.
● HelperVM— ​ a virtual machine resource that helps automate various JCL tasks, including
configuration sharing, between ​blueprints​. The ​HelperVM​ resource has the ability to run Ansible
scripts and communicate with the JCL Git server. One ​HelperVM​ resource can be added to any
blueprint​ and can run in a ​sandbox​.
● Inventory file​—a file generated by the HelperVM resource during the automated setup procedure.
Inventory files store sandbox-specific information onto the HelperVM. Inventory files are useful for
gathering information about a sandbox.
● Resource​—anything that can be included in a ​blueprint​ and reserved within JCL. A ​resource​ can
be a device such as a router or a switch, a virtual machine, a revenue port, a traffic generator, or
any other reservable asset. A ​blueprint c​ an include generic ​abstract resources​ and specific
concrete resources,​ although we recommend using ​abstract resources​ in ​blueprints​ as much as
possible to ensure resource availability.
● Sandbox— ​ an active topology that is an instantiation of a ​blueprint​. A ​sandbox​ is an active
topology with active resources that is created by the JCL ​automated setup procedure​ when a
blueprint​ is reserved. All ​resources​ in a topology are accessible and configurable and traffic can
be passed over ​connections​ in a s​ andbox.​
● Snapshot— ​ a directory stored on the ​JCL Git Server​ that stores the configuration of ​resources​ in a
sandbox​. ​Sandboxes​ that include a ​HelperVM​ resource can load ​snapshots​ during the ​automated
setup procedure​. A ​snapshot​ currently saves all Junos, Spirent, and Ixia configurations from a
sandbox​.
● vLabs— ​ a domain in JCL that provides Juniper customers with a platform to test drive use cases
and features at any time and at no risk to their production networks. The vLabs domain provides
pre-configured routing, switching, and security topologies and is intended for use by external
Juniper customers.

Prerequisites
This section covers the following topics:

❏ JCL Prerequisites
❏ Build Your Own Topology Prerequisites
JCL Prerequisites
JCL is engineered to operate on any computer’s web browser over the Internet without the user having to
install any additional software, including browser plug-ins or software programs.
Some JCL prerequisites:
❏ Login requirements: JCL is available to all Juniper employees and partners that have a
juniper.net user account.
See ​Create New User Login Account with Juniper Networks​ for information on creating a
juniper.net account.
❏ Browser requirements: JCL should work on any web browser and was tested using Mozilla
Firefox and Google Chrome web browsers. Always use the most recent version of the web
browser when accessing JCL.
❏ SSH, VNC, and RDP clients: SSH, VNC, and RDP clients can be used to access JCL resources.

Build Your Own Topology Prerequisites

A standard JCL user can view and reserve sandboxes from blueprints, but does not have permission to
build or edit topologies in the Build Your Own domain.
An advanced JCL user has all standard JCL user permissions and can also create and edit blueprints in
the Build Your Own domain..
The following prerequisites must be met in order for a user to achieve advanced user status:
❏ Juniper employees:
❏ Complete the ​Juniper Cloud Labs: Build-Your-Own Training​ at Juniper University:
❏ Pass the ​Juniper Cloud Labs: Build Your Own​ quiz.
❏ Juniper partners:
❏ Your partner status must be ​Ingenious Champion.​
❏ Complete the ​Juniper Cloud Labs: Build-Your-Own Training​ at Juniper University:
❏ Pass the ​Juniper Cloud Labs: Build Your Own​ quiz.
❏ After the above steps are successfully completed, send an email to
[email protected]​. Request JCL Build Your Own topology access.

Juniper Cloud Labs Resources

A JCL resource is any asset that can be added to a blueprint and reserved in JCL. A ​resource​ is defined
broadly and can be a device such as a router or a switch, a virtual machine, a revenue port, or a traffic
generator, to cite a few examples. A blueprint includes generic abstract resources—for instance, any vMX
virtual router—and specific concrete resources—for instance, a vMX virtual router named vMX-0123. We
strongly recommend adding abstract resources to blueprints whenever possible to ensure resource
availability.
JCL has a pool of available shared resources. You can view the available abstract resources using the
following path:
Inventory:​ ​Abstract Templates​: View List or Filter using the search box
Figure:​ Listing Abstract Resources

A list of available JCL resources for Build Your Own topologies is also available at ​Details about
resources in JCL Build-Your-Own (BYO)​.

What’s New in Juniper Cloud Labs 3.0?

JCL 3.0 introduces the following new functionality:
❏ The ability to Build Your Own blueprints using a broad array of virtual resources, including vMX,
vSRX, NorthStar, Junos Space Security Director, Network Director, JSA; Spirent and IXIA tester
​ buntu VM, CentOS VM, MetasploitableVM,
applications; and various VM’s - Kali, Helper​, U
LinuxJump, WindowsJump, Junos Space Service Now.
❏ improved user experience that allows users to access resources in a sandbox from anywhere on
the internet.
❏ simplified, web-based single-sign-on (SSO) access and authentication - which eliminates the
cumbersome VPN access process.
Chapter 2: Accessing Topologies
This section covers the following topics:
❏ Logging into JCL
❏ Creating a Sandbox from an Existing Blueprint

Logging into JCL

Ensure all prerequisites are met before logging into JCL. See ​Prerequisites​.
Go to the ​Juniper Cloud Labs​ website to log into JCL 3.0.
The website can be accessed from the following URL:
https://cloudlabs.juniper.net
Enter your Juniper credentials, then click the ​Launch Portal​ button.

Figure:​ Launching Juniper Cloud Labs

Creating a Sandbox from an Existing Blueprint

A blueprint is a collection of resources compiled into a topology using the JCL graphical user interface.
A blueprint becomes an active network—called a sandbox—upon reservation. A sandbox is a topology
with active resources that can be individually accessed and configured. Resources in a sandbox can pass
traffic over connections.
A blueprint can be set to private for personal use or set to public for the use of all JCL users. For
instructions on building a blueprint, see ​Building Your Own Topology​.
To create a sandbox from an existing blueprint:
1. Go to the ​Juniper Cloud Labs​ website and login. See ​Logging into JCL​.
 2. Select a domain by clicking the domains drop-down menu in the top right corner of the user
interface and selecting one of the available domains.
The figure provides an example of a user selecting the build-your-own domain.

Figure:​ Domain Selection (Selecting Build-Your-Own Example)

3. Click the ​Blueprints​ tab or icon in the left-hand navigation window. All published blueprints for the
domain appear in the navigation window.
4. Locate the blueprint that you want to access using one of the following methods:
a. Navigate all of the blueprints available on the current page.
b. Use the search bar in the top left-corner to search for a blueprint.
c. Filter the available blueprint options using the ​Filter By​ options in the left-hand navigation
menu.
d. Clicking blueprints to see which resources are included in a topology.

5. Click the ​Reserve​ button to begin the reservation procedure.

 Figure:​ Locating Blueprints

6. The ​Reserve dialog​ appears.

Most values can be left as their default values unless the sandbox has unique requirements. If
you want to change any values, click the pencil icon to the right of the value and change.
Click the ​Reserve​ button after entering these values to start the reservation.
 Figure:​ Reserve Dialog

6. ​The sandbox reservation process starts.

The following indicators can be used to confirm that your sandbox is being setup:
● A status icon in the top right corner of the interface indicates the status as ​Setup​ icon.
Roll your mouse over this icon to receive the estimated amount of time needed to
complete the setup process.
● The ​Sandbox​ header at the top of the is covered by a moving stripe shape.
● An email from Juniper Cloud Labs (​[email protected]​) that indicates the setup
process has started has been received.
● The resources in the sandbox have a moving, dotted line circle around them. This dotted
line circle indicates that JCL automated setup procedure is running for the resource.
Figure:​ Sandbox Setup

The sandbox reservation time varies by sandbox, but sandboxes are often available in 30
minutes or less.
The following indicators can be used to confirm that a sandbox is ready for use:
● The status icon in the top right corner has changed from ​Setup​ to ​Active​.
● A ​Setup Complete​ email has been received from _ ​ [email protected]​.
● The resource circles have changed from dotted lines to solid circles.

Figure:​ Active Sandbox

The sandbox has been reserved and is available for use.

Chapter 3: Working in the Sandbox
A blueprint becomes an active network—called a sandbox—upon reservation. A sandbox is an active
network topology. See ​Creating a Sandbox from an Existing Blueprint​.
This section covers the options available to JCL users working in a sandbox.
It covers the following topics:
❏ Accessing and Managing Resources in a Sandbox
❏ Managing the Sandbox Reservation
❏ Monitoring Resources in the Sandbox
❏ Changing Presentation Settings in a Sandbox
❏ Navigating the Canvas in a Sandbox
❏ Using the Instructions Help

Accessing and Managing Resources in a Sandbox

This section covers the following topics:
❏ Accessing a Resource in a Sandbox
❏ Connecting Resources in a Blueprint or Sandbox
❏ Adding IP Address Prefixes to Share User Access in a Sandbox
❏ Creating VM Console Access to a Resource

Accessing a Resource in a Sandbox

A resource in a sandbox can be accessed once a sandbox is active. See ​Creating a Sandbox from an
Existing Blueprint​ for information on creating a sandbox.
To access a resource in a sandbox:
1. Roll your mouse over the icon for the resource. Multiple icons appear.
2. Click the ​down arrow​ icon.
3. Navigate to the login options in the drop-down menu. The login options vary by resource, but
often include ​Console,​ ​SSH​, and other login options.
4. Select your desired login option to log into the resource. The selected login option logs into the
resource using the out-of-band management interface.
Figure:​ Accessing a Resource (SSH Example)

Connecting Resources in a Blueprint or Sandbox

Connections between resources can be made in a blueprint or in a sandbox. Connections made in a
blueprint remain in the blueprint; connections created in a sandbox expire at the end of the sandbox
reservation.
The process for creating connections is identical in a sandbox or blueprint.
To add a connection to connect resources in a blueprint or sandbox:
1. Mouse over one of the resources in your topology. Click the ​chain-link​ icon. The ​Create
Connections d ​ ialog box appears.
Figure:​ Creating a Connection

​ ialog box
2. Mouse to the target connected resource and click. The ​Resource Connections d
appears.

Figure:​ Resource Connections Dialog Box

 3.​ Select the connection type in the ​Resource Connections ​dialog box:
❏ Create Connection​ (default): Select if you are connecting the resources with a
single link.
❏ Bulk Connection:​ Select if you are connecting the resources with multiple links.
❏ Inventory​: Select to manage connections between resources that were already
created. This connection type can be used to delete links or by advanced users
to configure links.
For single link connections created using the ​Create Connection​ option, define the
following fields:
❏ Connection Type:​ Always select ​Route (Logical).​ ​The Tap (Logical)​ and
Connector​ options are not supported in JCL at this time.
❏ Select Source Port:​ Select the virtual port number on one end of the link.
❏ Select Target Port:​ Select the target port number on one end of the link.

Figure:​ Create Connection Dialog Box

For bulk connections created using the ​Bulk Connection​ option, define the following
fields:
❏ Connection Type:​ Always select ​Route (Logical).​ ​The Tap (Logical)​ and
Connector​ options are not supported in JCL at this time.
❏ Set number of requested ports​ box: Select the number of connections you’d like
to create between the resources, then click the ​Add All​ button.
❏ Click ​Save​ in the bottom right corner to save the connection.

Adding IP Address Prefixes to Share User Access in a Sandbox

You may have a need for users at different IP addresses to access resources in your sandbox. For
instance, you many want to share resource access with a customer or coworker or you want to access
resources from a computer that is not the computer you used to create the sandbox.
To configure a resource to allow logins from different IP addresses:
1. Click the ​Commands​ button in the overhead navigation bar. The ​Blueprint Commands d​ ialog box
appears.
 2. Find the ​Add Allowed Network Prefixes Direct access to the resources in the sandbox​ option in
the ​Blueprint Commands​ dialog box. Click the arrow to the right. The ​Command Inputs​ dialog
appears.
3. Enter the IP address or addresses that you want to allow in the ​List_of_Prefixes​ box. Be aware of
the following guidelines and behaviors:
❏ IPv4 addresses only.
❏ The IP address or addresses must be public IP addresses. You can get the public IP
address of your PC by searching “​What is my IP address?”​ using Google.
❏ A /32 subnet mask is assumed if no subnet mask is entered.
❏ The subnet mask must be /29-/32.
❏ Multiple IP addresses can be added simultaneously in the ​List_of_Prefixes​ box. Each IP
address must be separated by a comma.

Creating VM Console Access to a Resource

You may need VM console port access for a variety of reasons. Console sessions on a resource running
Junos OS, for instance, are persistent and allow you to view log messages during reboots and at other
times when the management port is unavailable.
A token is needed to use VM console access for a resource in JCL. If you try to login to a VM console
before generating this token, you will receive a browser message that your login attempt is invalid.
To create VM Console access to a resource:
1. Configure the resource to recognize the username to avoid being unable to log into the console
port. For a resource running Junos OS, SSH into the device and configure a console port
username and password. See ​Protecting Network Security by Configuring the Root Password​ for
one method of configuring a password on the device.
2. Mouse over a resource to select it.
3. Click the Right arrow ​Commands​ button. The ​Resource Commands​ box appears on the right side
of the interface.
4. Click the run button next to the ​Generate VM Console Access and embed in URL​ text.

Figure:​ Generating the VM Console Access Token

 4. Wait a few seconds to ensure the token is generated, then access the VM console login by
selecting ​VM Console ​from the resource’s drop-down menu.

Figure:​ Logging into the VM Console

A screen with the console login appears.

Figure:​ Console Login

5. If no login prompt appears, hit ​Enter​.

6. Enter the credentials created earlier in this procedure to log into the resource.

Managing the Sandbox Reservation

This section covers the following topics:
❏ Renaming a Sandbox
❏ Extending a Sandbox Reservation
❏ Ending a Sandbox Reservation

Renaming a Sandbox
By default, a sandbox inherits the name of the blueprint. The sandbox can be renamed during the
blueprint reservation process or from within the sandbox itself. This procedure shows users how to
rename the sandbox from the sandbox.
Renaming the sandbox is optional. You can rename the sandbox for any reason.
Renaming the sandbox is particular useful when two or more sandboxes are generated from the same
blueprint and you need a method of identifying each individual sandbox.
To rename a sandbox:
1. Click the pencil icon next to the sandbox name.
2. Type the new name into the sandbox.
Figure:​ Renaming a Sandbox

Extending a Sandbox Reservation

A sandbox is torn down when a reservation expires.
To extend a sandbox reservation:
1. Click the Extend icon in the top right corner of the user interface. The ​Extend Sandbox​ dialog appears.

Figure:​ Extending the Sandbox Reservation Icon

2. Select the amount of time that you wish to extend the reservation. In the figure below, the reservation is
extended 2 hours.
Figure:​ Extending Sandbox Duration

3. Hit the ​Extend​ button.

Figure:​ Extend Button

4. A ​Sandbox was extended successfully​ message appears on the screen to confirm the extension.
Ending a Sandbox Reservation
A sandbox is torn down once a reservation expires or if a user manually ends the reservation. This
process shows how to manually end a reservation.
If you need access to the topology after a reservation has ended, start a new sandbox with the same
topology by reserving the blueprint. See ​Creating a Sandbox from an Existing Blueprint​.
To manually end a sandbox reservation:
1. Click the end reservation icon in the top right corner of the interface. The end sandbox dialog box
appears.

Figure:​ End Reservation Icon

2. Click OK to confirm the end reservation request.

Figure:​ Ending a Reservation

The teardown procedure begins.

The following elements confirm the teardown procedure is in progress:
❏ The status icon in the top right corner indicates ​Teardown.​
❏ The sandbox ending process has started​ message is visible in the middle of the interface.
❏ The sandbox bar at the top of the screen is twirling.
Figure:​ Sandbox Ending Process

You can exit the web browser after confirming the teardown procedure has started; you do not need to
watch the teardown process for it to finish.

Monitoring Resources in the Sandbox

This section covers the following topics:
❏ Monitoring the Activity Feed and Output
❏ Power Cycling and Restarting Resources
❏ Monitoring Resource Health

Monitoring the Activity Feed and Output

JCL includes an activity feed that logs all sandbox activities, and an output window that logs all blueprint
and sandbox command outputs. These logs can be used for any purpose that requires a historical activity
record, including verifying sandbox activity or troubleshooting.
Click the ​Activity​ button to view the activity feed:
Figure:​ Activity Feed

Click the ​Output​ button to view the output logs:

Figure:​ Output Logs

Power Cycling and Restarting Resources

A resource in a sandbox can be powered up, powered down, or power cycled using the ​power
management​ commands. A resource can be re-initialized—completely torn down and restarted as a new
resource—using a ​resource management​ resource command.
The ​power management​ and ​resource management​ commands can be accessed by clicking the
Commands​ button when mousing over a resource. The ​Commands​ button is a right arrow icon.
To power up, power down, or power cycle a resource, click the ​Commands​ button and select the Run
button next to the powering task that you’d like to perform.
Figure:​ Power Management Commands

To re-initialize a resource, click the ​Commands​ button and select the Run button next to the ​Start Over
(re-init)​ option.

Figure:​ Re-initializing a Resource

Monitoring Resource Health

The health status of each individual resource in any sandbox can be monitored using the health status
icon. The health status icon is in the bottom right corner of every resource in a sandbox.
The colors of the health status icon mean the following:
❏ Green: healthy
❏ Red: resource has a problem
❏ ?: a health check is running
Figure:​ Resource Health Icon

You can also run a health check on any resource using the health check ​resource management
command. To run a health check on a resource:

1. Click the ​Commands​ button and select the Run button next to the ​Start Over (re-init)​ option. The
Health Check​ dialog opens on the right-side of the interface.
2. Enter a value for timeout and retries. We suggest entering 5 for both fields if your unsure of how
to proceed.
3. Click the ​Run​ button.
4. Click the ​Activity​ button to view the ​Activity Feed​ and review the results.

Figure:​ Health Check Dialog

Changing Presentation Settings in a Sandbox

This section covers the following topics:
❏ Moving a Resource in the Sandbox
❏ Changing Icon Sizes
❏ Changing the Zoom Level
❏ Rearranging the Resource Presentation
❏ Changing the View Mode
Moving a Resource in the Sandbox
If you do not like the placement of a resource on the canvas in your sandbox, you can move it to another
point on the canvas.
To move a resource, click and hold the resource. Continue holding the resource and drag it to the desired
point on the canvas.

Changing Icon Sizes

The icons in a sandbox can be viewed at one of three sizes: small, medium, or large. The default icon
size is medium.
Each icon size has an option in the ​Style​ bar. To change the icon size, simply click the desired icon size
in the ​Style​ bar.

Figure:​ Icon Sizes

Changing the Zoom Level

A JCL user can change the zoom level by either clicking a meter that increases or decreases the zoom
level or by selecting a zoom percentage from a drop-menu.
To change the zoom by clicking the meter, move the mouse to the zoom meter in the right corner of the
user interface. Click + to increase the zoom level and - to decrease the zoom level.
Figure:​ Changing the Zoom Level (Meter)

To change the zoom by selecting a zoom percentage, click the zoom percentage in the right corner of the
interface and select a percentage from the drop-down menu.

Figure:​ Changing the Zoom Level (Percentage)

Rearranging the Resource Presentation

JCL offers a variety of methods to present your resources within a sandbox.
You can change the resource presentation by clicking the ​More​ button near the top-right corner of the
user interface and selecting the desired arrangement style.
Figure:​ Arrangement Style Options

JCL also includes related layout options. An arrangement can be saved using the ​Save Layout​ option. An
arrangement can also be undone using the ​Undo​ option, or reverted to the last saved layout using the
Revert​ option.
To use the layout options, click the ​More​ button near the top-right corner of the user interface and select
the desired layout option:

Figure:​ Layout Options

Changing the View Mode

The resources in a sandbox can be viewed in one of two modes: diagram or list. The default view mode is
diagram.
To change the view, select the diagram mode or list mode icon in the top-right corner of the user
interface.
Figure:​ View Mode Options

Navigating the Canvas in a Sandbox

The JCL graphical user interface presents the available resources and connections for the sandbox over
a canvas. The canvas must be navigated in order to use the sandbox.
To move the canvas in JCL, click and hold any point in the canvas that isn’t a resource or a connection. A
clenched hand icon appears.
Continue to hold the mouse button down, and move the mouse in any direction. You will move across the
canvas in the direction of the mouse.

Figure:​ Canvas Navigation

You can also use the navigator to navigate a canvas. The navigator is especially helpful in navigating
large sandboxes with a high number of resources.
To navigate a sandbox canvas using the Navigator:
1. Click the ​Navigator​ button. The ​Navigator​ box appears in the bottom left-hand corner of the
interface.
2. Place your mouse in the blue box in the ​Navigator​ box. Click and hold the mouse, and move the
mouse in any direction to quickly navigate the canvas.
Figure:​ Using the Navigator

Using the Instructions Help

Some blueprints are built with instruction resources that are designed to provide information about the
topology. See ​Updating Blueprint Properties​ for information on adding Instructions to a blueprint.
Blueprint instruction resources can be documents, videos, slide decks, and other information assets
created or provided by the blueprint creator for the benefit of all blueprint users. These instructions can be
incredibly useful for guiding you through a topology or for troubleshooting scenarios.
Click the ​Instructions​ button to view the instruction resources provided with any blueprint:
Figure:​ Using Instructions
Chapter 4: Building Your Own Juniper Cloud
Labs Topology
JCL features a build your own topology feature that allows users to build their own blueprints.
This section covers the following topics:
❏ Getting Build Your Own Topology Access
❏ Building Your Own Topology
❏ Modifying Resource Attributes
❏ Understanding Blueprint Dropdown Menu Options
❏ Updating Blueprint Properties

Getting Build Your Own Topology Access

A JCL user must complete training and pass a quiz before being able to build their own topology. See
Build Your Own Topology Prerequisites​.

Building Your Own Topology

To build your own JCL topology:
1. Log into JCL. See ​Logging into JCL​.
You must have build your own topology access to build your own topology. If you need this
access, see ​Getting Build Your Own Topology Access​.
2. Click the Domain button in the top right corner of the JCL user interface. The listed domain is
always the last domain that you used within JCL. ​Demonstrations​ is the default domain.
Choose ​Build-Your-Own​ from the drop-down menu.
Figure:​ Build Your Own Domain

3. Click the ​+ Create Blueprint​ button in the left-hand navigation menu.

Figure:​ Creating a Blueprint

4. Select one of the templates. Select the ​BYO Empty​ template if you are creating a topology that is
not using a traffic generator. Select the ​BYO Starter with Ixia​ or ​BYO Starter with Spirent​ templates if you
want to create a topology that uses an Ixia or Spirent traffic generator.
5. Depending on your template selection, either the ​Create Blueprint​ dialog box or a blank canvas
appears.
❏ Blank canvas: Click the pencil icon at the top header of the JCL graphical user interface.
❏ Create Blueprint​ dialog box: Name the blueprint by clicking the pencil icon in the ​Name
field.
Note:​ We strongly recommend naming your blueprint at this point of the procedure. If your blueprint is
unnamed, it is assigned a non-descriptive default blueprint name that can make identifying and retrieving
the blueprint difficult.
6. (​Create Blueprint​ dialog box only) Review the resource information. Hit the ​Create​ button to create
the topology.
Figure:​ Create Blueprint Dialog

7. Build the topology:

❏ To add a resource to a topology:
❏ Adding an Abstract Resource: Click the ​+Abstract​ icon. The ​Add Abstract
Template​ dialog box appears. Locate your abstract resource in the ​Add Abstract
Template​ dialog box. Drag the resource onto the blueprint.
Figure:​ Adding an Abstract Resource

❏ Modifying Resource Attributes (optional): Each resource in a blueprint has

multiple configurable attributes. These attributes include a software version
attribute that allows users to select the software version of the resource and a
Zone attribute that allows users to select the geographical location providing the
resource. The attributes available vary by resource.
Resource modification is optional; resources can be added to blueprints without
modifying attributes. See ​Modifying Resource Attributes​.
❏ Duplicating a Resource: Mouse over the resource that is already in your
topology. Click the down icon and select ​Duplicate.​ A new resource that matches
the existing resource appears in your blueprint.
Figure:​ Duplicating a Resource

❏ (Not recommended in most setups) Adding a Concrete Resource: Click the

+Resource​ icon. The ​Add Resource​ dialog box appears. Locate your concrete
resource in the ​Add Resource​ dialog box.
A concrete resource should only be used in select cases when a specific
resource is needed. Use abstract resources whenever possible to ensure
resource availability.
❏ Removing a Resource: Mouse over the resource. Click the down icon and select
Remove​. A new resource that matches the existing resource appears in your
blueprint.
Note​: Remove resources in blueprints only. Removing resources from a sandbox
causes system errors that can make your sandbox unpredictable or inaccessible.
❏ Adding an App or Service: This feature is not currently supported in JCL.
❏ To add a connection to connect resources in a topology:
Mouse over one of the resources in your topology. Click the ​chain-link​ icon. The ​Create
Connections ​dialog box appears to start the connection process.
 Figure:​ Creating a Connection

To complete the connection process, see ​Connecting Resources in a Blueprint or Sandbox

7. (Optional) If you want your blueprint to be public, click the ​lock​ icon. The ​lock​ icon opens to indicate
the blueprint is public. Click the ​lock​ icon again to change the blueprint setting back to private, if desired.
Figure:​ Public Blueprint

8. Hit the ​Reserve​ button to create a sandbox based on this blueprint.

Modifying Resource Attributes

Each resource in a blueprint has multiple configurable attributes. These attributes, when added to a
resource, appear as configurable options in the ​Reserve​ dialog box when a JCL user reserves a blueprint.
A user reserving the blueprint with resource attributes must specify a value for each resource attribute as
part of the reservation process.
The use of resource attributes is optional; sandboxes can be generated in blueprints that never use
resource attributes.
A wide variety of attributes are available and vary by resource. Some commonly-used resource attributes
include the software version attribute that allows users to select the software version of the resource, the
Zone attribute that allows users to select the geographical location providing the resource, and the
HelperVM startup resource that allows users to load snapshot configurations into a sandbox using Ansible
playbooks.
To modify the attributes of a resource in a blueprint:
1. Mouse over the resource that is already in your topology.
2. Click the down icon and select ​Edit Abstract Resource.​ The Edit Resource ​Edit d
​ ialog
box appears.

Figure:​ Edit Abstract Resource

3. There are two tabs on the top of the dialog box:

❏ Requirements​: Attributes that must be met in order to reserve the resource.
❏ Additional Info:​ Attribute preferences that will be checked but can be unused in a
sandbox.
4. Modify the resource using one of the following options:
❏ Add attribute: Select the ​add attribute​ button at the bottom of the window. and
walk through the options.
❏ Add attribute value: Select the + icon next to the attribute, and walk through the
process to add an attribute value.
❏ Delete attribute: Select the trash can icon next to the attribute.
❏ Edit attribute value: Select the notepad icon next to the attribute, then walk
through the process to edit the attribute value.
5. Click the up arrow publish icon associated with the attribute to publish any
attribute value addition or edit.
Figure:​ Resource Attributes Screen

The ​Loading a Snapshot from the JCL Git Server​ procedure provides an example of a process completed
using resource attributes.

Understanding Blueprint Dropdown Menu Options

All blueprints have a dropdown menu that can be used to provide some blueprint functionality. Most of
this functionality is self-explanatory or is used to accomplish a task that is performed elsewhere in this
document. The tasks in the blueprint dropdown menu—with the notable exception of modifying blueprint
properties which is documented in ​Updating Blueprint Properties​—are therefore not covered in this guide.
The following figure shows how to view the blueprint dropdown menu options.
Figure:​ Blueprint Dropdown Menu Options

Updating Blueprint Properties

The Blueprint properties dialog allows users to configure many of the attributes of the blueprint. We
strongly recommend updating blueprint properties to make your blueprints easily accessible. Common
tasks performed in the blueprint properties include adding a support graphic to the blueprint, naming the
blueprint, setting the blueprint description, setting the estimated setup time attribute, setting default and
maximum durations, and adding instructions to the blueprint.
To perform these tasks:
1. Select ​Properties​ from the Blueprint drop-down menu.
Figure:​ Blueprint Properties

2. The ​Edit Blueprint​ dialog box appears.

Figure:​ Edit Blueprint Dialog

Perform any of the following tasks from the ​Edit Blueprint​ dialog box:
Note​: This step does not list every possible task in the ​Edit Blueprint​ dialog box. It only lists the
most commonly-used tasks.
❏ Add introduction graphic: To add an introduction graphic—the graphic that is viewed
when the blueprint is presented on the search screen—to the blueprint, mouse over the
box in the top-left corner. The word ​Change​ appears in the box. Click it and follow the
instructions to add the introduction graphic.
❏ Change blueprint name: Mouse over the text in the ​Name​ box and click. A cursor
appears. Edit the name.
❏ Change blueprint description: Mouse over the text in the ​Description​ box and click. A
cursor appears. Edit the description.
❏ Change default duration: Use the drop-down menu to change the default reservation
time. The default reservation time is always 2 hours if this attribute is unaltered.
❏ Change estimated setup duration: Click the number in the estimated setup duration
option and change it to the desired setup duration.
The estimated setup value appears when a user mouses over the setup status icon
during the sandbox setup procedure. It is set at 10 minutes by default.
❏ Add a script: Click the ​Add Scripts​ button and follow the procedure.
❏ Add Instructions: Click the ​Instructions​ tab in the top right corner of the dialog box.
Use the menu that appears to add an image, video, link, or other information asset.
The ​Instructions​ are user aids that are visible to anybody that pushes the ​Instructions
button in the sandbox.
Chapter 5: Automating Processes with the
HelperVM and the JCL Git Server
The HelperVM is a JCL resource that is added to a blueprint like any other resource. The Helper VM,
among other features, stores Ansible playbooks that can be used to save and load snapshot
configurations to the JCL Git Server. The snapshot configurations stored on the JCL Git Server currently
save the Junos OS, Spirent, and Ixia configurations for all resources in a sandbox.
The JCL Git Server is used to store snapshot configurations. Each JCL user is automatically given their
own account on the JCL Git Server after their first reservation of a blueprint that includes a HelperVM
resource.
Other HelperVM features include pre-loaded versions of many popular automation tools. The HelperVM
also saves inventory files about each sandbox that are created as part of the JCL automated setup
procedure. These inventory files store various information specific to your sandbox onto the HelperVM,
and are useful for troubleshooting or confirming specific details about your current sandbox.
This section covers some of the common JCL tasks performed using the HelperVM and the JCL Git
Server.
It covers:
❏ Adding the HelperVM to a Blueprint
❏ Creating and Accessing an Account on the JCL Git Server
❏ Saving a Snapshot to the JCL Git Server
❏ Updating a Snapshot Configuration
❏ Making the Snapshot Shareable
❏ Loading a Snapshot from the JCL Git Server
❏ Opening an Inventory File

Adding the HelperVM to a Blueprint

To add a HelperVM to a blueprint:
1. Click the ​+Abstract​ icon to add an abstract resource.
2. The ​Add Abstract Template​ dialog box appears. Locate the ​HelperVM​ resource in the ​Add
Abstract Template​ dialog box.
Search on the term ​HelperVM​ if you are unable to find the resource through browsing.
3. Click and hold the ​HelperVM​ resource to drag it onto the blueprint.
Figure:​ Adding a HelperVM Resource to a Blueprint

Creating and Accessing an Account on the JCL Git Server

An account on the JCL Git Server is automatically created when a user reserves a blueprint that includes
a HelperVM for the first time. The user reserving the blueprint receives an email from Gitlab with
instructions on creating a password for their account.
To create and access the JCL Git Server account:
1. Reserve a blueprint that includes a ​HelperVM​ resource. See ​Adding the HelperVM to a Topology​.
If this is your first time reserving a blueprint with a HelperVM resource, you will receive an email
from Gitlab. Do not discard this email.
If this is not your first time reserving a blueprint with a HelperVM resource but you do not have
JCL Git Server account, further instruction is provided later in this procedure.
2. After the sandbox is created, use RDP to access the ​HelperVM​ resource.
Figure:​ Using RDP to Connect to the HelperVM

The Application homepage appears.

​Note​: Be patient at this step. The RDP login process can sometimes take two or more minutes.

Figure:​ HelperVM RDP Homepage

 Click the ​Firefox Web Browser​ icon to open the Firefox browser. The browser will open
on the Gitlab homepage.
3. (First time JCL Git Server users only) Retrieve the email from Gitlab. If you are having difficulty
finding this email, check your ​Clutter​, J​ unk,​ or other folders where messages are automatically
filtered.
The email includes a unique URL that is used to create your Git Server username. Enter this URL
into the Firefox web browser running in the RDP session.
If you do not have this email, click the ​Request a new one​ link on the Gitlab homepage next to the
Didn’t receive a confirmation?​ message and get the URL from the email message.
4. (First time JCL Git server users only) Follow the process to create your Git Server account.
5. Enter your credentials at the Gitlab homepage to access your account.

Figure:​ Gitlab User Homepage

Saving a Snapshot to the JCL Git Server

The HelperVM resource includes Ansible scripts that can save snapshot configurations of the sandbox to
the JCL Git server. The snapshot configurations on the JCL Git server are generally best used on
sandboxes derived from the same blueprint to avoid conflicts, but can be used between blueprints in
some cases.
A JCL snapshot configuration currently includes:
❏ Junos OS configurations of devices running Junos
❏ Ixia and Spirent configurations
A HelperVM is needed in a sandbox to save a snapshot to the JCL Git server. The HelperVM
automatically generates some configuration files as part of the automated sandbox setup procedure and
communicates with the JCL Git server to allow the Ansible playbooks to be run.
To save a snapshot of a sandbox to the JCL Git server:
1. Reserve a blueprint that includes a ​HelperVM​ resource. See ​Adding the HelperVM to a Topology​.
2. Use SSH or a comparable login method to log into the ​HelperVM​ resource from the sandbox. See
Accessing a Resource in a Sandbox​.
3. The HelperVM prompt appears.
Navigate to the Ansible playbooks within the ​HelperVM​ resource.
​root@HelperVM:~# c ​ d JCL_Ansible_Playbooks
 4. Run the get configuration script to save a snapshot of your current sandbox onto the current
directory in the HelperVM resource.
root@HelperVM:~/JCL_Ansible_Playbooks# ​ansible-playbook get-config-from-device.yml
5. Confirm the files were saved in the current directory.
root@HelperVM:~/JCL_Ansible_Playbooks# ​ls -ltr
6. Run the push directory to git script to save the files onto the JCL Git server.
In this example, all of the snapshot files are saved onto the JCL Git server into a folder called
MyJCLSandboxConfig:​
root@HelperVM:~/JCL_Ansible_Playbooks# ​ansible-playbook push-directory-to-git.yml -e
“DirName=MyJCLSandboxConfig”
7. Open an RDP session into the HelperVM. Log into your JCL Git Server account to ensure the
snapshot was saved.
See ​Creating and Accessing an Account on the JCL Git Server​ for a walkthrough of the JCL Git
Server login process.

If you have a need to update an existing snapshot configuration, see ​Updating a Snapshot Configuration​.

Updating a Snapshot Configuration

This procedure outlines how to update a snapshot configuration. See ​Saving a Snapshot to the JCL Git
Server​ if you are configuring a snapshot for the first time.
To update the configurations in an existing snapshot:
1. Reserve a blueprint that includes a ​HelperVM​ resource. See ​Adding the HelperVM to a Topology​.
2. Use SSH or a comparable login method to log into the ​HelperVM​ resource from the sandbox. See
Accessing a Resource in a Sandbox​.
The HelperVM prompt appears.
3. Clone the existing snapshot configuration.
root@HelperVM:~# g ​ it clone
[email protected]:jcl-username/MyJCLSandboxConfig.git
4. Confirm the cloned snapshot directory is available.
​root@HelperVM:~# c ​ d MyJCLSandboxConfig/
​root@HelperVM MyJCLSandboxConfig# ​ls
5. Run the get configuration Ansible playbook to save the configuration.
❏ To update the entire configuration:
root@HelperVM MyJCLSandboxConfig# ​ansible-playbook get-config-from-device.yml
❏ To update the Junos configuration only:
root@HelperVM MyJCLSandboxConfig# ​ansible-playbook get-config-from-device.yml
--limit juniper
❏ To update the Spirent configuration only:
root@HelperVM MyJCLSandboxConfig# ​ansible-playbook get-config-from-device.yml
--limit spirent
❏ To update the Ixia configuration only:
root@HelperVM MyJCLSandboxConfig# ​ansible-playbook get-config-from-device.yml
--limit ixia
 6. Run the following git commands to push the updated clone configuration to the original sandbox
configuration:
root@HelperVM MyJCLSandboxConfig# ​git add .
root@HelperVM MyJCLSandboxConfig# ​git commit -m “updated Junos system config”
root@HelperVM MyJCLSandboxConfig# ​git push
7. Log into the JCL Git Server to confirm the snapshot was updated. See ​Creating and Accessing
an Account on the JCL Git Server​.

Making a Snapshot Shareable

This process shows users how to log into their JCL Git Server account and manage the privacy settings
on a snapshot.
While snapshots are best used to configure sandboxes derived from the same blueprint, different users
can create sandboxes from a public blueprint. Some snapshots, therefore, must have privacy settings that
allow for usage by multiple users.
Many other configuration options within the JCL Git Server are available. The entire range of JCL Git
Server configuration options is beyond the scope of this guide.
This process assumes a snapshot is saved to the user’s JCL Git Server. See ​Saving a Snapshot to the
JCL Git Server​.
To manage the privacy settings of a snapshot from the JCL Git Server.
1. Log into JCL Git Server using the Mozilla Firefox web browser in the RDP session of the
HelperVM. See ​Creating and Accessing an Account on the JCL Git Server​.
2. After logging in, you’ll see your projects. If you do not see your projects or have a need to return
to your projects, click ​Projects​: ​Your Projects​.
Click the snapshot that you saved using the procedure in ​Saving a Snapshot to the JCL Git
Server​.
The sandbox configuration page is opened.
3. Select ​Settings​ from the left-hand navigation menu. The General Settings box appears.
4. Select ​Permissions​ and change the project visibility to ​Internal​ if you want to share the snapshot
with other JCL users.
The default permission level is ​Private,​ which means only the creator of the director can use the
snapshot directory.
Do not use the ​Public​ permission level with JCL.
Note:​ This procedure covers one method of managing permission levels for a snapshot on the
JCL Git Server. Other methods of managing privacy settings for the snapshot exist.
5. Click the ​Save Changes​ button to complete the procedure.

Loading a Snapshot from the JCL Git Server

To load a snapshot configuration onto a sandbox:
1. Ensure a snapshot has been saved to the JCL Git server. See ​Saving a Snapshot to the Github
Server​.
2. Create a blueprint that includes the ​HelperVM​ resource. See ​Adding the HelperVM to a Topology​.
3. Click the ​HelperVM​ resource, and select ​Edit Abstract Resource​ from the down-arrow drop-down
menu.

Figure:​ Edit Abstract Resource

The ​Edit Abstract Resources​ dialog appears.

4. Click the ​Additional Info​ tab.
5. Edit the following attributes to configure the blueprint to prompt users to download the snapshot
as an option during reservation.
The example below provides values for the ​MyJCLSandboxConfig​ snapshot.
❏ HelperVM_Startup: ​git clone
[email protected]:jcl-username/MyJCLSandboxConfig; cd
MyJCLSandboxConfig; ansible-playbook install-config-to-device.yml
❏ HelperVM_StartupCmdTimeout: ​120
The procedure to change these attributes starts by clicking the ​Edit Attribute​ notepad icon
associated with the attribute. See ​Modifying Resource Attributes​ for information on modifying
resource attributes.
Figure:​ Editing HelperVM Resource Attributes

Click the ​Publish​ up-arrow icon for each of these attributes as part of this process.
Figure:​ Publish Icons

6. Click the ​Save Changes​ button.

7. Reserve the blueprint. The attributes appear as part of the ​Reserve​ dialog box.
8. Select the attributes in the ​Reserve​ dialog box to apply the snapshot configuration to the
sandbox.
Figure:​ Selecting a Snapshot for a Sandbox Example

9. Repeat this step for each resource attribute.

10. Reserve the blueprint. See ​Creating a Sandbox from an Existing Blueprint​.

Opening an Inventory File

The ​HelperVM​ resource automatically generates inventory files from your sandbox as part of the
automated sandbox setup procedure. These inventory files store various information specific to your
sandbox onto the HelperVM.
You may need to access these inventory files for a variety of reasons such as troubleshooting or to
confirm specific details about your sandbox for a task.
This procedure shows you how to open an inventory file.

1. Use SSH or a comparable login method to log into the ​HelperVM​ resource from the sandbox. See
Adding the HelperVM to a Topology​ and ​Accessing a Resource in a Sandbox​.
2. Open the inventory file using the ​more​ command.
All inventory files are stored in the ​/etc/ansible​ directory. You can navigate to the files you need
from this directory .
To access some of the commonly accessed inventory files.

○ To open the host inventory file: ​more /etc/ansible/hosts

○ To open the topology inventory file: ​more /etc/ansible/group_vars/all/topology.yaml
○ To open the reservation inventory file: ​more
/etc/ansible/group_vars/all/reservation.yaml
Figure:​ Topology Inventory File Example
Chapter 6: ​Setting up and Generating Traffic with
Spirent Resources
The JCL resource pool includes Spirent and Ixia resources that can be used to generate traffic in a
sandbox.
This section shows how to generate traffic in a JCL sandbox using Spirent resources. It uses a topology
that connects two SpirentVTC resources to revenue ports on the same virtual router. The SpirentVTC
resources generate traffic to one another bidirectionally through the revenue ports on the virtual router.
The complete options for generating traffic using Spirent devices are beyond the scope of this document.
This document provides one method of generating traffic using Spirent to illustrate how a Spirent resource
can be utilized in a JCL sandbox.
To setup and generate traffic with a Spirent resource:
1. Create a blueprint that includes two ​SpirentVTC​ resources that each connect to a virtual router or
switch. The blueprint must also include one ​SpirentGUI​ and one ​SpirentLabSrv​ resource.
Note​: Do not include more than one ​SpirentGUI​ or ​SpirentLabSrv​ resource in any blueprint or
sandbox. Each one of these resources can be used with all Spirent resources in a sandbox, and
adding more than one of these resources leads to sandbox setup failures.
The ​SpirentGUI​ and ​SpirentLabSrv​ resources only have management connections and should
not be connected to other resources. The management connections are not visible in the JCL
interface because the interface automatically hides all management interfaces.
A ​HelperVM​ resource is not required, but we strongly recommend also including one in your
blueprint.
Figure:​ Spirent Topology Blueprint

2. Create a sandbox by reserving your blueprint. Wait for the JCL automation process to create the
sandbox.
3. From the sandbox view, make a note of each interface on the virtual router or switch and the
interface at the opposite end of the link on the ​SpirentVTC​ resource. These mappings are used
later in this procedure to configure the networking device and Spirent interfaces.
The interface names can also be identified using the blueprint’s topology inventory file. See
Opening an Inventory File​.
4. Log into the virtual routing or switching resource connected to the Spirent traffic generators. See
Accessing a Resource in a Sandbox​.
5. Configure an IP address on the interface that connects to the Spirent traffic generator. The IP
address on each interface must be in the same subnet as the virtual spirent interface on the
opposite end of the link configured later in this procedure.
In this example, ge-0/0/1 and ge-0/0/2 on a vMX resource connect to a virtual Spirent resource.
The interfaces are assigned IP addresses 1.1.1.1/24 and 1.1.1.2/24.

Example:
​jcl-user@vmx0> c ​ onfigure
Entering configuration mode

​[edit]
jcl-user@vmx0# s ​ et interfaces ge-0/0/1 unit 0 family inet address 1.1.1.1/24
​jcl-user@vmx0# s ​ et interfaces ge-0/0/2 unit 0 family inet address 2.2.2.1/24
​jcl-user@vmx0# c ​ ommit
 6. Access the SpirentGUI client by logging into the SpirentGUI resource. RDP is the suggested
method of logging into the client, although other login options exist.
The Spirent test session manager user interface appears. A Spirent session using SpirentVTC
interfaces is already configured. This configuration was performed during the sandbox reservation
process by the automated JCL setup procedure.

Figure:​ Spirent Test Session Manager

7. Click the Connect icon on the SpirentGUI test session manager to establish connections to an
active session on the SpirentLabSrv resource in the sandbox. The Spirent Test Center opens.
8. The Spirent ports connected to the virtual router or switch have been pre-reserved and should
appear in the left-hand navigation menu under ​All Ports.​
9. Click the ​All Devices​ option in the left-hand navigation menu, and the ​Add​ button in the window.
Figure:​ Spirent TestCenter - All Devices Option

The ​Create Devices ​dialog box appears.

10. In the Select Ports box, select all of the ports. Click the ​Finish​ button.

Figure:​ Spirent TestCenter - Select Ports Menu

Both interfaces are added to the ​Emulated Device Interface​ tab.

​ 11. Change the following attributes for each device in the ​Emulated Device Interface​ tab:
❏ IPv4 Address
❏ 1.1.1.2​—connects to IP address 1.1.1.1
❏ 2.2.2.2​—connects to IP address 2.2.2.1
Figure:​ Spirent Testcenter - Configuring IP Addresses

❏ IPv4 Default Gateway (must match IP address at opposite end of link)

❏ 1.1.1.1​—IP address 1.1.1.2
❏ 2.2.2.1​—IP address 2.2.2.2

Figure:​ Spirent Testcenter - Configure IPv4 Default Gateway

12. Click the ​Apply​ icon.

13. Confirm that the addresses are reachable using the ARP protocol:
​ Right-click​ : ​ARP/ND​ : ​Start ARP/ND On All Devices
​Look for the ​All Attempted Arps resolved successfully​ message in the bottom left-hand corner to
confirm the addressing scheme.
Figure:​ Spirent TestCenter - ARP

If the attempted ARP is unsuccessful, check your IP address settings on the virtual router or switch and
on the virtual Spirent resource.
​14.​ ​Click the ​All Stream Blocks ​button.

Figure:​ Spirent TestCenter - All Streams Block

15. Click the ​Add​ button. The ​Traffic Wizard​ box appears.
 16. Both interfaces should be checked. Click the box next to an interface it is not already checked.
​ utton.
Click the ​Next b

Figure:​ Spirent TestCenter - Traffic Wizard Select Ports Dialog

17. The traffic wizard box moves to a new screen. Select the source and destination Spirent
resources. Select the Orientation as bidirectional if you want traffic to flow in both directions between the
Spirent resources.

Figure:​ Spirent TestCenter - Source and Destination Network Configuration

Click the ​Add​ button to add the setup to the wizard.

Click ​Finish​ to apply the setup.
Figure:​ Spirent TestCenter - Adding Interface Pairs

18. The resources appears in the ​Test Configuration​ box. Hit the ​Apply ​button to initiate the Spirent
resources.
Figure:​ Spirent TestCenter - Stream Block Additions

19. Select ​Actions:​ ​Start Traffic on All Ports​ to begin passing traffic.
Figure:​ Spirent TestCenter - Starting Traffic

20. Log back onto the virtual router or switch and verify that traffic is passing through the resource:

​ onitor interface traffic

​jcl-user@vmx0> m

The output for the two interfaces connected to the Spirent resource - ge-0/0/1 and ge-0/0/2 - show that
traffic is passing through these interfaces.

21. Select the ​Stop Traffic on All Ports​ button when you want to stop the Spirent ports from generating
traffic.

The process is complete.

Getting Juniper Cloud Labs Technical Support
The JCL support team is available to help you whenever you run into an issue. We welcome and strongly
encourage you to contact JCL support whenever you need assistance accomplishing a task within JCL.
This section covers the following topics:
❏ Gathering Information for Technical Support
❏ Running Troubleshooting Tests
❏ Contacting Technical Support

Gathering Information for Technical Support

To get the most efficient and thorough support, provide as much information about the issue as possible
in your support request.
Your support request should include:
❏ Urgency—Describe the business impact of the problem. Is this problem causing a critical,
revenue-impacting network outage or is it a minor inconvenience, for instance?
❏ The URL of the sandbox.
❏ Problem description—Explain the problem as thoroughly and directly as possible.
❏ Timing—Explain when you first saw the issue, and how frequently the issue occurred if you are
dealing with a persistent issue.
❏ Environment—Provide your computer’s OS type and version, browser version, the access client
type and version (SSH, VNC, or RDP, for example), and any other local application information.
❏ Test results. See ​Running Troubleshooting Tests​.
❏ Screenshots—All screenshots that detail the problem are helpful. A screenshot of the ​Activity
Feed​ is often very useful for support purposes.
❏ Video recordings, if you can get them.
❏ Any other asset that could help troubleshoot the problem.

Running Troubleshooting Tests

The first step of any JCL troubleshooting procedure is identifying if the issue is a general JCL issue or if it
is restricted to a single blueprint.
See the ​Monitoring Resource Health​ section for information on tests that can be run to identify the source
of the issue before contacting JCL support:

Contacting Technical Support

The technical support path depends on the results of the troubleshooting tests. See ​Running
Troubleshooting Tests​.
If the test results indicate that the issue applies to a blueprint, contact the blueprint owner. The blueprint
owner’s contact information is accessible using the ​More Info​ button in the blueprint or the sandbox.
If the test results indicate that the problem is with JCL or if you are unsure of your next step, email
[email protected]​.
The JCL support team is located in the eastern United States in the Eastern Standard Time (EST) and
Eastern Daylight Time (EDT) time zones. JCL support requests are addressed during active work hours in
these time zones.