Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Deploying Midsize Campus with Mist Wired Assurance


Policy Orchestration

With the proliferation of mobiles devices and ubiquitous Internet availability, employees and guest users need to connect to the campus network, regardless if whether they are on the premises or working remotely. Users likewise need connect using corporate devices as well as their own (BYOD), all with the same level of security and access experience. These requirements demand role-based policy orchestration. Indeed, policy orchestration and access control are two of the more critical elements in delivering a secure infrastructure for the midsize enterprise campus solution because they provide a comprehensive suite of features for device connectivity and security. When users connect to the network, the policy orchestration engine must:

  • Identify the user and the role of the user.

  • Authenticate and authorize the user.

  • Identify whether or not the client device of the user is company-owned or BYOD.

  • Identify the type of OS running on the client devices (MAC OSX, PC Windows, or other).

  • Quarantine the device if necessary.

  • Detect the location of the entry point.

  • Detect traffic encryption requirements.

  • Provide accountability of user access (for example, report the number of attempts and success rate).

Likewise, the access control must provide:

  • Guest access control.

  • Layer 2 access control (802.1X, MAC authentication).

  • MAC authorization and device profiling.

  • Protection against MAC spoofing.

  • Monitoring and containment of unauthorized connections.

  • Role-based access control.

  • Identity-aware networking (Network Access Control (NAC) and Identity and Access Management (IAM)).

This Midsize Campus solution uses Mist Wired Assurance and supports both user parameters and device MACs for access control. Using a mix of user-based and MAC-based authentication methods provides scale, as does the use of a dedicated LDAP back-end server.

Creating a WLAN (SSID) specific for guest users (such as vendors or contractors) allows them to be separated from corporate users, so, for example, they can enter the network without a corporate device or supplicant. DUA (Device/User/Application) Profiles determine the number of devices (with MAC association) and number of users including guests. In this example, we assumed guest access users will make up about 10 percent of total users.

Use Interface for Metadata Access Point (IF-MAP) protocol for session information transfers to the secure access server in real time. (IF-MAP is an open standard protocol that communicates information about sessions, roles, access zones, and other elements between clients to the server as a federation.)

When setting up your own network to implement this example, you include support for active/passive or active/active high availability (note that active/passive set up can limit performance, but you can use load balancing to help scale nonclustered nodes and increase performance.)

You can also use additional services or service modules in the same chassis to support remote access services and network access control (NAC) policy services as part of an overall security strategy managed by a security management server.


Robust security is important to the campus environment. This includes perimeter security, which must provide stateful firewall protection ingress and egress to the campus network as well as protect all traffic within the various silos of the campus network. Part of the security posture for the solution is also to provide role-based access control (RBAC) to the network, including AAA in conjunction with 802.1x, which provides an endpoint access authentication model.

Additional device security should be associated to headless network devices, such as printers and video surveillance cameras, to provide the ability to prevent MAC spoofing attempts with these types of devices which have the inability to provide traditional AAA credentials.

Access security posture for the Campus solution should allow authenticated endpoints to be dynamically allocated to different VLANs automatically. Activation and transmission of firewall filters and VLAN assignments should be supported on access switches with a policy provided by an authentication server. If the authentication server cannot be reached, switches will support an authorization failed policy, in which devices are set to a non-authenticated state. Authenticated ports will remain authenticated for the duration of the connected session until the device is disconnected (either physically or logically) or the policy has timed out. The switch ports will also provide a method to grant trusted access to resources, while denying non-authenticated devices or providing only limited access to a remediation service.

Quality of Service

Quality of service (QoS) is an essential design category for maintaining application and user real-time performance monitoring (RPM) and ensuring consistent performance of the network. Although the Midsize Enterprise Campus solution reference architecture is designed for high bandwidth services with gigabit Ethernet or 10GE links, QoS should be considered mandatory for any campus deployment, regardless of bandwidth, for any interface or access point with the potential for congestion or contention for resources.

QoS policies are implemented for per-hop-behavior (PHB), meaning that each device should be configured to ensure consistent end-to-end policy enforcement. Although QoS policies are implemented as PHB, QoS should be considered end-to-end and flow through the entire campus in order to correctly adhere to the RPMs of the specific applications and campus policies.

Figure 1 illustrates the QoS classification used in the validated reference architecture.

Figure 1: QoS Classification of Traffic
QoS Classification of Traffic

QoS policies are first established by setting the trust boundaries and the relationships of marking the traffic in the campus network. For this reference architecture, trusted relationships (trusted inter-switch policies) are established at the aggregation and core layers of the network. In a trusted relationship, the classifications and markings of the traffic do not require a rewrite or an inspection. However, queuing and policing policies should be considered at the ingress and egress of all inter-switch links. WAN policies (both to the corporate WAN and to the Internet) can be constrained by lower bandwidth access links (less than 100 MB) and thus require a QoS policy with queuing and policing applied to maintain RPMs . Depending on the inbound and outbound QoS policy for the campus, WAN links can have different levels of trust associated with the interface. The access layer should be considered untrusted. At the access layer, QoS access policies include queuing, policing, classification, marking, and rewriting for ingress traffic. Based on the campus QoS policy, some devices may be considered trusted, such as an IP phone, which would receive its marking policy from the corporate IP PBX. WLAN QoS policies are configured at the WLAN controller, which provides the campus administrator the ability to trust the client DSCP through the wireless connection.

For more information on setting up QoS from the Juniper Mist portal, see: QoS for Switches

High Availability

High availability (HA) and resiliency is essential for maintaining connectivity and avoiding service disruption. The expectation in this Midsize Enterprise Campus Solution Reference Architecture is to ensure uninterrupted (sub-second recovery) access, including during voice and video sessions, in the event of hardware or software failure in the network. Additionally it assumed, there is the ability to minimize downtime during planned outages through the use of features such as nonstop routing (NSR), nonstop bridging (NSB), and nonstop software upgrades (NSSU).

High Availability at Layer 2

In campus architecture, each access switch is connected to two aggregation switches for redundancy to provide reliability and HA. Aggregation switches are interconnected at Layer 2. As shown in Figure 2, this can create a Layer 2 loop. Ethernet does not have any inherent way to track frames that are looping.

Figure 2: Layer 2 Loop
Layer 2 Loop

The following techniques are detailed to address Layer 2 looping.

Spanning Tree Protocol (STP)

Spanning Tree Protocol (STP) is the industry standard for preventing Layer 2 loops. STP calculates the best path through a switched network that contains redundant paths. STP uses bridge protocol data unit (BPDU) data frames to exchange information with other switches. STP uses the information provided by the BPDUs to elect a root bridge, identify root ports for each switch, identify designated ports for each physical LAN segment, and prune specific redundant links to create a loop-free tree topology. The resulting tree topology provides a single active Layer 2 data path between any two endpoints, as shown in Figure 3.

Figure 3: Spanning Tree Protocol
Spanning Tree Protocol

Although STP can prevent Layer 2 loops, it is not an efficient protocol. At any given time, a Layer 2 switch port can be listening, learning, forwarding, or blocking in order to determine the loop-free data path. Many improvements have been made to STP to improve its convergence time from 50 seconds to much less. However, STP does not perform sub-second convergence like most Layer 3 protocols can. Another disadvantage of STP is that it blocks all but one of the redundant paths that are connected. As a result, network resources can be under-utilized as there are occupied switch ports not actively in use (because they are in a blocking state). Real-time applications suffer most when STP is used alone in a campus environment. To avoid the performance limitations of STP, this reference architecture used virtual chassis.

Virtual Chassis

Virtual chassis is an intelligent technique for avoiding Layer 2 looping altogether. As shown in Figure 4, multiple switches are brought under a single management and control plane, creating a virtual device that consists of two or more physical devices.

Figure 4: Virtual Chassis
Virtual Chassis

In a virtual chassis, each of the member devices are stacked together to act as single logical device. In a virtual chassis connection, there is a client device, such as a server or switch that has more than one physical link into the virtual chassis. This client device does not need to have any virtualization configured. On the other side of the connection is the virtual chassis. Each of the virtual chassis stack members has one or more physical links connected to the client device.

High availability at Layer 3

Every network element in the Campus solution ultimately converges into the core switch, which functions as the core of Layer 3 for the campus network. As such, the core switches of the campus must support high port speed and density, high availability and resiliency, a robust feature set, and scalability.

OSPF is used on the core switch, as the interior gateway protocol in this reference architecture (some campus networks might elect to use IS-IS). In addition, the core switch enables the loop-free alternate (LFA) feature in OSPF to converge faster during link and node failures. To detect forwarding errors and help enable faster end-to-end convergence, the Bidirectional Forwarding Detection (BFD) protocol should be enabled on all point-to-point and broadcast interfaces.

The recommended values for routing convergence for this reference architecture are:

  • Minimum interval of 50ms

  • Multiplier of 3

Neighbor authentication should be enabled between each node in the topology using either MD5 or SHA-1 encryption; the intent is to prevent accidental OSPF adjacencies in the future if new equipment is installed. There are various physical, logical, and software components that need to be configured to support redundancy between the core switches.

Physical redundancy:

  • Redundant power supplies

  • Redundant routing engines

  • Redundant switching fabric

  • Redundant line cards

Routing engine redundancy:

  • Graceful Routing Engine switchover (GRES)

  • Nonstop routing (NSR)

  • Nonstop bridging (NSB)

  • Non-Stop Service Software Upgrade (NSSU)

Protocol availability:

  • BFD enabled on all links

  • LFA enabled on all links

  • QoS properly configured to give network control adequate bandwidth during times of congestion

Configure the SRX Series Device

This example shows how to configure the SRX Series device starting logically from the lower layers to the upper layers of the network. In it, we set up four branch offices, each with a different VLAN, and all of which connect to the corporate intranet. Wi-Fi users at the branches connect to the network via access points that are connected to one of the respective VLANs configured on the SRX.

  1. Set the hostname and password. For this example, use Mist-SRX-GW as the hostname and for the sake of simplicity, configure the root password using plain text rather than encrypted:
  2. Configure the time zone and add both a DNS server and an NTP server. For this example, set the time zone to America/Los_Angeles and use an IP address of for the DNS server and an IP address of for the NTP server.
  3. Next, create the four VLANs. Use Table 1 to see the VLANs, usage, and port types used in this example.

    Table 1 lists the VLANs, usage, and port type used in this example. All other ports on the SRX Series device and EX switch are untagged VLAN ports.

    Table 1: VLAN Usage




    SRX to EX Port Type






    Default VLAN and provides in band management for all devices.





    Used by corporate wired and wireless traffic.





    Used by guest wireless devices.





    Used by all IoT devices.





    Used by the surveillance cameras.




    Used in switch ports where a dynamic profile is assigned a default restricted VLAN.

  4. For the primary link to the Internet, we’ll use interface ge-0/0/6, and also configure it as a DHCP client.
  5. In this step, we create a security policy to allow traffic between the trusted and untrusted zones.
  6. The EX switch needs to be able to access the Juniper Mist cloud. For this, we need to configure the security zones and the SRX so the connected EX switch can obtain an IP address from the DHCP pool, and so it can connect to the Internet.

    Modify the security policy to allow ICMP ECHO (ping) and DHCP service messages in the trusted security zone and add the irb.0 interface to the security zone.

  7. Create source network address translations (NATs) for the VLANs used in this example.
  8. Configure the system logs that we will need to collect from the SRX device. In this example, we set the maximum size of the Syslog to 100KB, keep the 3 most recent files only, set the files readable by all users, and add all emergency log messages related to users to the syslog.

    In addition, we configured our system logs to capture the following syslog messages:


    Syslog file Name

    File Size

    Severity level messages from all facilities

    Severity level messages from the authorization facility


    100 KB

    Any severity level message from the interactive commands facility




    1 MB



    1 MB



    1 MB

  9. Commit the configuration

Now that the SRX is configured for the EX switch to access the Internet, the next thing to do is to set up the EX switch so it can be managed from the Juniper Mist portal

Connecting the SRX and Juniper EX Series Switch

In this part of the example, we configure an SRX to provide the wired and wireless network connections for on-site employees, and wireless access to guest devices. The EX switch connects to the SRX device and provides the Layer 2 functionality and ports for the branch.

To follow the steps in this example, you need to log on to your SRX and be able to edit the Junos configuration.

Table 2 contains the list of the interfaces, VLAN IDs, and IP address used in this example. You can print out the table and modify the information to fit the variables of your own network, or swap in those values when you copy/paste commands shown in steps 1 through 6.

Table 2: VLAN and IP Address on the Interfaces



IP Address

Network Mask

















  1. We’ll start by configuring the interface that connects the SRX and the EX. The Junos CLI commands below create VLANs (as defined in Table 1), set VLAN 1 as the native VLAN, attach VLANs to a physical interface on the device, and assign IPv4 addresses to different units on that interface.
  2. Now we’ll create a security zone named trust on the interface, and include in it the VLANs (by way of their respective interface unit IDs).
  3. Corporate devices connecting on VLAN10 will need an IP address, so here we configure interface ge-0/0/0.10 to be the DHCP server address, create a DHCP server, and define an IP address pool for the connecting devices.
  4. As with the previous step, we’ll create a DHCP server and an IP address pool for guest users to connect on VLAN20. Interface ge-0/0/0.20 will be the DHCP Server address.
  5. Next, we’ll create a DHCP server and an IP address pool for IoT devices connecting on VLAN30. Interface ge-0/0/0.30 will be the DHCP server address.
  6. Finally, we’ll create a DHCP server and an IP address pool for camera devices connecting on VLAN40. Interface ge-0/0/0.40 will be the DHCP Server address.
  7. Commit the configuration.

    The EX switch and Juniper Access Points are now connected on the trunk port and the EX switch can connect to the Internet, and thus the Juniper Mist Cloud.

Configure the EX Series Switch in the Juniper Mist Cloud

With Juniper Mist cloud services, you can use Juniper Mist Wired Assurance to centrally manage all your Juniper switches. Juniper Mist Wired Assurance gives you full visibility on the devices that comprise your access layer network topology. The Juniper Mist portal provides a user interface to access your architecture through the AI-driven cloud services with your Juniper Mist account. You can monitor, measure, and get alerts on key compliance metrics on the wired network including switch version compliance, PoE compliance, switch-AP affinity, and VLANs insights. Juniper switches and Juniper access points (APs) combine to support dense, heavily utilized networks that can host a large number of mobile devices, and provide end-user security and reliable performance.

We group the adoption and management of EX Series Switches into three categories:

  • Day 0 represents zero-touch and single-click activation for adopting new and existing switches into the Juniper Mist Cloud.

  • Day 1 represents template-based configuration for scaling switches across the organization, site, or individual switches.

  • Day 2 represents ongoing switch insights and intelligence, leveraging the Marvis Virtual Network Assistant driven by Mist AI.

To adopt a cloud-ready switch manually, you need a Mist Activation code for the switch. Activation codes are sent by e-mail to the address on record at the time of purchase. You can also contact the Juniper Mist Customer Engagement team to get your activation code. When you enter the Activation code, Juniper Mist Cloud adopts the switches, Juniper access points, and subscriptions that were listed on your purchase order.

  1. On the EX switch, connect the management interface to the Internet, and power on the switch . As part of the zero touch provisioning (ZTP) process, the switch automatically accesses the phone home server (PHS) or a configured DHCP server to download the latest software image and then it connects to the Juniper Mist Cloud for configuration updates.
  2. Use a Web browser to log in to your Juniper Mist account. The Monitor screen shows an overview of the Juniper Mist cloud and any connected Juniper access points and clients. Click on Organization > Inventory in the menu on the left to open the Juniper Mist Inventory Screen.

    When the ZTP process completes, the switch that you purchased automatically appears in the Inventory screen. If the switch does not appear after a few minutes, despite refreshing the web page, try logging out and then logging back in.

  3. Select Switches at the top of the Inventory screen, and click the Claim Switches button and enter the activation code for the switch.
  4. Complete the fields on the screen. Select the Manage configuration with Mist check box and enter a root password for the switch. Note

    When you manage a switch on the Juniper Mist portal, we recommend that you restrict the usage of the CLI locally on your device to prevent conflicts. At a minimum, you should create a system login message that displays on the CLI of the switch warning users not to make configuration changes locally on the switch.

How to Activate a Brownfield Switch

Brownfield switches are switches being brought into the Juniper Mist Cloud from a previous deployment. We recommend that you back up the existing configuration on the switch before getting started. To prevent users from using the CLI to configure the switch after it has been adopted into the Juniper Mist Cloud, you may also want to create a system login message on the switch to warn against making configuration changes, or you can restrict their management access altogether by changing the password or placing restrictions on the CLI user accounts.

This procedure describes how to set up a secure connection between a supported EX Series switch running a supported version of Junos OS. Be sure you can log in to both the Juniper Mist portal and the switch since you will be making configuration changes to both systems.

  1. Log in to your organization on Juniper Mist Cloud Click Organization > Inventory to open the Inventory screen.
  2. Select Switches at the top of the Inventory screen and then click Adopt Switches in the upper-right corner to generate the Junos OS CLI commands needed for the interoperability. The commands create a Juniper Mist user account and an SSH connection to the Juniper Mist Cloud over TCP port 2200 (This is the switch port connection for a management interface and is used for configuration settings and sending telemetry data).
  3. In the window that appears, click Copy to Clipboard to get the commands from the Juniper Mist Cloud.
  4. On the console of the switch, type configuration to enter configuration mode and then paste the commands you just copied (type top if you are not already at the base level of the hierarchy).
  5. On the Juniper Mist portal, click Organization > Inventory > Switches and select the switch you just added.
  6. Click the More drop-down list at the top of the screen, and then click Assign to Site to continue making your selections as prompted.
  7. Confirm your connection from the switch to the Juniper Mist Cloud in the Junos CLI by typing show system connections.

    The output shows that the switch established a connection to the Juniper Mist Cloud. It includes the IP Address of the management interface, the IP address of the Juniper Mist Cloud and the connection status.



The command output shows the switch connection to the Juniper Mist Cloud. It includes the IP address of the management interface on the switch, the destination IP address of the Juniper Mist Cloud, and the connection result.


Confirm your connection from the switch to the Juniper Mist Cloud by running the Junos OS command shown below on your switch console.

user@host> show system connections | grep 2200

If you do not see the switch in the Inventory list, the SRX may be blocking the acknowledgment messages for the initial connection request. If the SRX is blocking the inbound packets over TCP port 2200, add a firewall rule to enable communication on port 2200. The switch will appear in Organization > Inventory > Switches.

Day 1: Use a Template-Based Configuration with Device and Port Profile

A key feature of switch management through the Juniper Mist Cloud is the ability to use configuration templates and a hierarchical model to group switches and to make bulk updates. Using templates allows you to have consistent configurations across the organization and to conveniently apply them to a particular switch and at scale across your network.

You can create a template configuration and then apply those settings to all the devices in a group. When a conflict occurs, the more narrow settings override the broader settings. For example, when there are settings at both the branch and organizational levels that apply to the same device, the more narrow settings (in this case, branch) override the broader settings that are defined at the organization level.

Figure 5: Network Behind the SRX Device
Network Behind the SRX

The following procedure configures the EX switch with the network example behind the SRX. The switches here were on-boarded using the brownfield method with only a minimal management configuration to access the Internet.

Start by defining the standard configurations that will be used for all the switches in the branch, using the Switch Configuration template.

  1. To create a Configuration template, click Organization > Switch Template in the menu on the left.

    Click a headings (All Switches Configuration, Shared Elements, or Select Switches Configuration) to expand the configuration, and the down arrow to collapse the configuration.

    1. Under All Switches Configuration, add the following:
      • Under RADIUS, add a RADIUS server for the organization or site.

      • Under NTP, add the NTP server for the organization or site.

      • Under CLI Configuration, apply any necessary additional configuration parameters such as a corporate login banner, corporate SNMP or syslog servers and so on.

    2. Under Shared Elements, add the following:
      • Under Networks, add the following VLANs for the campus:

        • vlan10 (Corp)

        • vlan20 (Guest)

        • vlan30 (IoT)

        • vlan40 (Cameras)

        • vlan99 (Restricted)

      • Under Port Profiles, create the new port profiles for uplink ports such as wan-uplink and switch-uplink for the related ports, and map the port profiles to trunk the above VLANs. vlan99, which is only locally significant, is an exception.

      • Under Port Profiles, create the new port profiles for device facing ports such as wifi_ap, cameras, and corp. for the related port and map the port profiles to the above VLANs.

      • Under Dynamic Port Configuration, create a rule that assigns the port profile mist_ap to Juniper access points automatically. The rule we are creating uses LLDP to detect the chassis ID. For devices with the MAC address of a Juniper access point, the Juniper access point profile is assigned (shown as xx-xx-xx in the following image:

    3. Under Select Switches Configurations, add rules for distribution and access layer switch roles:
      • Under Port Configuration Rules, define the port configuration rules and map the port profiles to the physical ports in the switch. Create a rule to associate the port profile with your switches, in the example we create rules for an EX4650 virtual chassis with the role of distribution-vc and an EX3400 virtual chassis switch with a role of access-vc2.

      • Map the uplink port profiles to physical ports on the distribution switch, as shown in the following image:

      • Include any additional configurations in the CLI Config box. In this example, because the distribution switch is a two-member virtual chassis, we use the no-split-detection command. To ensure root bridge election, rstp-bridge-priority is set to 4k, as shown in the following image:

      • Repeat the steps to build rules for the access switch, as shown in the following image:

      • On the Port Config screen, map the port profiles to physical ports in the switch:

      • Next, enable the dynamic port profile assignment by mapping the switch port to a restricted_device profile. This maps a port profile to a VLAN with restricted access and enables Dynamic Configuration, as is shown in the following image:

      • In the CLI config box, you can Include any additional Junos configuration code you may have. In the current example, as previously noted, no-split-detection is set because the access switch is a two-member virtual chassis:


    You can set Junos configurations that are not represented in the Juniper Mist portal, by including the statements in the CLI configuration text box.

  2. Now that the configuration template is set up, you can map the template you just created to your site. In the main menu, click Network > Switch Configuration and then select the check box next to your site. Click the Assign to Template link to map the template (here, Campus-Template) to your site, as shown in the following image:
  3. Next we need to apply configuration rules to any devices that have been recently added to the Juniper Mist portal. To do so, click Switches in the menu and, for this example, select HQ site from the drop down. A list of devices assigned to that site appears, as shown in the following image:
  4. For this example, one switch remains to be configured, as shown in the following image. Click the switch name to open the configuration page, and then set a hostname.
  5. Because the switch is already a member of the Org group, it inherits global configuration settings defined at that level. These include the Radius and NTP servers we configured in step 1, and the networks we defined in step 2.

    By assigning an existing role to the switch, the switch will also inherit those setting as defined in the template (you can see this by typing different role names in the Role field). For this example, since the switch is a standalone access switch, choose the role access-std, as shown in the following image:

  6. By default IP address assignments are managed by a DHCP server (and Juniper recommends that you use this option), but you can specify a particular IP address or range of IP addresses by editing the fields shown in the following image:
  7. You can also add any additional Junos CLI commands that you want to run by including them to the Additional CLI Commands field, as shown in the following image. (Note that these CLI commands are only applied to the specific switch; they are not part of a template and so will not be inheritable by other switches.)
  8. Click Save in the top right of the screen to apply the configuration to the switch. Repeat steps 6 through 9 for any remaining switches.
  9. To confirm that the switches have been added to the topology as expected, click Switches on the main menu, and then Topology to display an interactive list of the configured switches.

Wireless Configuration on the Juniper Mist Cloud

Juniper Mist Wi-Fi Assurance, driven by machine learning on Juniper Mist, replaces manual troubleshooting tasks with automated Wi-Fi (also called wireless, and WLAN) operations. This subscription service makes Wi-Fi predictable, reliable, and measurable with unique visibility into user service levels. You can set up and track service-level thresholds for key wireless criteria connection metrics, such as time to connect, capacity, coverage, and throughput.

In the example below, we create a Wi-Fi template that includes the SSIDs needed for a branch office site. Templates are handy because they contain all the configuration settings you need for a given location, and provide an easy, uniform way to apply them.

Once the template has been defined, we will then claim any Juniper Access Points that are deployed at the site to include it the Juniper Mist portal. The APs need to be physically deployed at site and connected to the EX switch. Each Juniper Access Point has an AP claim code (Activation code), that you can use to add it to a site, and thus bring it under management by the Juniper Mist portal. From the Juniper Mist portal, you navigate to the switch and "claim" the AP so that its location and relationship to switch are understood by the Juniper Mist portal. Claiming the AP also assigns it to a particular site so you can manage it, in conjunction with any other APs in the same location, as a part of the site.

In the steps below, you will create a site template, and then claim APs to which the configuration settings defined in the template will apply.

  1. To create a template, click Organization > Config Templates in the menu on the left.
  2. For this example, we want to create a WLAN template that can be applied to the entire organization, so give the template a name, and select Entire Org as shown in the following image:
  3. Configure the Wi-Fi settings as shown in the following image (that is, select WPA-2/EAP (802.1x) for Security, specify the IP address of your RADIUS server, and specify Untagged as the supported VLAN type):
  4. Next, we’ll create a site called Branch-1. Click Organization >Site Configuration in the menu, and then Create Site.
  5. In the screen that appears, fill out the settings as appropriate and then when done, click Save at the top of the page.
  6. To claim one or more Juniper Access Points (that is, to include the AP as a member of the Branch-1 site, click Access point in the main menu. A list of eligible access points reporting in to the Juniper Mist portal (through the EX switch we configured) appears on the page.
  7. Click the Claim APs button at the top of the page, and then enter the Claim Code for one of the Juniper Access Points deployed at the site. (From the same page you can also select the site to which the AP belongs (Branch-1, in the current example), give the AP a name, and attach to the AP an AP profile with additional settings if you like.)
  8. Click the Claim button at the bottom of the page to assign the AP to the site and make it available to the Juniper Mist portal.

Additional SSID Configuration

Midsize branch offices often require multiple SSIDs and WLANs to control access and security on the basis of user groups. With Juniper Mist, this can be easily handled by creating multiple VLANs, each with different access profiles and/or security settings, to support the various profiles.

Recall that in an earlier procedure, we configured a switch port on the SRX as a trunk port with native-vlan-id enabled for the management of the access points. Now, in the procedure below, we update the branch site to include WLAN networks for both guest access and for IoT device connections.

  1. To edit the template for the branch office, click Organization > Config Templates in the menu.
  2. Click Add WLAN to create a WLAN with an SSID for guest access on VLAN20, and then Tagged to assign the VLAN ID.
  3. In the Guest Portal work area, click Custom guest portal to customize a WLAN for guest access.
  4. Enter a name the SSID (here, Branch-IoT), and enable PSK with passphrase security as shown in the following image. Also assign VLAN ID (30, in this example) and select Untagged.

    Repeat the procedure above to set up any other WLANs you want. When you are done, you can view the list of configured WLANs, as shown in the following image:

    Both the EX switch and the access points are now configured and accessible from the Juniper Mist portal.


The Midsize Campus solution reference architecture provides a solid foundation for baseline campus design for the medium to large campus. The architecture was validated against application RPMs and tested at scale to include Layer 2 and Layer 3 design, security, QoS, HA, and scale-up to 10,000 users and 40,000 devices (both real and simulated devices). In addition, the solution includes wireless access as well as policy and identity capabilities necessary for BYOD strategies for today’s mobile enterprise.