Free 350-501 Practice Test

In a multi-tenant environment where a single PE router provides centralized NAT services for multiple L3VPN customers, it is common for customers to use overlapping private IP address spaces (e.g., RFC 1918 addresses). To handle this, the NAT implementation must be VRF-aware. When a NAT translation is created for a packet originating from a customer's VRF, the NAT table on the PE router stores not only the IP and port mappings but also an identifier for the source VRF. This ensures that when return traffic arrives at the outside global address, the router can look up the correct translation, identify the original inside VRF, and forward the packet to the correct customer.

A. Port Address Translation (PAT) allows multiple inside local addresses, even from different VRFs, to be translated to the same outside global IP address using unique port numbers.
C. The question explicitly states that a single centralized router is providing the NAT service, which contradicts the premise that each site has a separate NAT.
D. A fundamental feature of MPLS L3VPNs is the ability to support customers with overlapping private IP address spaces, which VRF-aware NAT is specifically designed to accommodate.

1. Cisco IOS XE IP Addressing Services Configuration Guide

"Configuring NAT for VRF Awareness" section.

Reference: "When a packet is translated

a NAT translation entry is created. This entry contains the inside VRF of the packet. When a translated packet is forwarded

the VRF in the NAT translation entry is used to route the packet." This directly confirms that the NAT table contains a field for the inside VRF. The same document also states

"This feature allows multiple VRFs to be configured on a single device to use the same IP address

" which refutes option D.

2. Cisco IOS IP Application Services Configuration Guide

"NAT Virtual Interface" chapter.

Reference: The documentation for the NAT Virtual Interface (NVI) feature

which is often used in VRF-aware NAT

explains that translations are VRF-aware. The configuration commands

such as ip nat inside source ... vrf ...

explicitly tie the NAT rule and its subsequent translation entries to a specific VRF

demonstrating that the VRF is a key component of the translation logic.

3. Cisco Press

"MPLS Fundamentals" by Luc De Ghein

Chapter 8: "Advanced MPLS VPN Topics".

Reference: While a commercial book

its content is derived from official principles. It explains that for VPN Internet access

VRF-aware NAT is required to handle overlapping addresses. The NAT process must keep track of the originating VRF for each session to ensure return traffic is sent back to the correct VPN

which implies the VRF is part of the translation state.

Overlay Management Protocol (OMP) is the proprietary control plane protocol for the Cisco SD-WAN fabric. It operates between the vSmart controllers and the WAN Edge routers (vEdge/cEdge), and also between the vSmart controllers themselves. OMP is responsible for distributing routing information (such as OMP routes, TLOC routes, and service routes), security keys for data plane encryption, and centralized data policies across the overlay network. It establishes and maintains the SD-WAN control plane, functioning similarly to BGP but is purpose-built for the overlay environment. All OMP communication occurs over secure DTLS or TLS connections.

A. OTCP: This is not a standard or recognized protocol within the Cisco SD-WAN architecture; it is a fictitious acronym used as a distractor.
C. UDP: UDP is a transport layer (Layer 4) protocol. While OMP control connections are encapsulated within DTLS, which runs over UDP (or TLS over TCP), UDP itself is the transport mechanism, not the control plane protocol.
D. BGP: BGP is a standard routing protocol used on the service-side (LAN) or transport-side (underlay) of a WAN Edge router to exchange routes with external networks, not for the overlay control plane between routers and vSmart controllers.

1. Cisco SD-WAN Design Guide: In the "Control Plane" section of the "Cisco SD-WAN Architecture" chapter, it states, "The vSmart controller is the centralized brain of the solution... It runs an OMP (Overlay Management Protocol) to communicate with the SD-WAN routers. OMP is the protocol responsible for establishing and maintaining the Cisco SD-WAN control plane." (Reference: Cisco SD-WAN Design Guide, Chapter: Cisco SD-WAN Architecture, Section: Control Plane).

2. Cisco SD-WAN Overlay Management Protocol (OMP) Configuration Guide, Cisco IOS XE Release 17.x: The introduction clearly defines the protocol's role: "The Overlay Management Protocol (OMP) is the control protocol that runs between Cisco vSmart Controllers and WAN Edge routers in the overlay network. The protocol is enabled by default. You do not need to explicitly enable it on Cisco vSmart Controllers and WAN Edge routers." (Reference: Cisco SD-WAN Overlay Management Protocol (OMP) Configuration Guide, Cisco IOS XE Release 17.x, Document ID: bcgompxe-17, Chapter: Overlay Management Protocol Overview).

3. Cisco SD-WAN Getting Started Guide: This guide explains the function of each component, stating, "The Cisco vSmart Controller is the centralized brain of the Cisco SD-WAN solution... It runs the Overlay Management Protocol (OMP) and distributes connectivity and policy information to the WAN Edge routers." (Reference: Cisco SD-WAN Getting Started Guide, Chapter: Cisco SD-WAN Overlay Network, Section: Cisco vSmart Controller).

The core issue described is a race condition between the Interior Gateway Protocol (IGP) and the Label Distribution Protocol (LDP). When a network link recovers, the IGP (like OSPF or IS-IS) can converge and install a new route in the routing table faster than LDP can establish a session and exchange labels for that path. This results in traffic being forwarded to a next-hop for which no MPLS label exists, causing packets to be dropped (black-holed). The MPLS LDP IGP Synchronization feature is designed specifically to prevent this. It instructs the IGP to advertise a link with a maximum metric until the LDP session is established and synchronized over that link, effectively delaying its use for traffic forwarding until the MPLS data plane is ready.

A. Disabling IP CEF is incorrect because Cisco Express Forwarding (CEF) is a prerequisite for MPLS operation on Cisco routers and is essential for high-performance forwarding.
C. LDP Session Protection is a feature that maintains LDP sessions during link failures by using a different IP path, but it does not address the initial convergence synchronization issue between IGP and LDP.
D. Disabling MPLS LDP IGP synchronization is the opposite of the required action; it would ensure the problem of unsynchronized convergence and potential packet loss persists.

1. Cisco IOS XE MPLS Configuration Guide, Release Gibraltar 16.11.x, "MPLS LDP-IGP Synchronization" section: "The MPLS LDP-IGP Synchronization feature ensures that the Label Distribution Protocol (LDP) is fully established before the Interior Gateway Protocol (IGP) starts to forward traffic through a link... To prevent packet loss, the MPLS LDP-IGP Synchronization feature delays the IGP from advertising a link until LDP is fully synchronized."

2. Cisco IOS XR MPLS Configuration Guide for the Cisco CRS Router, "Implementing LDP-IGP Synchronization" chapter: "LDP-IGP synchronization is a mechanism that allows you to synchronize LDP and an IGP. This synchronization prevents the loss of MPLS packets that can occur because the IGP has converged on a link, but LDP has not."

3. Cisco IOS MPLS Configuration Guide, Release 12.4, "MPLS LDP-IGP Synchronization" section: "When a link comes up, the IGP can converge faster than the LDP. If the IGP converges faster, the router may start to forward IP packets before the MPLS forwarding table is updated with the labels for the new link. The packets are then dropped. To prevent packet loss, the MPLS LDP-IGP Synchronization feature delays the IGP from advertising a link until LDP is fully synchronized."

LDP Non-Stop Forwarding (NSF), also known as LDP Graceful Restart, is a high-availability feature that preserves the MPLS forwarding table (LFIB) during a control plane failure or restart. For LDP NSF to function correctly, it relies on the underlying Interior Gateway Protocol (IGP) also being NSF-capable. This ensures the routing information (FIB), upon which LDP builds its label bindings, remains stable. Therefore, enabling NSF for the link-state IGP (OSPF or IS-IS) is a mandatory prerequisite. Additionally, the LDP Graceful Restart mechanism is designed to operate between directly connected LDP peers, which is a stated requirement in the Cisco implementation.

A. This is too specific. The requirement is for the active IGP to be NSF-aware, which is more generally stated in option B, as LDP NSF is primarily documented with link-state protocols.
C. Cisco Express Forwarding (CEF) is a fundamental prerequisite for both MPLS and NSF. Disabling it would prevent the separation of control and data planes that NSF relies upon.
E. BGP NSF is a complementary but separate high-availability feature. It is not a direct dependency for implementing LDP NSF, which handles transport labels within the core.

1. Cisco Systems

"MPLS Label Distribution Protocol Configuration Guide

Cisco IOS XE Gibraltar 16.12.x". In the "LDP Graceful Restart" section

under "Prerequisites for LDP Graceful Restart

" the guide explicitly states:

"You must enable graceful restart for the link-state IGP (OSPF or IS-IS) that is in use on the network." (Supports option B)

"You must implement direct connections for LDP peers." (Supports option D)

"You must enable Cisco Express Forwarding (CEF)." (Refutes option C)

2. Cisco Systems

"MPLS High Availability Configuration Guide

Cisco IOS XE Release 3S". The section "How to Configure MPLS High Availability Features" details the configuration for "MPLS LDP Nonstop Forwarding." It lists the same prerequisites

confirming that the IGP must be NSF-capable and LDP peers must be directly connected. It makes no mention of BGP NSF being a prerequisite for LDP NSF.

In Cisco IOS XR, for an address family (e.g., IPv4 unicast) to be active for a specific neighbor, it must first be enabled globally under the router bgp process. The provided configuration is missing the global address-family ipv4 unicast block. Furthermore, while IPv4 unicast is typically enabled by default for new neighbors, this default behavior is suppressed when another address family (in this case, vpnv4 unicast) is configured globally. Because the global IPv4 unicast capability is not enabled, the address-family ipv4 unicast configuration under the neighbor is an error. It attempts to activate a capability that the local BGP process does not support, which will cause the BGP capability negotiation to fail and prevent the session from being established for IPv4.

A. The configuration explicitly references inbound and outbound route policies (route-policy pass-all), so the statement that a policy is absent is incorrect.
C. The VPNv4 and IPv4 unicast address families are distinct and can coexist. The presence of a VPNv4 configuration does not interfere with IPv4 negotiation, it only changes the default behavior.
D. BGP uses default values for TCP session parameters (e.g., timers) if they are not explicitly configured. The absence of these optional parameters is not an error.

1. Cisco IOS XR BGP Configuration Guide

Release 7.3.x - "BGP Overview" and "Configuring a BGP Neighbor" sections. The guide details the Address Family Identifier (AFI) model in IOS XR. It explains that configuration is performed under address families and that for a neighbor to use an address family

it must be enabled for that neighbor. Implicitly

the BGP process must first be configured for that address family globally.

Reference Detail: In the "Configuring a Basic BGP Process" section

the documentation states

"BGP also requires that you configure at least one address family that BGP will carry routing information for

and at least one BGP neighbor." This establishes the requirement for global address-family configuration.

2. Implementing BGP for Cisco IOS XR (Cisco Press) - Chapter 3

"BGP Configuration on Cisco IOS XR Software

" Section: "Address Family Configuration."

Reference Detail (Page 68): "By default

when you configure a neighbor

the IPv4 unicast address family is activated for that neighbor. However

if you configure a different address family first

then the IPv4 unicast address family is not activated by default. You must configure it manually." This source confirms that the presence of the address-family vpnv4 unicast configuration disables the default IPv4 activation

making the explicit but incomplete IPv4 configuration the source of the error.

The question requires identifying two Next-Next-Hop (NNHOP) backup tunnels for the primary LSP path R6-R2-R5-XR2. NNHOP protection is a node protection mechanism where the Point of Local Repair (PLR) creates a backup tunnel that bypasses the immediate next-hop node and terminates at the node after it (the NNHOP).
1. To protect node R2, the PLR is R6. The NNHOP is R5. The backup tunnel must go from R6 to R5 without traversing R2. The path R6-R1-R4-R5 meets this requirement.
2. To protect node R5, the PLR is R2. The NNHOP is XR2. The backup tunnel must go from R2 to XR2 without traversing R5. The path R2-R1-R4-XR1-XR2 meets this requirement.

B: This describes link protection (to the next-hop R5), not NNHOP protection, which must bypass the next-hop node entirely. D: This path is a segment of the primary LSP, not a backup tunnel. A backup must provide an alternate path around a potential failure. E: This tunnel terminates at the protected node (R2) instead of bypassing it to reach the NNHOP (R5), making it invalid for NNHOP protection.

1. Cisco Systems

"MPLS Configuration Guide

Cisco IOS XE Fuji 16.9.x"

Chapter: MPLS Traffic Engineering -- Fast Reroute Link and Node Protection. The section "How to Configure MPLS TE Fast Reroute Link and Node Protection" states

"For node protection

the PLR calculates a backup tunnel that bypasses the primary next-hop node. The backup tunnel terminates at the next-next-hop node." This directly supports the selection of paths that bypass the immediate next-hop (R2 and R5 respectively) and terminate at the NNHOP (R5 and XR2 respectively).

2. Pan

P.

et al. "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels"

IETF

May 2005

Section 4.2

"Node Protection". This foundational standard defines node protection

stating the backup tunnel "bypasses the protected next-hop node". The diagrams and text illustrate that the PLR forwards traffic to the NNHOP

which is exactly the behavior described in the correct answers.

3. Cisco Systems

"MPLS Configuration Guide for Cisco NCS 5500 Series Routers

IOS XR Release 7.3.x"

Chapter: Implementing MPLS Traffic Engineering

Section: Configure MPLS-TE Fast Reroute (FRR). This guide reinforces the concept: "Node protection creates a backup path that bypasses the next-hop router on the LSP." This confirms the principle that the backup tunnel must avoid the immediate downstream node.

The provided JSON payload is structured according to the IETF YANG data model for interfaces (ietf-interfaces) and IP management (ietf-ip). The script targets an interface named "Loopback1". Within the payload, it defines several configuration attributes for this interface, including a description, an enabled state, and most importantly, an IPv4 address ("ip": "192.168.1.1") and netmask. This data is sent via a RESTCONF API call (e.g., using PUT or PATCH) to configure the specified loopback interface on a Cisco device. The script's primary function is to apply this IP configuration.

B. Configure a physical interface on the router with an IP address and then create a loopback interface. The JSON payload only contains data for "Loopback1" and does not reference or configure any physical interfaces.
C. Configure a physical interface on the router with an IP address. The target interface is explicitly named "Loopback1", which is a logical (software) interface, not a physical one.
D. Delete the existing loopback Interface and replace it with a new loopback interface. This describes the mechanism of an HTTP PUT request, but it is not the direct action of the script itself. The script's purpose is to define a configuration, not to issue a delete command.

1. Cisco IOS XE Programmability Configuration Guide, Release 17.x - RESTCONF Protocol: This guide details how to use RESTCONF to manage Cisco devices. The section on "Configure a Feature Using RESTCONF" provides examples of JSON payloads for configuring interfaces. The structure in the question directly matches the standard format for defining interface attributes, including IP addresses, using the ietf-interfaces and ietf-ip YANG models. (Reference: See examples under "Configure a Feature Using RESTCONF" chapter).

2. RFC 8040 - RESTCONF Protocol: This is the standard defining the RESTCONF protocol. Section 3.5, "Data Resources," explains how URIs are used to target specific data nodes in the YANG data model, such as /ietf-interfaces:interfaces/interface=Loopback1. The JSON payload in the question is the content used in POST, PUT, or PATCH operations to manipulate this data resource.

3. RFC 8343 - A YANG Data Model for Interface Management (ietf-interfaces): This document defines the standard ietf-interfaces YANG model. Section 5.7 describes the interface list, which contains configuration for each interface, including its name. The JSON in the question uses this model to identify and configure "Loopback1".

4. RFC 8344 - A YANG Data Model for IP Management (ietf-ip): This RFC defines the ietf-ip model used for IP address configuration. Section 5 details the ipv4 container and the address list, which includes the ip and netmask leaves. The question's JSON payload uses this exact structure to define the IP address 192.168.1.1/255.255.255.0.

The iosxrcommand module, part of the cisco.iosxr Ansible collection, is specifically designed to execute arbitrary CLI commands on remote devices running Cisco IOS XR. This module is essential for automation tasks where a dedicated, idempotent module does not exist for a specific configuration or operational command. It allows administrators to run commands like show version or show running-config and capture the output for verification, troubleshooting, or reporting within an Ansible playbook, making it a versatile tool for network automation.

A. The iosxrsystem module manages global system settings like hostname and domain name. Fact collection is primarily handled by the iosxrfacts module.
B. The iosxruser module is used to manage user accounts and their properties (e.g., password, roles), not for configuring system banners. The iosxrbanner module manages banners.
C. The iosxrlogging module configures logging parameters. The description of "seventy levels 2 to 5" is nonsensical; logging levels are standardized (0-7), and the module name has a typo (losxr).

1. Ansible Documentation for Cisco IOS XR Modules. The official documentation for the cisco.iosxr.iosxrcommand module explicitly states its purpose: "Run commands on remote devices running Cisco IOSXR." This directly validates the correct answer.

Source: Ansible Documentation

cisco.iosxr.iosxrcommandmodule. (Accessed via docs.ansible.com)

2. Cisco IOS XR Programmability Configuration Guide. This official Cisco guide details the use of Ansible for managing IOS XR devices. It describes the iosxrcommand module as the method for sending CLI commands to the device.

Source: Cisco IOS XR Programmability Configuration Guide

Release 7.3.x

Chapter: "Using Ansible"

Section: "Ansible for Cisco IOS XR Software Modules".

3. Ansible Documentation for Incorrect Modules. The official Ansible documentation confirms the incorrectness of the other options by defining the specific functions of their respective modules:

cisco.iosxr.iosxrsystem: "Manages system attributes on Cisco IOSXR devices."

cisco.iosxr.iosxruser: "Manages user accounts on Cisco IOSXR devices."

cisco.iosxr.iosxrbanner: "Manage multiline banners on Cisco IOSXR devices."

Source: Ansible Documentation

cisco.iosxr collection. (Accessed via docs.ansible.com)

An Adjacency Segment Identifier (SID) is a fundamental component of Segment Routing (SR) that represents a specific, direct adjacency to a neighboring router. A key characteristic of an Adjacency SID is its local significance. This means the SID value is allocated by and is only meaningful to the local router that advertises it. Another router in the same SR domain can use the identical SID value for one of its own adjacencies without conflict. This contrasts with Prefix SIDs, which must be globally unique within the SR domain to ensure unambiguous routing to a specific node or prefix.

A. It applies only to point-to-point links. This is incorrect. Adjacency SIDs can be assigned to adjacencies on any link type, including point-to-point, broadcast, and non-broadcast multi-access (NBMA) links.
B. It applies only to multipoint links. This is incorrect. Adjacency SIDs are commonly used on point-to-point links and are not restricted to multipoint or broadcast link types.
D. It is globally unique. This is incorrect. Global uniqueness is a defining characteristic of Prefix SIDs, which are allocated from the Segment Routing Global Block (SRGB). Adjacency SIDs are explicitly local.

1. RFC 8402: Segment Routing Architecture.

Section 3.2

"Adjacency Segment": "An Adjacency SID is a local label that identifies an adjacency to a neighbor. An Adjacency SID is locally significant to the node that allocates it." This statement directly confirms the local uniqueness of the Adjacency SID.

2. Cisco Systems

"Segment Routing Configuration Guide

Cisco IOS XE Bengaluru 17.6.x"

Chapter: "Segment Routing for MPLS Data Plane"

Section: "Segment Identifier": "Adjacency SID—An adjacency SID is a local label that represents a specific adjacency

such as a link

to a neighboring router." The term "local label" explicitly denotes its local significance.

3. Cisco Systems

"Segment Routing MPLS Architecture" White Paper.

Section: "Segment Routing Building Blocks"

Subsection: "Adjacency SID": "The Adjacency SID is by nature a local SID. Its value is relevant only to the router that advertises it." This document reinforces that the scope of an Adjacency SID is confined to the originating router.

The scenario requires providing IPv6 connectivity between two dual-stack sites across an IPv4-only core network. This is a classic use case for an IPv6-in-IPv4 tunneling technology. The specific requirement to use a "specific assigned IPv6 space" from the company's administrators makes IPv6 Rapid Deployment (6rd) the most suitable choice. 6rd is a stateless tunneling mechanism that allows an organization to use its own IPv6 prefix to provide service over an IPv4 infrastructure. It automatically builds tunnels by embedding the IPv4 address of the edge device into the organization's assigned IPv6 prefix, providing scalable IPv6-to-IPv6 connectivity.

B. NAT46: This is not a standard IETF term. If interpreted as NAT64, its purpose is to allow IPv6-only clients to communicate with IPv4-only servers, which is not the required IPv6-to-IPv6 connectivity.
C. DS-Lite: Dual-Stack Lite is designed for the opposite scenario: providing IPv4 connectivity to users across an IPv6-only core network by tunneling IPv4 packets inside IPv6.
D. NAT44: This technology translates between IPv4 addresses (typically private to public). It is exclusively an IPv4 technology and is irrelevant for establishing IPv6 connectivity.

1. Cisco IOS XE IPV6 Configuration Guide, Cisco IOS XE Amsterdam 17.3.x: In the chapter "IPv6 over IPv4 Tunneling," the section on "IPv6 Rapid Deployment (6rd) Tunnel" states, "The IPv6 rapid deployment (6rd) feature allows a service provider to provide a unicast IPv6 service to customers over its IPv4 network. The 6rd feature uses a service provider-specific IPv6 prefix, which allows the service provider to use its own IPv6 address space." This directly supports the use of a specific assigned prefix over an IPv4 network.

2. RFC 5969: IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification: Section 1, "Introduction," describes 6rd as a mechanism for a Service Provider (or enterprise) to provide IPv6 access to customers over an existing IPv4 network using the provider's own IPv6 address prefix.

3. Cisco Press, CCNP Service Provider SPCOR 350-501 Official Cert Guide (1st Edition): Chapter 10, "IPv6 Transition Mechanisms," in the section "6rd Tunnels," explains, "6rd is similar to 6to4, but it is designed to be deployed within a single administrative domain... It allows the service provider to use its own IPv6 address prefix instead of the fixed 2002::/16 prefix used by 6to4." This confirms 6rd as the correct choice for using a specifically assigned prefix.