JN0-460 JNCIS-MistAI-Wired: Wired Assurance, EVPN-VXLAN, and Campus Fabric

JN0-460 is the current exam for Juniper Networks Certified Specialist, Mist AI Wired. Juniper launched the wired specialist certification on January 15, 2024 as the Mist portfolio expanded beyond wireless assurance. The exam is delivered through Pearson VUE, contains 65 multiple-choice questions in 90 minutes, is offered in English, and lists JNCIA-MistAI as the prerequisite certification.

The current blueprint covers Wired Assurance fundamentals, provisioning and deployment, day-to-day management and operations, campus fabric architectures, and EVPN-VXLAN. That combination makes the credential different from a conventional switching exam. Candidates need to understand Ethernet and campus architecture, but they also need to know how Mist organizes switches, applies profiles and templates, measures service outcomes, exposes client insight, and automates operational workflows.

The current associate foundation is JN0-253. The JN0-452 wireless specialist is a parallel track rather than a prerequisite. Historically, JN0-451 represented the original wireless-oriented Mist specialist certification before Juniper split the portfolio into wired and wireless specialist credentials.

Wired Assurance changes how campus switching health is measured

Traditional switch operations often focus on device health, port state, errors, VLAN membership, and protocol status. Wired Assurance adds a service-oriented view by correlating switch, client, and network data in the Mist cloud. The specialist must still understand the underlying Ethernet behavior, but can use centralized telemetry to ask whether users and devices are receiving the intended wired service.

This is particularly valuable in environments with many access switches. A device can be online while clients behind one port profile experience authentication, address-assignment, or connectivity failures. The operational objective is to move from a symptom or SLE degradation to the affected switch, port, client, configuration object, or upstream dependency without treating every incident as an isolated CLI session.

Accounts, subscriptions, and supported devices define the service boundary

The Wired Assurance fundamentals domain includes solutions, supported devices, features and components, Mist AI accounts, and subscriptions. These topics matter because cloud-delivered capabilities depend on both the physical switch and the services enabled for the organization. An operator must know which devices can be onboarded, which features are licensed, and where administrative ownership resides.

When building a study lab, document the control boundary before configuration. Identify the organization, site, device assignment, subscription, switch software requirements, and cloud connectivity. If an expected capability is missing, checking entitlement and platform support early can save time that would otherwise be spent searching device configuration for a feature the environment does not provide.

Provisioning should turn site intent into predictable switch configuration

The deployment objectives cover provisioning processes, deployment options, configuration options, templates, supported architectures, and site variables. Templates are powerful because they allow a consistent baseline to be expressed once and applied across many switches. Site variables then provide controlled variation without creating a separate hand-built configuration for every location.

The key skill is understanding precedence and scope. A value can originate in a template, a site object, or a device-specific setting, and the final switch configuration reflects how those layers combine. Practice tracing one setting from its source to the generated device state. When a configuration is unexpected, determine which object supplied the value before editing anything.

Port profiles and dynamic port configuration reduce repetitive access-layer work

Campus access ports often repeat a small number of intent patterns: employee access, voice plus data, access points, cameras, printers, building systems, or other device classes. Port profiles let administrators define those patterns consistently. Dynamic port configuration can then use device or policy information to apply the appropriate behavior with less manual per-port work.

For preparation, create several device personas and decide what each requires: VLAN or segment, authentication, PoE, policy, and any special port behavior. Then map those requirements into profiles and observe how the switch changes when a device moves. This makes the operational benefit tangible and also exposes the risks of an overly broad profile or incorrect classification.

Authentication and device onboarding are useful examples of why the client view matters. A switchport may be electrically up while the attached endpoint is blocked by identity, policy, or address-assignment failure. Follow the client timeline through link, authentication, segmentation, DHCP, and upstream reachability. The point at which expected state diverges determines whether the next check belongs in Mist policy, switch configuration, an identity service, or the routed network.

Service Level Expectations and client insights connect configuration to experience

Wired Assurance management includes Service Level Expectations and client insights. The specialist should be able to move between a service metric and the detailed evidence behind it. If a group of clients has poor connectivity, the investigation may involve authentication, DHCP, switchport errors, uplink behavior, configuration mismatch, or another shared dependency.

Build troubleshooting exercises around a timeline. Capture a healthy client, then introduce one controlled fault and note which SLE or insight changes first. Inspect the switch, port, configuration, and upstream service that explains the symptom. This approach prevents dashboards from becoming passive reporting tools; they become structured starting points for fault isolation.

APIs make wired operations available to external automation

The management objectives include APIs because Mist environments often need to integrate with inventory, workflow, monitoring, or automation systems. Programmatic access can retrieve switch and client information, apply standardized changes, or feed operational data into other tools. The same safety principles that apply to device automation apply here: scope credentials correctly, validate inputs, handle errors, and verify outcomes.

Start with read operations and compare returned data to the Mist interface. Then build a narrow change workflow with explicit validation and a rollback plan. The purpose of API use is not to automate everything; it is to remove repetitive work where the desired state is clear and machine verification can prove that the change achieved the intended result.

Underlay design should be tested separately from the overlay. Before troubleshooting EVPN information, verify that the VTEPs can reach one another through the routed fabric and that the expected loopbacks and next hops are present. An overlay cannot compensate for a broken IP Clos. This separation is especially helpful in exam scenarios where an EVPN symptom is intentionally caused by a lower-layer routing problem.

Campus fabric architecture is about scalable segmentation and resilient forwarding

The current blueprint includes EVPN multihoming, core-distribution and IP Clos campus fabric models, group-based policy and microsegmentation, centrally routed bridging versus edge-routed bridging, and scaling considerations. These topics require a stronger architectural view than basic access switching. Candidates should understand where Layer 2 ends, where routing occurs, how redundant attachment is provided, and how policy follows users or groups.

Draw each architecture before configuring it. Mark underlay links, VTEPs, routing boundaries, endpoint attachment, and the location where policy is enforced. Then trace both same-segment and inter-segment traffic. Comparing CRB and ERB becomes much easier when you can point to the node performing the routed decision and explain the scaling or traffic-path consequence of that choice.

VXLAN supplies the overlay while EVPN distributes reachability

JN0-460 expects knowledge of VXLAN Layer 2 tunneling, control and data-plane behavior, VTEPs, and VXLAN gateways. It also covers EVPN concepts including multipath, route types, Ethernet Segment Identifiers, route distinguishers, route targets, policies, MAC learning, and control-plane operation. The two technologies should be learned together but not confused: VXLAN provides the encapsulated data path, while EVPN uses BGP to distribute endpoint and reachability information.

Trace one endpoint across the fabric. Identify where its MAC and IP information is learned, how that information is advertised, which route type carries it, how import policy and route targets control visibility, which VTEP encapsulates the frame, and where the overlay is terminated. If a remote endpoint is unreachable, this sequence gives you separate checkpoints for local learning, control-plane advertisement, policy, underlay reachability, and encapsulation.

Scaling questions should be tied to operational consequences. More endpoints, segments, sites, and policy groups increase the amount of state the fabric and management system must distribute and observe. A design that works in a small proof of concept may become difficult to operate if templates, route-target strategy, and segmentation are inconsistent. Specialist-level thinking includes choosing repeatable patterns that remain understandable as the campus grows.

Change control is another practical part of fabric operations. A template or policy update may affect many switches at once, so the operator should know the blast radius before deployment, compare intended and generated configuration, and verify key SLEs afterward. The cloud platform makes centralized change easier; disciplined validation is what keeps that convenience from turning a small mistake into a site-wide incident.

Multihoming and policy make failure behavior part of the design

EVPN multihoming provides resilient attachment while preserving control over forwarding and loop avoidance. Ethernet Segment Identifiers identify the multihomed segment, and the control plane coordinates how traffic reaches it. Candidates should understand what happens during a member or node failure rather than only knowing the configuration objects involved.

Microsegmentation and group-based policy add another dimension: two endpoints may be physically connected and reachable through the fabric while policy intentionally restricts communication. In troubleshooting, prove whether the failure is transport, endpoint learning, routing, or policy. That distinction prevents an engineer from dismantling a healthy overlay to fix an access-control decision.

The strongest JN0-460 preparation does not split “Mist” and “networking” into separate study blocks. Provision a switch through Mist, verify the generated configuration, connect clients, inspect SLEs, and then trace the same traffic through the campus fabric. Create controlled faults such as a wrong profile, failed uplink, missing EVPN advertisement, or policy mismatch and observe how both the cloud interface and device state expose the problem.

The wider Juniper certifications family provides progression context, but JN0-460 has a distinct operational identity. It tests whether a wired networking professional can use Mist to provision and assure campus services while still understanding the switching, routing, EVPN, and VXLAN mechanics beneath the dashboard. That combination of centralized operations and packet-level reasoning is the core of the specialist role.