JN0-481 Practice Questions

During the Deploy phase Apstra allocates required items (ASN ranges, VLAN/VNI IDs, IP pools, etc.) from the global resource pools without user action. The blueprint consumes the next available values, guaranteeing uniqueness across all blueprints unless the operator overrides them before deployment.

A. Device profiles and assignments are unrelated to automatic pool allocation.

B. Pools exist globally by default; user-created pools are optional, not mandatory.

C. Resources are defined globally, not created within each blueprint.

1. Juniper Networks, “Apstra Resource Pools and Allocation Guide 4.2”, §4 “Automatic Allocation at Deploy Time” (pp. 42-45).

2. Juniper Networks, “Apstra Concepts Guide 4.2”, §3.4 “Global vs Blueprint Resource Pools”.

The Ethernet frame physically exists in two separate Layer 2 broadcast domains. The first is the L2 segment between Server A and the ingress switch, Leaf 1. The frame is then encapsulated into a VXLAN packet and transported over the Layer 3 IP fabric. At the egress switch, Leaf 2, the original Ethernet frame is decapsulated and placed onto the second L2 broadcast domain, the segment between Leaf 2 and Server B. Although these two physical segments are part of the same logical L2 broadcast domain (Virtual Network) extended by VXLAN, the frame itself physically traverses two distinct domains at the fabric edge.

A. This

1. Juniper Day One: Deploying IP Fabrics with EVPN-VXLAN, Ch. 2 “Control & Data Plane,” pp. 21-23.

2. Juniper Networks Validated Design Guide: EVPN-VXLAN Data Center Fabric, §3.2.2 “Traffic Flow,” p. 15.

In Juniper Apstra, a security policy's application point defines the scope of traffic the policy will affect. The 'Routing Zone' application point corresponds directly to a VRF. Selecting this option applies the policy rules to all traffic entering or leaving that specific VRF, making it the correct choice for controlling traffic at the VRF level. This is commonly used for establishing broad security postures, such as a default-deny policy for a VRF or controlling traffic to/from external connections within that routing instance.

External Endpoint: This applies policies to traffic from/to specific networks outside the Apstra-managed fabric, not the entire VRF.

Internal Endpoint: This applies policies to specific workloads or devices within the fabric, typically identified by tags, not an entire VRF.

Virtual Network: This applies policies at the Layer 2 broadcast domain (VLAN) level, which is a more granular scope than a VRF.

1. Juniper Apstra 4.2.0 User Guide, "Group-Based Policy > Policy Application Points". The guide states, "Routing Zone - Applies to all traffic entering or leaving the selected routing zone (VRF)."

When a device managed by Juniper Apstra has its configuration changed out-of-band (OOB) via the CLI, Apstra detects this as a "Config Deviation" anomaly. Clicking the "Accept Changes" button instructs Apstra to learn these OOB changes and incorporate them into its rendered or "golden" configuration for that specific device. This action effectively updates Apstra's intent to match the new reality on the device, resolving the anomaly.

A: Apstra does not guess intent or add similar configurations; it incorporates the exact changes that were made out-of-band.

C: Clicking "Accept Changes" resolves the deviation immediately; it does not hold changes pending a "Full Config" push.

D: This describes ignoring the anomaly. Accepting the changes prevents them from being overwritten by the next configuration push from Apstra.

1. Juniper Apstra User Guide 4.2.1, "Anomalies > Config Deviation". The guide explains that accepting changes "updates the pristine configuration with the out-of-band configuration."

2. Juniper Apstra Datasheet. Describes Apstra's role as the "single source of truth," which is maintained by either pushing intent-based config or accepting OOB changes to update the intent.

In Juniper Apstra, all modifications to a blueprint's design and topology are performed in the 'Staged' environment. The 'Active' environment is a read-only representation of the currently deployed network configuration. To change the physical cabling (the cable map), the operator must navigate to the 'Staged' tab, then select the 'Physical' view, and finally the 'Links' sub-tab. Here, links between device ports can be added, modified, or deleted to match the physical reality before committing the changes to the live network.

A. The 'Active' view is read-only and used for monitoring the current state of the network, not for making configuration changes.

C. 'Connectivity Templates' define logical server attachments, not the physical fabric links. Also, the 'Active' view is read-only.

D. 'Connectivity Templates' are used for defining how servers and external systems connect to the fabric, not for modifying the core spine-leaf cabling map.

1. Juniper Apstra User Guide 4.2.1, "Blueprints > Staged > Physical > Links". This section of the documentation explicitly details the procedure for viewing and editing device-to-device physical links within the staged version of a blueprint.

2. Juniper Networks TechLibrary, "Day One+: Deploying a Data Center with Juniper Apstra", Chapter 4: "Build Your Network Blueprint". This guide illustrates the workflow, showing that all design changes, including physical topology, occur in the 'Staged' section.

Juniper Apstra's Security Policies define rules for traffic flow between different application groups or network zones. When these abstract policies are rendered and pushed to network devices, they are translated into platform-specific configurations. For Juniper Junos devices, these policies are implemented as firewall filters. For other vendors like Arista EOS or Cisco NX-OS, they are implemented as Access Control Lists (ACLs). Both firewall filters and ACLs are functionally equivalent in this context, serving as stateless packet filters to permit or deny traffic based on defined criteria.

A. Filter-based forwarding (FBF)

FBF is a routing feature that directs traffic to a specific next-hop based on filter criteria, which is different from the permit/deny function of a security policy.

C. Policy-based routing (PBR)

PBR is used to override default routing behavior based on policy, not for implementing the stateless firewall rules defined in Apstra Security Policies.

1. Juniper Apstra User Guide, "Policy". The documentation states, "Apstra policies are rendered as access control lists (ACLs) on the interface of the leaf devices."

2. Juniper TechLibrary, "Day One+: Deploying in the Data Center with Apstra", Chapter 5: Security Policies. This guide explains that Apstra policies are translated into device-specific ACLs or firewall filters to enforce the desired security posture.

In Juniper Apstra's vendor-agnostic data model, a 'routing zone' is the abstraction for a Layer 3 virtual routing and forwarding instance (VRF). A routing zone provides traffic isolation and a separate routing table domain within the network fabric. When Apstra renders the configuration for a physical device (like a Juniper QFX switch or an Arista switch), it translates the 'routing zone' construct into the specific VRF configuration syntax required by that device's network operating system (e.g., routing-instances instance-type vrf in Junos).

A. IRB: An Integrated Routing and Bridging interface is a Layer 3 interface on a VLAN, which Apstra models as a virtual network with a gateway, not a routing zone.

C. VLAN: A VLAN is a Layer 2 broadcast domain, which Apstra models as a 'Virtual Network', not a routing zone.

D. Access list: An access list is a packet filter, which Apstra manages through security policies, a concept distinct from a routing zone.

1. Juniper Apstra User Guide, "Blueprints > Staged > Virtual > Routing Zones". The documentation explicitly states, "A routing zone is a collection of virtual networks that are in the same Layer 3 routing domain (a VRF)."

2. Juniper TechLibrary, "Apstra Concepts". The glossary and conceptual overview define a Routing Zone as the Apstra abstraction for a VRF, used to enforce L3 isolation between groups of virtual networks.

VXLAN (Virtual Extensible LAN) encapsulates Layer 2 frames in Layer 3 packets, creating virtual networks over an existing IP network. To distinguish between these different virtual networks or broadcast domains, VXLAN uses a 24-bit identifier in its header called the Virtual Network Identifier (VNI). Each VNI uniquely identifies a VXLAN segment, allowing for up to 16 million isolated Layer 2 domains on the same physical infrastructure, which is a significant increase over the 4094 limit of traditional VLANs.

A. VLAN ID

A VLAN ID is a 12-bit identifier used in traditional IEEE 802.1Q networks, not the primary identifier for a VXLAN broadcast domain.

B. Agent Circuit Identifier (ACI)

ACI is part of the DHCP Relay Agent Information Option (Option 82) and is unrelated to VXLAN segmentation.

D. End System Identifier (ESI)

ESI is an identifier used in EVPN multihoming to identify a customer edge device connected to multiple provider edge devices.

1. Juniper Networks TechLibrary, "EVPN-VXLAN Overview". This document states, "Each VXLAN is identified by a 24-bit virtual network identifier (VNI), which is also known as the VXLAN segment ID. A VNI uniquely identifies a Layer 2 segment in a VXLAN."

2. RFC 7348, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", Section 4. This RFC defines the VNI as the "24-bit ID" used to identify the virtual network segment.

In a Juniper Apstra environment, off-box device agents can run directly on the controller VM. When the number of managed devices grows, these agents can consume significant CPU and memory, impacting the controller's performance. The designed architectural solution for this is to scale horizontally by deploying Apstra worker VMs. These worker VMs form a cluster with the controller, and resource-intensive tasks, such as running off-box agents, can be offloaded from the controller to the workers, thus distributing the load and preserving controller resources.

A. Add more CPU and memory to the Apstra controller VM.

This is vertical scaling and may provide temporary relief, but the recommended Apstra architecture for scaling agent load is horizontal scaling with worker VMs.

C. Use on-box agents instead of off-box agents.

This is a different architectural choice that depends on device support; it doesn't solve the performance issue for an existing off-box agent deployment.

D. Modify the agent profile to consume less resources.

Agent profiles in Apstra are used to define connection parameters (e.g., protocol, credentials), not to manage or throttle agent resource consumption.

1. Juniper Apstra User Guide, "Apstra Cluster". The documentation explains, "For large-scale deployments, you can deploy Apstra worker nodes to which you can offload resource-intensive tasks from the Apstra controller. Off-box device agents are one of the tasks that can be offloaded to worker nodes."

2. Juniper Apstra Deployment Guide, "System Requirements and Sizing". This guide details the specifications for controller and worker VMs, outlining the cluster architecture for scaling deployments.

In Juniper Apstra, design elements are hierarchical. Logical devices are foundational building blocks used within interface maps. Interface maps are then used in rack types, and rack types are used in templates. To modify a logical device that is already in use, all dependent objects that reference it must first be removed or unlinked. This includes any templates, the rack types used in those templates, and the interface maps used in those rack types. Attempting to modify the logical device without removing these dependencies results in an error, as the change could invalidate the dependent designs.

A. This is incomplete. Removing only the templates is not sufficient, as the logical device is still referenced by interface maps and rack types.

B. This is incomplete. While interface maps must be removed, the rack types and templates that use them also create a dependency that must be resolved.

C. This is incomplete. Removing only the rack types is insufficient, as the templates and interface maps that reference the logical device must also be removed.

1. Juniper Apstra 4.2 User Guide. In the "Design > Logical Devices" section, the documentation notes constraints on editing design elements. Specifically, it states, "You can't edit a logical device that is used in an interface map." This principle extends to all dependent objects in the hierarchy (racks, templates). To edit the logical device, the chain of dependencies must be broken.