JN0-457

Mist Cloud Microservices Architecture

The Mist platform is built on a cloud-native microservices architecture deployed on AWS across multiple global regions. Each service (telemetry, config, events, Marvis AI, location) runs as an independent, horizontally scalable container orchestrated by Kubernetes. This design eliminates the single-controller bottleneck found in legacy WLAN architectures and enables per-service rolling upgrades without downtime.

Telemetry Ingestion & Data Lake

Every Mist AP streams state changes, SLE metrics, and client events to the cloud over a persistent TLS WebSocket connection on port 443. Data is ingested into a Kafka pipeline and persisted in a multi-tier data lake (hot: 7 days in-memory, warm: 30 days SSD, cold: 12+ months S3). Marvis trains ML models on this anonymized dataset to detect anomalies across the global fleet.

Telemetry Flow:
AP/Switch/SSR ──TLS:443──► API Gateway ──► Kafka Bus
                                              │
                        ┌─────────────────────┼─────────────────────┐
                        ▼                     ▼                     ▼
                  SLE Processor         Event Store            Marvis ML
                  (time-series DB)      (PostgreSQL)           (TensorFlow)
                        │                     │                     │
                        └─────────────────────┼─────────────────────┘
                                              ▼
                                         S3 Data Lake (cold storage)

Organization & MSP Hierarchy

The Mist object model separates MSP (Managed Service Provider) tenants from Org (customer tenant) from Site (physical location). An MSP admin can manage multiple Orgs; each Org contains 1..N sites. Configuration inheritance follows: MSP template -> Org config -> Site override -> Device override.

Multi-Site Templates

Templates define reusable configuration fragments at the Org level and attach to Site Groups or individual Sites. Four template types exist:

Mist Edge Clusters

Mist Edge is an on-prem x86 appliance (or VM) that extends cloud services into the data center. It provides tunnel termination (L2TPv3 to APs for guest anchoring), RADIUS proxy (for legacy PSK RADIUS), and local survivability. Edges deploy in Active/Active clusters behind a VIP.

# Mist Edge cluster failover
Cluster VIP: 10.10.50.10
├── mist-edge-01  (Active)   priority=100
├── mist-edge-02  (Active)   priority=100
└── mist-edge-03  (Standby)  priority=90

AP discovers Edge via DNS SRV: _mist-tunnel._tcp.edge.example.com
Hash: client-mac -> edge member (consistent hashing for L2 session persistence)

EAP-TLS on Mist Access Assurance

Mist Access Assurance is the cloud-native NAC offering that eliminates on-prem RADIUS servers. It performs EAP-TLS, EAP-TTLS, PEAP, and MAB authentication directly in the cloud with enforcement at the AP or switch.

# EAP-TLS Authentication Flow (Mist Access Assurance)
1. Client      --EAPoL-Start-->      AP
2. AP          --Access-Req-->       Mist Auth (radsec.mist.com:2083)
3. Mist Auth   --EAP-TLS chal-->     Client  (via AP/RadSec)
4. Client      --Cert + ClientHello-> Mist Auth
5. Mist Auth   validates chain against Org CA (uploaded .pem)
6. Mist Auth   --Access-Accept-->    AP  (VLAN 20, role=employee)
7. AP          --4-way handshake-->  Client (PMK derived from MSK)

Cert Validation Sources:
- Org-uploaded Root/Intermediate CA (PKI import)
- IdP integration: Azure AD, Okta, Google Workspace (SCEP/OAuth)
- CRL and OCSP checks every 15 min

WxLAN Policy Framework

WxLAN (Wireless Experience LAN) is Mist's label-based policy engine. Instead of writing ACLs per SSID, administrators assign labels to users, devices, applications, and destinations, then write human-readable policies: "Employees can access ERP, Guests can only access Internet."

Role-Based Access Control (RBAC)

RBAC policies are defined under WxLAN -> Policy. Evaluation order is top-down first-match. Each row contains Source label(s), Resource/Destination label(s), and Action (Allow/Block/Rate-Limit).

Per-Application Rate Limits

Mist DPI classifies traffic at the AP via signature matching (2000+ apps). Rate limits attach to WxLAN app-labels per direction:

# Rate-limit example JSON (Org WLAN template)
{
  "wxlan_rules": [
    {
      "name": "limit-social",
      "src_wxtags": ["role-employee"],
      "dst_app_wxtags": ["facebook","tiktok","instagram"],
      "action": "rate-limit",
      "bw_mbps_up": 2,
      "bw_mbps_down": 5
    },
    {
      "name": "prioritize-zoom",
      "src_wxtags": ["any"],
      "dst_app_wxtags": ["zoom","teams","webex"],
      "action": "allow",
      "qos_class": "ef",
      "dscp": 46
    }
  ]
}

Policy-Based Forwarding (PBF)

PBF steers specific flows to non-default gateways without routing protocols. Use cases: force guest SSID through Mist Edge tunnel, send IoT traffic to DPI firewall, route VoIP over dedicated SD-WAN overlay.

RadSec (RFC 6614)

RadSec encapsulates RADIUS within TLS over TCP port 2083, providing confidentiality, integrity, and reliable delivery across the Internet. Mist APs establish a single persistent RadSec tunnel to the Mist Auth cloud or to a customer RADIUS server for legacy integration.

# RadSec vs legacy RADIUS
                    RADIUS (legacy)           RadSec
Transport:          UDP 1812/1813             TCP 2083 (TLS)
Auth:               Shared secret             X.509 mutual TLS
Reliability:        UDP timeout/retransmit    TCP + persistent session
Encryption:         MD5 hash only (User-Pass) Full TLS 1.2+/1.3
NAT traversal:      fragile                   works natively
Internet-safe:      NO                        YES

MacSec (IEEE 802.1AE)

MacSec provides line-rate hop-by-hop Layer-2 encryption (AES-128-GCM or AES-256-GCM). On Juniper EX switches managed by Mist, MacSec secures uplinks between access and distribution layers and between buildings.

set security macsec connectivity-association CA1 security-mode static-cak
set security macsec connectivity-association CA1 pre-shared-key ckn DEADBEEF... cak 16-byte-hex
set security macsec connectivity-association CA1 cipher-suite gcm-aes-256
set security macsec interfaces et-0/0/48 connectivity-association CA1

Managed from Mist via Switch Template -> Security -> MACsec. Key rotation interval and MKA protocol are configurable.

Radio Resource Management (RRM)

Mist RRM runs as a cloud-based optimizer every 60 minutes. It consumes neighbor reports, co-channel interference (CCI), and client load data to jointly solve channel assignment and transmit power. Unlike traditional DCA that hunts for the best channel locally, Mist RRM uses reinforcement learning across the entire site.

Auto-Placement

Auto-Placement automatically positions APs on the floorplan using BLE ranging and Wi-Fi neighbor RSSI. After uploading a floorplan (PNG/DXF), you place 3 anchor APs; the algorithm trilaterates the remaining AP coordinates within ~3 meter accuracy. This powers accurate location analytics, asset tracking, and coverage heatmaps without manual drag-and-drop.

Site Survey Best Practices

Coverage vs. Capacity Design

6 GHz (Wi-Fi 6E / 7) Considerations

The 6 GHz band (U-NII-5 through U-NII-8) opens 1200 MHz of clean spectrum (59 x 20 MHz channels in the US). Mist AP43/AP34/AP64 series support Wi-Fi 6E; AP47/AP24 series add Wi-Fi 7 (320 MHz, MLO).

OFDMA & MU-MIMO

Session Smart Router (SSR) Overview

Juniper SSR (originally 128 Technology) is the WAN Edge component of the Mist AI-driven SD-WAN. It replaces traditional tunnel-heavy SD-WAN (IPSec/GRE overlay) with Secure Vector Routing (SVR): tunnel-less, session-oriented, metadata-in-packet forwarding.

Secure Vector Routing (SVR)

SVR embeds a small metadata header into the first packet of a session. Subsequent packets in the same 5-tuple are matched to the session state on every SSR hop; no full tunnel is required. This saves 40-60 bytes per packet versus IPSec and preserves native IP semantics (QoS, MTU).

# SVR Packet Flow (tenant=employees, service=salesforce)
1st packet ─► [OrigIP][MetaHdr: tenant,service,sla]   ◄ rewritten at branch SSR
                                │
                       Encrypted (AES-GCM) link
                                │
n-th packet ► Session-matched on state only, plain IP
                                │
                       Hub SSR removes metadata
                                │
                         Salesforce DC

MetaHdr carries:
- Tenant-id, Service-id
- Session-cookie (32-bit)
- Forward/reverse path IDs
- SLA class

Tenants, Services & Service Paths

WAN Edge Templates

Mist WAN Edge templates live at the Org level and define the baseline SSR configuration: physical/virtual interfaces, BGP peerings, tenants, services, traffic-steering rules, and application SLA policies. Templates are attached to Site Groups; site-specific overrides (IP addresses, gateway) are applied per device.

# Simplified WAN Edge template (JSON excerpt)
{
  "type": "spoke",
  "ip_configs": {
    "MPLS": { "type": "static", "ip": "10.1.1.2/30" },
    "INET": { "type": "dhcp" },
    "LTE":  { "type": "dhcp", "apn": "broadband" }
  },
  "path_preferences": {
    "realtime":   { "paths": ["MPLS","INET","LTE"] },
    "business":   { "paths": ["INET","MPLS","LTE"] },
    "best_effort":{ "paths": ["INET","LTE"] }
  },
  "service_policies": [
    { "tenant":"employees", "services":["zoom"],        "path":"realtime"   },
    { "tenant":"employees", "services":["salesforce"],  "path":"business"   },
    { "tenant":"guests",    "services":["internet"],    "path":"best_effort"}
  ]
}

Application Identification

SSR identifies applications via three mechanisms, evaluated in order:

1. Signature DPI: 3000+ application signatures inspect L7 payload. TLS JA3/SNI fingerprints cover encrypted flows.
2. SaaS Feeds: Dynamic IP lists pulled from vendors (O365, Salesforce, Zoom, AWS). Updated every 4 hours.
3. Custom Apps: Operator-defined FQDN/IP/port/protocol tuples for proprietary applications.

SLA Policies & Path Selection

Each application path is continuously measured for latency, jitter, and loss via in-band probes. When an SLA threshold is breached, SVR flows switch to the next-preferred path mid-session with zero reset (sessions are stateless between hops).

BFD (Bidirectional Forwarding Detection)

SSR uses BFD (RFC 5880) for sub-second next-hop liveness on MPLS, Internet, and LTE paths. Default timers are 300 ms Tx/Rx, multiplier 3 (detection in ~900 ms). Tighter timers (50/50/3) available for hub links.

set protocols bfd-liveness-detection minimum-interval 300
set protocols bfd-liveness-detection minimum-receive-interval 300
set protocols bfd-liveness-detection multiplier 3
set protocols bfd-liveness-detection session-mode automatic

Zero-Trust Network Access (ZTNA) Principles

Zero-Trust replaces implicit network trust with continuous per-session verification of user identity, device posture, and context. Mist delivers ZTNA via Access Assurance (cloud NAC), Marvis continuous posture checks, and WxLAN segmentation enforced at the AP/switch.

Device Onboarding & MDM Integration

Mist integrates with MDM/UEM platforms (Intune, Jamf, Workspace ONE, MobileIron/Ivanti Neurons) via the Mist Client Lookup API. When a device authenticates, Mist Access Assurance queries MDM for compliance posture, ownership (corporate vs BYOD), and device type, then assigns the appropriate role/VLAN.

# Posture-based authorization rule
IF   client.auth == "eap-tls"                AND
     mdm.compliance_state == "compliant"     AND
     mdm.ownership == "corporate"            AND
     cert.issuer == "CN=CorpCA-Intermediate"
THEN role = "employee-full"
     vlan = 20
     wxtag = "role-employee"
ELSE IF mdm.compliance_state == "non_compliant"
THEN role = "quarantine"
     vlan = 99
     wxtag = "role-quarantine"
ELSE role = "guest-byod"
     vlan = 30
     wxtag = "role-byod"

802.1X with Mist Access Assurance / NAC

Mist Access Assurance (formerly Mist NAC) is a cloud-delivered IEEE 802.1X authenticator and RADIUS server. It supports EAP-TLS, EAP-TTLS (PAP/MSCHAPv2), PEAP-MSCHAPv2, and MAC Authentication Bypass (MAB). Authentication policies chain identity providers, certificate attributes, and MDM posture to role labels.

Dynamic VLAN Assignment

After successful authentication, Access Assurance returns RADIUS attributes that steer the client into the correct VLAN without reconfiguring SSIDs or ports.

# RFC 3580 / RFC 4675 attributes returned
Tunnel-Type              = VLAN (13)
Tunnel-Medium-Type       = IEEE-802 (6)
Tunnel-Private-Group-ID  = "20"          # dynamic VLAN id
Filter-Id                = "employee"    # WxLAN label
Airespace-ACL-Name       = "acl-emp"     # optional
Session-Timeout          = 3600          # re-auth in 1 hour

RadSec over the Internet

Mist APs authenticate to Access Assurance using RadSec over TCP 2083. The TLS tunnel uses mutual certificate authentication; the AP certificate is provisioned by Mist cloud at ZTP time, and the cloud side presents an intermediate-signed server cert. Even a remote-worker home AP (BT-4 teleworker model) can securely authenticate against Mist Auth without VPN.

AP (10.0.1.5) ──TCP:2083 TLS─► radsec.mist.com
               mutual cert auth
               keepalive 30s
               multiplexed RADIUS over single tunnel

# On-prem RADIUS w/ RadSec (FreeRADIUS, ClearPass, Cisco ISE)
listen {
  type = auth+acct
  ipaddr = 0.0.0.0
  port = 2083
  proto = tcp
  tls {
    private_key_file = /etc/raddb/certs/server.key
    certificate_file = /etc/raddb/certs/server.pem
    ca_file = /etc/raddb/certs/mist-ca.pem
  }
}

Certificate Lifecycle

EAP-TLS requires X.509 client certificates for every device. Lifecycle automation is critical.

Pulse / Ivanti Neurons Integration

Juniper/Ivanti Pulse Secure (now Ivanti Connect Secure / Neurons for Secure Access) integrates with Mist at two layers: endpoint VPN agent posture feeds Mist Access Assurance, and Mist roles trigger Ivanti ZTNA application gating.

• Ivanti Neurons posture sent via SCIM to Mist -> drives role mapping
• Mist Marvis client-event feed exposed to Ivanti for UEBA correlation
• SAML SSO: Mist dashboard can federate to Ivanti-backed IdP for admin logins
• Mist-assigned role label surfaces as ZTNA user-tag in Ivanti policies

Mist REST API v1

Every Mist dashboard action is a thin wrapper over the public REST API. Base URL varies by cloud region (e.g. https://api.mist.com/api/v1). Authentication uses API Tokens (org-scoped) or session cookies (user-scoped with 2FA).

curl Examples

# List sites in an Org
curl -s -H "Authorization: Token $MIST_TOKEN" \
     https://api.mist.com/api/v1/orgs/$ORG_ID/sites | jq .

# Create a new WLAN SSID
curl -X POST \
     -H "Authorization: Token $MIST_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "ssid":"Corp-EAP",
       "auth":{"type":"eap","eap_reauth":false},
       "enabled":true,
       "vlan_id":20,
       "interface":"all"
     }' \
     https://api.mist.com/api/v1/sites/$SITE_ID/wlans

# Reboot a specific AP
curl -X POST \
     -H "Authorization: Token $MIST_TOKEN" \
     https://api.mist.com/api/v1/sites/$SITE_ID/devices/$AP_ID/reboot

# Fetch connected clients (last 60 min)
curl -s -H "Authorization: Token $MIST_TOKEN" \
     "https://api.mist.com/api/v1/sites/$SITE_ID/stats/clients?duration=1h&limit=1000" | jq .

Webhooks

Mist streams near-real-time events to your endpoint over HTTPS POST. Configure at Org or Site level, subscribing to topics (alarms, audits, device-events, client-join, zone-enter, etc.).

# Create a webhook subscription
curl -X POST -H "Authorization: Token $MIST_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "name":"soc-events",
       "url":"https://soc.example.com/mist",
       "secret":"s3cretHMAC",
       "enabled":true,
       "topics":["alarms","audits","device-events","client-join"]
     }' \
     https://api.mist.com/api/v1/orgs/$ORG_ID/webhooks

# Inbound webhook signature verification (Python pseudo)
import hmac, hashlib
sig = request.headers["X-Mist-Signature-v2"]
calc = "v2=" + hmac.new(secret.encode(),
                        request.body,
                        hashlib.sha256).hexdigest()
assert hmac.compare_digest(sig, calc)

terraform-provider-mist

The official Terraform provider (Juniper/mist) manages Mist objects declaratively. Ideal for GitOps workflows and multi-tenant rollouts.

# providers.tf
terraform {
  required_providers {
    mist = {
      source  = "Juniper/mist"
      version = "~> 0.2"
    }
  }
}
provider "mist" {
  host      = "api.mist.com"
  apitoken  = var.mist_token
}

# site.tf
resource "mist_site" "lon1" {
  org_id     = var.org_id
  name       = "London-HQ"
  country_code = "GB"
  timezone   = "Europe/London"
  latlng     = { lat = 51.5074, lng = -0.1278 }
}

resource "mist_org_wlan" "corp" {
  org_id   = var.org_id
  ssid     = "Corp-EAP"
  auth     = { type = "eap" }
  vlan_id  = "20"
  enabled  = true
}

Ansible Collection (juniper.mist)

# playbook-create-sites.yml
- name: Roll out branch sites
  hosts: localhost
  gather_facts: false
  collections:
    - juniper.mist
  vars:
    mist_token: "{{ lookup('env','MIST_TOKEN') }}"
    org_id:     "{{ lookup('env','MIST_ORG_ID') }}"
  tasks:
    - name: Ensure sites exist
      juniper.mist.site:
        org_id: "{{ org_id }}"
        token:  "{{ mist_token }}"
        name:   "{{ item.name }}"
        country_code: "{{ item.cc }}"
        timezone: "{{ item.tz }}"
        state: present
      loop:
        - { name: "Paris-01",   cc: "FR", tz: "Europe/Paris" }
        - { name: "Madrid-01",  cc: "ES", tz: "Europe/Madrid" }
        - { name: "Warsaw-01",  cc: "PL", tz: "Europe/Warsaw" }

Python mistapi Library

The official mistapi Python SDK wraps the REST endpoints and handles pagination, rate limiting, and auth. Install with pip install mistapi.

# bulk_reboot_unhealthy_aps.py
import os, mistapi
from mistapi.api.v1.sites.stats import getSiteDeviceStats
from mistapi.api.v1.sites.devices import rebootDevice

apisession = mistapi.APISession(
    host="api.mist.com",
    apitoken=os.environ["MIST_TOKEN"]
)
apisession.login()

site_id = os.environ["SITE_ID"]
stats = getSiteDeviceStats(apisession, site_id, type="ap", limit=1000).data

for ap in stats:
    if ap.get("status") == "connected" and ap.get("uptime",0) > 30*86400:
        # reboot APs up more than 30 days
        print(f"Rebooting {ap['name']} ({ap['mac']})")
        rebootDevice(apisession, site_id, ap['id'])

CI/CD with Mist

A mature Mist GitOps pipeline typically chains Git -> CI runner -> Terraform plan/apply -> smoke test against Mist API.

# .github/workflows/mist.yml
name: mist-gitops
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - name: terraform init
        run: terraform init
        env: { TF_VAR_mist_token: ${{ secrets.MIST_TOKEN }} }
      - name: terraform plan
        run: terraform plan -out tfplan
      - name: terraform apply
        if: github.ref == 'refs/heads/main'
        run: terraform apply -auto-approve tfplan
      - name: smoke test
        run: |
          curl -sfH "Authorization: Token $MIST_TOKEN" \
               https://api.mist.com/api/v1/self > /dev/null

Marvis Actions

Marvis Actions are ML-derived remediation suggestions Mist surfaces when the AI engine is highly confident a specific fix will resolve an issue. Admins can accept (one-click), auto-apply (if enabled), or dismiss.

Anomaly API

The Anomaly API exposes Marvis-detected deviations from the learned baseline for SLEs, app performance, and user experience. Consume it to correlate with external SIEM/XDR.

# Query current anomalies for a site
curl -s -H "Authorization: Token $MIST_TOKEN" \
     "https://api.mist.com/api/v1/sites/$SITE_ID/insights/anomalies?duration=24h" \
     | jq '.results[] | {type, scope, severity, description}'

# Sample response
{
  "type": "dhcp_failure_spike",
  "scope": "site",
  "severity": "high",
  "description": "DHCP failure rate 18% (baseline 0.4%) on VLAN 20",
  "affected_clients": 143,
  "started": "2026-03-15T09:12:00Z"
}

Anomalies are also pushed via the anomalies webhook topic for real-time consumption.