JNCIS-MistAI-Wired cheat sheet

Mist manages Juniper EX and QFX switches in a Junos-based architecture; wired assurance works by having switches connect to the Mist cloud over HTTPS (outbound TCP 443) rather than requiring an on-premises controller.

Port profiles are named, reusable bundles of port settings (mode, VLAN membership, PoE, STP, storm control, 802.1X) applied to switch ports; a port profile is assigned to individual ports or in ranges, and one profile can serve many ports across many switches.

Switch configuration in Mist is expressed as a site-level template applied to a switch model plus a device-level override; the effective running config is the merge of org template, site template, and device override, with the most specific level winning.

VLANs in Mist are defined as site-level VLAN objects with an ID and name; a port in access mode carries one untagged VLAN, a port in trunk mode carries a list of tagged VLANs plus optionally one native (untagged) VLAN.

PoE on EX switches is configured per port as class-based (LLDP negotiation), or forced; PoE budget is per switch or per PoE controller, and exceeding the budget leaves later ports unpowered rather than failing the config.

Spanning tree on Juniper EX defaults to RSTP; Mist exposes STP settings such as edge (BPDU guard-like behavior for access ports), BPDU blocking, and loop protection at the port profile level.

Link aggregation (LAG / ae interface) bundles multiple physical ports; LACP is the negotiated mode, static LAG is the non-negotiated mode, and member links must match on speed and duplex and be configured identically at both ends.

LLDP and LLDP-MED are used by Mist to discover what is connected to a switch port (APs, phones, other switches); neighbor discovery feeds the topology view, so disabling LLDP degrades wired assurance accuracy.

Onboarding order: create the org, create the site, add the switch by claim code or by assigning it in Inventory, then apply a switch template; a claimed switch that never appears online usually has no outbound 443 reachability or wrong NTP/DNS.

Switch templates are org- or site-scoped configuration containers; you assign a template to a switch model (or to specific switches) and then override at the device level for exceptions, avoiding per-device config sprawl.

The Mist onboarding flow for a new EX switch: factory default, DHCP address, resolve the Mist redirect/claim, then the switch downloads its configuration; static IP, DNS, and NTP must be valid before the switch can stay connected.

Port profiles should be designed per role (AP uplink, user access, trunk to core, server, unused/disabled) and named accordingly; assigning a disabled profile to unused ports is the standard hardening pattern.

Site variables and switch variables let one template serve many sites; variables substitute values such as VLAN IDs, management subnets, or uplink port names at apply time, so a template is not hard-coded per site.

Firmware upgrades are scheduled from the Mist UI per switch or per site; the switch must have enough free flash and a stable connection, and upgrades are best done in a maintenance window because the switch reloads.

Configuration changes in Mist are staged and pushed; the UI shows a diff between the running config and the intended config, and a failed push leaves the switch on its previous config with an event logged.

Adoption/claim requires the switch to be in the org inventory; a switch claimed to the wrong org must be released (unclaimed) before it can be claimed elsewhere, and the claim code is tied to the device serial.

Mist SLEs (Service Level Expectations) for wired include switch health, and cover classification such as coverage, capacity, and connectivity; each SLE is scored 0-100 from classified events, and you drill into the classifier to see affected switches and clients.

Marvis, the Mist AI assistant, answers natural-language questions and surfaces root causes; Marvis Actions lists prioritized problems (for example a switch with high CPU, a port flapping, or a PoE budget overrun) with a suggested fix.

Key wired telemetry: port up/down events, PoE draw per port, LLDP neighbors, CPU and memory, and interface error counters; a port that flaps repeatedly appears as repeated link events and is a common root cause of client connectivity SLE misses.

A switch showing offline in Mist but passing traffic locally points to the management path: check the outbound HTTPS tunnel, DNS, NTP skew, and whether the switch was recently upgraded or its config push failed.

PoE troubleshooting: compare the port's requested class with the delivered power; a device that draws more than its class or exceeds the switch budget will fail to power, and the event log records the PoE denial.

Loop troubleshooting: a broadcast storm or MAC flapping indicates a Layer 2 loop; check STP state, whether edge/loop protection is enabled on access ports, and whether an unauthorized switch or AP was plugged into an access port.

Client-level troubleshooting: locate the client in Mist, check which switch port it is on, its VLAN, its authentication result (802.1X/MAC RADIUS), and DHCP; a client with an IP but no connectivity usually points to VLAN or upstream routing.

SLE classifier events are the evidence trail: each miss is tagged with a classifier (for example DHCP failure, authentication failure, or port down), and the fix is chosen from the classifier rather than from the aggregate score.

The Mist REST API is token-based: create an API token in the org settings, send it as an Authorization: Token header, and scope the token to the org or to specific sites with read or write permission.

Core API resource paths follow /api/v1/orgs/{org_id}/... and /api/v1/sites/{site_id}/...; switches, switch templates, port profiles, sites, and stats are separate collections, so automation reads the object then patches only the changed fields.

Configuration changes via API use PUT/PATCH on the site setting or device object; use GET first to read the current object, modify, then PUT it back, because a PUT replaces the object rather than merging it.

Webhooks let Mist push events to an external endpoint; you subscribe to topics (for example device events or alarms) and Mist POSTs JSON payloads, which is how you feed a ticketing or monitoring system without polling.

Mist supports third-party integrations through its API and webhooks plus standard protocols on the switch side (RADIUS for 802.1X, syslog, SNMP, TACACS+); the cloud does not replace those protocols for authentication and logging.

Marvis and the API both expose the same underlying data; for reporting, pull site stats and SLE metrics on a schedule rather than scraping the UI, and store them because the API returns time-windowed data.

Idempotent automation: keep the intended config in version control, apply it via API or templates, and compare against the running config; drift shows up as a diff between the stored intent and the switch's actual config.

Rate limits apply to the Mist API; batch reads and cache results rather than polling every switch every minute, and use webhooks for event-driven workflows to stay within limits.