Help us improve your experience.
Let us know what you think.
Do you have time for a two-minute survey?
We introduce Microsoft Teams integration with Juniper Mist. The integration enables Mist to provide you with insights into all the Teams calls that took place in your network. You can use this data to debug any bad user experience with Teams. Mist gathers information about Teams calls from the Microsoft Azure cloud, and correlates it with the wired, wireless, and WAN network insights. The correlated Teams insights are displayed on the Monitor > Service Levels page at the site and individual client level.
To integrate your Teams account with your Mist organization, use the Link Account option on the Application Insights Integration tile on the Organization > Settings page.
You can use the Marvis Conversational Assistant to query the Teams calls and troubleshoot any issues with them. Using the Marvis Conversational Assistant, you can:
List all Teams calls.
List bad Teams calls.
Troubleshoot the Teams application based on the client MAC address, hostname, and site. You can troubleshoot the issues reported during the last 7 days.
Note: This is available for beta trials currently.
Before you submit a support ticket against a site, device, or client, you have an option to perform a quick troubleshooting from the ticket creation screen itself. The support ticket creation page, accessed from the help (?) menu, has a Marvis launch button against each of the following fields: Impacted Sites, Impacted Devices, and Impacted Clients. To initiate a troubleshooting operation, click the Marvis button and then select the item (site, device, or client) that you want to troubleshoot. You need a Marvis subscription to be able to use this feature.
For many years, Mist has supported WLAN authentication with a variety of multi pre-shared key options. With the advent of WPA3 Personal, those MPSK options are limited to WPA2. We are taking the first step of adding multiple passphrase support with WPA3. We don’t have all the bells and whistles we have with WPA2, and we may never due to the nature of Simultaneous Authentication of Equals (SAE) authentication.
We have added support for WPA3 Personal multiple passphrases with RADIUS lookup (RADIUS PSK) and use the same RADIUS AVPs as WPA2 RADIUS PSK. Please note, only MAC based lookups are supported. MAC-less is not supported.
RADIUS AVPs for RADIUS PSK:
Attribute Name | Vendor ID | Attribute Number | Attribute Format |
Cisco-AVPair | 9 | 1 | String |
Format:
psk-mode=ascii & psk=<passphrase> |
You can configure this option on the Security tile on the Site > WLANs > WLAN Name page. You need to enter RADIUS servers as well in the RADIUS configuration. The keys are stored on the external RADIUS server.
WPA3+WPA2 Transition is supported and so is 802.11r fast roaming.
To configure the multiple passphrase option with WPA3, you need AP firmware version 0.14 or higher.
In the dynamic VLANs configuration on the WLAN page (Site > WLANs > WLAN Name), we have renamed the VLAN type ‘Airespace (airespace-interface-name)’ as ‘Named’, and ‘Standard (Tunnel-Private-Group-ID)’ as ‘VLAN ID’. We have also updated the labels ‘Static VLAN ID’ and ‘Dynamic VLAN ID’ to ‘Static VLAN ID(s)’ and ‘Dynamic VLAN ID(s)’, respectively.
A Named VLAN supports Airespace-Interface-Name or Tunnel-Private-Group-ID RADIUS attributes and can be specified as a single VLAN, a pool of VLANs, or as variables. A VLAN ID supports Tunnel-Private-Group-ID RADIUS Attributes and can be specified as a single VLAN, VLAN range, or as variables.
Sometimes you need to prevent a client from accessing the network. For the past couple of years, the Banned Client feature for Wi-Fi clients relied upon a cloud assisted lookup to determine if the client should be banned after a successful authentication. The positive of this is that it allows for a large list of banned clients.
However, there are times when you may want to ban the client straight away and it may not be feasible to have the client perform a successful authentication. So now, in 0.14 firmware or newer, with less than 512 clients in the banned client list, the AP will perform the ban locally without cloud assist and before authentication.
Here is the new Banned Client behavior based on firmware versions and the number of banned clients:
You can add clients to the banned list from the View Client Classification window on the Site > Security page, as shown below. The banned client can apply to the site, or to the entire organization. Remember to also enable the Prevent banned clients from associating setting on the WLANs you want clients to be banned.
The AP list page now displays a firmware upgrade recommendation message for the APs that are running outdated firmware versions. The message is displayed to Super Users only as a banner text on the top of the page and also as a hover text that appears when you hover over the warning icon in the AP status column. The hover text also provides a hyperlink to additional documentation pertaining to the firmware upgrade. For more information, refer to the Firmware release notes page.
You can now add new members to a Virtual Chassis, or renumber or replace the existing members in a Virtual Chassis, by using the Modify Virtual Chassis option on the switch details page. This option replaces the Edit Virtual Chassis option on the Utilities menu on the switch list (the Switches page).
The Modify Virtual Chassis option is available for a switch only if its configuration is managed by Mist. This workflow leverages the Junos preprovisioning method which specifies the role and serial number of all members in a Virtual Chassis. To learn more about preprovisioning, see Example: Configuring an EX4200 Virtual Chassis Using a Preprovisioned Configuration File.
The Virtual Chassis formation workflow
This workflow remains the same. However, the Virtual Chassis is preprovisioned for all new Virtual Chassis formed via the cloud. The Virtual Chassis formation on the Mist cloud using the Form Virtual Chassis option on the switch list page is applicable only to the following three platforms: EX2300, EX4650, and QFX5120. All other EX Series and QFX Series platforms form a Virtual Chassis automatically when the dedicated VC ports are connected between two or more members.
The Modify Virtual Chassis workflow:
This workflow applies to all the EX Series and QFX Series platforms that support Virtual Chassis. Here are the enhancements to this workflow:
Renumber members within a Virtual Chassis: You can move around the port panel of a switch to change the order of the member. The order is incremental. The first entry is member 0, the second is member 1, and so on. You are required to specify the FPC0.
Changing the role of a member: You can change the role of a member to a primary or backup routing engine. All other members will assume the role of a linecard member.
Deleting a primary, backup, or linecard member: You can delete the members that are disconnected from the Virtual Chassis. To delete, click the trash icon.
Replacing a member: You can replace a disconnected Virtual Chassis member with another, by deleting the old member and adding a new switch.
Adding a member: You can add new member switches to the Virtual Chassis by clicking the Add Switch button.
For the Add Switch feature to work, you must ensure the following:
The new switch is of the same model as the other members in the Virtual Chassis.
The new switch runs the same Junos version as the other members.
The new switch is connected to the network.
The new switch is assigned to the same site.
Within a Virtual Chassis, you cannot renumber, move around, or delete FPC0 unless it is disconnected. It is the device identifier for connectivity to the Mist cloud.
When you delete an FPC0, replace it with an existing member in the Virtual Chassis. You cannot add a new member during the deletion of the FPC0.
Prior to modifying a Virtual Chassis, you must delete any additional CLI commands related to the Virtual Chassis because those CLI commands take precedence over everything else.
The Add Switch dropdown will only show switches that meet the following criteria:
The switch should be a part of the same site. The switch models with dedicated Virtual Chassis ports can be in connected or disconnected state. However, for modifying an EX2300, EX4650, or QFX5120 Virtual Chassis, the members should be in connected state.
The switch is of the same model family.
The switch configuration is managed by Mist.
The switch is not currently part of the same or another Virtual Chassis.
The switch runs the same major firmware version as the existing members.
The Modify Virtual Chassis button is disabled when Configuration Management is disabled.
The Modify Virtual Chassis button is available and visible only to Super Users and Network Admins.
Though the switch templates provide scalability, you had to still configure some device-specific fields such as IP addresses, Router-ID, Name individually on each device. You no longer need to manually configure these settings. Instead, you can import the following switch-specific configurations to Mist via a CSV file: MAC address, serial number, switch name, switch role, router-ID, IP configuration (OOB), Primary IP (In-Band), and Default Gateway (In-Band). The option to import the settings is available on the switch list page. To import the settings, select the switches that need to be configured and then click the Bulk Upload Configuration button.
The Bulk Upload Configurations window provides the required guidelines for you to perform the import. You can download a sample CSV file from the Bulk Upload Configurations window, update it with the required information in accordance with the guidelines provided, and then upload the file back.
If you specify any networks or L3 interfaces on the Bulk Upload Configurations window, you can configure settings for the specified networks and interfaces. Networks are specified if you want to configure additional IP addresses on individual devices as IRB interfaces.
You must not modify the header fields, MAC addresses, and the serial numbers in the CSV file.
You can configure port mirroring on switches at the organization level (Organization > Switch Templates), site level (Site > Switch Configuration) and device level. Port mirroring is the ability of a device 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.
On the Switch Detail page, we have made the following enhancements to the bulk port action functionality:
On the port selection view, the Edit Port Configuration port action has been replaced with Add Port Range under Port Configuration. This new implementation is consistent with the original Add Port Range on Switch Detail page.
When you select multiple ports from the front panel view, the configuration page filters the Port Configuration, Networks, and Port Profiles settings applicable to the selected ports. If the selected ports do not have any configuration, the Port Configuration, Networks, and Port Profiles tiles are displayed without any data.
When you select a single port from the front panel view, the configuration page filters port Statistics and Wired Client insights in addition to the Port Configuration, Networks, and Port Profiles settings.
When you add a port range by using the Add Port Range option in the Port Configuration tile, the New Port Range window prepopulates the Port IDs field with the ports you selected on the Front Panel view.
Different sites may have unique DNS or RADIUS configurations. Mist now supports these use cases by providing an option to configure DNS Settings (Servers and DNS Suffix), NTP, and RADIUS servers as site variables at the switch template level. Site variables provide a way to use tags to represent real values so that the value can vary according to the context where you use the variable. This means the same variable can configure different values in different sites. You can configure DNS, NTP, and RADIUS as site variables on the organization-level switch templates:
As each site has a corresponding value, the site variables are resolved on each device as shown below:
We have added two new Sub-Classifiers to the Successful Connect metric in the Wired SLE framework. The Successful Connect metric tracks the percentage of successful authentication and DHCP requests initiated when a client initially connects to a wired port.
The following are the new Sub-Classifiers added:
To further simplify the cloud-to-cloud integration with Juniper Secure Edge (JSE), WAN Assurance now supports autoprovisioning of JSE tunnels. JSE provides full-stack Secure Services Edge (SSE) capabilities to protect web, SaaS, and on-premises applications. When combined with Juniper’s AI-Driven SD-WAN, JSE provides a best-of-suite SASE solution that helps you deliver seamless and secure end-user experiences. It leverages the existing architectures and grows with them as they expand their SASE footprint. Using Mist with JSE, you can decide which portion of the traffic (originated from the LAN side of a spoke or a hub) must be inspected before it is allowed to transit to the Internet.
The JSE autoprovisioning process involves the following steps:
Provide your Mist organization with user credentials (email address and password) required to integrate Mist cloud with the secure WAN edge provider (JSE). You can configure credentials from the Secure WAN Edge Integration tile on the Organization > Settings page.
Note: This should be the credentials of the user created on the Juniper Secure Edge portal.
Configure a JSE provider with the Juniper Secure Edge (Auto) option enabled from the Secure Edge Connector tile on the WAN Edge template on the Organization > WAN Edge Templates page.
Note: The SRX Series devices do not support multiple primary and secondary WAN interfaces in a provider profile. An SRX Series device can support one primary WAN interface and one secondary WAN interface in a provider profile.
In the Number of Users field on the SECURE EDGE CONNECTOR AUTO PROVISION SETTINGS, enter the maximum number of users supported by the JSE tunnel. This option is available only if you have configured a JSE provider as mentioned in the previous step.
When you assign a template enabled with the Juniper Secure Edge (Auto) option to a site, an associated JSE site (location object) is automatically created and a tunnel from the device to the closest network point of presence (POP) is brought up.
For the Secure Edge Connector configuration to take effect, you must create an application policy with Mist Secure Edge Connector-to-Juniper Secure Edge traffic steering.
For more information, see IDP-Based Threat Detection for SRX Series Firewalls and IDP-Based Threat Detection on Session Smart Routers.
You can add exceptions to your Intrusion Detection and Prevention (IDP) Profiles by configuring them with bypass profiles. An IDP profile can have multiple bypass profiles, each with multiple bypass rules. The option to add bypass profiles is available only for the IDP profiles of the following types:
Standard – The Standard profile is the default profile and represents the set of IDP signatures and rules that Juniper Networks recommends. Each attack type and severity has a Juniper-defined, non-configurable action that the IDP engine enforces when it detects an attack. The possible actions are as follows:
Close the client and server TCP connection.
Drop the current packet and all subsequent packets
Send an alert only (no additional action).
Strict – The Strict profile contains a similar set of IDP signatures and rules as the standard profile. However, when the system detects an attack, this profile actively blocks any malicious traffic or other attacks detected on the network.
Critical – Only SRX – (Applicable only to the SRX Series devices) This profile detects critical attack signatures and takes the recommended action. Note that Mist recommends the ‘Critical – Only SRX’ profile for SRX300 line of firewalls.
To know about these profile, see IDP-based threat detection (SRX) and IDP-based threat detection (SSR). You can create IDP bypass profiles from the Organization > Application Policy page.
You can create bypass rules against specific destination IP addresses, attack names, and severity.
To help you scale your hub architecture horizontally, we have introduced hub groups. Each hub group can support up to 31 hub endpoints, helping you overcome the previous limit of 31 hub endpoints per overlay. With this change, you can use hub groups to increase the number of overlay paths.
The configuration workflow involves the following:
Configuring the hub group on the hub profile. Supported values range from 2 to 128. If you want to add multiple hubs to the same hub group, configure the same hub group value on all the hub profiles involved. The value 1 represents the default hub group.
Selecting overlay paths to hubs (OVERLAY HUB ENDPOINTS) on a spoke device. The endpoints are filtered under each hub group configured. You can do this from the WAN configuration section on a spoke device details page (WAN Edges > WAN Edges > WAN Edge name) or in a spoke template (Organization > WAN Edge Template > WAN Edge template name).
The hub profiles let you control the selection of path for the traffic going from hub to spoke. To do this, follow the steps below:
Configure hub-to-spoke overlay endpoints in the HUB TO SPOKE ENDPOINTS section on the hub profile. Starting in this release, Mist lets you specify hub-to-hub and hub-to-spoke endpoints separately. The hub-to-spoke configuration field consists of two parts – a read-only part that shows the hub profile name and an editable part in which you configure an endpoint name. Note that we have replaced the field label Overlay Hub Endpoint with Default Endpoint and moved it to the HUB TO SPOKE ENDPOINTS section.
Specify the hub endpoint (configured in the previous step) on the spoke device details page (WAN Edges > WAN Edges > WAN Edge Name) or spoke template (Organization > WAN Edge Template > WAN Edge Template Name). You can select the hub endpoint on the spoke from the OVERLAY HUB ENDPOINTS field in the WAN configuration section. These endpoints are listed per hub group.
After configuring the endpoints, use them in the traffic steering configuration on the hub (on the Organization >Hub Profiles > Hub Profile Name page) to steer the traffic going from hub to spoke. You can choose from the following three strategies: ordered , weighted, and ECMP. Based on this selection, traffic will be steered through the corresponding paths from hub to spoke.
We have introduced the following options on the Networks page (Organization > Networks):
Advertise to Other Spokes: Enable this network to advertise the network prefix to other spokes. This option is enabled by default. If you want the network to advertise this prefix only to the hubs, but not to other spokes, disable this option.
Advertise to Hub LAN BGP Neighbor: By default, this network prefix is advertised to any LAN BGP neighbor at the hub. If you do not want the network to advertise this prefix to the hub LAN BGP neighbors, disable this option.
Overlay Summarization: Enable this network to summarize the network prefix advertised to the overlay. For instance, Mist can summarize 192.168.1.0/24 to 192.168.0.0/16. This feature limits the number of BGP updates received by a hub from each spoke and sent by the hub back to all the other spokes.
LAN BGP Summarization: Enable this network to summarize the network prefix advertised to the LAN BGP neighbor. For instance, Mist can summarize 192.168.1.0/24 to 192.168.0.0/16.
You can specify a preferred path for the traffic going from a spoke device to the BGP-learned prefixes, by configuring overlay path preferences in the routing policies on the spoke devices. This feature allows you to determine which hub the traffic should pass through. You can do this by performing the following steps in the BGP section on the spoke device details page (WAN Edges > WAN Edges > WAN Edge Name) or in the spoke device template (Organization > WAN Edge Templates):
Configure a BGP group with Overlay selected as the peering network.
Configure a routing policy with the intended overlay path preferences in the policy term. The OVERLAY PATH PREFERENCE field populates the overlay endpoints defined in the WAN configuration section of the spoke device.
Select this policy as the Export policy on the Edit BGP Group window.
You can now configure WAN Edge devices to block traffic at URL subcategory level. This feature provides you with more granular control in blocking traffic as it allows you to define application policies for a subset of URLs. You can select URL subcategories from the application creation screen (Organization > Applications > Add Applications).
Previously, Mist supported configuration of application policies for URLs at the category level, which would mean applying the same policy to multiple URL subcategories.
The WAN Edge front panel now displays LTE interface-specific information for compatible SSR and SRX devices. The front panel has a port icon to represent LTE interfaces. You can hover over the port icon to view the following LTE-specific information along with interface status details: Received Signal Strength Indicator (RSSI), Reference Signal Received Power (RSRP), Signal-to-Noise Ratio (SNR), Integrated Circuit Card ID (ICCID), International Mobile Equipment Identity (IMEI), and International Mobile Subscriber Identity (IMSI).
SRX devices with a DHCP server configured send the following additional DHCP client information to the Mist cloud: Client, MAC Address, and Device Type. You can view these details along with the number of applications, TX bytes, RX bytes, and total bytes in the Applications section of the WAN Insights page.
We have added additional network segmentation support on SSR devices through custom VRs (virtual routers). This support is already available for SRX Series devices. You can create a custom VR from the LAN section of your WAN edge device details page or from the WAN Edge template. In the LAN section, select an existing VR from the ‘Custom VR’ drop-down list or create a new custom VR.
The Mist Edge Radius Proxy service now supports Change of Authorization (CoA) operation. CoA is a mechanism that supports changing the authorization of a user or device dynamically after they were authenticated.
For this feature to work, you need the AP firmware version 0.14.29091 or higher.
The configuration involves the following steps:
On the Mist Edge,
Enable RADIUS Proxy. You must select Proxy to External RADIUS server as the RADIUS Proxy type. In the RADIUS Proxy section, select the Tunnel as Source option if you want the requests to come from the Tunterm IP. If this option is not selected, the request comes from the out of band management (OOBM) interface.
Configure the CoA/DM server on the Mist Edge to receive the CoA Request packets or Disconnect Request packets from a specified set of Dynamic Authorization Clients (DACs). The CoA/DM server configuration includes a server IP and a shared secret. You can also set the inclusion of an event timestamp to be mandatory or optional. This configuration enables the Mist Edge to listen in on the CoA port (UDP 3799) for any incoming CoA Request or Disconnect Request packets from the RADIUS server.
To configure these settings on an organization-level Mist Edge, navigate to Mist Edges > Mist Edge Name > Mist Edge Cluster. To configure this for a site-level Mist Edge, go to the Organization > Site Configuration > Site Name page.
On the WLAN page,
Select a supported security type. The following security types are supported: Enterprise (802.1X), Personal (SAE/PSK) + MAC Address Authentication by RADIUS lookup, OWE + MAC Address Authentication by RADIUS lookup, Open Access + MAC Address Authentication by RADIUS lookup.
Set the Authentication Servers to Mist Edge Proxy and enable CoA.
Enable VLAN Tagging and set Custom Forwarding to Mist Tunnel (for an organization-level Mist Edge) or to Site Edge (for a site-level Mist Edge).