Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Using This Guided Setup

To recreate the network in this example, you’ll need an account with admin-level credentials for an organization in the Juniper Mist cloud. You should be able to add a site to the organization.

On the hardware side, you’ll need at least two supported SRX Services Gateways. These should be available for you to use in your Organization’s Inventory, which means they are already connected to the WAN and have been onboarded to the Juniper Mist cloud (that is, claimed and adopted).

For help onboarding and/or claiming your devices, please see the following:

The Juniper SRX Gateway devices should also be manageable by the Juniper Mist cloud, and you should not make any further configuration changes to the device outside of the Juniper Mist console. This is because any existing configuration will be replaced when the Juniper Mist console pushes its stored configuration to the device. In addition, if you make configuration changes to the device outside of the Juniper Mist console after the initial configuration push, these changes will not be known to the Juniper Mist console. Thus, whenever another cloud-side config push is made to the device, those changes will be lost.

That said, there is an option in the Juniper Mist console to add device-level configuration statements, which will be included in all subsequent cloud-side pushes. This is shown in Task X.

Using the Juniper Mist Console

The GUI typically groups related configuration settings together in a settings panel, identified by a title. In some cases, there are a lot of settings and panels in each screen. In this document, we use the title to help you navigate within the page, but you may need to scroll down the page to find a given panel.

  • For screens with a lot of information, you can in some cases display the settings panels in three columns by making the screen wider.

  • Some settings panels require an intermediate save action to store the information locally. These are indicated by a blue checkmark at the top of the panel. These saves are not pushed to the device. A gray checkmark means the configuration is not complete or that there is something wrong with one of the settings.

  • To push the configuration to the device(s), be sure to scroll to the top of the screen and click the Save button.

Hierarchy in the Juniper Mist Console

The GUI uses an inheritance hierarchy for sites, templates, and devices, in that order. Settings made at the site level will apply to all devices. This is convenient for things like DNS settings, which are global in nature.

Device-level settings, which apply only to that device, are also possible. If the same setting is configured for the device at the template level, the device-level settings will take precedence. This lets you create device-specific exceptions to any settings made at the template level (for example, if you need the device to perform some kind of individual role while at the same time inheriting most of its settings from the parent template).

Settings made in a template can be applied to one or more sites. If you are using site variables in the template, the variables will be replaced by actual values for the site when you apply the template to another site.

Variables

Site variables provide a way to use tags (such as “corp_ip”) to represent actual values (such as 10.10.0.1) so that the value can vary according to the context where you use the variable. For example, for Site 1 you can define corp_ip to be 10.10.0.1, while for Site 2 the value you give corp_ip is 192.168.1.10. You can then use the tag to replace the actual IP address for Juniper Mist Cloud configurations such as in the WAN edge template, so that when you attach the template to different sites, the appropriate IP address is automatically used in each site.

To define site variables, use double brackets to format the variable name, like so:

{{site-variable}}

Using These Instructions

The Juniper Mist console does a great job of abstracting much of the network design and configuration details required for the underlay and even automates things like tunnel set up between the hub and spokes. But there is still a fair amount of configuration work to do in the GUI.

In the sections that follow, we break this work into seven tasks, each of which includes required steps. Some tasks are used as objects (or, building blocks) in a later task.

The steps walk you through the configuration for the first instance. For example, creating a site for one of the hubs. If you need to create additional instances of the same task, you’ll see a table that contains the configuration settings needed, such as the remaining hub and two additional spokes.

The idea is for you to follow the steps to complete the first instance of the task and then use the values in the table to go through the steps again to complete the next instance of the task, and so on, rather than cycling through the steps this example again for each set of values.

The tables also make it easier if you need to adapt this example for your own environment. So, for example, if the 10.0.0.1/28 IP addresses we use here are not suitable for your environment, or if you are not using the ge-0/0/1 interface on your device, you can update the tables to include those that are. This is work you should complete before you proceed.