Mist Edge Design Guide

Mist Edge provides centralized Datapath for user traffic traditionally performed by legacy wireless controllers, while keeping all the control and management functions in the Mist Cloud, providing micro services architecture to the campus. With Mist Edge solution customers can retain their centralized Datapath, providing the same level of redundancy and access to corporate resources, while extending visibility into user network experience and streamlining IT operations through cloud management.

Here are a few benefits of the Mist Edge in a Centralized architecture solution.

Agility

• Zero Touch Provisioning – no AP pre-staging required, support for same AP to tunnel to multiple locations and any number of cluster support
• Exceptional support with minimal effort – leverage Mist SLEs and Marvis Actions
• No firmware dependency between AP and Mist Edge, Mist Edge services can be updated independently and takes less than 3 seconds to update.
• Additional Mist Edges can be easily introduced for horizontal scale increase of APs or users.

Security

• Traffic Isolation – same level of traffic control as original WLC architecture. Transparently move user traffic to a single central location, isolating it from your access switches, dramatically simplifying the deployment, as well as providing full BUM traffic flood gates, increasing overall efficiency at scale with tens of thousands of concurrently connected clients.
• Automated Security – machine-driven site deployment, no credential exposure.
• Secure WebSocket to talk to the cloud
• IPSec tunnel support for remote worker deployments.

Resiliency

• Supports High Availability, Failover, Auto-preemption and Load balancing

Scalability

• Can scale from few branches to Thousands of them.
• Can support Campus with a few hundred APs to Thousands of them.
• A single Mist Edge (X-10) can support 10000 AP and 100000 Clients.
• No limitation scaling horizontally within a cluster, i.e. dozens of Mist Edges can be within a cluster

Architecture and Key components

The components of the Centralized Architecture solution include the following.

• Mist APs
• Mist Edge Appliances

This guide aims to cover the deployment and configuration recommendations for Mist Edge.

Mist Edge Use Cases

• Centralized Datapath Architecture for Campus/Branch deployments
  • Mist Edge offers High Availability and Clustering capabilities, including load balancing, failover protection, and preemptive functionality for optimal performance and reliability.
  • Edge provides seamless roaming through on-premises tunnel termination of traffic to and from access points.
  • Traffic Isolation by extending one or multiple VLANs from Mist Edges located at Campus, Data Center or DMZ simultaneously.
• Remote Worker use-cases, which leverages IPsec tunnels from Aps to Mist Edge to offer secure and reliable networks to remote end users.

Mist Edge Configuration Components

Mist Edge offers a simple, yet powerful configuration scheme orchestrated by the cloud.  The configuration objects needed to deploy Mist Edge in your network are discussed below:

Mist Edge – Hardware or virtual appliance.  Just like the APs, the Mist edge comes with a claim-code (hardware appliance only) and this can be claimed via UI or scanned by an app to add to an organization inventory.  Within the Mist Edge configuration, configure the Tunnel IP.  That is the IP or Hostname to which APs will form a tunnel.

Mist Edge Cluster – Mist Edges need to be a part of a cluster to actively terminate tunnels from AP. A cluster can have a single edge to multiple edges. Under normal operation, the members within a cluster will be in active-active mode and load balance all the AP tunnels.  The UI allows for configuring a Primary and Secondary cluster, however via the API there is no limit to the number of clusters that can be configured.

Mist Tunnels – The Mist tunnel object contains the attributes that determine the tunnel protocol, endpoints, tunneled vlans, tunnel failover timers, auto-preemption and more. The tunnel configuration decides the primary cluster and secondary cluster for AP tunnel termination.  APs will load balance across Mist Edges in the primary cluster.

AP scale considerations

The Juniper Mist cloud solution can scale to manage, configure and monitor thousands of APs without the need for an on-premises controller managed topology. If the solution calls for centralized datapath, Mist Edge fits right in to simply replace the existing incumbent solutions.  Choose the appropriate edge for your deployment by utilizing the following metrics to ensure it meets your scale requirements. We leverage Mist Edge in our largest and most demanding environments.  For medium and large campus deployments, we recommend Mist Edge- X5-M device with 80 percent max AP capacity under nominal conditions.

Client scale consideration

As the number of wireless devices continues to grow, it’s crucial to design your wireless network in a way that safeguards your wired infrastructure. By deploying Mist Edges, you can effectively manage BCMC traffic, prevent excessive flooding and avoid mac table overflow.

• For deployments with an expected number of wireless clients exceeding 2000 in a segment (across all VLANs), we recommend considering if Mist Edge is appropriate for your deployment.
• For deployments exceeding 100K wireless clients, we recommend configuring multiple tunnels carrying traffic from different WLANs from APs to 2 or more multiple mist edge clusters that do not share the same L2 VLANs (geo-segmentation). The edges can be housed in same DC or can be geographically separated.

Design consideration for L2 Redundancy

APs located at multiple sites can effectively terminate tunnels to Mist Edges that belong to the primary cluster (active/active), as specified in the Mist Tunnel Configuration. To ensure L2 redundancy, the cluster must consist of a minimum of two Edges. This arrangement provides robust network coverage and enhances overall system reliability. Regardless of the number of Mist Edges in a cluster, all the edges will be active and the ap tunnels will be load balanced across them. The cloud decides and pushes down a list of the mist edges for tunnel termination. Each AP receives a list with a different order of edges, the order of the edges determines the preferred edge for the AP.

If multiple sites are tunneling traffic to a cluster with more than one edge, aps from within a site may terminate tunnels on different edge. This is the default behavior and recommended, since it achieves optimal load balancing. However, this behavior can be fine-tuned to tunnel traffic from a particular site to terminate on a single edge. This can be configured through the Tunnel Host Selection section under the Mist Clusters in the UI.

If multiple mist edges reside on the same L2 segment in your network, we recommend them to be added to the same cluster in active/active mode. We recommend to design for 80 percent capacity on Mist edge. For ME-X5-M SKU, which supports a max of 5000 AP tunnels, we should plan for 4000 AP tunnels which is 80 percent of the max tunnels. In case of multiple Mist Edge loss situation, the tunnel terminator service can be oversubscribed temporarily.

The “Shuffle” option is the default behavior. “Shuffle by site” will configure APs on a single site to terminate on a single edge within a cluster. Remember to plan for the capacity of the edge based on the largest AP site if choosing “Shuffle by site option”.

Design considerations for Data Center Redundancy

When designing data center redundancy or L3 separated networks, Mist Edges should be partitioned into Primary and Secondary clusters. All the Mist Edges that are part of Primary Cluster are active and the Edges in Secondary Cluster are in a standby mode. Each cluster in the distributed data centers may have one or more mist edges.

L3 redundancy can also be achieved with one edge each in Primary and secondary clusters. This will be an active standby deployment.

The user interface provides the capability to handle up to two cluster failovers, making it an optimal solution for a majority of campus deployments. However, if additional levels of failover protection are necessary, this can easily be accomplished through API integration, allowing for custom configuration to meet specific requirements.

In case of distributed datacenters, separated geographically, Site A geographically closer to data center A, can be assigned Mist Cluster A as the primary cluster and Mist Cluster B in data center B and the secondary cluster. Site B can be assigned to actively terminate tunnels on cluster B, which is serving as primary cluster and use cluster A as secondary cluster. Refer to diagram and configuration below. Note: AP does not form concurrent tunnels to a secondary cluster member, dotted lines are for illustration only.

The configuration for the above deployment can be achieved using the UI on the Mist Tunnel page. Select the tunnel and configure the Primary and Secondary cluster options. The same tunnel object can be used for mapping the tunneled WLAN, found in WLAN configuration, at multiple sites which need to have “Mist Cluster A” as the preferred cluster and “Mist Cluster B” for L3 redundancy. Mist APs do not support simultaneous active and standby tunnels.

Site A, B, C Tunnel Configuration

Site D, E, F Tunnel Configuration

Failover Tunnel Timers

The failover timers control how quickly an AP will fail over to another Mist Edge and can be finely tuned to fit your application needs. Configuring a very aggressive failover timer is not recommended if the network suffers from latency and jitter. Below are the recommended values that can be configured under a specific Mist Tunnel.

“Hello Interval” is in seconds between 0.5 and 300, default is 60 seconds.  It is used as a heartbeat to detect if a tunnel is alive. AP will try another peer after missing N hellos specified by “Hello Retries” (integer between 1 and 30).  The retries after missing the first hello interval will start from 0.5 sec for one retry, 1 second for two retries, 2 seconds for three retries and so on, doubling for each additional retry.  To calculate the total worst case failover, you would add the hello interval in seconds and add the hello retry time.

Recommended Timers

When APs tunnel traffic to multiple edges, failover timers for the VLANs carrying application-sensitive data can be fine-tuned on a per-tunnel basis between AP and Edge for optimal performance.

Additional Features

Auto Preemption

In the event of a temporary network disruption or issues if an ap is unable to reach or exchange hellos successfully with their preferred edge, the ap will failover to the next edge within the L2 cluster or to its secondary L3 cluster. Auto preemption is a mechanism through which aps are nudged to terminate the tunnels on the preferred peer, given that the peer is reachable.

Auto Preemption is disabled by default. With the default presets, if an ap tunnel failovers to a non-preferred edge, it will continue forwarding traffic to that edge. These ap tunnels can be manually moved by preempting or disconnecting the tunnels through API or UI.

The preemption configuration is done at individual Mist Tunnels. When enabled, the cloud orchestrates the preemption and slowly moves the ap tunnels to preferred edges to cause the least traffic disruption. A service running in the cloud monitors for any APs that have failed over from a preferred edge, given that the edge is up and healthy. Based on the option selected from below, the cloud will nudge the AP to disconnect from the current edge and move to the preferred peer. Clients on the AP are not deauthenticated.

The service is disabled by default. You have two options when enabling this service:

• Every 15 mins – If the connectivity between the APs and the mist edge cluster is jittery, AP tunnels may end up failing over to a Mist Edge from a secondary cluster. This may cause clients to do a RE-IP, if the secondary edge is in a L3 separated data center with a different IP schema. In such cases, we recommend to use the option of every 15 mins.
• Time of the day – This option allows the customer to specify a time and date during which they want to move APs back to the preferred edge, if they have failed over between the specified times. We recommend choosing a time and day when your network is least busy.

Dual Tunnel

Mist APs can be configured to tunnel traffic to two different Mist Edge Clusters that are geographically or L3 separated in the WLAN configuration page. This is the recommended architecture for customers migrating from legacy controller architecture that do anchor tunnel or site to site tunnels.

Incase if the recommended architecture is not possible, due to the underlying network architecture, Mist Edges support Anchor Tunnels or Site to DMZ tunnels. This is covered in the next section.

Anchor Tunnel

For deployments that require traffic to be tunneled to a DMZ area further into the data centers, Mist Edge can be configured to carry all traffic to DMZ and the specific traffic can be further tunneled to another Mist Edge. Anchor tunnel carried traffic between two Mist Edges. Anchor tunnel can be configured from the Mist Tunnel page.

Site Edges

For deployments that require traffic to be tunneled at each site due to the underlying network constrains or security concerns, the Mist edge can be configured as Site edge.  Site Edge would optionally be configured when only APs from a single site need to be tunneled to a Mist Edge. Site Edge can also be useful for when you have many sites with site specific Mist Edges, and you want to reuse a WLAN template for ease of operation.  The basics of the mist edge configuration and working mostly remain the same. The edge once claimed needs to be assigned to a Site, like an AP. Configuration for the edge will be managed from Site-> Mist Edge. Mist Tunnel properties and failover preference need to be specified from the specific site settings.

Remote Worker

Juniper Mist Edge extends virtual LANs (VLANs) to distributed branches and telecommuters to replace remote virtual private network (VPN) technology. Provides dynamic traffic segmentation for IoT devices. Split tunneling allows for guest access and corporate traffic. Please refer to the Mist Teleworker guide to configure Mist Edge for remote workers.

Zero Touch Provisioning (ZTP)

Mist Edge can be onboarded an ZTP to the cloud just like APs.  Hardware devices need to be claimed using the order activation code or claim code on the device in your Organization under the Mist Edge page. Once claimed, the device will show up in the list and be pre-configured even before the device is brought up online. We recommend that admins pre-configure the device.

Successful ZTP process requires two pre requisites –

• DHCP IP that can be routed to reach the mist cloud
• Port 443 needs to be opened up on the firewall for the device to establish connection with ep term. The FQDN and port information for all the cloud environments can be found here.

IP address and Port configurations

Each Mist Edge needs a minimum of two IP addresses. The requirements are discussed below:

Out of Band Management IP – Mist Edge has a dedicated interface to communicate with Mist Cloud, receive configuration, send stats and status for services running on the edge. The interface expects a DHCP IP with access to the mist cloud by default to successfully complete the ZTP process. The DHCP OOBM IP can be changed via the UI to use static IP after successful configuration.

We highly recommend using DHCP for OOBM IP but in cases that DHCP is not available, user can login into the Mist Edge using the credentials and manually assign the IP address.

Tunnel IP – This is the interface to which APs form the tunnel. This is configured on the UI in the Tunnel IP section. This need to be done for every Mist Edge. This IP needs to be reachable from the AP subnet.

OOBM IP and Tunnel IP are different IP addresses and need to be from different subnets.

Data Port – The Data Ports need to be plugged into your upstream router setup as trunk port that has all the VLANs trunked for the tunneled WLANs. The data port can be configured in single arm or dual arm configuration. Mist Edge auto detects port channel (LACP).

• Single Arm – Ports configured as single arm will carry both upstream and downstream traffic. 1 or more ports can be configured and detected as single LACP.
• Dual Arm – Ports in dual arm setting will carry upstream and downstream on two different ports. Dual arm port configuration will be detected as two LACPs.

Downstream data is the tunneled(encapsulated) traffic originated from the AP. Upstream is the client(decapsulated) traffic towards the upstream resources in your data center.

 LACP status can be monitored under the Mist Edge insights as shown below.

Port Configurations

• For dual arm deployments, Mist Edge automatically configures the upstream data ports as a trunk and the VLANs configured under the Mist Tunnels are added as tagged VLANS.
• For single arm deployments, Mist Edge configures the tunnel IP VLAN as its untagged/native VLAN and trunk the VLANs configured under the Mist Tunnels are added as tagged VLANS.

Advanced use cases where specific VLANs need to be mapped to the upstream data ports can be achieved through API.

Below are some screenshots of different ways the Mist Edge ports can be configured in Single/Dual arm deployments.

Single ARM Examples:

Dual ARM Examples:

Mist Edge Services

Critical Resource Monitoring (CRM)

Mist Edge can be configured to monitor the health of the upstream resources which helps determine the reachability of those resources from the Mist Edge data ports. In the event that the health check of the upstream resource fails, the Mist Edge prompts the APs to failover to the next member and shuts down the tunnel terminator service, temporarily, until the upstream resources are healthy and reachable again.

The upstream resource monitoring is configured under the Mist Cluster screen. It is disabled by default. Protocols to monitor a resource include ARP, PING and TCP. Multiple resources using different protocols can be configured to monitor the health check. Even if one of the health check fails, the Mist edge will prompt the APs to failover to another edge. Commonly used health checks are ARPing or PINGing the default gateways.

RadSec Proxy Service

Mist edge can be configured to run a cloud managed RadSec proxy service. The configuration for RadSec proxy can be done from the Mist Cluster page. RadSec Proxy service can be deployed to securely proxy authentication requests from the AP. This service is used for remote AP deployments to provide a way for remote users to successfully authenticate to the network and to provide the same experience as inside the office

• If the APs have connectivity to the AAA servers, we recommend to APs to directly communicate to the AAA servers. Make sure to configure the AP subnet and secret as radius clients on the server. When NAS IP field is left blank in WLAN config AP will use its IP Address as the NAS-IP-Address.

Mist Edge uses the OOBM as the source IP by default for proxying the AAA requests. It can be changed to use the tunnel IP as source by checking the box “Tunnel IP as Source”. TCP Port 2083 needs to be allowed between the AP and Mist Edge for the incoming TLS tunnels from the AP and the configured RADIUS ports need to be allowed between the Mist Edge and AAA server(s).  The appropriate IP and shared secret needs to be added on the AAA server. We also support different AAA server per SSID and Key Wrap which are disabled by default.

QoS

By default Mist Edge tunnels the packets by preserving the inner packet’s DSCP by copying it onto the outer L2TP packet.

Mist Edge can also run DHCP Proxy and IGMP snooping services that are configured under the specific Mist Edge page.