Appendix: Day-1 Deploy

WAN Router Installation

In this chapter, we share configuration examples for two Juniper WAN routers that are also managed by the Juniper Mist cloud. Such a solution is called a “Full Stack” solution as it enables you to manage all network devices located at a branch within a single pane of glass.

Juniper SSR as WAN Router Managed by Juniper Mist Cloud

Juniper Networks® SSR Series Routers support LAG interfaces along with the suggested LACP “force-up” option starting with release V6.3.0. At the time of this writing, this firmware version was in beta. It is planned to share the information on how one can use LAG with force-up option as part of a Juniper Network Configuration Example (NCE). Please check the Juniper Web-Site for availability of this example.

Juniper SRX as WAN Router Managed by Juniper Mist Cloud

Note:

Make sure the SRX device has an AppID license or else it cannot be managed by Juniper Mist cloud. This is independent of whether you use it as a standalone firewall or as an SD-WAN router managing your VPN.

With the example below, we are sharing the minimum requirements with a standalone WAN router and a standalone EX Series Switch to establish a simple branch with in-band management of the switch over a LAG interface. You can extend this by having the EX Series Switch form a Virtual Chassis or have the WAN router form a High Availability cluster pair. Unfortunately, we cannot describe all possible permutations here, so we just cover the basics.

Note:

Should your design have multiple LAGs from the WAN router towards the access switches, then you have the following options:

1. VLANs can be shared across multiple LAGs when the device is a Juniper SRX 3xx Series where the Juniper Mist cloud can automatically configure IRBs.
2. When using a Juniper SRX 1500 Series or higher, you need to define a unique set of VLANs per LAG or utilize a distribution layer architecture with high availability configuration in cluster mode.

Go to Organization > Applications and check that there is an existing application with the following settings:

• Name=any
• Type=Custom Apps
• IP Addresses=0.0.0.0/0

Add another application with the following settings:

• Name=Branch-VLANs
• Type=Custom Apps
• IP Addresses=10.0.0.0/8

You should now see the two applications listed as shown below:

Go to Organization > Networks and add the first VLAN:

• Name=VLAN1033
• Subnet IP Address=10.33.33.0
• Prefix Length=24
• VLAN ID=Leave this field empty. This is the native VLAN used for in-band management of the attached EX Series Switch as well as the AP.
• Access to Mist Cloud=Enabled. This must be enabled for the attached switches and AP to be managed by the Juniper Mist cloud.

Then, add the second VLAN (in our topology we use this for wired clients):

• Name=VLAN1099
• Subnet IP Address=10.99.99.0
• Prefix Length=24
• VLAN ID=1099

Then, add the third VLAN (in our topology we use it for wireless clients via AP)

• Name=VLAN1088
• Subnet IP Address=10.88.88.0
• Prefix Length=24
• VLAN ID=1088

Review the three networks and verify that no VLAN ID is set for the switch and AP management network, since this is a native VLAN on the downlink trunk.

The following JSON template may be used to configure the branch WAN router. Alternatively, manual configuration steps for the branch WAN router are listed immediately after the JSON template.

When not using the JSON template, execute the following steps instead to configure the branch WAN router:

Go to Organization > WAN Edge Templates

Create a new template with the following parameters:

• Name=Branch-WAN-Router
• Type=Standalone
• Create from Device Model=Checked
• Model=<Select your Model>

After the template has been created, start with basic configuration settings based on your environment such as the following:

• NTP=time.google.com
• DNS Servers=8.8.8.8, 9.9.9.9

When you check the template, you should see the following preconfigured WAN interfaces. We are going to use the “wan” ge-0/0/0 interface to obtain a DHCP lease from the broadband router.

We are going to modify the LAN interfaces of this template. Delete the preconfigured “lan” interface (not shown here). Then create a first LAN network (native for our device management) with:

• Network=VLAN1033
• Interface=ge-0/0/5-6
• Port Aggregation=Enabled
• Enable Force Up=Checked
• AE Index=0
• Check that the VLAN ID: <default> appears from the Networks definition before
• IP Address=10.33.33.1
• IP-Prefix Length=24
• DHCP=Server
• IP Start=10.33.33.10
• IP End=10.33.33.250
• Gateway=10.33.33.1
• DNS Servers=8.8.8.8, 9.9.9.9

Then, create a second LAN network (trunked for our wired clients) with:

• Network=VLAN1099
• Interface=ge-0/0/5-6
• Port Aggregation=Enabled
• Enable Force Up=Checked
• AE Index=0
• Check that the VLAN ID: 1099 appears from the Networks definition before
• IP Address=10.99.99.1
• IP-Prefix Length=24
• DHCP=Server
• IP Start=10.99.99.10
• IP End=10.99.99.250
• Gateway=10.99.99.1
• DNS Servers=8.8.8.8, 9.9.9.9

Then, create a third LAN network (trunked for our wireless clients) with:

• Network=VLAN1088
• Interface=ge-0/0/5-6
• Port Aggregation=Enabled
• Enable Force Up=Checked
• AE Index=0
• Check that the VLAN ID: 1088 appears from the Networks definition before
• IP Address=10.88.88.1
• IP-Prefix Length=24
• DHCP=Server
• IP Start=10.88.88.10
• IP End=10.88.88.250
• Gateway=10.88.88.1
• DNS Servers=8.8.8.8, 9.9.9.9

The final LAN interface table should look like the figure below:

Next step is adding a new destination to the Traffic Steering Policy. This is required to enable communication between the local VLANs which we want to happen in our example. Add a new Traffic Steering Policy using the following settings:

• Name=LAN
• Strategy=Ordered
• Paths:
  • Type=LAN: VLAN1033
  • Type=LAN: VLAN1099
  • Type=LAN: VLAN1088

You should see the following for traffic steering destinations now:

Implement the #Toc170115267__Ref170471401 for Application Policies. Parts should already exist that you only need to modify.

Table 1: Application Policies

Serial Number	Rule Name	Network	Action	Destination	Steering
1	Inside_Branch_hairpin	VLAN1033, VLAN1099, VLAN1088	Pass	Branch-VLANs	LAN
2	Internet	VLAN1033, VLAN1099, VLAN1088	Pass	any	wan

You should see the following configuration for Application Policies now after the implementation of the above table:

In the current version, clients on the LAN side cannot get an answer when sending ICMP ping to the WAN router as their local gateway. However, receiving pings is crucial for any local debugging. Hence, it is highly recommended that you add some additional Junos CLI commands to enable ping for any wired or wireless clients towards the WAN router as the local gateway of the VLAN they are attached to. See the example below:

In the portal, it should look like the below figure:

Click Save to save the template now.

You must assign a site for this template or else it won’t be used on any device.

Here, we add the Spoke1 site to the template, which is where our switches are located.

To assign your SRX Series Firewall devices to sites, the devices must be present in the Juniper Mist inventory. You can claim or adopt your SRX Series Firewall to onboard it in the Juniper Mist cloud. After the device is onboarded, the organization inventory shows the device.

To assign an SRX Series Firewall to a site:

1. In the portal, click Organization > Admin > Inventory.
2. Refresh your browser and check under WAN Edges to find out if your SRX Series Firewall is part of the inventory.

   

3. Assign each SRX Series Firewall to an individual site using the Assign to Site option.

   

4. On the Assign WAN Edges page, select the site you want to assign from the list of available sites.

   

5. Do not select the Manage configuration with Mist option. If you do, you may see unwanted changes on your SRX Series Firewall. You can enable the option later if required, after you've assigned the device to the site.
6. Check the Use site setting for APP Track license option if you have a valid Application Security license, and then click Assign to Site.

   The below figure shows changes in the inventory once you assign the device to the site:

   

7. After the device is onboarded, on the WAN Edges tab, select <your site> and then click on the device.

   

8. Check the device and AppSecure status:

   

9. Now activate Enable Configuration Management of the device as the last step so that Mist can configure the device:

   

10. OPTIONAL: Use a Remote Console to verify the device configuration and status after Juniper Mist cloud takes over management of the device. In our example, you see the below output:

    The moment you attach the EX Series Switch and power it up, it should obtain a DHCP lease from the WAN router which you can verify as shown below. From time to time, you should also see the Phone-Home Client on the switch trying to contact the redirect server as in our example:

    An example when using SRX Series Firewalls in a redundant cluster configuration is shown below. At the time this JVD was written, the configuration pushed to the device needed was not fully able to be configured in the GUI, hence we used a combination of forming the redundant ethernet interfaces in the GUI and then the LAG interfaces with the “force-up” option manually via additional CLI a bit below in the same template.

    When using SRX Series Firewalls in cluster mode, you need to configure a minimum of 4 links when using LAGs as it is not possible to span a single aggregate ethernet bundle across the two redundant cluster nodes. Instead, you form individual aggregate ethernet bundles on each local cluster node and bind those together through a redundant ethernet interface typically called a “reth” interface. You can find an example topology in #Toc170115267__Ref170471510 :

    Figure 2: Branch Topology of Juniper SRX Chassis Cluster as WAN Router

    As stated above, we only form the reth interface in the GUI for now. Critical configuration points are then:

    • The Interface field must have all four interface names that are distributed across all cluster nodes. On node1, the interface name is always renamed when the cluster is built. What the exact new interface name will be is device specific.
    • Do not click on Port Aggregation. We add the below manual additional Junos CLI for this.
    • Activate the Redundant check box.
    • Choose a Redundant Index number starting with 1. In our example, when setting the value to “1”, this translates into a reth interface named “reth1” that must then also be correctly referenced in the additional CLI.

    

11. Finally, review the additional Junos CLI example below and add something like this to your own template along with the other changes to complete the remaining configuration.

Activating a Greenfield Switch via claim and ZTP-based installation

A switch-specific QR code is setup at the time of purchase. The switch will arrive in a box with the cloud-ready logo, and a sticker with a QR code will be on the back of the switch near the fan exhaust and interfaces.

Using the Mist AI App to Add a Cloud-Ready Switch to the Juniper Mist Cloud

Step-by-Step Procedure:

1. Download and install the MistAI app to your phone.
2. Unbox your switch, connect the management port to the internet, and power it on. As part of the ZTP process, the switch will automatically access the PHC server (or the DHCP server if you have set this up instead) and then connect to the Juniper Mist cloud for configuration updates.
3. Using a web browser, log in to your Juniper Mist account. The Monitor screen appears, showing an overview of the Juniper Mist cloud and any APs and clients that are already connected. In the menu on the left, click Switches to open that screen. Once the ZTP process resolves, the switch will automatically appear here (if the switch doesn’t appear after a few minutes, despite refreshing the web page, log out and then log back in, or go to the troubleshooting section, below, to find out how to confirm whether the device is connecting to the cloud.
4. While the switch is being resolved in the Juniper Mist cloud, find the QR code on the front of the switch.
5. On your phone, open the MistAI app and log into your Juniper Mist cloud account. Tap the Claim AP to Org button that appears.

   

6. Point the QR Code viewer at the QR code on your switch. Once the QR code comes into focus and (that is, your camera is held at the right distance), the app automatically claims the device and adds it to your organization’s inventory in the portal.

Manually Adding a Cloud-ready Switch to the Juniper Mist Cloud

Step-by-Step Procedure:

To adopt a cloud-ready switch manually, you need an activation code for the switch (these are sent via email to the address on record at the time of purchase, or they can be obtained by contacting Juniper Mist Customer Engagement team). Using the activation code will adopt the switch and any Juniper access points that are part of the purchase order, as well as claiming any subscriptions that are included in your purchase.

1. Start by unboxing your switch, connecting the management port to the Internet, and powering it on. As part of the ZTP process, the switch will automatically access the PHC server (or the DHCP server if you have set this up instead) and then connect to the Juniper Mist cloud for configuration updates.
2. Using a web browser, log in to your Juniper Mist account. The Monitor screen appears, showing an overview of the Juniper Mist cloud and any Juniper APs and clients that are already connected. In the menu on the left, click Organization > Inventory to open that screen.

   

3. Choose Switches at the top of the Inventory screen, and then click the Claim Switches button and enter the claim code or activation code for the switch.

   

4. Fill out the other fields on the screen as you like. Note that if you deselect ‘Assign claimed switches to site’, the switch will not be listed in the Switches page. To see your switch on the Switches page, you must first assign the switch to the site from the Inventory page. Check Manage configuration with Juniper Mist and then enter a root password for the switch. Note that this choice puts the switch under the management of Mist, and as such, Juniper recommends that local configuration using the CLI be restricted to prevent conflicts (for example, you may want to create a system login message on the switch to warn against making configuration changes locally, from the CLI).
5. Once the ZTP process resolves, the switch will automatically appear on the Inventory screen. If the switch doesn’t appear after a few minutes despite refreshing the web page, log out and then log back in, or go to the troubleshooting section below to find out how to confirm whether the device is connecting to the cloud.

Activating a Brownfield Switch via Adoption Code-Based Installation

Note:

It is important to backup your existing Junos configuration on the switch before activating a brownfield switch, because when the switch is adopted for management from the Juniper Mist cloud, as described below, the old configuration will be replaced. Do this by running the request system software configuration-backup <path> command, which saves the currently active configuration and any installation-specific parameters.

To prevent users from using the Junos CLI to configure the switch after it has been adopted into the Juniper Mist cloud, you may want to create a system login message on the switch to warn against making configuration changes, or to restrict their management access altogether by changing the password or placing restrictions on the Junos CLI user accounts.

Adding a Brownfield Switch to the Juniper Mist Cloud

This procedure describes how to set up a secure connection between a supported EX Series Switch running a supported version of Junos. In it, you will make a few configuration changes on the portal as well as some on the switch using the Junos CLI. Be sure you can log on to both systems.

1. Log in to your organization on the Juniper Mist cloud and then click Organization > Inventory in the menu.
2. Choose Switches at the top of the screen that appears, and then click the Adopt Switch button in the upper right corner to generate the Junos CLI commands needed for the interoperability. The commands create a Juniper Mist user account, and a SSH connection to the Juniper Mist cloud over TCP port 2200 (the switch connection is from 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. At the Junos CLI, type “edit” to start 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. Back in the portal, click Organization > Inventory > Switches and select the switch you just added.
6. Click the More drop-down at the top of the screen, and then the Assign to Site button to continue making your selections as prompted.
7. Confirm your updates on the switch by running show commands at the system services level of the hierarchy, and again at the system login user juniper-mist level of the hierarchy.
   Note:

   The Junos CLI for adoption is unique to the Mist organization itself. Once retrieved, you can use it on other EX Series Switches that belong to the same organization. After first contacting the Juniper Mist cloud, the default passwords are going to be changed to unique passwords per device.

Add the Switch to the Juniper Mist Portal and View Details

Now that the switch is able to register with the portal, the next steps are to add the switch to the appropriate site and to assign APs. You do this from the portal.

Step-by-Step Procedure:

1. To add the switch to a site, click Organization > Inventory in the Juniper Mist menu and then the Switches tab at the top of the screen that appears. Select the switch you just added, and then click the More button, Assign to Site, and then choose a site from the drop-down list that appears in the Assign Switches window. Click the Assign to Site button to complete the action.
2. Click Access Points to see a list of unassigned APs.
3. Click Switches to see the list of switches. You can choose a switch from the list to confirm that it and the portal are correctly provisioned. Note that the PoE compliance you set up earlier on the switch interfaces is shown with the switch, as are the VLANs and other details.

   

4. From the Switches page, click a switch name to drill down into a detailed view of that switch, including connected APs and clients. For each switch on the list, you can view various properties, including the version, model number, CPU and memory utilization, bytes transferred, power drawn by the PoE devices, and port errors.

   

5. Finally, as the stepping off point of this JVD, open a Junos shell from the portal by selecting the switch you just added and then clicking Open Shell in the upper right corner of the Switches screen. From here, you have full read and write access to the switch for any further configuration changes you wish to make.

EX Series Switch Behind a WAN Router

Now it is time to onboard your switch and add it to your infrastructure. We assume in this example that we form a LAG with the WAN router and that we use the force-up method described in the previous chapter Best practices when using Link Aggregation on the uplink Interfaces”.

To assign a switch to a site:

1. In the portal, click Organization > Admin > Inventory.
   Figure 3: Navigating to Inventory
2. In the Inventory page, ensure the inventory view is set to org (Entire Org) and refresh your browser until you see all of your devices.
   Figure 4: EX Series Switch in Inventory
3. Select your new switch and click Assign to Site.
4. On the Assign Switches page:
   1. Select spoke1-site.
   2. Disable Manage configuration with Mist option. You can enable this option at a later stage, if required.
      Figure 5: Selecting Site for Assigning Switch
5. Click Assign to Site.
6. Confirm the changes in the inventory once you assign the device to the site.
7. You can see spoke1-site under New Site.
   Figure 6: Assigned Switch to Site Details
8. In the portal, go to Switches and select spoke1-site.
   Figure 7: Selecting Assigned Switch for Modification

   The page displays the list of switches assigned to the site.

9. Click the required switch to open the switch configuration page.
10. Verify the device name, then scroll down to the Switch Configuration section and check Enable Configuration Management.
    Figure 8: Configuration of Assigned Switch
11. Under Port Configuration, click Add Port Range.
    Figure 9: Port Configuration of Assigned Switch
12. On the New Port Range page, configure the following options:
    1. Set the Port IDs as ge-0/0/1 and ge-0/0/2 (two ports for the LAG).
    2. For the interface, select the default “L2 Interface”.
    3. Select the existing Configuration Profile as “Uplink”.
    4. Enable Port Aggregation.
    5. Enable LACP to detect a failed or broken link.
    6. Disable force-up. You need to enable this option only on the WAN router or if this is a distribution switch where you configure a downlink towards an access switch.
    7. Leave LACP periodic slow disabled.
    8. Set the AE Index to 0 to ensure that the AE index is the same on both sides.
       Figure 10: Port Configuration of Assigned Switch

       

13. The figure below shows the summary of the port configuration.
    Figure 11: Port Configuration of Assigned Switch
14. Save your changes.
    Figure 12: Save Changes

You’ve now added a new EX Series Switch to your Juniper Mist™ Wired Assurance deployment.

Optionally, you can confirm that your switch has the two links up by using Remote Shell as shown in the following sample output:

Troubleshooting Tips

In case you encounter any issue with the onboarding process with the Juniper Mist cloud, taking the steps below may help with resetting a device and ensure further communication to the Juniper Mist cloud. An external reference is available via the following link: https://www.mist.com/documentation/troubleshooting-switches/

Check any Firewall between EX Series Switch and Mist cloud communication

We assume that you have implemented the protocol and port openings on your firewall as described here: https://www.mist.com/documentation/ports-enable-firewall/ . For EX Series Switch management the two most important ones are:

• A TCP to destination port 2200. The EX Series Switch establishes an outbound SSH session to pass a source NAT towards the Internet which works in the following way:
  • The device uses a raw socket for a TCP connection to the Juniper Mist cloud.
  • Once the TCP connection is established, the device sends a special DMI message so that the Juniper Mist cloud gathers information such as the device serial number to determine which devices need to be managed.
  • If the Mist cloud has identified the device based on the DMI, it uses the existing TCP connection to establish a reverse SSH session back to the device with the credentials known for SSH login.

It is critical that the Firewall vendor does not attempt to apply any kind of further application-level management looking deeper into the session. It can be assumed that the special DMI message and reverse SSH login are unknown applications. This TCP 2200 port session must not be inspected deeper and must be treated as raw all the time.

• An HTTPS TLS-encrypted session towards destination port 443 towards FQDN redirect.juniper.net. This is required for the ZTP process to work and for the device to retrieve the initial config to attach to the correct Juniper Mist cloud. If for some reason this is not possible, consider the brownfield adoption method instead.
• In the future, you need to open an HTTPS TLS-encrypted session towards destination port 443 towards the Juniper Mist cloud. This is a future alternative when people cannot use the above outbound SSH method for some reason. Here, the firewall vendor can apply application-level management for the TLS session.

If you have console access to the device you can try the following check:

For the next step, you need to know the FQDN of the management instance of the Juniper Mist cloud. You get this information by going to Organization > Inventory and then selecting Switches and then clicking Adopt Switches.

In the above example, the device is managed by FQDN “oc-term.mistsys.net” so we can try to open a telnet session to port 2200.

If you see that the telnet session can be established, then this is a good sign but unfortunately not 100% certain. This is because we cannot simulate the entire process described above via telnet. Firewalls trying to apply an application check may still disconnect such a session later. The next step is to review if a session is established and not interrupted after a while.

Recover a Root Password

When you need to recover your root password, you must have a local console connection to the device and then follow the instructions here: https://www.juniper.net/documentation/us/en/software/junos/user-access/topics/topic-map/recovering-root-password.html

Remove a Virtual Chassis

If you experience an issue with a Virtual Chassis setup, in some cases you may want to reset the entire system to factory settings. The CLI output below is based on the excellent demonstration video on YouTube .

After entering the above commands on the primary switch, the primary switch will disconnect from the Virtual Chassis. Any further commands entered on this switch now go to the dedicated console port for this switch. The system will elect a new primary so try the next console port and repeat this process until all switches are finally disconnected from the Virtual Chassis and you have a dedicated console connection to all switches.

Now, go to each of your switches and depending on their member ID, issue the following commands:

As a last step, ensure all your switches display “Master” as their role (ignore the master priority for now) and don’t see any other switch as connected before you leave the lab.

Factory reload of a single device

To get an EX Series Switch back to the initial factory configuration, execute the commands shown below and then afterwards, check that it can contact the Juniper Mist cloud.

Check the device RTC Clock when having ZTP issues.

The longer a device has been sitting in stock, the more its clock may deviate. Phone home ZTP checks the server certificate and with a local clock set to the year 1970, this would not work. A best practice is to always add an NTP server to update the time which is something the Juniper Mist cloud will automatically configure once the device is managed by Juniper Mist cloud. However, this not the case yet in the factory default state when you start a ZTP process. If this happens, you can either configure an NTP server or manually set the clock as shown below:

Juniper Access Point Attached to EX Series Switch

Here, we integrate the next element to complete the branch installation which is attaching the AP to the switch to support wireless clients.

Pre-conditions That Must Be Met for AP Onboarding

To be able to execute this lab, we assume that the following conditions are met:

• The AP is cabled to our EX Series Switch and has power (through an external power supply or through PoE).
• If PoE is used, the switch must have enough PoE power left and support at a minimum IEEE 802.3af or IEEE 802.3at depending on your AP model.
• LLDP should be activated (this is not mandated) on switches and routers for debugging.
• You have completely followed the instructions from the above chapters as those include instructions for the following:
  • A DHCP server is configured for the AP management VLAN 1033 subnet 10.33.33.0/24 in this branch. In our example, that is done on the WAN router.
  • An additional VLAN 1088 subnet 10.88.88.0/24 is used for WLAN clients.
  • An additional VLAN 1099 subnet 10.99.99.0/24 is used for wired clients.
  • On the WAN router, a LAG is formed to the switch containing native VLAN 1033 and VLANs 1088 and 1099 as trunk. Keep in mind that without further changes, the native VLAN from the uplink gets assigned to VLAN 1 on the switch where irb.0 for in-band management is assigned. Providing that management VLAN then to a downstream device such as an AP needs then to reference this VLAN 1.
  • On the port where the switch is attached, the default VLAN 1 is native and VLAN 1088 is trunked. We did not add 1099 for wired clients again as the port does not need to support it.
  • The WAN router must implement some form of source NAT on the WAN interfaces to allow management traffic towards the Juniper Mist cloud.

Below is just a reminder about the minimal configuration on the switch (apart from the uplink):

How to Claim APs to an Organization?

APs can be claimed to any organization by using either an activation code, claim code, or QR code.

Activation Code

Whenever you order APs, our Sales Operations team will send you an activation code which can be used for claiming the APs and subscriptions as per the order. You can use this activation code to claim APs in one go. To claim the APs, go to the Organization > Subscriptions page and select Add Activation Code button in the upper-right corner. Once the activation code is added and activated, all the APs will automatically get claimed to the organization. You can see the list of APs on the Inventory page (Organization > Inventory).

AP Claim Code

You can individually claim APs to your organization by navigating to Organization > Inventory > Claim APs and entering in the claim code found on the back of each AP.

AP QR Code

Using our Mist AI mobile app, you can scan the QR code printed on the back of our APs to claim APs to your organization. Our app is compatible with both iOS and Android devices. Read more about it here: https://www.mist.com/documentation/mist-ai-mobile-app/

Where Can I Get the Claim Codes for the APs in My Organization?

The claim code of the AP is written on the backside of the AP where the QR code of the AP is printed.

Troubleshoot: Bringing the AP Online as “Connected” into the Inventory

We assume in this step you have used any of the methods above to claim the AP into the inventory. When you refresh the browser window after 3-5 minutes, the AP should appear automatically in the “Connected” state in the Inventory such as seen in the figure below:

If that is the case, you can skip this section now as we describe here how to troubleshoot if that is not the case.

The troubleshooting of Juniper APs is explained in detail here: https://www.mist.com/documentation/category/troubleshooting/ . This section will focus on what to troubleshoot on the EX Series Switch side to help bring the AP into the “Connected” state in the Inventory.

Note:

If the AP is not assigned to a site, it will always appear in the “Disconnected” state irrespective of its connectivity to the cloud. Remember that along with claiming the AP, assigning the AP to a site is mandatory.

If you are local to the site, check the AP’s status LED since its blinking code may indicate the error.

The first thing to do is to understand the source of the error by viewing the AP’s status LED. If you can’t see the LED on the AP, reboot it. If the AP is powered by PoE, then you can do that using one of two methods:

• Use the Bounce Ports option on the portal. Selecting the port where the AP is attached opens a pane where you can directly select to bounce a particular port which will also power cycle the attached AP.

  

  You will see a new window with information about the bounce port status as shown in the figure below:

  

  Note:

  Bouncing a port may take several minutes since two Junos configuration commits must happen as part of the process.

• Change the PoE interface configuration via Remote Shell (This option is not recommended).

If the AP is powered by an external power supply, then you must ask someone to unplug it for a while and then power it on again. The AP has no console connection like the switches.

The next step is to use a remote console to the switch to review items such as:

• Is the port that the AP is connected to showing as “Up”?
• Is the port that the AP is connected to correctly configured and forwarding packets?
• Does the MAC address of the AP appear on the expected port?
• Do you see the AP appearing as an LLDP neighbour?
• Assuming the AP is powered by PoE, what’s the actual power draw?

The following example output shows an AP that is attached to interface ge-0/0/3:

• Check if the port is administratively “up” and a physical link detected.
• Then, check that the port is in forwarding mode and that it is configured with the expected VLAN (the default VLAN in this example) and is in access mode. Also, verify that the VLAN assigned is the same VLAN that the WAN router uses for DHCP lease handouts for AP management.
• Next, check if the MAC address (also printed on the QR code) of the AP appears on the switch’s interface as expected.
  Note:

  At this point, it is appropriate to check the port authorization status of the AP as well. Sometimes it is intended that the AP authorizes itself to the switch it is attached to and sometimes this is not required, and someone accidentally applies a port profile with authentication enabled.

• Next, check if you see the AP’s MAC address appearing as an LLDP neighbour Chassis ID. The port info may be different based on the AP model you have, however the system name may help you determine more about the state of the AP:
  • When no LLDP system name is reported, then the AP has a connection issue. For example, it cannot receive a DHCP lease.
  • When the LLDP system name is “Mist”, like in the example below, then the AP is usually up but not assigned to an inventory.
  • When the LLDP system name is the MAC address of the AP or the inventory name, then it should already be in the “Connected” state in the inventory of your organization and you can start applying more configuration.
  • Should you have PoE running on the switch, you should also check the power consumption of the AP. The PoE mode negotiated depends on the AP model (usually 802.3af on 802.3at) and can be verified in the datasheet. Depending on the configuration state and radio usage, you should see differences in the actual “power consumed” report.
  • The following checks should be done on the WAN router. In our example, we use a Remote Console to a Juniper SRX Firewall acting as WAN router. You should look for the DHCP lease requests from the AP and verify that you see two sessions towards port 443 for TCP/UDP towards the Juniper Mist cloud as shown in the example below.

Day 1 Additional EX Series Switch Features Commonly Used in Branches

In this chapter, we highlight the prominent features (but not all features) tested in this JVD. Please review the Test Report and the additional information provided in the following links:

• https://www.juniper.net/documentation/us/en/software/mist/mist-wired/index.html
• https://www.mist.com/documentation/category/wired-assurance/

When do we use Dynamic Port Profiles and when do we use a NAC Infrastructure?

Port profiles can be assigned statically or dynamically based on the detected wired client. Both have their advantages and downsides which we do not discuss here. When you choose a dynamic approach, an EX Series Switch managed by Juniper Mist cloud offers the following two options:

• Dynamic VLAN/filter assignment by RADIUS/NAC infrastructure. In this case, you usually configure a static VLAN into a quarantine network that has limited access to the Internet and corporate resources and assign it as default VLAN in the port profile to be used. This is for fall through configuration in case the RADIUS authentication fails and you can’t afford all clients not being able to access the network. You then also activate 802.1x authentication for the port or 802.1x authentication and MAB (MAC address-based authentication). When the wired client then logs in to the port, the RADIUS server receives several attributes about the client such as:
  • Authentication parameters like a username or a certificate.
  • Switch name and port.
  • Wired client MAC address.

  The RADIUS server in the back end can then send a number of RADIUS authorization parameters along of the Access-Access message that describe what to assign to that port dynamically like:

  • A single access VLAN for the client.
  • Several VLANs where one is native, and the others are tagged VLANs. This is also called colorless port assignment in the literature. This is usually used when the attached device is an AP.
  • A string as filter ID that can be used to apply:
    • An ACL-based filter for local firewalling.
    • A GBP tag to be assigned to a wired client. (Does only apply in IP-Clos fabrics. This option is not relevant for this JVD discussing Branch designs).
• Dynamic Port Configuration (DPC) by Juniper Mist cloud for colorless ports. As the name indicates, this feature is limited to EX Series Switches which are managed by Juniper Mist cloud and does not work elsewhere. 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) also MAC OUI.

Note:

We recommend using dynamic VLAN/filter assignment by RADIUS/NAC infrastructure whenever possible. Especially when using Juniper Mist Access Assurance as your RADIUS/NAC infrastructure where this becomes an easy to manage task.

Let’s review these use cases and how they work:

• Use case 1: RADIUS/NAC Infrastructure present in the network

  Usually – there are two goals with enabling authentication on a port:

  • Making the system zero trust
  • Assign the devices to their relevant network segments.

In networks utilizing a RADIUS infrastructure, we recommend all ports be set to an access port with a dot1x + MAB port profile enabled. We rely on RADIUS transactions to get the network/VLAN assignments as well as assign the ports as access or trunk based on the use case. Clients could be a combination of devices that are capable of dot1x (802.1x EAP-authenticated supplicants) or all device MAC addresses are available in the RADIUS database. Please be sure to configure RADIUS servers with enhanced timers in the switch template. (Enhanced timers reduce the default fallback time from dot1x to MAB from ~120-180 seconds to ~10-15 seconds, which is highly recommended for a good client experience).

Let’s discuss the different use cases for return attributes (AVP) from RADIUS that we recommend being sent as part of the access-accept message:

• Clients that need to be assigned to a specific VLAN while the port remains an access port. Here, you use the AVP=Tunnel-Private-Group-ID. See the example configuration below:

• Clients that need to be assigned to multiple VLANs and need to be moved to a trunk port. Here, you use the AVP=Egress-VLAN-ID or Egress-VLAN-Name. See the example configuration below:
• Clients that need to be assigned to a policy as firewall-filter/ACL (In addition to either of the above two AVPs). Here, you use the AVP=Filter-Id.

  Keep in mind that before you can use a particular filter ID, you must create a filter on the switch itself. Here is an example using additional CLI:

• Another way is to assign the Dynamic VLAN based on a Port Profile but still requiring the authentication via RADIUS at least to be performed for the wired client. Hence, the RADIUS-Server in this case is not required to send back any of the above-mentioned RADIUS AVPs as part of the final Access-Accept message. Only the Access-Accept message is required and the VLAN configuration will be derived from the Port Profile. The figure below shows where this optional configuration can be made.

  

  Note:

  We do not recommend adding DPC in any of the above scenarios, hence do not turn on DPC on any of the ports in this scenario as well. This is the most preferred scenario in case you have a RADIUS/NAC infrastructure.Also, ensure that the re-auth timer is adjusted.

• Use case 2: Usage of RADIUS/NAC Infrastructure but augment some devices with Dynamic Port Configuration for the below mentioned reasons:

  All of the above AVPs listed in use case 1 still hold true. Juniper Dynamic Port Configuration however, adds the use of LLDP as an identifier for the port configuration as well as MAC OUI (the vendor bytes of a MAC address) which is usually not possible when using a RADIUS/NAC Infrastructure to manage.

  Motivation for this approach:

  • Avoid adding a lot of MACs (APs and cameras are usually volume devices) to the RADIUS user database and use LLDP and MAC OUI instead.
  • Reduce the cost of RADIUS/NAC Infrastructure, since it involves client count.

  Juniper recommends that when using VLAN allocation for some ports via Dynamic Port Configuration one should enable an additional layer of protection like 802.1x or MAC address-based authentication (MAB). The rest of the ports are to remain 802.1x or MAC address based authentication (MAB) only but then without adding Dynamic Port Configuration.

  In case you cannot predict where selected devices will be plugged in to the network, all ports need to enabled for Dynamic Port Configuration and 802.1x or MAC address-based authentication (MAB) which is the less recommended approach.

  Note:

  For both use case 1 and use case 2, when 802.1x and MAC address-based authentication (MAB) are enabled on all ports, it is critical to note that no MAC addresses will be learned until the authentication is successful. Hence, DPC via MAC-based rules will not work and should not be configured. We only recommend using DPC with LLDP-based rules when ports are enabled for 802.1x and MAB.

• Use case 3: No RADIUS/NAC infrastructure, Dynamic Port Configuration + static assignment of port profiles.

  In the absence of a RADIUS/NAC Infrastructure, Dynamic Port Configuration could be used either with LLDP or MAC rules to provision ports. The preferred approach is if one is aware of the ports that are allocated for Dynamic Port Configuration eligible devices, one should enable Dynamic Port Configuration only on those ports. The rest of the ports are to be statically assigned.

  The less preferred approach is if one is not aware of the ports where Dynamic Port Configuration eligible devices will be plugged in, enable Dynamic Port Configuration on all ports.

  We also recommend the default profile where the Dynamic Port Configuration is enabled, to be pointing to a dummy (or at least a quarantine) VLAN, so no devices get IPs when they are plugged and do not match any Dynamic Port Configuration rules.

  Note:

  Avoid using Dynamic Port Configuration if the port experiences a large 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.

  The below figure has an example where Dynamic Port Configuration is used to identify a Juniper AP by the vendor MAC OUI part of the LLDP chassis ID.

  

  Do not forget that you must activate Dynamic Port Configuration for the port by using the checkbox as the indicated by the image below:

  

  Note:

  It takes a couple of 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).

Configure DHCP Snooping for Switches

DHCP snooping enables a switch to examine all the DHCP traffic initiated from the untrusted ports on the network. When DHCP snooping is enabled on a VLAN, the system examines DHCP messages sent from untrusted hosts associated with the VLAN and extracts their IP addresses and lease information. This information is used to build and maintain the DHCP snooping database. Only hosts that can be verified using this database are allowed access to the network. More detailed information about this security feature and how it operates can be found here https://www.juniper.net/documentation/us/en/software/junos/security-services/topics/concept/port-security-dhcp-snooping-els.html

Note:

By default, access ports are treated as untrusted ports and trunk ports are treated as trusted ports.

There are three places where you can configure the DHCP Snooping/ARP Inspection/IP Source Guard in the portal:

• Switch Device Details page.
• Site > Switch Configuration page
• Organization > Switch Templates.

The configuration priority will be Switch Device Details page first, then Site > Switch Configuration page and as lowest priority Organization > Switch Templates.

Below is an example where you can enable the above configuration for a single network. There are two options you can enable for the all networks / single network as per your requirement.

In the example below, we are enabling DHCP snooping for a single network > Vlan24 (vlan-id-24).

The VLAN should be present on the switch to take the configuration effect. That’s why we need to add the port to the port profile. For the access port profile, we have the option to make it either trusted or untrusted. If it’s not set, it will be on default. Port network can be a simple network or VoIP network. A trunk port by default is always trusted.

In the example below, we make the access port trusted:

The port profile to the port would be as below:

We have the option for the override site/template settings for DHCP snooping from the site settings and device settings:

Site settings:

We have the options for overriding the trusted/untrusted/default options for port profile from the site settings and device settings.

Site settings:

Device settings:

Enabling DHCP snooping will allow the Juniper Mist cloud to show IP Address information when reviewing the Clients Table. Unlike a campus fabric deployment, the switch has no VRF configuration and is a pure Layer 2 forwarder. Hence, the switch is usually not enabled for ARP resolution as a default gateway and would not be able to gather such information automatically and report it to the Juniper Mist cloud.

Command to configure DHCP snooping:

Command to check the DHCP snooping table locally on the switch like in the example below: