Free Practice Questions for Juniper JN0-480 Exam

According to the Juniper documentation1, the Resources menu in the Juniper Apstra UI allows you to create and manage various types of resources that are assigned to different elements of the network. Resources include the following types:

IPv4 (including Host IPv4)

IPv6 (including Host IPv6)

ASN (autonomous system number)

VNI (virtual network identifier)

VLAN (virtual local area network)

Integer (used for pool type VLAN in local pools in Freeform blueprints)

Therefore, the correct answer is C and D. ASN pools and IP pools are two types of resources that can be created in the Resources menu. Bridge domain identifier (BDI) and DHCP pools are not applicable in this scenario, because they are not part of the resources types supported by Juniper Apstra. References: Resources Introduction | Apstra 4.1 | Juniper Networks

To implement remote user authentication for the role-based access control of your Apstra server, you can use one of the following methods: TACACS+, LDAP, or RADIUS. These are the protocols that Juniper Apstra supports to authenticate and authorize users based on roles assigned to individual users within an enterprise. You can configure the Apstra server to use one or more of these protocols as the authentication sources and specify the order of preference. You can also configure the Apstra server to use local user accounts as a fallback option if the remote authentication fails. The other options are incorrect because:

D. SAML is wrong because SAML (Security Assertion Markup Language) is not a supported protocol for remote user authentication for the role-based access control of your Apstra server. SAML is an XML-based standard for exchanging authentication and authorization data between different parties, such as identity providers and service providers. SAML is commonly used for web-based single sign-on (SSO) scenarios, but it is not compatible with the Apstra server.

E. Auth0 is wrong because Auth0 is not a protocol, but a service that provides authentication and authorization solutions for web and mobile applications. Auth0 is a platform that supports various protocols and standards, such as OAuth, OpenID Connect, SAML, and JWT. Auth0 is not a supported service for remote user authentication for the role-based access control of your Apstra server. References:

User Authentication Overview

[Juniper Apstra] Authentication and Authorization Debugging1

Authenticate User (API)

Configure Apstra Server

According to the Juniper documentation1, a predefined device profile is a configuration template that is shipped with Apstra software and supports most qualified Juniper devices. A predefined device profile cannot be changed, since any changes would be discarded and overwritten when you upgrade the Apstra server version. If you want to customize a predefined device profile, you can clone and edit it instead. Therefore, the correct answer is A. The changes you make to a predefined device profile will be discarded and overwritten when upgrading the Apstra server version. References: Edit Device Profile | Apstra 4.2 | Juniper Networks

A security policy is the feature that would be used to accomplish the task of controlling access to other virtual networks in the same routing zone using the Juniper Apstra UI. A security policy allows you to define rules that specify which traffic is allowed or denied between different virtual networks, IP endpoints, or routing zones. A security policy can be applied to one or more virtual networks in the same routing zone, and it can use various criteria to match the traffic, such as source and destination IP addresses, protocols, ports, or tags. A security policy can also support DHCP relay, which enables the forwarding of DHCP requests from one virtual network to another. The other options are incorrect because:

A. interface policy is wrong because an interface policy is a feature that allows you to configure the interface parameters for the devices in a blueprint, such as interface names, speeds, types, or descriptions. An interface policy does not affect the access control between different virtual networks in the same routing zone.

B. anti-affinity policy is wrong because an anti-affinity policy is a feature that allows you to prevent certain devices or logical devices from being placed in thesame rack or leaf pair in a blueprint. An anti-affinity policy is used to enhance the availability and redundancy of the network, not to control the access between different virtual networks in the same routing zone.

C. routing policy is wrong because a routing policy is a feature that allows you to configure the routing parameters for the devices in a blueprint, such as routing protocols, autonomous system numbers, route filters, or route maps. A routing policy does not affect the access control between different virtual networks in the same routing zone, unless the routing policy is used to filter or modify the routes exchanged between different routing zones. References:

Security Policy

Interface Policy

Anti-Affinity Policy

Routing Policy

Juniper Apstra supports three deploy modes for devices: Deploy, Drain, and Ready. These modes determine the configuration and state of the devices in the data center fabric12.

Deploy: This mode applies the full Apstra-rendered configuration to the device, according to the Apstra Reference Design. The device state becomes IS-ACTIVE and the device is ready to carry traffic in the fabric12.

Drain: This mode adds a “drain” configuration to the device, which prevents any new traffic from entering the device. The device state becomes IS-READY and the device is prepared for maintenance or decommissioning12.

Ready: This mode removes the Apstra-rendered configuration from the device, leaving only the basic configuration such as device hostname, interface descriptions, and port speed/breakout. The device state becomes IS-READY and the device is not part of the fabric12. References:

Device Configuration Lifecycle

Set Deploy Mode (Datacenter)

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.

References:

IP Fabric Overview

Broadcast Domain - NetworkLessons.com

BGP is the protocol used to advertise EVPN routes. EVPN routes are a new type of BGP network layer reachability information (NLRI) that carry MAC address and IP prefix information for Ethernet VPNs. EVPN routes are exchanged between PEs using BGP multiprotocol extensions (MP-BGP) over MPLS, VXLAN, SR, or SRv6 tunnels. EVPN routes enable PEs to learn the reachability of MAC addresses and IP prefixes of different sites within the same EVPN instance. EVPN routes also support various features such as fast convergence, redundancy, aliasing, and inter-subnet routing. The other options are incorrect because:

A. OSPF is wrong because OSPF is an interior gateway protocol (IGP) that is used to advertise IP routes within an autonomous system. OSPF is not used to advertise EVPN routes, which are a type of BGP NLRI that carry MAC address and IP prefix information for Ethernet VPNs.

C. IS-IS is wrong because IS-IS is an interior gateway protocol (IGP) that is used to advertise IP routes and MPLS labels within an autonomous system. IS-IS is not used to advertise EVPN routes, which are a type of BGP NLRI that carry MAC address and IP prefix information for Ethernet VPNs.

D. RIP is wrong because RIP is an interior gateway protocol (IGP) that is used to advertise IP routes within an autonomous system. RIP is not used to advertise EVPN routes, which are a type of BGP NLRI that carry MAC address and IP prefix information for Ethernet VPNs. References:

EVPN Fundamentals

RFC 9136 - IP Prefix Advertisement in Ethernet VPN (EVPN)

EVPN Type-5 Routes: IP Prefix Advertisement

Understanding EVPN Pure Type 5 Routes

Device profiles are objects that associate a specific vendor model to a logical device in Juniper Apstra. Device profiles contain extensive hardware model details, such as form factor, ASIC, CPU, RAM, ECMP limit, and supported features. Device profiles also define how configuration is generated, how telemetry commands are rendered, and how configuration is deployed on a device. Device profiles enable the Apstra system to render and deploy the configuration according to the Apstra Reference Design12. References:

Device Profiles

Juniper Device Profiles

In the EVPN-VXLAN data center fabric bridged overlay architecture shown in the exhibit, the servers are connected to Leaf1 and Leaf6 using the same virtual network identifier (VNI). This means that the servers belong to the same Layer 2 domain and can communicate with each other using VXLAN tunnels across the fabric. The underlay network provides the IP connectivity between the leaf and spine devices, and it uses EBGP as the routing protocol. Therefore, the following two statements are correct in this scenario:

Loopback IPv4 addresses must be advertised into the EBGP underlay from leaf and spine devices. This is because the loopback addresses are used as the source and destination IP addresses for the VXLAN tunnels, and they must be reachable by all the devices in the fabric. The loopback addresses are also used as the router IDs and the BGP peer addresses for the EBGP sessions.

The underlay EBGP peering’s must be established between leaf and spine devices. This is because the EBGP sessions are used to exchange the underlay routing information and the EVPN routes for the overlay network. The EBGPsessions are established using the loopback addresses of the devices, and they follow a spine-and-leaf topology, where each leaf device peers with all the spine devices, and each spine device peers with all the leaf devices.

The following two statements are incorrect in this scenario:

The underlay must use IRB interfaces. This is not true, because the underlay network does not provide any Layer 3 gateway functionality for the overlay network. The IRB interfaces are used to provide inter-VXLAN routing within the fabric, which is not the case in the bridged overlay architecture. The IRB interfaces are used in the edge-routed bridging (ERB) or the centrally-routed bridging (CRB) architectures, which are different from the bridged overlay architecture.

The underlay must be provisioned with PIMv2. This is not true, because the underlay network does not use multicast for the VXLAN tunnels. The VXLAN tunnels are established using EVPN, which uses BGP to distribute the MAC and IP addresses of the end hosts and the VTEP information of the devices. EVPN eliminates the need for multicast in the underlay network, and it provides optimal forwarding and fast convergence for the overlay network.

References:

Exploring EVPN-VXLAN Overlay Architectures – Bridged Overlay

EVPN LAGs in EVPN-VXLAN Reference Architectures

EVPN-VXLAN Configuration Guide