Juniper Data Center, Specialist JN0-481 Exam Questions

Answer : B

A Juniper Apstra rack is a physical entity that contains one or more network devices, such as leaf nodes, access switches, or generic systems. A rack is used to organize and manage the network devices in the Apstra software application. A rack has the following characteristics:

It stores information on how leaf nodes connect to generic devices. This is because a rack can include generic systems, which are devices that are not managed by Juniper Apstra, but are connected to the network. A generic system can be a server, a firewall, a load balancer, or any other device that has a network interface.A rack stores the information on how the leaf nodes, which are the devices that provide access to the end hosts, connect to the generic devices, such as the port number, the link speed, the LAG mode, and the roles1.

It has a rack type, which defines the type and number of leaf devices, access switches, and/or generic systems that are used in the rack. A rack type is a resource that is created in the data center design phase, and it does not specify the vendor or the model of the devices.A rack type can be predefined or custom-made, and it can be used to create multiple racks with the same structure and configuration2.

It has a rack build, which assigns the specific vendor and model of the devices to the rack. A rack build is created in the staged phase, and it uses the rack type as a template.A rack build can also assign the resources, such as the IP addresses, the ASNs, and the VNIs, to the devices in the rack3.

It has a rack deployment, which applies the network configuration and services to the devices in the rack. A rack deployment is performed in the active phase, and it uses the rack build as a reference.A rack deployment can also monitor the network performance and compliance of the devices in the rack4.

The following three statements are incorrect in this scenario:

It stores information on how pods connect to super spines. This is not true, because a rack does not store any information on the pod or the super spine level of the network. A pod is a cluster of leaf and spine devices that form a 3-stage Clos topology, and a super spine is a device that connects multiple pods in a 5-stage Clos topology.A rack only stores information on the leaf and the access level of the network1.

It stores IP address and ASN pool information. This is not true, because a rack does not store any information on the IP address and ASN pools. IP address and ASN pools are resources that are created in the data center design phase, and they contain a range of IP addresses and ASNs that can be assigned to the devices and the virtual networks.A rack only uses the IP address and ASN pools to assign the resources to the devices in the rack build2.

It stores device port data rates and vendor information. This is not true, because a rack does not store any information on the device port data rates and vendor information. The device port data rates and vendor information are specified in the rack build, which assigns the specific vendor and model of the devices to the rack.A rack only uses the rack build to apply the network configuration and services to the devices in the rack deployment3.

Racks (Staged)

Rack Types (Datacenter Design)

Rack Builds (Staged)

Racks (Active)

Answer : A

In Apstra, Deploy mode is the state in which a device is intended to fully participate in the fabric. For a three-stage eBGP IP Clos (typical EVPN-VXLAN underlay), ''fully functioning'' means the switch receives the complete, intent-derived configuration required for production operation---underlay interface addressing, BGP peering, routing policy constructs, and any overlay-related prerequisites appropriate for its role (leaf, spine, border leaf). In Apstra's device configuration lifecycle, Deploy is the mode that causes Apstra to render and apply the full set of intended services for that node so it becomes an active member of the IP fabric and contributes to ECMP pathing and control-plane adjacency.

By contrast, Ready is commonly used when you want the device discovered and prepared (for example, basic identity and interface readiness), but not actively routing in the fabric. Drain is a maintenance state used to gracefully withdraw an already-deployed device from forwarding to minimize impact (for example, for upgrades or repairs). Not Set indicates the deploy mode has not been chosen and therefore does not represent an operationally complete participation state.

Therefore, when your objective is an operational IP fabric where the assigned devices are actively routing and forwarding according to blueprint intent on Junos v24.4, the correct choice is Deploy.

Answer : B, C

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

Answer : B

The exhibit shows the border leaf receiving multiple routes via BGP from the external router, including 172.23.x/24 prefixes, and those routes appearing in the Finance VRF routing table. To stop these routes from being installed in the Finance table, you must change what the border leaf imports from that eBGP session. In Apstra, this control is implemented through a Routing Policy attached to the protocol session described by the connectivity template. By setting the Import Policy to accept default route only, Apstra renders Junos policy so that only 0.0.0.0/0 is imported into the VRF, while the 172.23.x/24 prefixes are rejected and therefore never installed in Finance.inet.0.

Option C is a common trap: the ''Expect Default IPv4 Route'' setting is an assurance expectation---it generates an expectation/anomaly if the default route is missing, but it does not change device configuration or filtering behavior. Export-policy changes (option D) would only affect what the border leaf advertises outbound to the external router, not what it learns inbound. Aggregation (option A) does not prevent installation of the specific learned /24s; it changes advertisement behavior rather than import filtering. The correct fix is to tighten the import policy on that external eBGP session.

Verified Juniper sources (URLs):

https://www.juniper.net/documentation/us/en/software/apstra5.1/apstra-user-guide/topics/concept/routing-policies.html

https://www.juniper.net/documentation/us/en/software/apstra6.0/apstra-user-guide/topics/concept/routing-policies.html

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

Answer : A, B, C

In Juniper Apstra 5.1, tags are a lightweight metadata mechanism used to classify objects and enable conditional automation (for example, driving dynamic configlets or simplifying filtering/searching in the UI). Apstra supports tagging several blueprint-operational objects that commonly participate in day-1/day-2 workflows.

Virtual networks can be tagged so operators can group, search, and apply automation consistently across sets of segments. This is useful in EVPN-VXLAN fabrics where virtual networks represent VLAN- or VXLAN-backed broadcast domains and you may want policies or configlet logic to apply to all ''finance'' or ''pci'' segments as a group.

Interfaces can be tagged directly within a blueprint (for example, leaf access ports, uplinks, or specific border-facing ports). Interface tags are often used to drive template-based configuration behavior and to simplify operational actions across many ports without relying on fragile naming conventions.

Generic systems (internal or external) can also be tagged. Apstra documentation explicitly describes using tags to specify roles for internal generic systems, enabling you to differentiate server types or attachment roles and then apply the correct intent (connectivity templates, VN attachments, or policies) in a repeatable way.

By contrast, property sets are structured data objects used for parameterization (YAML/JSON values for templates/probes), and device profiles describe hardware/NOS capabilities; they are not the standard blueprint objects for tag assignment in this scenario.

Verified Juniper sources (URLs):

https://www.juniper.net/documentation/us/en/software/apstra5.1/apstra-user-guide/topics/task/tag-virtual-network-update.html

https://www.juniper.net/documentation/us/en/software/apstra5.1/apstra-user-guide/topics/topic-map/tag-interface-add-remove-datacenter.html

https://www.juniper.net/documentation/us/en/software/apstra5.1/apstra-user-guide/topics/topic-map/internal-generic-system-create.html

Answer : C

In a VXLAN overlay, each Layer 2 broadcast domain (the logical equivalent of a VLAN/bridge domain) is identified by a 24-bit VXLAN Network Identifier (VNI) carried in the VXLAN header. This VNI is what allows the overlay to scale far beyond traditional VLAN space (12-bit VLAN IDs), enabling up to ~16 million distinct segments. In an EVPN-VXLAN data center fabric, Junos v24.4 leaf switches operate as VTEPs and map local bridge domains (often associated with VLANs on server-facing ports) to a VNI. When traffic is sent across the routed underlay, the leaf encapsulates Ethernet frames into VXLAN packets and inserts the VNI so the receiving VTEP can place the frame into the correct broadcast domain on decapsulation.

Apstra 5.1 abstracts this mapping through virtual networks and resource allocation: when you define a VXLAN-based virtual network, Apstra allocates a VNI from the appropriate pool and consistently programs the necessary constructs on all participating leaves. The key point is that VNI is the unique identifier in the VXLAN data plane used to label the broadcast domain across the IP fabric; VLAN IDs may exist locally at the edge for tagging, but the globally significant overlay identifier is the VNI.

Verified Juniper sources (URLs):

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

Answer : A, B

In Apstra, a collapsed fabric (also described as ''spineless'') consolidates traditional fabric tiers so that the primary fabric devices perform combined roles. Instead of a dedicated spine tier providing transit between leafs, the fabric is formed by leaf devices connected directly to each other using mesh links. This means a collapsed fabric uses a full-mesh topology at the leaf level, replacing the usual leaf-to-spine connections found in a three-stage Clos. Therefore, the statement that leaf devices are full-mesh connected is correct.

Because the collapsed fabric devices serve the fabric roles, they also provide the EVPN-VXLAN overlay functions (VTEP behavior, EVPN control-plane participation, and VXLAN encapsulation/decapsulation) necessary for tenant segmentation and service delivery. Juniper's collapsed fabric validated designs further describe the collapsed fabric switches as serving all fabric roles (including border-leaf behaviors when external connectivity is required), reinforcing that overlay functions reside on these fabric leaf devices.

The remaining statements are not generally true for the collapsed fabric definition. Top-of-rack (access) switches---when present in certain collapsed designs---are not defined by default as full-mesh connected, and VXLAN support is not a requirement for those TOR/access switches unless the specific architecture explicitly uses them as VTEPs. The defining characteristics are the consolidated fabric roles and the leaf-level full-mesh.

Verified Juniper sources (URLs):

https://www.juniper.net/documentation/us/en/software/apstra5.0/apstra-user-guide/topics/concept/templates.html

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

https://www.juniper.net/documentation/us/en/software/jvd/jvd-collapsed-dc-fabric-with-apstra/jvd-collapsed-dc-fabric-with-apstra.pdf