ON THIS PAGE
Day 1: Use a Template-Based Configuration with Device and Port Profile
Configuration Templates
A key feature of switch management through the Juniper Mist cloud architecture is the ability to use configuration templates and a hierarchical model to group the switches and make bulk updates. Templates provide uniformity and convenience, while the hierarchy (organization, network, and switch) provides both scale and granularity.
You can create a template configuration and then apply those settings to all the devices in a given group. When a conflict occurs, for example when there are settings at both the network and organizational levels that apply to the same device, the more narrow settings (in this case, network) override the broader settings defined at the organization level.

Individual switches, at the bottom of the hierarchy, can inherit all or part of the configuration defined at the organization level, and again at the network level. Of course, individual switches can also have their own unique configurations.
You can include individual CLI commands at any level of the hierarchy. These commands are then appended to all the switches in that group on an AND basis – that is, individual CLI settings are appended to the existing configuration (existing setting are not replaced).
Organization Level |
Network Level |
Switch Level |
---|---|---|
|
|
|
|
|
|
|
|
|
|
- |
- |
|
- |
- |
|
- |
- |
There is a lot of flexibility in how you can design templates and use them at different levels of the hierarchy. To illustrate this, we’ll look at four use cases to show the interplay between configuration settings made at different levels of the hierarchy.
For each of the use cases below, start by clicking Organization > Switch Templates in the main Juniper Mist menu. If you don’t see that option, you need a network administrator account before you can proceed.
Case 1: Organization-Level Switch Settings
Enterprise A has multiple sites, all of which use the same VLANs and ports. However, at the switch level, different switch models are deployed, and the switches don’t all have the same exact port configurations or the same number of ports.

Template Solution
-
Start with an organizational-level switch template.
-
Configure the VLANs and ports, which will then be applied uniformly to all switches in each network that is included in the organization.
-
Use the Port Configuration Rules feature in the organization template to create different port configuration rules for each of the different switch models found in the organization.
-
Assign the organization template to all sites. Any switches, now or in the future, that are added to one of the sites will inherit the VLAN settings, and the port rules, according to the switch model.
Case 2: Network-Level Settings
Enterprise B has multiple sites, all of which use the same VLANs, ports, and port configurations. However, one network has a RADIUS server that uses 802.1X authentication (and so is different from what is configured at the organization level).

Template Solution
-
Start with a network-level switch template.
-
Because this network uses a unique RADIUS server (that is, one that is different than the one defined at the organization level), we will override that configuration with the setting specified here.
Case 3: Individual Switch Administration
Enterprise C has multiple sites, each of which is managed by a local IT team. In other words, each team wants to be able to configure the switches under their control, without inheriting any setting from the network or organization level hierarchies. As such, if a given switch has a specific VLAN or RADIUS server (such as 10.10.10.10) they can add it here.

Dynamic Port Profiles
When you connect a device to a Juniper switch interface, the port can be automatically provisioned with device-appropriate port properties and network access. For example, if you connect a Juniper access point to a switch, the port will be automatically set as a trunk interface and added to selected VLANs. Likewise, if you connect a remote camera to the switch, that port can be automatically configured as an access interface and assigned a different VLAN.
This feature is called dynamic ports, and it work by leveraging the client device’s Link Layer Discovery Protocol (LLDP) properties to automatically associate pre-configured port and network settings, and applying those settings to the interface. LLDP data is assigned by the device manufacturer and is typically hard coded in the device. The following LLDP properties are supported for use with dynamic port profiles:
-
System name
-
LLDP chassis ID
-
RADIUS user name
In the procedures that follow, you’ll set up a dynamic port profile for interface
ge-0/0/2
. To do so, you’ll create one or more network objects
(these are used to define network access on the basis of VLAN IDs that are already
in use on the network), and you’ll create at least one port profile (these include
properties such as trunk or access port, untagged or native VLAN, and VoIP). Then
you’ll associate the port profile with a network object, and, in the dynamic port
profile, associate the device LLDP with one of the port/network profiles.
After connecting a Juniper access point, the port configuration will change from the previous default, restricted_device, to the dynamically assigned mist-ap profile. Figure 5 shows what this looks like in the Juniper Mist dashboard (the Switches page).

Note that to set up dynamic ports, the switch needs to be managed through the Juniper Mist portal. You will also need to know the LLDP properties of one or more client devices to make these configurations on your switch.
Configure Network Access
To protect against unknown or rouge devices being added to the network, Juniper recommends that you create a restricted network, with limited access, that can be applied by default to unknown devices. We’ll do that in the steps below, but at the same time we recommend that you create a few other network objects based on different VLAN IDs from you network so you have a selection to choose from when later creating the port profiles.

To add a network to the configuration:
- In the Juniper Mist portal, click Switches in the menu on the left and then click a switch name to open the properties dashboard for that device (if you are looking at the Topology view, you may need to drill down to find the switch).
- Scroll down the page that appears to find the Networks configuration box, and then click Add Network.
- Give the Network a name, which will be used to identify it in the list when creating the port profile.
- Specify a VLAN ID that includes (or excludes) the network access you want for this object.
- When you’re done, click the check mark to add it to your Network list.
Add a Port Profile
Port Profiles is where you configure the settings that will be automatically applied to devices that match the LLDP information when they are connected an interface.
Figure 7 shows two port completed profile configurations. The one the left shows the default settings that are applied to unknown devices. The one on the right shows a typical configuration of Juniper access points. Each port profile provides different levels of network access, as determined by which network(s) you attach.

To add a port profile to the configuration:
- Under Port Profiles, click Add Profile.
- Give the Profile a name, which will be used to identify it in the list when defining the dynamic port configuration.
- Fill out the rest of the fields to create a template of the properties you want. In particular, choose whether the interface should be Trunk or Access. For Juniper access points, use Trunk.
- Assign a network to the profile.
- When you’re done click the check mark to add this network object to the list of port profiles.
Configure a Dynamic Port
To configure a dynamic port, you define a LLDP string and match rules in the dynamic port profile. These rules are evaluated so that the first match to occur is applied. Wild cards are supported. To get the level of differentiation you may need to identify a given device, you can specify an offset for the evaluation start point, or specify a particular LLDP segment to use for the match.
Figure 8 shows an example of the configurations. Whenever a Juniper access point is connected to a specified port on the switch, the port is automatically provisioned as a trunk port, and the device granted default network access.

The following steps use the Chassis ID for a Juniper access point, such as can be
found by running the show lldp neighbors
command from the Junos
OS CLI:
user@device> show lldp neighbors Local Interface Parent Interface Chassis Id Port info System Name ge-0/0/2 - 00:00:5E:00:53:e1 ETH0 AP43-2 ge-1/0/4 - 00:00:5E:00:53:da ETH0 AP-41-EX-switch
Associate Ports
The last thing to do is to associate the profile you just created with one or more ports on the switch so that only if a recognized device is connected to an appropriate port is the profile be applied.

To add a port configuration:
With the procedures above completed, whenever a new device is connected to a port on the switch that is covered by one of the dynamic port profiles, the profile will read the device’s LLDP, and if it finds a match, automatically apply the associated port properties and network access to the port.
Virtual Chassis
We recommend using Virtual Chassis (VC). With VC, you can combine multiple EX Series Switches so they act as a single logical device with in the Juniper Mist cloud (a Wired Assurance subscription is required for each physical EX Series Switch in your VC deployment). Using VC eliminates the risk of loops, the need for legacy redundancy protocols such as spanning tree and VRRP, and the time required for individual device management. In core/distribution deployments, you can connect to the Virtual Chassis using link aggregation group (LAG) uplinks, which then has the additional benefit of the member switches providing device-level redundancy for the link in case of device failure.

A Virtual Chassis can include from two to ten switches, with each member switch having however many ports. Such a physical configuration can provide better resilience in case one member switch goes down; there are simply more surviving switches available to take up the redistributed load. The trade-off, though, is that those switches require both space and power.
Virtual Chassis for the Juniper Mist cloud is supported for the switches shown in Table 2. The switch model is accompanied by the maximum number of members allowed in the Virtual Chassis.
Switch |
Maximum Members |
---|---|
EX2300 |
4 |
EX3400 |
10 |
EX4300 |
10 |
EX4400 |
10 |
EX4600 |
10 |
EX4650 |
2 |
Design Considerations for Virtual Chassis
We recommend that you physically distribute your Juniper access points across a floor in the network operations center (NOC) so that they connect to multiple switches in a virtual stack. Doing so provides better redundancy and is a more robust design for handling power-supply-related hardware failure.

For example, let’s say you want to deploy a solution that includes 96 ports. The two main options for doing so are:
-
Use two EX4300-48P switches, with one switch serving as the primary and one as backup. The advantages here are a compact footprint and cost effectiveness. The main disadvantage is that the loss of one switch can impact 50 percent of your users.
-
Use four EX4300-24P switches, with one switch serving as the primary, one as backup, and two switches serving as line cards. The advantages here are higher availability (the loss of one switch only affects 25 percent of users), and the fact that uplinks are not affected by a switch failure (provided that the failed switch did not include any uplinks). The main disadvantage is that you need more space, power, and cost to support the equipment.
Regardless of the options you go with, if you do plan to leverage one or more Virtual Chassis in your deployment, we recommend that you configure the primary and backup switches in the Virtual Chassis so that they are in different physical locations in the NOC. The member devices of the Virtual Chassis should be likewise distributed so that no more than half are dependent on the same power supply or other single point of failure, and they should be evenly spaced by a member hop in the Virtual Chassis.
Forming A Virtual Chassis (EX2300 Series Switches)
To form a Virtual Chassis, all member switches need to be the same model and running the same version of Junos OS. You'll need management access to the Juniper Mist portal, and physical access to the switches for cabling.
A Wired Assurance subscription is required for each physical EX Series switch in your VC deployment.

In this procedure, you use the Juniper Mist portal to select the switches you want to form a VC, configure those switches (by setting the role and interface ID), and then making the physical connections. Once you've connected the cables, it takes about 10 to 15 minutes for the VC to form.

As noted, it takes about 10 to 15 minutes for the VC to form after connecting the cables. You'll be notified in the portal once the VC has been formed. Before that, if you select a member switch in the portal, you'll see a message that the VC is forming.
Adding A Switch To The Virtual Chassis
Adding a member switch to a VC follows essentially the same procedure as described in the previous section. You can have the new switch be the primary, the backup, or just another switch in the VC.
The switches must all be the same model and running the same Junos OS version, and you need to make the physical connections after you do the VC settings in the portal. When done, the new VC will finish forming in about three to five minutes.
- In the Switches window of the Juniper Mist portal, select the existing VC. The More button appears, this time with an option to Edit Virtual Chassis.
- Click Edit Virtual Chassis in the drop-down menu.
- In the window that opens, click the Add Switch button and
specify the Port ID of the new member.Figure 15: Adding A Switch To The VC
- Click the Update button to apply your changes.
- You can confirm your changes by clicking the switch name to display the VC
member switches and properties.Figure 16: VC Member Switches
Removing A Switch From The Virtual Chassis
There is no Delete button that will directly remove a member switch from its VC. Instead, the way to remove a switch from its VC is to disconnect the VC cable from each switch. The Juniper Mist portal will then report the status for that switch as "not present" in the VC.
You can then open the Edit Virtual Chassis window, and the click the "trash" icon that appears next to the broken link representing the newly disconnected member VC.
Virtual Chassis on EX3400 and EX4300
Switches in a Virtual Chassis must all be Juniper Mist cloud ready. You will need physical access to the switches for cabling, and management access to both the Junos OS CLI and Juniper Mist portal.

Note that the second switch in the Virtual Chassis is automatically assigned the backup role, and its LED will blink when connected. All remaining switches automatically assume line-card roles, and their MST LEDs will remain dark.

In the process described below, you start with a switch that is available from the Juniper Mist portal. Then you log in to the switch using the Juniper Mist portal and configure its Virtual Chassis interfaces. From there, you make the physical connection from that switch to the next one in the Virtual Chassis group, propagate the relevant settings, and repeat until all the Virtual Chassis members are connected.

When you are finished, the Virtual Chassis will be provisioned for the Juniper Mist cloud and the details of the EX Series swtich cluster will be visible in the Juniper Mist portal.
root@EX3400-VC> show virtual-chassis Virtual Chassis ID: c3d2.5525.cd30 Virtual Chassis Mode: Enabled Mstr Mixed Route Neighbor List Member ID Status Serial No Model prio Role Mode Mode ID Interface 0 (FPC 0) Prsnt NW3619450867 ex3400-24p 128 Master* N VC 1 vcp-255/1/0 1 vcp-255/1/1 1 (FPC 1) Prsnt NW3619451026 ex3400-24p 128 Backup N VC 0 vcp-255/1/0 0 vcp-255/1/1 Member ID for next new member: 2 (FPC 2)