Pass the Juniper JNCIS-DC JN0-481 Questions and answers with ExamsMirror

Juniper Apstra describes data center fabric management as a full lifecycle that spans three core phases: Design (Day 0), Deployment (Day 1), and Operations (Day 2). These phases map directly to how Apstra applies intent-based networking to a data center fabric.

In the Design phase, you model the intended architecture—templates (3-stage or 5-stage), rack types, logical devices, interface maps, resource pools, and high-level constructs such as routing zones and virtual networks. The objective is to capture intent in a vendor-agnostic way while ensuring consistency and validation before anything is pushed.

In the Deployment phase, Apstra turns the modeled intent into device-level implementation. This includes onboarding systems, assigning device profiles, allocating resources, rendering configurations, and pushing the resulting configuration to switches so the IP fabric becomes operational. This is where Junos v24.4 leaf/spine nodes receive underlay and overlay configuration generated from the blueprint.

In the Operational phase, Apstra continuously validates the running network against intent using telemetry and analytics (IBA), detects deviations and anomalies, supports maintenance workflows (such as drain), and provides troubleshooting tools (queries, time-series utilization, and configuration compliance).

“Configuration” and “installation” are activities that occur within the lifecycle, but the lifecycle phases themselves are Design, Deployment, and Operations.

In Apstra 5.1, a logical device defines the abstract port layout and capabilities (including supported speeds), while an interface map binds that abstract port layout to the real, vendor-specific front-panel ports. Rack types then consume logical devices and interface maps to model the rack’s leaf/superspine roles. Once a logical device is referenced by interface maps and used inside rack types (and potentially templates that instantiate those rack types), Apstra treats the combination as a consistent contract: port counts, roles, and speeds must remain semantically valid for every object that depends on it.

The exhibit’s validation error indicates that after changing interface speeds on the logical device, the existing interface map(s) and their usage in rack types no longer match the logical device definition (for example, the map expects certain ports/speeds/roles, but the updated logical device would leave the map invalid). Because the logical device is being consumed in multiple places, the safest and required way to remove the error is to remove all dependencies—templates (if they reference the rack types), rack types, and interface maps—so Apstra can accept the new logical device definition without violating existing mappings. After updating the logical device, you then recreate or update the interface maps and re-associate them with the rack types/templates so the entire chain remains consistent under the new speed requirements.

Referring to the exhibit, the image shows a simplified diagram of an IP fabric network connecting two servers, labeled as Server A and Server B. The IP fabric is a network architecture that uses a Clos topology to provide high bandwidth, low latency, and scalability for data center networks. The IP fabric consists of spine and leaf devices that use BGP as the routing protocol and VXLAN as the overlay technology1.

A broadcast domain is a logical portion of a network where any device can directly transmit broadcast frames to other devices at the data link layer (OSI Layer 2). A broadcast frame is a frame that has a destination MAC address of all ones (FF:FF:FF:FF:FF:FF), which means that it is intended for all devices in the same broadcast domain. A broadcast domain is usually bounded by a router, which does not forward broadcast frames to other networks2.

In the exhibit, there are two broadcast domains that an Ethernet frame will pass through when traversing the IP fabric from Server A to Server B. The first broadcast domain is the one that contains Server A and the leaf device that it is connected to. The second broadcast domain is the one that contains Server B and the leaf device that it is connected to. The IP fabric itself is not a broadcast domain, because it uses IP routing and VXLAN encapsulation to transport the Ethernet frames over the Layer 3 network. Therefore, the statement C is correct in this scenario.

The following three statements are incorrect in this scenario:

A. 1. This is not true, because there are not one, but two broadcast domains that an Ethernet frame will pass through when traversing the IP fabric from Server A to Server B. The IP fabric itself is not a broadcast domain, because it uses IP routing and VXLAN encapsulation to transport the Ethernet frames over the Layer 3 network.

B. 4. This is not true, because there are not four, but two broadcast domains that an Ethernet frame will pass through when traversing the IP fabric from Server A to Server B. The spine devices and the leaf devices that are not connected to the servers are not part of the broadcast domains, because they use IP routing and VXLAN encapsulation to transport the Ethernet frames over the Layer 3 network.

D. 3. This is not true, because there are not three, but two broadcast domains that an Ethernet frame will pass through when traversing the IP fabric from Server A to Server B. The IP fabric itself is not a broadcast domain, because it uses IP routing and VXLAN encapsulation to transport the Ethernet frames over the Layer 3 network.

In Apstra IBA, a probe is a directed graph made of stages (data you can inspect) and processors (operations that transform/aggregate data). While stages can be inspected during probe construction, the simplest operational way to make probe results readily consumable by day-2 operators is to publish them through widgets that can be placed on Analytics dashboards. A dashboard widget is the visualization and presentation object that renders either (1) counts of anomalies or (2) the outputs produced by stages and processors in a probe. Creating a widget tied to the probe output means the operator can open a dashboard and immediately see the metric trends, tables, or anomaly indicators without navigating into probe internals.

A predefined probe is optional content (a starting template) and is not required for visibility. Processors and stages are internal probe building blocks, but they do not, by themselves, create an operator-friendly view in the UI. In a Junos v24.4 EVPN-VXLAN fabric, this is especially useful for link utilization, drops, latency signals, or any custom telemetry pipeline: you build the probe logic once, then expose the key results in a widget that persists across operational workflows and can be shared on standardized dashboards for capacity planning and troubleshooting.

Verified Juniper sources (URLs):

https://www.juniper.net/documentation/us/en/software/apstra4.2/apstra-user-guide/topics/concept/widgets.html

https://www.juniper.net/documentation/us/en/software/apstra4.2/apstra-user-guide/topics/topic-map/widget-stage-create.html

https://www.juniper.net/documentation/us/en/software/apstra4.2/apstra-user-guide/topics/concept/probes.html

In Apstra deployments that use on-box device agents, the agent package installs multiple processes inside the switch’s NOS namespace to provide an isolated runtime environment for Apstra control and telemetry collection. Two of those processes are the Telemetry Agent and the Deployment Agent. The Telemetry Agent is responsible for collecting operational information from the device—such as LLDP neighbor details, routing-related state, and interface information—and sending that telemetry upstream to Apstra. This telemetry is a key input for closed-loop assurance in EVPN-VXLAN fabrics, where Apstra correlates underlay health (interfaces, neighbors, sessions) with overlay services.

The Deployment Agent is responsible for receiving configuration content pushed from Apstra and applying it on the device. In a Junos v24.4 fabric, this is the component that enables Apstra to converge device configuration to the blueprint’s intent (for example, BGP underlay, EVPN signaling, and VXLAN constructs) without requiring manual CLI workflows. Both agents are typically idle most of the time, becoming active when Apstra needs to apply configuration changes or when significant state changes trigger telemetry updates.

Other listed options—“routing agent” and “authentication agent”—are not the named Apstra device-agent processes described for the on-box agent package in Juniper documentation.

Verified Juniper sources (URLs):

https://www.juniper.net/documentation/us/en/software/apstra4.2/apstra-server-and-security-guide/topics/concept/apstra-device-agents.html

In an EVPN-VXLAN fabric where all hosts are single-homed (each endpoint is attached to only one leaf/VTEP), the EVPN control plane still needs to advertise endpoint reachability and enable BUM handling across the overlay. Two EVPN route types are fundamental in this case: Type 2 and Type 3.

EVPN Route Type 2 (MAC/IP Advertisement) is used to advertise learned MAC addresses and, optionally, associated IP addresses for endpoints connected to the local leaf. This enables remote VTEPs to learn where a given host resides (which VTEP to send unicast traffic to) without relying on data-plane flooding for MAC learning. In Junos v24.4 EVPN-VXLAN deployments, Type 2 routes are the core mechanism for distributing endpoint reachability (MAC and MAC+IP bindings) within the EVPN domain.

EVPN Route Type 3 (Inclusive Multicast Ethernet Tag / IMET) is used to establish the flooding scope for BUM traffic in EVPN-VXLAN. In VXLAN fabrics that use ingress replication (common in data centers), Type 3 routes help build the list of remote VTEPs that should receive replicated BUM traffic for a given segment.

By contrast, Type 4 (Ethernet Segment) routes are associated with EVPN multihoming (ESI-based) and DF election; with only single-homed hosts, Type 4 is not required. Type 7 is not part of the baseline single-homed EVPN-VXLAN host advertisement set in this context.

Verified Juniper sources (URLs):

https://www.juniper.net/documentation/us/en/software/junos/evpn/topics/concept/evpn-bgp-multihoming-overview.html

https://www.juniper.net/documentation/us/en/software/junos/evpn/topics/topic-map/assisted-replication-evpn.html

In Apstra 5.1, the correct operational method to gracefully remove a switch from service for maintenance is to set its Deploy Mode to Drain. Drain is a day-2 operational control that tells Apstra to adjust intent so the fabric can continue operating while the targeted device is logically taken out of service as much as the design allows. This is especially relevant in EVPN-VXLAN leaf-spine fabrics where taking down a spine or a leaf can disrupt underlay BGP adjacencies and overlay reachability if traffic is not shifted first.

This action is performed from the blueprint’s Active view because Drain affects the currently deployed, running fabric state (not a staged design change). Selecting the device under Active and changing Deploy Mode to Drain initiates the workflow that prepares the device for maintenance by reducing its role in forwarding and/or withdrawing dependent services according to the blueprint’s modeled redundancy (for example, shifting server-facing traffic to an MLAG/ESI peer where applicable, or reducing reliance on the device for transit). After the device is drained, an OS upgrade can be performed with less impact, and the device can later be returned to service by switching Deploy Mode back to Deploy and committing the change.

The “Upgrade” action is not the deploy-mode mechanism described for graceful removal; the key is Deploy Mode → Drain from Active, which is explicitly intended for maintenance and decommissioning scenarios.

Verified Juniper sources (URLs):

https://www.juniper.net/documentation/us/en/software/apstra5.1/apstra-user-guide/topics/task/device-drain.html

https://www.juniper.net/documentation/us/en/software/apstra4.2/apstra-drain-mode/apstra-drain-mode-guide/topics/concept/apstra-drain-mode-activate-or-disable-drain.html

A three-stage Clos (leaf–spine) data center fabric separates roles to keep forwarding predictable and scalable. The leaf layer is the attachment point for endpoints, so servers connect to leaf devices. This is where the fabric accepts workload traffic, applies edge policies, and provides tenant/service constructs (for EVPN-VXLAN fabrics, the leafs typically act as VTEPs and host IRB gateways as required). The spine layer provides the non-blocking transit core between leafs using L3 underlay routing and ECMP, but it is not the place where servers attach directly.

For north-south connectivity, a typical three-stage Apstra data center architecture includes border leaf switches. These border devices provide the controlled connection point between the fabric and external networks (Internet/WAN/DCI or upstream services). As a result, fabric traffic enters and exits the border devices, not the spines. This design keeps the spines dedicated to high-speed east-west transit and simplifies operations: external routing policies, security controls, and inter-domain handoffs are concentrated at the border, while the spines remain a uniform L3 transit tier. In Junos v24.4 EVPN-VXLAN deployments, this separation also helps maintain clean overlay boundaries and consistent underlay behavior across the fabric.

Verified Juniper sources (URLs):

https://www.juniper.net/documentation/us/en/software/juniper-data-center-assurance/user-guide/topics/concept/dc-network-topology-on-dc-assurance.html

https://www.juniper.net/documentation/us/en/software/jvd/jvd-3-stage-datacenterdesign-with-juniper-apstra/solution_architecture.html

https://www.juniper.net/content/dam/www/assets/white-papers/us/en/design-considerations-for-spine-and-leaf-ip-fabrics.pdf

In a three-stage eBGP IP Clos, a leaf typically learns the same prefix through multiple spines, and those spines are commonly in different AS numbers (a standard Clos pattern for simplified operations and fault isolation). To install multiple equal-cost eBGP paths for the same destination, Junos requires BGP multipath and, when the candidate paths come from different neighbor ASs, you must use the multiple-as capability (expressed as “multipath multiple-as” in many designs) to bypass the default same-neighbor-AS restriction for multipath selection. This ensures multiple eligible eBGP next-hops can be accepted as equal-cost paths and installed.

Separately, to actually perform load balancing in the forwarding plane across those installed next-hops, Junos uses a load-balancing policy that is applied to the forwarding table via routing-options forwarding-table export . This policy (for example, per-packet or consistent-hash variants, depending on platform and intent) activates the forwarding behavior needed to distribute traffic over the ECMP set.

A “load-balance policy applied to the BGP group” is not the required mechanism for ECMP forwarding behavior in this context, and multihop is unnecessary in a Clos underlay because neighbors are typically directly connected.

Verified Juniper sources (URLs):

https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/load-balancing-bgp-session.html