Juniper JN0-480 Data Center, Specialist Exam Practice Test

Answer : D

According to the Juniper documentation1, a routing zone is an L3 domain, the unit of tenancy in multi-tenant networks. You create routing zones for tenants to isolate their IP traffic from one another, thus enabling tenants to re-use IP subnets. In addition to being in its own VRF, each routing zone can be assigned its own DHCP relay server and external system connections. You can create one or more virtual networks within a routing zone, which means a tenant can stretch its L2 applications across multiple racks within its routing zone. For virtual networks with Layer 3 SVI, the SVI is associated with a Virtual Routing and Forwarding (VRF) instance for each routing zone isolating the virtual network SVI from other virtual network SVIs in other routing zones. Therefore, the correct answer is D. A routing zone is used to enable the communication between two VNIs within a VRF. A routing zone is not used for L4-L7 inspection, securing routing protocols, or requiring firewalls. Those are not the purposes of a routing zone in Juniper Apstra software.Reference:Routing Zones

Answer : B, C

To implement ECMP in IP fabric using EBGP, you need to enable BGP to install multiple equal-cost paths in the routing table and to advertise them to the peers. The following actions are required to achieve this:

B) Use a load balancing policy applied to BGP as an export policy. This is true because you need to apply a load balancing policy to BGP as an export policy to allow BGP to advertise multiple paths to the same destination to the peers. By default, BGP only advertises the best path to the peers, which prevents ECMP. A load balancing policy can be configured to match the desired routes and set the multipath attribute to true. This will enable BGP to advertise up to the maximum number of paths configured by the maximum-paths command. For example, the following configuration applies a load balancing policy to BGP as an export policy for the neighbor 10.10.10.1:

policy-statement load-balance { term 1 { from { route-filter 192.168.0.0/16 exact; } then { multipath; accept; } } } protocols { bgp { group ebgp { type external; neighbor 10.10.10.1 { export load-balance; } } } }

C) Use the multipath multiple-as BGP parameter. This is true because you need to enable the multipath multiple-as BGP parameter to allow BGP to install multiple paths from different autonomous systems in the routing table. By default, BGP only installs multiple paths from the same autonomous system, which limits ECMP. The multipath multiple-as parameter can be configured under the BGP group or neighbor level. This will enable BGP to install up to the maximum number of paths configured by the maximum-paths command. For example, the following configuration enables the multipath multiple-as parameter for the BGP group ebgp:

protocols { bgp { group ebgp { type external; multipath multiple-as; } } }

The following options are incorrect because:

A) Use a load balancing policy applied to the forwarding table as an export policy is wrong because applying a load balancing policy to the forwarding table does not affect the BGP advertisement or installation of multiple paths. A load balancing policy applied to the forwarding table only affects how the traffic is distributed among the multiple paths in the forwarding table. It does not enable ECMP in BGP.

D) Use a load balancing policy applied to BGP as an import policy is wrong because applying a load balancing policy to BGP as an import policy does not affect the BGP advertisement of multiple paths. A load balancing policy applied to BGP as an import policy only affects how the BGP routes are accepted or rejected from the peers. It does not enable ECMP in BGP.Reference:

IP Fabric Underlay Network Design and Implementation

Use ECMP to distribute traffic between two paths, one learned by eBGP and one learned by iBGP on a Cisco NX-OS switch

Example: Configure an EVPN-VXLAN Centrally-Routed Bridging Fabric Using EBGP

Answer : B, C

The cabling map is a graphical representation of the physical connections between the devices in the data center fabric. It shows the status of the cables, interfaces, and BGP sessions for each device. You can use the cabling map to verify and repair the cabling before deploying your blueprint. Based on the web search results, we can infer the following statements:

Apstra can use LLDP data from the spine-to-leaf fabric devices to update the connections in the cabling map.This is true because Apstra can collect LLDP data from the devices using the Generic Graph Collector processor and use it to update the cabling map automatically.LLDP is a protocol that allows devices to exchange information about their identity, capabilities, and neighbors12.

Apstra can use LLDP data from the leaf devices to update the leaf-to-generic connections in the cabling map.This is true because Apstra can also collect LLDP data from the leaf devices and use it to update the connections to the generic devices, such as routers, firewalls, or servers.Generic devices are devices that are not managed by Apstra but are part of the data center fabric23.

You must manually change the cabling map to update spine-to-leaf fabric links.This is false because Apstra can use LLDP data to update the spine-to-leaf fabric links automatically, as explained above.However, you can also manually change the cabling map to override the Apstra-generated cabling, if needed24.

You must manually change the cabling map to update leaf-to-generic links.This is false because Apstra can use LLDP data to update the leaf-to-generic links automatically, as explained above.However, you can also manually change the cabling map to override the Apstra-generated cabling, if needed24.Reference:

LLDP Overview

Edit Cabling Map (Datacenter)

Generic Devices

Import / Export Cabling Map (Datacenter)

Answer : B

In Juniper Apstra, a blueprint is a logical representation of the network design and configuration. When you create a new blueprint, you need to commit the changes to apply them to the network devices. However, committing the changes does not mean that the network is immediately updated and operational. It may take some time for the network to converge and reflect the new state of the blueprint. During this time, you may see some anomalies related to BGP in the main dashboard, which indicate that the BGP sessions are not established or stable between the devices. These anomalies are usually temporary and will disappear once the network converges and the BGP sessions are up and running. Therefore, the statement B is the most likely cause of these anomalies in this scenario.

The following three statements are less likely causes of these anomalies in this scenario:

You have misconfigured ASNs. This is possible, but not very likely, because Juniper Apstra provides ASN pools that can be automatically assigned to the devices based on their roles. You can also manually specify the ASNs for the devices, but you need to ensure that they are unique and consistent with the network design. If you have misconfigured ASNs, you may see some anomalies related to BGP, but they will not disappear after the network converges. You will need to fix the ASNs and commit the changes again to resolve the anomalies.

Spine-leaf links are incorrectly set. This is possible, but not very likely, because Juniper Apstra provides connectivity templates that can be used to define the spine-leaf links based on the interface maps. You can also manually specify the spine-leaf links, but you need to ensure that they are correct and match the physical cabling. If you have incorrectly set the spine-leaf links, you may see some anomalies related to BGP, but they will not disappear after the network converges. You will need to fix the spine-leaf links and commit the changes again to resolve the anomalies.

A generic system has not been configured. This is not relevant, because a generic system is a device that is not managed by Juniper Apstra, but is connected to the network. A generic system does not affect the BGP sessions between the devices that are managed by Juniper Apstra. If you have a generic system in your network, you need to configure it manually and ensure that it is compatible with the network design. A generic system does not cause any anomalies related to BGP in the main dashboard.

Blueprint Summaries and Dashboard

BGP Session Flapping Probe

Probe: BGP Session Monitoring

Answer : B, C

According to the Juniper documentation1, a generic system is a device that is not managed by Juniper Apstra and does not have a specific role or type assigned to it. A generic system can be used to represent a server, a firewall, a load balancer, or any other device that is not part of the fabric. In the exhibit, the device shown is a generic system, as indicated by its role, system type, and management level. Therefore, the correct answer is B. The device shown is a generic system.

According to the Juniper documentation2, a LAG is a link aggregation group that bundles multiple physical interfaces into a single logical interface. A LAG can provide increased bandwidth, redundancy, and load balancing for the network traffic. In the exhibit, the device shown has four physical interfaces that are part of a LAG, as indicated by their description and li_type. The LAG is facing the leaf pair, which are the two switches that connect to the device. Therefore, the correct answer is C. Four physical interfaces exist in a LAG facing the leaf pair.Reference:Generic Systems (Datacenter Design),Form LAG | Apstra 4.1 | Juniper Networks

Answer : B

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.Reference:

Device Profiles

Juniper Device Profiles

Answer : B

Juniper Apstra role-based access control (RBAC) is a feature that allows you to specify access permissions for different users based on their roles.RBAC servers are remote network servers that authenticate and authorize network access based on roles assigned to individual users within an enterprise1.Juniper Apstra has four predefined user roles: administrator, device_ztp, user, and viewer2. The administrator role is the most powerful role, and it can see all permissions and perform all actions in the Apstra software application.The administrator role can also create, clone, edit, and delete user roles, except for the four predefined user roles, which cannot be modified2. Therefore, the statement that the administrator role can see all permissions is correct.

The following three statements are incorrect in this scenario:

The viewer role is predefined and can be deleted. This is not true, because the viewer role is one of the four predefined user roles, and it cannot be deleted.The viewer role is the most restricted role, and it can only view the network information and configuration, but not make any changes2.

The user role can create roles. This is not true, because the user role is one of the four predefined user roles, and it cannot create roles.The user role can perform most of the network configuration and management tasks, but it cannot access the platform settings or the user management features2.

The administrator role is the only predefined role. This is not true, because there are four predefined user roles, not just one.The other three predefined user roles are device_ztp, user, and viewer2.

Providers --- Apstra 3.3.0 documentation

User/Role Management (Platform)