Appendix: Day-0 Plan

Building a Virtual Chassis

Virtual Chassis Overview (Juniper Mist)

The Virtual Chassis technology enables you to connect multiple individual switches together to form one logical unit and to manage them as a single unit. You can configure and manage a Virtual Chassis using the Juniper Mist™ portal. The switches you add to a Virtual Chassis are called members. In a Virtual Chassis setup, Virtual Chassis ports (VCPs) connect the member switches and are responsible for passing the data and control traffic between member switches.

A Virtual Chassis helps you mitigate the risk of loops. It also eliminates the need for legacy redundancy protocols such as spanning-tree protocols (STPs) and Virtual Router Redundancy Protocol (VRRP). In core and distribution deployments, you can connect to the Virtual Chassis using link aggregation group (LAG) uplinks. These uplinks ensure that the member switches in a Virtual Chassis have device-level redundancy.

A Virtual Chassis can include from two to ten switches. Such a physical configuration can provide better resilience if a member switch goes down. One possible disadvantage of combining several switches into a Virtual Chassis is that this configuration requires more space and power than a single device requires.

Link to video: Virtual Chassis Overview

You can create a Virtual Chassis using the Form Virtual Chassis option on the portal. The Form Virtual Chassis option applies only to the EX2300, EX4650, and QFX5120 switches as these switches don't have dedicated Virtual Chassis ports (VCPs). This option is not available to the EX3400, EX4100, EX4100-F, EX4300, EX4400, and EX4600 switches as they come with dedicated VCPs.

Table 1 shows the switch models along with the maximum number of member switches allowed in a Virtual Chassis configuration.

Table 1: Maximum Number of Member Switches Allowed in a Virtual Chassis Configuration

Switch Model	Maximum Number of Members
EX2300	4
EX4650	4
EX3400	10
EX4100	10
EX4100-F	10
EX4300	10
EX4400	10
EX4400-24X	10
EX4600	10
QFX5120-32C,QFX5120-48T, QFX5120-48Y	2
QFX5120-48YM	4
QFX5110	10

Juniper Mist supports only pre-provisioned Virtual Chassis configuration. It doesn't support non-provisioned configuration. The pre-provisioned configuration enables the deterministic control of the roles and member IDs assigned to the member switches when creating and managing a Virtual Chassis. The pre-provisioned configuration distinguishes member switches by associating their serial numbers with the member ID.

For more information, see Virtual Chassis Overview for Switches .

Mixed and Non-Mixed Virtual Chassis

A Virtual Chassis that includes switches of the same model can operate as a non-mixed Virtual Chassis. However, a Virtual Chassis that includes different models of the same switch (for example, two or more types of EX Series switches) must operate in mixed mode because of architecture differences between the different switch models.

Table 2: Supported Combination of Switches in a Mixed-Mode Virtual Chassis

Allowed Routing Engine Members	Allowed Linecard Members
EX4300	EX4300 and EX4600
EX4300-48MP	EX4300-48MP and EX4300 (excludes EX4600)
EX4600	EX4600 and EX4300 (excludes EX4300-48MP)

For more information about the combination of switches that a mixed or a non-mixed Virtual Chassis configuration supports, see Understanding Mixed EX Series and QFX Series Virtual Chassis .

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 Chassis. 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. The member devices of the Virtual Chassis should likewise be 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.

Workflow for VC formation with Mist for EX3400, EX4100, EX4100-F, EX4300, EX4400 & EX4600

Note:

Virtual Chassis formation on EX Series Switches should NOT be done by switching them all on at the same time. Please follow the procedure described below to facilitate primary and backup switch selection.

The EX3400, EX4100, EX4100-F, EX4300, EX4400, and EX4600 switches come with dedicated Virtual Chassis ports (VCPs). You can create Virtual Chassis using these switches by connecting them to each other via VCPs. These switches don't support the Form Virtual Chassis option on the Switches page on the portal. However, once a Virtual Chassis is created with these switches, you can use the Modify Virtual Chassis option on the Switch Details page to modify and manage the Virtual Chassis. The Virtual Chassis workflow for these switches involves the following two steps:

1. Form the Virtual Chassis by connecting the dedicated VCPs between the switches and powering on them using the procedure below.
2. Pre-provision the Virtual Chassis using the Modify Virtual Chassis option on the portal. Mist supports only the pre-provisioned Virtual Chassis configuration. The pre-provisioned configuration specifies the chassis serial number, member ID, and role for both member switches in the Virtual Chassis. When a new member router joins the Virtual Chassis, Junos compares its serial number against the values specified in the pre-provisioned configuration. Pre-provisioning prevents any accidental role assignments, or the accidental addition of a new member to the Virtual Chassis. Each role, member ID, addition, or removal of members, is under the control of the configuration.

Before configuring a Virtual Chassis, ensure the following:

• The switches need to have a direct connection to the Juniper Mist cloud. Ensure that you have an uplink connection directly to the switch.
• All the switches that you want to include in the Virtual Chassis are onboarded to the Juniper Mist cloud and assigned to the same site. To onboard a new switch (greenfield deployment), see “Activating a Greenfield Switch via claim and ZTP-based installation”. To onboard an existing switch (brownfield deployment), see “Activating a Brownfield Switch via Adoption Code-Based Installation”.
• All the switches are running the same Junos software version. If they are not, you can upgrade the switch software using a USB drive locally or using the portal. See Upgrade Junos OS Software on Your Switch .

In addition to Virtual Chassis creation, you can renumber, replace, or add a member to an existing Virtual Chassis, by using the Modify Virtual Chassis option on the Switch Details page. The Modify Virtual Chassis option is available for switches that have configuration management enabled in Mist.

You can configure the Virtual Chassis in mixed mode or non-mixed mode. A Virtual Chassis that includes switches of the same model operates as a non-mixed Virtual Chassis. However, a Virtual Chassis that includes different models of the same switch operates in mixed mode because of architecture differences between the different switch models.

To configure a Virtual Chassis using EX3400, EX4100, EX4100-F, EX4300, EX4400, or EX4600 switches:

1. Power off the switches that you want to include in the Virtual Chassis.
2. Connect the switches to each other using the dedicated VCPs, preferably in a bus topology, as shown in the sample image below. The location of the VCPs will vary depending on the switch models. Do not close the ring topology. We do that after the VC is up. Example with 4 members:
   1. Physically connect VC port 1 on Switch 1 to the VC port 0 on Switch 2. The switch you want to be the backup RE.
   2. Next, physically connect VC port 1 on Switch 2 to VC port 0 on Switch 3. The switch you want to be a linecard.
   3. Next, physically connect VC port 1 on Switch 3 to VC port 0 on Switch 4. The switch you want to be a linecard.
   4. DO NOT connect VC port 1 on Switch 4 to VC port 0 on Switch 1 to close the ring.
   Figure 3: Showing Virtual Chassis Ports
3. Power on Switch 1, which will function in the primary role. This member becomes FPC0.
   Note:

   The order in which you power on devices also determines the member ID. If you prefer to see the Virtual Chassis members on the portal in the same order as they are physically stacked, you need to power them on and then connect them in that order.

4. Approximately three minutes after powering on Switch 1 that you selected for the primary role, power on Switch 2 that you want to function in the backup role. This member will become FPC1.
5. Wait for approximately three minutes, and then boot up the rest of the switches (Switch 3 and Switch 4 in our case) that you want to function in the linecard role.
6. Wait for the MST LED on the primary and backup switches to come up. The LED appears solid on the primary switch. On the backup switch, the LED stays in a blinking state.
   Figure 4: Showing MST LED

   On linecards, the SYS and SPD LEDs will be solid GREEN and the MST LED will be off.

7. Close the VC ring now, and physically connect VC port 1 on Switch 4 to VC port 0 on Switch 1.
   Figure 5: Cabling Virtual Chassis Ports

   A Virtual Chassis is now physically formed but not pre-provisioned.

8. Connect the Virtual Chassis to the Juniper Mist cloud by connecting the uplink port on the primary switch to the upstream switch. This step initiates a zero-touch provisioning (ZTP) process on the Virtual Chassis and connects it to the Juniper Mist cloud.
9. Next, wait about 10 minutes for the ZTP and configuration push from the cloud and Mist UI to show the 4-member VC stack. You can verify by checking Switch Insights and Switch UI as shown in the below screenshots:
10. Click Switches > Switch Name to go to the Virtual Chassis page (the Switch Details page) to verify the details.
    Note:

    The pre-provision procedure described below is optional when you have followed the suggested VC bus topology during initial onboarding and the order of powering on of each switch to select its role. However, it is recommended to review it in case you made an error or want to change the port configuration before bringing the Virtual Chassis into production.

11. After the Virtual Chassis is connected to the Juniper Mist cloud, pre-provision it. Pre-provisioning allows users to define the roles and renumber appropriately. To pre-provision the Virtual Chassis, follow the steps below:

    1. On the Switch Details page, click Modify Virtual Chassis. The Modify Virtual Chassis page appears.

    2. On the Modify Virtual Chassis page, click Update. See a sample Modify Virtual Chassis page below:

       

This step pushes the pre-provisioned Virtual Chassis configuration to the device and overwrites the old auto-provision Virtual Chassis configuration on the device (if needed). This option assumes the current positioning of the members and pre-provisions them as is. Optionally, you can use Remote Shell as pictured below to check:

Note:

If you make any changes on the Modify Virtual Chassis page, such as moving the members around or adding or removing members, the Pre-provision Virtual Chassis button is disabled and the Update button is enabled. If this is the case, click the Update button to apply the changes made and pre-provision the Virtual Chassis.

All configurations are pushed instantly after you pre-provision the Virtual Chassis. The statistics could take up to 15 minutes to appear on the Mist dashboard.

Workflow for Virtual Chassis Formation with Mist for EX2300, EX4650 and QFX5120

Note:

Virtual Chassis formation on the following EX Series Switches cannot be executed without pre-provisioning. You may need to enable this in a lab or staging environment where you have proper access to the Mist cloud managing the devices so that they appear on the Inventory page. This must be done before you can execute the Virtual Chassis formation explained below.

The Juniper Networks EX2300, EX4650, and QFX5120 switches do not form a Virtual Chassis by default, as these switches don’t have dedicated Virtual Chassis ports (VCPs). Therefore, to create a Virtual Chassis with these switches, you need to use the Form Virtual Chassis option on the portal. The Form Virtual Chassis option applies only to the EX2300, EX4650, and QFX5120 switches. This workflow creates a pre-provisioned Virtual Chassis configuration. Mist supports only the pre-provisioned Virtual Chassis configuration.

Before configuring a Virtual Chassis, ensure the following:

• The switches need to have a direct connection to the Juniper Mist cloud. Ensure that you have an uplink connection directly to the switch.
• All the switches that you want to include in the Virtual Chassis are onboarded to the Juniper Mist cloud and assigned to the same site. To onboard a new switch (greenfield deployment), see “Activating a Greenfield Switch via claim and ZTP-based installation”. To onboard an existing switch (brownfield deployment), see “Activating a Brownfield Switch via Adoption Code-Based Installation”.
• All the switches are running the same Junos software version. If they are not, you can upgrade the switch software using a USB drive locally or using the portal. See Upgrade Junos OS Software on Your Switch .

The following steps assume that the pre-provisioning phase has already happened. To configure a Virtual Chassis using EX2300, EX4650, or QFX5120 switches:

1. Click the Switches tab on the left to navigate to the Switches page.
2. Select the switches that you want to include in the Virtual Chassis. An EX2300 switch variant can form a Virtual Chassis with any EX2300 switch variants. An EX4650 variant switch can form a Virtual Chassis with any EX4650 switch variants. A QFX5120 switch variant can form a Virtual Chassis only with the same QFX5120 switch variant. Therefore, the Form Virtual Chassis option is available only if you select the right switch models for a Virtual Chassis.
3. Click More > Form Virtual Chassis.

   

   Note:

   You can see the Form Virtual Chassis option only if:

   • The selected switches are running the same Junos version and have the configuration management option enabled.
   • All the selected switch models are supported by the Virtual Chassis.
4. You can also create a Virtual Chassis from the Switch Details page by using the Utilities > Form Virtual Chassis option. The Form Virtual Chassis window appears, as shown in the following screenshot:

   

5. On the Form Virtual Chassis window, specify the following:
   1. Port IDs for the switches. These are IDs for the Virtual Chassis ports (VCPs). This window displays all the switches you selected from the Switches page.
   2. The Primary switch. The switch that you selected first is the primary switch by default. You can modify that.
   3. The Backup switch. This configuration is optional. If you don't select a switch to function as another Routing engine, Mist assigns the linecard role to that switch.
   4. Ensure that you have an uplink connection directly to the primary switch.
6. Click Form Virtual Chassis and wait 3 to 5 minutes for the Virtual Chassis to be created.

   1. The switches page shows a message indicating that you must connect the switches to each other using the VCPs:

      

7. Connect the switches to each other using the VCPs configured.

   1. When the Virtual Chassis formation is in progress, the Switches page shows the switch status as VC forming.

      

8. After the Virtual Chassis formation is successful, the Switches page displays only one entry for the Virtual Chassis with the name of the primary switch. However, the Mist APs column displays one AP for each Virtual Chassis member in a comma-separated format.

   

9. The Switch Details page displays the front panel of all the Virtual Chassis members:

   

10. You can use the Modify Virtual Chassis option on the Switch Details page to renumber and replace Virtual Chassis members and add members to a Virtual Chassis connected to the Juniper Mist cloud. For more information, see Manage a Virtual Chassis Using Mist (Add, Delete, Replace, and Modify Members) .

Workflow for VC formation with Mist for EX4400-24X

Note:

Virtual Chassis formation on the following EX Series Switches cannot be executed without pre-provisioning. You may need to enable this in a lab or staging environment where you have proper access to the Mist cloud managing the devices so that they appear on the Inventory page. For EX4400-24X switches, plan to have serial console access when pre-provisioning the Virtual Chassis.

1. Unbox and power on the EX4400-24X switches.
2. Cloud reachability - Connect the 10GbE front panel ports or plug in a relevant uplink module on the EX4400-24X from each member of the Virtual Chassis to each of the upstream device(s) such as the WAN router and make sure the links come up as connected and able to reach Juniper Mist cloud.
3. Onboard the switch on the Mist Dashboard:
   1. Claim method (Preferred): Please review the chapter “Activating a Greenfield Switch via claim and ZTP-based installation” below using QR-Code and Mist App / Mist dashboard.
   2. Adopt method: Please review the chapter “Activating a Brownfield Switch via Adoption Code-Based Installation” below.
4. When using the claim method, the devices should appear in the Inventory of the Juniper Mist cloud automatically as part of the process. Using the adopt method, the switches may appear immediately or after the Virtual Chassis has been formed.

5. The steps below detail forming a Virtual Chassis from the two EX4400-24X switches as an example:

   Connect the Virtual Chassis ports (VCPs) on EX4400-24X using DAC Cables – 40G/100G. The Virtual Chassis ports are located on the front-panel on the EX4400-24X (as indicated in the below figure) and only support the HGoE protocol for Virtual Chassis formation.

   

6. Using either Remote Console or a serial console cable connected directly to the first switch that will become the primary switch of your Virtual Chassis, login to the Junos CLI by entering the following command:

   1. See an example in the below figure. This CLI needed to convert the 2 front panel ports on the EX4400-24X switches from network ports to VCPs to enable Virtual Chassis formation.

      

   2. Make sure the switch reboots now.

7. Repeat the command on your backup switch followed by a reboot. Also repeat the command and reboot on any optional linecard switches.
8. Once the devices come up after the reboot, they should be in Virtual Chassis mode and seen as a single device on the Mist dashboard:

   

9. OPTIONAL: Check the Virtual Chassis state via Remote Shell as shown in the figure below:

   

Day 0 Adding an EX Series Switch to the Juniper Mist Cloud

How does an EX Series Switch connect to the Juniper Mist Cloud to get managed?

When an EX Series Switch must be managed by the Juniper Mist cloud, it must have a way to exchange data with the nearest reachable Juniper Mist cloud. You can’t use an EX Series Switch in air-gapped environments that do not provide Internet access. Should there be a firewall between the EX Series Switch and the Juniper Mist cloud, please check the link in your Mist account for “Ports & Endpoints” to configure the firewall to allow this traffic.

To avoid needing to use a console connection to pre-stage the device to apply a configuration, the switch should get a DHCP lease from the local network like any other wired or wireless client. Typically, the local WAN router runs a DHCP server configured to provide DHCP leases and access towards the Juniper Mist cloud for the attached switch.

Below, we show the factory default configuration that is expected to be on the switch when powering it on for the first time.

This factory default configuration allows the switch to obtain a DHCP lease from various interfaces, install a default route and try to get managed from the Juniper Mist Cloud by starting to send traffic to it. The switch always tries to call out to the Juniper Mist cloud as it is assumed source NAT is applied on the path to the cloud somewhere in the network.

With the default DHCP lease obtained, the switch is managed by two major methods of operation:

• The DHCP lease can be obtained by the dedicated out-of-band management port (may be labeled differently on the QFX Series and EX9200 line of Switches). This port is referred to as “me0” in Junos and the DHCP lease will be assigned to the virtual interface called “vme” (it’s referred to as “fxp0” on the EX9200 line of Switches). The usage of dedicated out-of-band management ports is designed for and typically used by campus fabric setups.
• The DHCP lease can be obtained by any regular revenue port on the switch. The factory-default configuration configures a native default VLAN on all revenue ports and maps that VLAN into the integrated routing and bridging (IRB) interface called “irb.0”. The DHCP lease is then assigned to this virtual interface. All other VLANs are assumed to use the same interface as trunked VLANs with IEEE 802.1q tags assigned. This in-band management method is very popular in branch deployments as you do not need extra cables just to manage the switch itself. Instead, you multiplex the upstream traffic into the same link and separate by means of regular VLANs.

A standalone switch for the recommended in-band management method can be attached to the WAN router via:

• A single link which is not redundant. The native VLAN over which the switch is managed from the Juniper Mist cloud is there as an initial link where the WAN router side might just be an access VLAN when starting. Over time you can change the two sides without losing the ability to manage the switch as long as you have a VLAN natively configured that continues to have the managed switch providing connection towards the Juniper Mist cloud.

  Multiple links that are redundant. It’s assumed in this case that both sides are able to configure IEEE 802.ad link aggregation and active LACP to detect outages of any configured link. As the link aggregation is not configured initially on the EX Series Switch you must first ensure that it is able to get a successful connection towards the Juniper Mist cloud and then reconfigure the links as a LAG with active LACP. There are multiple options of how you can achieve this which are explained in the next chapter “Best practices when using Link Aggregation on the uplink Interfaces”.

  Figure 6: Switch In-Band Management

For a Virtual Chassis using in-band management, the recommendation is not using any single link (even if technically possible) and instead use multiple Links forming a LAG with active LACP enabled. The recommendation is to have each uplink on a different member of the Virtual Chassis as shown below. As the link aggregation is not configured initially on the virtual chassis you must first ensure that it is able to get a successful connection towards the Juniper Mist cloud and then reconfigure the links as a LAG with active LACP. There are multiple options of how you can achieve this which are explained in the next chapter Best practices when using Link Aggregation on the uplink Interfaces .

Even though it is seldom used at the branch, one may still use out-of-band management. Here, we assume for cost reasons that a branch has an out-of-band management network set up only inside a single branch and not stretched across multiple branches.

A standalone switch, when using the out-of-band management method, can be attached to the WAN router via the switch’s dedicated management port. The WAN router then must provide the DHCP lease (one for each standalone switch, and one for each virtual chassis). Once the lease is obtained, the EX Series Switch can connect to the Juniper Mist cloud via the Internet and get managed by Mist. You have the same choice in terms of uplink to the WAN router:

• A single link which is not redundant. The management port is always configured as an access VLAN and the WAN router’s port configuration does not change over time. Hence, you are free to configure the uplink at any time between the WAN router and EX Series Switch without the fear of losing the ability to manage the switch.

  Multiple links that are redundant. It’s assumed in this case that both sides are able to configure IEEE 802.ad link aggregation and active LACP to detect outages of any configured link. The management port is always configured as an access VLAN and the WAN router’s port configuration does not change over time. Hence, you are free to configure the uplink at any time between the WAN router and EX Series Switch without the fear of losing the ability to manage the switch.

  Figure 8: Switch Out-of-Band Management

For a Virtual Chassis using in-band management, the recommendation is not using any single link (even if technically possible) and instead use multiple Links forming a LAG with active LACP enabled. The difference between a Virtual Chassis and a standalone switch is that only one DHCP lease is consumed for the entire Virtual Chassis even if it has up to 10 members. To achieve this, the DHCP lease that is configured on the virtual “vme” interface can float between the Primary and Backup switches of a Virtual Chassis. A linecard switch of a Virtual Chassis will not get a DHCP lease.

When using the switch management port to perform out-of-band management, the physical port is referred to as “me0” and a virtual port named “vme” will get the DHCP lease to be able to connect to the Juniper Mist cloud as shown below.

Independent of whichever method of managing the switch you are using, it is assumed that the DHCP lease also contains a DNS server assignment. Hence, ICMP pings using DNS resolution like the one shown below are expected to work.

Best practices when using Link Aggregation on the uplink Interfaces

When building a LAG between an EX Series Switch as a standalone or Virtual Chassis, you achieve two abilities:

• You have redundancy of the links. Hence, if one or more links fail, you still have links in the interface bundle that remain uninterrupted.
• You achieve more throughput when you have more than a single flow as the flows can be multiplexed among all links in the bundle. The exact method of operation is withdrawn from discussion here as it depends on individual configuration.

To achieve the best in redundancy and more throughput we assume both sides support:

• Link aggregation according to IEEE 802.3ad.
• Dead link detection when both sides have configured active LACP on each link in the bundle. Simply configuring a LAG without using LACP and then hoping that a dead link detected by the physical layer being down is not sufficient. Example: If the LAG consists of a pair of fiber optic links and only one link breaks, then one side will still see a physically “up” link and not notice the link is no longer bi-directional. A protocol like LACP constantly checking each link presence is the better choice. It also helps triggering a rebalance of the ECMP balance algorithm on a topology change.

This isn’t a concern when using out-of-band management since the LAG link setup is independent from the device management connection to the Juniper Mist cloud. However, when using in-band management, you need to avoid losing the management connection to the switch when forming the LAG between the WAN router and the EX Series Switch. This is because when configuring active LACP for a particular side, there will be no communication on that link before the remote side has configured active LACP and exchanged LACP packets to unblock this link for communication. This leads to a kind of chicken and egg problem between the WAN router and attached EX Series Switch. You cannot have one side activating active LACP on the bundle without losing the other side. To overcome this problem, you have the following options:

• The recommended method is: Some devices (like the Juniper Networks® SRX Series Firewalls) support special features like the so called “force-up” feature. This relaxes the strict active LACP checking on one link of the WAN router’s bundle. Hence, the EX Series Switch can use this link to communicate with the Juniper Mist cloud before the LAG is formed on both sides. The following describes the workflow to set this up:
  • FIRST: On the WAN router, configure the entire LAG bundle with all member links. One member link is configured with the “force-up” feature.
  • SECOND: The EX Series Switch attach comes up initially. Communication to the Juniper Mist cloud will only be possible over the WAN router link which has the force-up option set.
  • THIRD: Now you can configure the LAG bundle on the EX Series Switch with all members included. As the WAN router already has a valid configuration the entire LAG between the two should automatically come up.
  • FOURTH: Once both sides have built the LAG with active LACP running on all member links, you can remove the “force-up” feature on the WAN router side.
• If such a “force-up” feature or similar is not supported by the WAN router, then consider the next method when building the LAG:
  • FIRST: Configure the link bundle excluding one link on the EX Series Switch and let the Juniper Mist cloud push the configuration.
  • SECOND: Configure the link bundle excluding one opposite link on the WAN router and apply the configuration.
  • THIRD: Both devices should now build a LAG link with active LACP on both sides, still communication should remain on the single untouched link between the two.
  • FOURTH: Now you can update the LAG bundle on the EX Series Switch with all members included. Device management is expected to now failover to the LAG bundle and continue.
  • FIFTH: You can update the LAG bundle on the WAN router with all members included to reach the final state.
• The last alternative method is to pre-stage the LAG configuration on the EX Series Switch. This will ensure the needed configuration is already there and the device is already known to the Juniper Mist cloud.
  • Pre-stage the device in a lab or staging environment before shipping it onsite. You may also use this opportunity to refresh the Junos firmware on the device.
  • While onsite with proper instructions to the person performing the installation, consider doing out-of-band management for a short while until the LAG is configured.

The figure below shows the example configuration on SRX as a WAN router utilizing the recommended “force-up” feature.

Note:

The methods that have been presented here for connecting a WAN router and a directly connected EX Series Switch works the same in respect to a larger topology with distribution and access switches. It can be used when you build the connection between the WAN router and distribution switch and then start deploying the access switches. The “force-up” feature is available on EX Series Switches so you can use it on the distribution switches when configuring the downlinks to the access switches.

Overview of the Zero Touch Provisioning (ZTP) Process

Note:

The Zero Touch Provisioning (ZTP) process described here is not to be mistaken with an older ZTP method that is described in documentation and that is also supported. That method always needs a local DHCP server that delivers special DHCP attributes within the DHCP lease to the local EX Series Switch to inform the switch where to fetch the initial configuration and other items (usually via TFTP). The ZTP method described here is free of such constraints. The local DHCP server just needs to provide regular IP address, gateway and DNS server information like that provided for any other wired or wireless client.

Once a cloud-ready switch is connected to the internet and powered on for the first time, it triggers an onboard phone-home client (PHC) to get configuration updates from the phone-home server (PHS) as shown in Figure 2. The default behavior is for the PHC to connect to a redirect server, which then redirects it to a phone home server where the switch can get the configuration or software image. This enables the switch to obtain the most recent Junos configuration or software image securely and automatically, with no intervention other than physically connecting the switch to the network. Alternatively, you can configure the switch to use a DHCP server configured with the necessary ZTP options to complete the ZTP process. To revert to the ZTP default, you need to boot from factory default state (or you can issue the Junos request system zeroize command to reset the configuration).

Juniper ZTP follows IETF RFC 8071 as a standards-based method. The switch must be “cloud-ready” to be able to perform this operation out of the Box without any additional pre-configuration needed. The Juniper Networks® Cloud-Ready Switches come ready to install and manage using the portal at https://manage.mist.com .Your switch is cloud-ready if it has a QR claim code on the front or back panel.

Note:

The onboarding procedures described in this guide apply only to cloud-ready EX and QFX switches. See Juniper Mist Supported Hardware for a list of cloud-ready EX and QFX switches.

Design a Switch Template

A key feature of switch management through the Juniper Mist cloud 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, site, and switch) provides both scale and granularity.

What templates, and the hierarchical model, means in practice is that you can create a template configuration and then apply those settings to all the devices in each group. When a conflict occurs, for example when there are settings at both the site and organizational levels that apply to the same device, the narrower settings (in this case, the site hierarchy) 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 site level. Of course, individual switches can also have their own unique configurations.

You can include individual CLI commands at any level of the hierarchy, which 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).

We recommend that all switches in an organization be managed exclusively through the Juniper Mist cloud, and not from the device’s CLI.

The process of configuring a switch with Juniper Mist™ Wired Assurance involves two main steps: creating a switch configuration template and applying it to one or multiple sites. The configuration settings linked to a particular site will be applied to the switches within that site. This allows you to manage and apply consistent and standardized configurations across your network infrastructure, making the configuration process more efficient and streamlined.

For a quick overview of switch templates, watch the following video .

To configure a switch, you need to have a Super User role assigned to you. This role grants you the necessary permissions to make changes and customize the switch settings. Other Roles may just allow you to change a port or only to review a configuration without the ability to change it.

Create a Switch Configuration Template

Switch configuration templates make it easy to apply the same settings to switches across your sites. Whether it's one site or multiple sites, you can use the template to quickly configure new switches. When you assign a switch to a site, it automatically adopts the configuration from the associated template.

Note:

Configuration done on the switch through the Mist dashboard overrides any configuration done through the device CLI. The switch details page doesn’t display any configuration changes you make directly on the switch through the switch CLI.

To create a switch configuration template:

1. Open the portal and click Organization > Switch Templates.
2. Click Create Template, enter a name for the template in the Template Name field, and then click Create. The Switch Templates: <Template Name> page appears.
   Note:

   You have the flexibility to import the template settings in a JSON file instead of manually entering the information. To import the settings, click Import Template. To get a JSON file with the configuration settings that can be customized and imported, open an existing configuration template of your choice, and click Export.

3. In the All Switches configuration section, configure basic settings for the switches. Use the tips on the screen to configure the settings.

   

   Table 3: All Switch Configuration Field Descriptions

   Field	Description
   RADIUS	Choose an authentication server for validating usernames and passwords, certificates, or other authentication factors provided by users. Mist Auth—Select this option if you want to configure Juniper Mist Access Assurance, a cloud-based authentication service from Mist, on your switch. For this option to work, you also need to use a port with dot1x or MAB authentication. Note: Mist Auth on wired switches requires Junos 20.4R3-S7 or above, 22.3R3 or above, 22.4R2 or above, or 23.1R1 or above. To configure Mist Access Assurance features such as authentication policies, policy label, certificates, and identity providers, navigate to Organization > Access. RADIUS—Select this option to configure a RADIUS authentication server and an accounting server, for enabling dot1x port authentication at the switch level. For the dot1x port authentication to work, you also need to create a port profile that uses dot1x authentication, and you must assign that profile to a port on the switch.The default port numbers are: port 1812 for the authentication server port 1813 for the accounting server Note: If you want to set up dot1x authentication for switch management access (for the switch CLI login), you need to include the following CLI commands in the Additional CLI Commands section in the template: set system authentication-order radius set system radius-server <radius-server-IP> port 1812 set system radius-server <radius-server-IP> secret <secret-code> set system radius-server <radius-server-IP> source-address <radius-Source-IP>
   TACACS+	Configure TACACS+ for centralized user authentication on network devices. Additionally, you can enable TACACS+ accounting on the device to gather statistical data about user logins and logouts on a LAN, and send this data to a TACACS+ accounting server. The port range supported for TACACS+ and accounting servers is 1 to 65535.
   NTP	Specify the IP address or hostname of the Network Time Protocol (NTP) server. NTP is used to synchronize the clocks of the switch and other hardware devices on the Internet.
   DNS SETTINGS	Configure the domain name server (DNS) settings. You can configure up to three DNS IP addresses and suffixes in comma separated format.
   SNMP	Configure Simple Network Management Protocol (SNMP) on the switch to support network management and monitoring. You can configure the SNMPv2 or SNMPv3. Here are the SNMP options that you can configure: Options under SNMPv2 (V2) General—Specify the system's name, location, administrative contact information, and a brief description of the managed system. When using SNMPv2, you have the option to specify the source address for SNMP trap packets sent by the device. If you don't specify a source address, the address of the outgoing interface is used by default. Client—Define a list of SNMP clients. You can add multiple client lists. This configuration includes a name for the client list and IP addresses of the clients (in comma separated format). Each client list can have multiple clients. A client is a prefix with /32 mask. Trap Group—Create a named group of hosts to receive the specified trap notifications. At least one trap group must be configured for SNMP traps to be sent. The configuration includes the following fields: Group Name—Specify a name for the trap group. Categories—Choose from the following list of categories. You can select multiple values as there are: authentication, chassis, configuration, link, remote-operations, routing, services, startup and vrrp-events Targets—Specify the target IP addresses. You can specify multiple targets. Version—Specify the version number of SNMP traps. Community—Define an SNMP community. An SNMP community is used to authorize SNMP clients by their source IP address. It also determines the accessibility and permissions (read-only or read-write) for specific MIB objects defined in a view. You can include a client list, authorization information, and a view in the community configuration. View (Applicable to both SNMPv2 and SNMPv3)—Define a MIB view to identify a group of MIB objects. Each object in the view shares a common object identifier (OID) prefix. MIB views allow an agent to have more control over access to specific branches and objects within its MIB tree. A view is made up of a name and a collection of SNMP OIDs, which can be explicitly included or excluded. Options under SNMPv3 (V3) General—Specify the system's name, location, administrative contact information, and a brief description of the managed system. When using SNMPv2, configure an engine ID, which serves as a unique identifier for SNMPv3 entities. USM—Configure the user-based security model (USM) settings. This configuration includes a username, authentication type, and an encryption type. You can configure a local engine or a remote engine for USM. If you select a remote engine, specify an engine identifier in hexadecimal format. This ID is used to compute the security digest for authenticating and encrypting packets sent to a user on the remote host. If you specify the Local Engine option, the engine ID specified on the General tab is considered. If no engine ID is specified, local mist is configured as the default value. VACM—Define a view-based access control model (VACM). A VACM lets you set access privileges for a group. You can control access by filtering the MIB objects available for read, write, and notify operations using a predefined view (you must define the required views first from the Views tab). Each view can be associated with a specific security model (v1, v2c, or usm) and security level (authenticated, privacy, or none). You can also apply security settings (you have the option to use already defined USM settings here) to the access group from the Security to Group settings. Notify—Select SNMPv3 management targets for notifications, and specify the notification type. To configure this, assign a name to the notification, choose the targets or tags that should receive the notifications, and indicate whether it should be a trap (unconfirmed) or an inform (confirmed) notification. Target—Configure the message processing and security parameters for sending notifications to a particular management target. You can also specify the target IP address here. View (Applicable to both SNMPv2 and SNMPv3)—Define a MIB view to identify a group of MIB objects. Each object in the view shares a common object identifier (OID) prefix. MIB views allow an agent to have more control over access to specific branches and objects within its MIB tree. A view is made up of a name and a collection of SNMP OIDs, which can be explicitly included or excluded.
   STATIC ROUTE	Configure static routes. The switch uses static routes when: It doesn't have a route with a better (lower) preference value. It can't determine the route to a destination. It needs to forward packets that can't be routed. Types of static routes supported: Subnet—Includes the IP addresses for the destination network and the next hop. Network—Includes a VLAN (containing a VLAN ID and a subnet) and the next hop IP address.
   CLI CONFIGURATION	For any additional settings that are not available in the template's GUI, you can still configure them using set CLI commands. For instance, you can set up a custom login message to display a warning to users, advising them not to make any CLI changes directly on the switch. Here's an example of how you can do it: set system login message "\n\n Warning! This switch is managed by Mist. Do not make any CLI changes." To delete a CLI command that was already added, use the delete command, as shown in the following example: delete system login message "\n\n Warning! This switch is managed by Mist. Do not make any CLI changes." Note: Ensure that you enter the complete CLI command for the configuration to be successful.
   OSPF AREAS	Define an Open Shortest Path First (OSPF) area, if required. OSPF is a link-state routing protocol used to determine the best path for forwarding IP packets within an IP network. OSPF divides a network into areas to improve scalability and control the flow of routing information.
   DHCP SNOOPING	Enable the DHCP snooping option to monitor DHCP messages from untrusted devices connected to the switch. DHCP snooping creates a database to keep track of these messages. This helps prevent the acceptance of DHCPOFFER packets on untrusted ports, assuming they originate from unauthorized DHCP servers. DHCP configuration has the following options: All Networks— Select the All Networks check box to enable DHCP snooping on all VLANs. Networks—If you want to enable DHCP snooping only on specific networks, click Add (+) in the Networks box and add the required VLANs. Address Resolution Protocol (ARP) Inspection—Enable this feature to block any man-in-the-middle attacks. ARP Inspection examines the source MAC address in ARP packets received on untrusted ports. It validates the address against the DHCP snooping database. If the source MAC address does not have a matching entry (IP-MAC binding) in the database, it drops the packets. You can check ARP statistics by using the following CLI commands: show dhcp-security arp inspection statistics , and show log messages | match DAI . The device logs the number of invalid ARP packets that it receives on each interface, along with the sender’s IP and MAC addresses. You can use these log messages to discover ARP spoofing on the network. IP Source Guard—IP source guard validates the source IP and MAC addresses received on untrusted ports against entries in the DHCP snooping database. If the source addresses do not have matching entries in the database, IP Source Guard discards the packet. Note: IP Source Guard works only with single-supplicant 802.1X user authentication mode. If you have a DHCP server connected to an untrusted access port, DHCP won't function properly. In such cases, you may need to make adjustments to ensure that DHCP works as intended. By default, DHCP considers all trunk ports as trusted and all access ports as untrusted. You need to enable VLAN on the switch for the DHCP snooping configuration to take effect. So, you need to apply port profiles (described later in this document) to the ports. A device with a static IP address might not have a matching MAC-IP binding in the DHCP snooping database, if you have connected the device to an untrusted port on the switch. To check the DHCP snooping database on your switch and view the bindings, use the CLI command show dhcp-security binding. This command will provide you with information about the DHCP bindings recorded in the snooping database. Note: You need to enable this feature if you want to view the DHCP issues for the switch under the Successful Connect SLE metric.
   SYSLOG	Configure SYSLOG settings to set up how system log messages are handled. You can configure settings to send the system log messages to files, remote destinations, user terminals, or to the system console. Here are the configuration options available for SYSLOG settings: Files—Send log messages to a named file. Hosts—Send log messages to a remote location. This could be an IP address or hostname of a device that will be notified whenever those log messages are generated. Users—Notify a specific user of the log event. Console—Send log messages of a specified class and severity to the console. Log messages include priority information, which provides details about the facility and severity levels of the log messages. Archive—Define parameters for archiving log messages. General—Specify general information such as a time format, routing instance, and source address for the log messages.
   PORT MIRRORING	Configure port mirroring. Port mirroring is the ability of a router to send a copy of a packet to an external host address or a packet analyzer for analysis. In the port mirroring configuration, you can specify the following: Input: The source (an interface or network) of the traffic to be monitored. Along with the input, you can specify whether you want Mist to monitor the ingress traffic or the egress traffic for an interface. If you want both ingress and egress traffic to be monitored, add two input entries for the same interface - one with the ingress flag and the other with the egress flag. Output: The destination interface to which you want to mirror the traffic. You cannot specify the same interface or network in both the input and output fields.

4. In the Management section of the Switch Template Configuration page, configure the following:
   1. Configuration Revert Timer—This feature helps restore connectivity between a switch and the Mist cloud if a configuration change causes the switch to lose connection. It automatically reverts the changes made by a user and reconnects to the cloud within a specified time duration. By default, this time duration is set to 10 minutes for EX Series switches. You can specify a different time duration here.
   2. Root password—A plain-text password for the root-level user (whose username is root).
   3. Protection of Routing Engine—Enable this feature to ensure that the Routing Engine accepts traffic only from trusted systems. This configuration creates a stateless firewall filter that discards all traffic destined for the Routing Engine, except SSH and BGP protocol packets from specified trusted sources.
5. In the Shared Elements section, configure the following:
   1. In the Networks tile, click Add Network and configure the VLANs to be used in the port profiles. The settings include a Name, VLAN ID, and a Subnet.
   2. In the Port Profiles tile, choose a predefined port profile or click Add Profile to create a new profile and assign a network to it. Port profiles provide a way to automate provisioning of multiple switch interfaces. Use the tips on the screen to configure the port profile settings.

      Table 4 for tips about key fields in the port profile. Note: This table does not include basic fields such as Name, Enabled, Disabled, Description, and so on.

      Table 4: Tips for Key Fields in the Port Profile

      Field	Description
      Mode	Trunk—Trunk interfaces typically connect to other switches, APs, and routers on the LAN. In this mode, the interface can be in multiple VLANs and can multiplex traffic between different VLANs. Specify the Port Network, VoIP Network (if applicable), and Trunk Networks. Access—Default mode. Access interfaces typically connect to network devices, such as PCs, printers, IP phones, and IP cameras. In this mode, the interface can be in a single VLAN only. Specify the Port Network and the VoIP Network (if applicable).
      Use dot1x authentication	Select this option to enable IEEE 802.1X authentication for Port-Based Network Access Control. 802.1X authentication is supported on interfaces that are members of private VLANs (PVLANs). The following options are available if you enable dot1x authentication on a port: Allow Multiple Supplicants—Select this option to allow multiple end devices to connect to the port. Each device is authenticated individually. Dynamic VLAN—Specify dynamic VLANs that will be returned by the RADIUS server attribute 'tunnel-private-group-ID' or 'Egress-VLAN-Name'. This configuration enables a port to perform dynamic VLAN assignment. MAC authentication—Select this option to enable MAC authentication for the port. When this option is selected, you can also specify an Authentication Protocol. If you specify a protocol, it must be used by supplicants to provide authentication credentials. Use Guest Network—Select this option to use a guest network for authentication. Then select a Guest Network from the drop-down list. Bypass authentication when server is down—If you select this option, clients can join the network without authentication if the server is down. You need to also do the following for dot1x authentication to work: Configure a RADIUS server for dot1x authentication from the Authentication Servers tile in the All Switches Configuration section of the template. Assign a dot1x port profile to a switch port for the RADIUS configuration to be pushed to the switch. You can do this from the Port Config tab in the Select Switches Configuration section of the template.
      MAC Limit	Configure the maximum number of MAC addresses that can be dynamically learned by an interface. When the interface exceeds the configured MAC limit, it drops the frames. A MAC limit also results in a log entry. The default value: 0 Supported range: 0 through 16383
      PoE	Enable the port to support power over Ethernet (PoE).
      STP Edge	Configure the port as a Spanning Tree Protocol (STP) edge port, if you want to enable Bridge Protocol Data Unit (BPDU) guard on a port. This setting ensures that the port is treated as an edge port and guards against the reception of BPDUs, which are control messages in the STP. If you plug a non-edge device into a port configured with STP Edge, the port is disabled. In addition, the Switch Insights page generates a Port BPDU Blocked event. The Front Panel on the Switch Details will also display a BPDU Error for this port. You can clear the port of the BPDU error by selecting the port on the Front Panel and then clicking Clear BPDU Errors. You can also configure STP Edge at the switch level, from the Port Profile section on the switch details page.
      QoS	Enable Quality of Service (QoS) for the port to prioritize latency-sensitive traffic, such as voice, over other traffic on a port. Note: For optimal results, it's important to enable Quality of Service (QoS) for both the downstream (incoming) and upstream (outgoing) traffic. This ensures that the network can effectively prioritize and manage traffic in both directions, leading to improved performance and better overall quality of service. You have the option to override the QoS configuration on the WLAN settings page (Site > WLANs > <WLAN name>). To override the QoS configuration, select the Override QoS check box and choose a wireless access class. The downstream traffic (AP > client) gets marked with the override access class value specified. The override configuration doesn't support upstream traffic (client > AP).
      Storm Control	Enable storm control to monitor traffic levels and automatically drop broadcast, multicast, and unknown unicast packets when the traffic exceeds a traffic level (specified in percentage). This specified traffic level is known as the storm control level. This feature actively prevents packet proliferation and maintains the performance of the LAN. When you enable Storm Control, you can also choose to exclude broadcast, multicast, and unknown unicast packets from monitoring.
      Persistent (Sticky) MAC Learning	Enable Persistent (Sticky) MAC to stop unauthorized devices from connecting to your network. When enabled, the switch learns the MAC addresses of devices that arrive on the port and saves them in memory. If the number of MAC addresses learned exceeds the 'MAC Limit' specified above, the port drops the frames. Also, you will see a 'MAC Limit Exceeded' event on the Insights page. You can hover over the port from the front panel on the switch details page to see the MAC Limit and the MAC Count (the number of MAC addresses that the port learned dynamically). Note: You cannot enable this feature on a Trunk port or on a port with 802.1X authentication, as Junos OS does not support this combination. Enable this feature for static wired clients. Do not enable it for Juniper AP interfaces. The portal does not show the MAC addresses that an interface has learned. It shows only the maximum MAC address count. To view the MAC addresses that an interface learned, select the Utilities > Remote Shell option on the switch details page and run the following commands: show ethernet-switching table persistent-learning show ethernet-switching table persistent-learning interface The MAC Count value remains on the port until you clear it from the front panel on the switch details or until you disable the Persistent (Sticky) MAC Learning feature. To clear the MAC addresses that a port learned, select the port on the switch front panel and then click Clear MAC [Dynamic/Persistent]. This action generates a MAC Limit Reset event on the Switch Insights page.

   3. In the VRF tile, configure Virtual Routing and Forwarding (VRF).
   4. With VRF, you can divide an EX Series switch into multiple virtual routing instances, effectively isolating the traffic within the network. You can define a name for the VRF, specify the networks associated with it, and include any additional routes needed.
      Note:

      You can't assign the default network (VLAN ID = 1) to a VRF.

6. In the Dynamic Port Configuration tile, set up rules for dynamically assigning port profiles. When a user connects a client device to a switch port with this feature enabled, the switch identifies the device and assigns a suitable port profile to the port. Dynamic port profiling utilizes a set of device properties of the client device to automatically associate pre-configured port and network settings to the interface. You can configure a dynamic port profile based on the following parameters:
   • LLDP System Name
   • LLDP Description
   • LLDP Chassis ID
   • Radius Username
   • Radius Filter-ID
   • MAC (Ethernet mac-address)
   Note:

   Avoid using Dynamic Port Configuration if the port experiences a huge number of port flaps. Each port flap will trigger a configuration change on the switch (Junos commit). In such a case it is better to apply dynamic VLAN configuration via RADIUS.

   Here's an example of a rule that automatically assigns the port profile “access-point” to a Juniper AP. As per this rule, when the port identifies a device with a chassis ID that starts with “5c:5b:35”, it assigns the “access-point” profile to the connected device.

   

7. For your dynamic port configurations to take effect, you also need to specify the ports that you want to function as dynamic ports. You can do this by selecting the Enable Dynamic Configuration check box on the Port Config tab in the Select Switches section of the switch template. You can also do this at the switch level, from the Port Configuration section on the Switch Details page.
   Note:

   It takes a couple minutes for a port profile to be applied to a port after a client is recognized, and a couple of minutes after that for the port profile assignment status to appear on the portal.In case of switch reboots or a mass link up or down event affecting all ports on a switch, it takes approximately 20 minutes for all the ports to be assigned to the right profile (assuming that dynamic port configuration is enabled on all the ports).

8. In the Select Switches Configuration section, configure the following:
   1. On the Info tab, create a rule to associate the shared elements with your switch. Here's an example of how to add a rule that maps the EX4300 switch to an "access" role.

      

9. On the Port Config tab, click Add Port Range to associate a port profile with a port. Here, you also have the following key options:
   1. Enable Dynamic Configuration on the port. Dynamic port profiling allows you to assign a dynamic profile to a connected device based on defined attributes. If the device matches the attributes, Mist assigns a matching dynamic profile to the device. But if the device doesn't match the attributes, it will be placed in a specified VLAN. In the following example, the port is enabled with dynamic port allocation and is assigned with a restricted VLAN. In this case, if the connected device doesn't match the dynamic profiling attributes, it will be placed into a restricted VLAN such as a non-routable VLAN or a guest VLAN. Interfaces enabled with Port Aggregation don't support dynamic port configuration.
   2. Enable Port Aggregation. Port aggregation or link aggregation enables you to group Ethernet interfaces to form a single link layer interface. This interface is also known as a link aggregation group (LAG) or bundle. The number of interfaces that you can group into a LAG and the total number of LAGs that a switch supports vary depending on switch model. You can use LAG with or without LACP enabled. If the device on the other end doesn't support LACP, you can disable LACP here. You can also configure the LACP force-up state for the switch. This configuration sets the state of the interface as up when the peer has limited LACP capability. You can also configure an LACP packet transmission interval. If you configure the LACP Periodic Slow option on an AE interface, the LACP packets are transmitted every 30 seconds. By default, the interval is set to fast in which the packets are transmitted every second. The following example shows the use of LAG in an uplink port configuration:

      

   3. Configure alerts and email notifications for the interface up and down events on specified ports of a switch. To configure a switch port to support alerts, select the Enable “Up/Down Port” Alerts check box. Also, on the Monitor > Alerts > Alerts Configuration page, you must select from the following check boxes to enable alerts for the ports.
      1. Critical WAN Edge Port Up
      2. Critical WAN Edge Port Down
      3. Critical Switch Port Up
      4. Critical Switch Port Down
   4. On the IP Config tab, you can specify a networks for in-band management traffic.
   5. On the IP Config (OOB) tab, you can enable a dedicated management virtual routing and forwarding (VRF) instance on the switch. Enabling this feature confines the management interface (em0/me0/fxp0,vme) to a non-default VRF instance. This feature works for standalone devices and Virtual Chassis systems running Junos OS version 21.4 or later. With the dedicated management VRF instance in place, management traffic does not have to share a routing table with other control traffic or protocol traffic.
   6. On the CLI Config tab, include CLIs (in the set format) to configure any additional rule-based settings for which the template doesn’t provide a GUI option.
      Note:

      We have removed for this JVD the next section about Group-Based Policy configuration and Switch Policies based on GBP. This does only apply in Campus Fabric with IP-Clos. This configuration option does not apply in Branch designs hence not relevant here.

10. Click Save to save the switch template.

    The Confirm changes window appears.

11. Click Save on the Confirm changes window.

    The template is saved. To view the new template, go to Organization > Switch Templates.

Assign a Template to Sites

After creating a switch configuration template, you need to assign it to the relevant sites. This ensures that the configuration settings are applied to the devices within those sites. You have the flexibility to apply the template to a single site or multiple sites, depending on your specific requirements.

To assign a template to one or multiple sites:

1. Click Organization > Switch Templates.
   1. The Switch Templates page appears.
2. Click the template that you want to assign to sites.
   1. The Switch Templates: Template-Name page appears.
3. Click Assign to Sites.
   1. The Assign Template to Sites window appears.
4. Select the sites to which you want to apply the template and then click Apply.

Alternatively, you can apply a template to a site from the Site Configuration page, using the following steps:

1. Click Site > Switch Configuration.
2. Click a site from the list to open it.
3. Select a template from the Configuration Template field, and then click Save.

Precedence and Hierarchy of Configuration and Templates

Configuration templates have a hierarchy of assignments that you need to keep in mind when using them:

• All configs are inherited from a template to a site. All switches assigned to a site inherits the corresponding config.
• Each config element has an override option at both Site and Device levels making the configuration model extremely flexible.
• The precedence for configuration:
  • The configuration highest level is applied on the Switch (Device) itself > Network (Site) > Template (Org).

Configuration hierarchy of templates

Figure 13 shows an example of the configuration hierarchy:

It is possible to override the configuration from upper levels in the hierarchy to create more individualized configuration in case it is needed. Figure 14 shows an example:

Note:

Unless required, it is recommended not to override at the network/site configuration. You could use site variables instead, which is explained below.

Site Variables

To minimize the number of configuration overrides at the site level, we could use the concept of site variables.

The following is an example of using site variables where we want to individually configure the DNS servers and DNS suffixes to be used:

1. Go to Organization > Site Configuration and select an existing site or create a new one.
2. Create a variable containing your DNS servers as a string.
3. Create a variable containing your DNS suffix as a string.
4. Save the site setting.

   Your two example variables should now look like the below figure:

5. Go to Organization > Switch Templates and select an existing template or create a new one.
6. Under DNS Settings:
   1. For DNS Servers="{{dns_servers}}"
   2. For DNS Suffix= "{{dns_suffix}}.example.com"
7. Make sure the template is assigned to this site.
8. Save the site setting.

   Your two example configuration fields should now look like the below figure so that the right values are substituted:

   

More details: https://www.juniper.net/documentation/us/en/software/mist/mist-management/topics/task/site-variables.html