Juniper JN0-460: Mist AI Wired and Campus Fabric

The Juniper JN0-460 examination assesses Mist AI Wired, Specialist (JNCIS-MistAI-Wired) capabilities. It builds on the JNCIA-MistAI foundation and addresses wired assurance, switch onboarding, campus fabric design, EVPN-VXLAN and operational visibility. Juniper lists a 90-minute, 65-question written exam. Wireless clients and access points may dominate discussions of Mist, but JN0-460 asks what happens on the wired side: whether switch ports assign clients correctly, how configurations scale across sites and why an EVPN fabric keeps segments isolated while preserving reachability. A wired-assurance deployment succeeds only when physical switching, automation, identity and user experience agree.

Connect the Mist organization model to switching outcomes

A cloud-managed switching deployment relies on organization and site objects, subscriptions, administrator roles and configuration templates. These management constructs have practical consequences. A port profile intended for an employee desk may be dangerous when applied to an uplink or a device that carries infrastructure management traffic. Begin from explicit access requirements, map interfaces to their physical roles and define how dynamic assignments should be decided. A template can standardize dozens of locations, but it must support exceptions without becoming an unmaintainable collection of overrides.

When switches are onboarded, validate identity, management reachability, software compatibility and the expected site's configuration. Avoid assuming that a device appearing in the portal has successfully applied every configuration. Compare intended and observed VLAN membership, LAG formation, PoE delivery and authentication state. A branch might show several devices online while one access port silently drops its intended voice VLAN. Diagnose that local forwarding consequence before treating it as a cloud portal defect. Clear ownership of template changes matters because a single pushed error can disrupt many branches.

Use port profiles and dynamic assignment deliberately

Port profiles bundle relevant attributes such as access VLAN, trunking behavior, authentication and services that depend on device type. Their appeal is predictable repetition: a switch port assigned to a phone can be provisioned consistently at many sites. The challenge is incorrect assumptions about endpoints. A printer, access point, security camera and desk phone may need different access conditions and power budgets. If the design relies on LLDP or authentication attributes to select a profile, test what happens when a device does not advertise the expected information.

Dynamic port configuration should implement a documented trust decision, not simply automate a permissive default. A successful physical connection is only the first stage. Identity services, RADIUS responses and policy may determine the assigned network. If an authentication server is unavailable, the fallback must match business risk: a safety-critical endpoint may require controlled continuity while an ordinary guest should not gain unrestricted production access. The relationship between 802.1X and network access control and switch policy is particularly useful when separating a port-state problem from an authorization problem.

Interpret wired service-level expectations

Mist Wired Assurance can expose client and switch health, service-level expectations, insights, events and API-driven workflows. A dashboard that reports switch uptime alone cannot reveal whether one user is connected through a misconfigured access port or suffering repeated link renegotiation. Examine the affected client, site and time range. Compare LLDP neighbors, interface counters, authentication events, port speed, duplex and uplink path. Evidence might point to intermittent cabling rather than a configuration bug, or to a profile applied by automation after an apparently unrelated template update.

A useful operational workflow connects a reported symptom to a measurable stage: link establishment, authentication, assigned segment, IP address, default gateway and application path. Mist analytics can prioritize suspicious behavior, but an alert is not a root-cause explanation by itself. Evaluate the proposed correction against physical wiring and known configuration. When automation produces a change, maintain an audit record and a tested rollback path. It is better to resolve one misclassified endpoint than to weaken access policies for an entire switch stack.

Understand campus EVPN-VXLAN and multihoming

Juniper's campus fabric material introduces Ethernet VPN as a control plane and VXLAN as a data-plane encapsulation. VXLAN tunnel endpoints carry tenant or segment traffic through a routed network, while BGP EVPN can advertise endpoint reachability and relevant route information. Concepts such as route distinguishers, route targets, Ethernet segment identifiers and EVPN route types help explain how the control plane represents tenants and multihoming. The central idea is that logical Layer 2 connectivity can be carried across an IP fabric without requiring all physical links to participate in one uncontrolled spanning tree domain.

Architectures such as campus fabric core-distribution or IP Clos differ in scale, failure domains and routing placement. Centralized and edge-routed bridging choices influence gateway location and how east-west flows are forwarded. A small office switch network does not automatically need an EVPN fabric, but a campus with multiple buildings and demanding availability may benefit from clear segmentation and fast alternate paths. Study why a misconfigured route target can create isolation failure even while VXLAN tunnel reachability appears healthy. Sound EVPN-VXLAN design requires validating both tunnel-endpoint reachability and tenant route-target imports before declaring the distributed fabric healthy.

Troubleshoot a campus client onboarding failure

A university deploys new switches and centralized wired profiles. Most classroom computers authenticate successfully, but scientific instruments in one laboratory periodically lose access after a switch restart. Establish the exact client type and expected VLAN, then trace physical link negotiation, port profile, authentication or fallback action, assigned address and routed reachability. Are the instruments unable to authenticate, or do they land in a segment without the expected application route? Examine device logs and the cloud event timeline before changing the organization-wide profile. If the issue is caused by an outdated instrument that lacks 802.1X support, the correct exception should be narrowly documented and controlled.

At the same time, the site's uplinks connect to a campus EVPN fabric. Confirm that the laboratory VLAN maps to the correct virtual network and that route targets do not leak its traffic into student guest networks. Test the behavior during a switch reboot and a single uplink failure. Check whether affected instruments recover their forwarding state and whether a duplicate MAC or stale endpoint advertisement appears. A diagnosis that addresses only the switch port, ignoring the fabric's logical segment, may restore local connectivity while leaving the application unreachable across buildings.

Account for wired access dependencies during a branch cutover

A branch office often hides several dependencies behind one switch port. An employee may connect a desk phone with a computer plugged into the phone's downstream Ethernet connector. The phone needs the right voice VLAN and power, while the workstation needs authenticated access to the employee network. When the organization migrates to a Mist-managed switching estate, one incorrectly scoped port profile can impair both endpoints in different ways. The phone may receive power yet fail to obtain a voice address; the computer may authenticate but land in a restricted network. The investigation should determine the precise stage that fails for each device, rather than treating the pair as one generic “port outage.”

In a controlled migration test, verify the PoE class and budget, LLDP neighbor information, VLAN tags, authentication results, addressing and application service. Test the fallback when RADIUS is unavailable, ensuring that a critical telephone does not gain unrestricted data access and that a guest device cannot impersonate a managed endpoint. Compare intended profile assignment with the actual switch configuration after a reboot. If profile automation reapplies a stale setting, an operator should identify the management-side drift rather than repeatedly making undocumented local overrides.

Scale introduces another issue: a profile change intended for one room may affect all ports labeled with the same site template. Use a staged site, validate representative device types, and examine the blast radius before publishing. The rollback must restore both configuration and policy context, not just physical link status. Review the impact on campus fabric membership if a VLAN or virtual network identifier also changes. A successful change means each authorized device reaches its expected applications, disallowed traffic stays blocked, and failures can be traced through management records and switch evidence. That is the core operational maturity behind JN0-460.

A second useful Mist wired validation is a planned RADIUS outage. The site may need phones to reach a constrained emergency service while preventing unknown endpoints from joining the corporate VLAN. Define the intended fail-open or fail-closed behavior for each device category before testing. Review switch port role, authentication method, fallback segmentation, learned identity and event timeline. Ensure the recovery itself does not leave temporary permissions in place after RADIUS returns. This exercise exposes whether the wired assurance dashboard reflects actual user reachability and policy enforcement. It also demonstrates that high-quality automated network operations depend on explicit business intent, not simply automatically restoring connectivity by any means.

Control automation and observe changes end to end

Mist APIs and webhooks can help standardize campus deployment, but scaled changes require controls over credentials, data exposure and partial failures. Limit API permissions, validate input and record which site, switch and port was modified. A loop that successfully provisions nine of ten devices should not claim the entire job succeeded. Include a verification pass against actual switch state, not merely the API's acceptance response. Where automation assigns user segments, approval and audit requirements become particularly important.

For JN0-460 preparation, practice one end-to-end wired provisioning workflow and several failure injections: wrong port profile, RADIUS denial, duplex mismatch, absent VXLAN reachability and route-target error. Describe the evidence that distinguishes each. Compare the adjacent Juniper Mist AI wireless specialist focus with the wired certification: both use cloud-assisted visibility, but JN0-460 centers switch access, assurance and campus fabric architecture. The key outcome is a reliable connection between intent, configuration, forwarding and observed user service.