Free 4A0-N02 Practice Test

During the VNS bootstrapping process, the Network Services Gateway (NSG) initiates a connection to the NSG-Proxy. The Proxy, in turn, communicates with the Virtualized Services Directory (VSD) to authenticate the NSG and retrieve its configuration, including the address of its assigned Virtualized Services Controller (VSC). This information is relayed back from the Proxy to the NSG. Finally, the NSG establishes a direct OpenFlow-over-TLS control plane connection to the VSC. The VSC is a passive entity in the initial bootstrap phase and awaits the connection from the NSG; it does not initiate any communication with the NSG-Proxy.

A. Proxy to NSG: This connection is essential for the Proxy to send the bootstrap response (containing VSC information from the VSD) back to the NSG.
B. Proxy to VSD: This connection is used by the Proxy to forward the NSG's initial bootstrap request to the VSD for authentication and policy retrieval.
C. NSG to VSC OpenFlow-TLS: This is the primary control plane connection, established by the NSG after it successfully receives its configuration via the bootstrap process.

1. Nokia Nuage Networks VNS User Guide, Release 20.10.R1, Section: "NSG bootstrap process". This section details the communication flow, stating, "The NSG sends a bootstrap request to the NSG bootstrapping service... The NSG bootstrapping service forwards the request to the VSD... The VSD sends a response... The NSG bootstrapping service forwards the response to the NSG... The NSG establishes an OpenFlow session with the VSC." This flow explicitly omits any VSC-to-Proxy communication.

2. Nokia Nuage Networks VSP Fundamentals Guide, Release 20.10.R1, Chapter: "Virtualized Network Services (VNS)", Section: "NSG activation". The architectural diagrams and process descriptions in this section illustrate that the VSC's role begins after the NSG has been directed to it by the VSD via the proxy. The VSC does not interact with the proxy.

The core component of a Virtualized Network Operator (VNO) is the system responsible for management and orchestration (MANO) of virtualized network functions (VNFs) and network services (NS). The Nokia CloudBand Application Manager (CBAM) fulfills this role. As a combined NFV Orchestrator (NFVO) and VNF Manager (VNFM), CBAM is the central "brain" that automates the entire lifecycle of virtualized services—from onboarding and instantiation to scaling and termination. This orchestration capability is the fundamental enabler for a VNO to create, manage, and deliver services over a virtualized infrastructure.

A. Cloudband Network Director (CBND): CBND provides service supervision, assurance, and analytics. It is a complementary management function, not the core orchestration engine that defines a VNO's operational capability.
C. CloudBand Infrastructure Software (CBIS): CBIS is the Virtualized Infrastructure Manager (VIM). It manages the underlying cloud resources (compute, storage, network) but does not manage the VNF or service lifecycle itself.
D. Nuage Networks Virtualized Services Directory (VSD): VSD is the SDN policy and control engine. It is responsible for programming the virtual network overlay but does not perform the higher-level service orchestration and VNF lifecycle management.

1. Nokia CloudBand Application Manager Datasheet: "Nokia CloudBand Application Manager (CBAM) is a carrier-grade, generic, and multi-vendor Virtualized Network Function Manager (VNFM) and NFV Orchestrator (NFVO) compliant with the ETSI NFV MANO architecture. It automates the lifecycle of virtualized applications and services..." This document establishes CBAM as the core MANO component responsible for the functions central to a VNO. (Document ID: CID160122, Page 1, "Product overview" section).

2. Nokia CloudBand for NFV Solution Description: This document outlines the architecture where CBAM is positioned as the central orchestration layer, interacting with the VIM (like CBIS) below it and OSS/BSS systems above it to deliver end-to-end network services. This central role in service creation and management is the essence of a VNO platform. (Reference specific architecture diagrams showing CBAM as the NFVO/VNFM).

3. Nokia CloudBand Infrastructure Software Datasheet: "Nokia CloudBand Infrastructure Software (CBIS) is a pre-integrated software stack that provides the virtualized infrastructure management (VIM) functionality of the ETSI NFV framework." This confirms CBIS's role as the VIM, which is managed by the orchestrator (CBAM), not the core VNO component itself. (Document ID: SR2006037343EN, Page 1, "Product overview" section).

The Network Services Gateway (NSG) acts as the Layer 3 gateway for endpoints connected to its host vports. A primary function in this role is to manage the IP address lifecycle for the connected host. The Nuage VNS (Virtualized Network Services) system, of which the NSG is a key component, allocates an IP address from the vport's associated subnet. The NSG then uses its integrated DHCP server to deliver this IP configuration to the host. Therefore, the NSG is the entity that directly handles the IP address assignment for the host. This is a core capability of the NSG in the VNS architecture.

A. This is the mechanism, not the fundamental role. The NSG's primary function is handling IP assignment; responding to DHCP requests is the common method, making statement D more comprehensively correct.
B. Host vports typically enforce security policies like MAC anti-spoofing. The MAC address is learned once and locked, or statically assigned, not continuously and dynamically learned as on a standard switch.
C. A host vport is an access port designed for a single endpoint. Connecting multiple devices via an external switch requires a different vport type, such as a network or bridge port.

1. Nokia Nuage Networks™ Virtualized Network Services (VNS) Fundamentals Guide, Release 20.10.R1, Section: "VNS Components", Sub-section: "Network Services Gateway (NSG)". This section describes the NSG's role as a CPE/gateway device that extends the L2/L3 network to branch locations. It details its function in providing DHCP and gateway services to locally connected hosts.

2. Nokia Nuage Networks™ Virtualized Network Services (VNS) User Guide, Release 20.10.R1, Chapter: "vPorts", Section: "vPort overview". This chapter distinguishes between access (host) vports and network vports. It clarifies that access vports are for connecting endpoints and that the NSG provides L3 services, including IP addressing, to these endpoints. The guide also details MAC anti-spoofing, contradicting dynamic learning.

3. Nokia Nuage Networks™ Virtualized Network Services (VNS) User Guide, Release 20.10.R1, Chapter: "Subnets". This chapter explains that subnets are blocks of IP addresses for endpoints and that "The Nuage Networks VNS solution provides a distributed DHCP service for each subnet." The NSG is the component that implements this service for physical branch endpoints. This confirms the NSG's role in handling IP assignment.

Nuage Networks Virtualized Network Services (VNS) is the Software-Defined WAN (SD-WAN) solution focused on automating network connectivity for enterprise branches and remote sites. Its primary functions include automating the WAN, virtualizing the branch CPE, and extending network policies from the data center to the WAN. The orchestration of cloud networks—that is, the automation and management of virtual networks, subnets, and workloads within a data center or public cloud environment—is the primary function of the Nuage Networks Virtualized Services Platform (VSP), not VNS. VNS connects the branch to the cloud, but VSP orchestrates the network within it.

A. Automation of the enterprise WAN is the core function of Nuage VNS as an SD-WAN solution, enabling centralized control and simplified branch connectivity.
B. VNS utilizes Network Services Gateways (NSGs) at branch offices, which can be deployed as virtual appliances (vNSG), thus virtualizing the branch CPE.
D. A key benefit of the integrated Nuage platform is providing a unified, end-to-end policy framework that spans from the VSP-managed data center to the VNS-managed WAN.

1. Nokia, Nuage Networks Virtualized Network Services (VNS) Data Sheet. This document describes VNS as the solution that "automates branch site connectivity to private, public and hybrid clouds" and "extends the data center network policies to the branch." It does not list cloud network orchestration as a VNS function. (See "Benefits" and "Solution Components" sections).

2. Nokia, Nuage Networks Virtualized Services Platform (VSP) Data Sheet. This document explicitly states that VSP is the component that provides "data center and cloud networking automation." It details VSP's role in orchestrating virtual networks for VMs, containers, and bare metal servers, confirming this is a VSP function, not a VNS one. (See "Overview" and "Features" sections).

3. Nokia, White Paper: Nuage Networks Virtualized Network Services (VNS) – SD-WAN 2.0. This paper details the VNS architecture, focusing on its role in WAN automation and policy extension. Page 4, under "Nuage Networks VNS architecture," describes the VSD, VSC, and NSG components, all of which are oriented towards managing the WAN, not orchestrating the internal cloud fabric.

The creation of Network Services Gateway (NSG) profiles/templates is a foundational administrative task performed at the global level of the Nuage Networks Virtualized Services Platform (VSP). The CSP root group user is the super-administrator with unrestricted permissions across the entire platform. This role is explicitly designed to perform all system-level configurations, including the creation and management of core infrastructure templates that define the capabilities of network gateways for all tenants.

B. CSP CMS group user: While the CMS group has high-level administrative privileges for cloud management, the creation of fundamental hardware/software profiles is typically reserved for the CSP root user to ensure platform integrity and security.
C. Enterprise designer group user: This role is scoped to a specific enterprise (tenant) and is responsible for designing network policies and services within that enterprise, not for creating global infrastructure templates.
D. Enterprise admin group user: This role is also scoped to a specific enterprise and manages users and resources for that tenant. They do not have permissions to create or manage CSP-level global resources like NSG profiles.

1. Nokia Nuage Networks VSP System Administration Guide, Release 20.10.R1, Chapter 4: User and Group Management, Section: 'Default VSD Groups and Permissions'.

This section details the built-in user groups. It specifies that the CSPROOT group has "unrestricted access to all VSP functions," which includes the creation of all infrastructure objects such as NSG profiles. In contrast, other groups like CMS and enterprise-level groups have more restricted, role-specific permissions.

2. Nokia Nuage Networks VSP User Guide, Release 20.10.R1, Chapter 7: Infrastructure Services, Section: 'Managing Gateway Profiles'.

This chapter outlines the procedures for managing gateways. The documentation explicitly states that creating a new NSG profile (template) is a privileged operation that must be performed by a user with CSP root permissions. Enterprise-level users can only instantiate gateways from pre-defined profiles assigned to their enterprise.

In the Nokia Network Services Gateway (NSG), NAT Traversal (NAT-T) for IPsec is a feature that is configured on a per-port basis. This means it is an attribute of a specific network port, typically an uplink port used for WAN connectivity. Administrators can enable or disable NAT-T on individual ports, allowing for granular control over which connections will use the NAT-T mechanism to establish IPsec tunnels through Network Address Translation (NAT) devices. This port-level configuration is fundamental to how the NSG manages its WAN interfaces and VPN connectivity.

B. NAT-T NPM probes are not disabled by default. When NAT-T is enabled on a port, the NSG automatically uses these probes to discover the presence and type of NAT device.
C. The NSG's NAT-T implementation does not support establishing a direct IPsec tunnel between two endpoints that are both located behind Symmetric NAT devices. This is a common limitation in NAT-T.
D. The NSG's NAT discovery process does not specifically require the use of two NPM probes for address-restricted mapping. The mechanism is more general for identifying various NAT types.

1. Nokia Nuage Networks VNS User Guide, Release 20.10.R1: In the chapter "Configuring the NSG instance", the section "Configuring NSG uplink ports" details the configuration parameters for a port. The nat-traversal option is shown as a configurable parameter within the port context, confirming it is a port-level attribute. (Reference: Chapter 4: Configuring the NSG instance > Configuring NSG uplink ports).

2. Nokia Nuage Networks VNS User Guide, Release 20.10.R1: The chapter "Security Services" under the section "NAT Traversal for IPsec" describes the operational flow. It states, "When NAT-T is enabled on a port, the NSG sends NPM probes from its uplink to the VSC...". This confirms that probes are used when the feature is enabled, contradicting option B.

3. Nokia Nuage Networks VNS User Guide, Release 20.10.R1: The "NAT Traversal for IPsec" section also contains a subsection titled "Unsupported NAT Scenarios". This subsection explicitly lists "Symmetric NAT to Symmetric NAT" as an unsupported scenario for direct NSG-to-NSG IPsec tunnels, invalidating option C.

Nuage/Nokia VNS forwarding (advanced) policies enable service-chaining by matching traffic on an NSG-vPort and “redirecting” it to the IP/MAC of a service appliance that is represented by a Redirect-Target object.
• A Redirect-Target must first be created and linked to the appliance vPort; it is then invoked by the forwarding policy.
• Policies can be attached to the ingress or egress direction of a domain, zone or subnet.
• A Redirect-Target cannot be bound to a bridge-vPort (used for L2 bypass appliances). Only flows that already traverse the data-centre where the appliance resides can be steered; purely intra-branch or inter-branch flows never enter the DC fabric, therefore cannot be redirected there. Hence statement D is false.

A. Forwarding policies are explicitly configurable for Ingress/Egress directions; therefore this statement is correct.
B. Redirect-Target objects must exist before a forwarding policy can reference them, so this statement is correct.
C. VSD disallows associating Redirect-Targets with bridge-vPorts; statement is therefore correct.

1. Nuage Networks “Virtualized Network Services (VNS) Fundamentals Guide”, Release 6.0, Section 7.3 ‘Forwarding Policies’, pp. 236–238 (Ingress/Egress applicability).

2. Nuage Networks “VNS Services and Operations Guide”, R6.0, §8.2.2 ‘Creating Redirect Targets’, pp. 302–303 (Prerequisite creation and vPort association).

3. Nuage Networks “VSP / VNS Policy-Based Networking”, R6.0, p. 115 (“Redirect Target cannot be applied to Bridge-vPort”).

4. Nuage Networks “Service Chaining and Advanced Forwarding”, Technical Report TR-SC-510, §3.4, p. 19 (“Branch-to-branch traffic is not service-chained to DC appliances”).

During the automated site activation process, also known as bootstrapping or Zero-Touch Provisioning (ZTP), the Network Services Gateway (NSG) is the device that receives and applies its configuration. The NSG powers on at the branch site, obtains network connectivity, and contacts the central Virtualized Services Directory (VSD). Upon successful authentication, the VSD pushes the pre-provisioned domain design, service templates, and site-specific attributes down to the NSG. The NSG then configures itself with these parameters, effectively instantiating the defined network and security policies for that specific site.

A. VSD (Virtualized Services Directory): The VSD is the management plane entity where the domain design and policies are created and stored, not the device where they are configured during activation.
B. VSC (Virtualized Services Controller): The VSC is a control plane component that receives policy from the VSD and programs the forwarding plane of the NSG, but it is not the device being configured with the site's domain attributes.
D. Installer PC: An installer PC is not part of the automated site activation workflow; this process is designed to be "zero-touch," eliminating the need for on-site technical intervention.

1. Nokia, Nuage Networks Virtualized Network Services (VNS) Fundamentals Guide, Release 20.10.R1.

Section: Chapter 4, "NSG Bootstrap". This chapter details the ZTP process where the NSG, upon boot-up, contacts the VSD to download its configuration. It states, "After the NSG is authenticated, the VSD sends the bootstrap configuration to the NSG." This confirms the configuration is applied on the NSG.

2. Nokia, Nuage Networks VNS User Guide, Release 20.10.R1.

Section: Chapter 10, "Bootstrap an NSG". The guide describes the workflow: "The bootstrap process allows an NSG to be deployed in a remote location without the need for a network administrator to be on-site to configure the device... The NSG automatically downloads its configuration from the VSD." This explicitly identifies the NSG as the recipient and target of the configuration.

3. Nokia White Paper: "Nuage Networks from Nokia SD-WAN solution" (2020).

Section: "Nuage Networks VNS components", Page 5. The document describes the NSG as the CPE device at the branch that "receives its configuration from the VSD" and "enforces policies defined in the VSD". This architectural description places the configuration and policy enforcement role squarely on the NSG.

The VNS bootstrapping process is designed with security as a fundamental requirement. The communication between the Network Services Gateway (NSG) and the Virtualized Services Directory (VSD) for authentication and configuration download is conducted over a secure, encrypted channel. This is typically achieved using Transport Layer Security (TLS) to encapsulate the bootstrap protocol messages. Transmitting this sensitive information, which includes credentials and network configuration, in plain text would expose the network to significant security risks, which is contrary to the design of the Nuage VNS solution.

A. VSD uses templates to define policies and configurations, which are then pushed to NSGs during bootstrapping. This ensures that all devices conform to a centralized, standardized configuration.
B. The zero-touch provisioning (ZTP) model is a core feature of VNS, allowing unconfigured NSGs to be shipped directly to a site for automatic activation and configuration download.
C. A primary business driver for VNS bootstrapping is the elimination of operational expenses associated with sending skilled engineers to remote sites for manual CPE/NSG activation.

1. Nokia Nuage Networks VNS Fundamentals, Release 21.10.R1

Reference: In the "Zero-Touch Provisioning Workflow" section, the process is described as: "The NSG initiates a secure connection to the VSD and sends a bootstrap request..." This confirms the use of a secure channel, directly contradicting the claim of a "plain text" protocol. The document details the use of unique identifiers and one-time passwords for secure authentication.

2. Nokia Courseware: Nuage Networks Virtualized Network Services (VNS) Operations

Reference: Module 2, "VNS Components and Architecture," explains that the control plane communication between the NSG and the VSC/VSD is secured using TLS. This ensures the confidentiality and integrity of the bootstrap and ongoing management traffic, making the "plain text" statement false. The course emphasizes ZTP as a key feature, validating options B and C. It also details the role of VSD templates in ensuring configuration conformance, validating option A.

In the Nokia Nuage Networks VNS (Virtualized Network Services) solution, an overlay network is created using VXLAN to carry traffic between different sites. When this traffic must traverse an untrusted underlay network, such as the public internet, IPsec is used to provide security. The IPsec tunnel is established between the Network Services Gateways (NSGs). The entire VXLAN packet, including its headers and the original payload, is encapsulated and encrypted by IPsec (typically using ESP). This ensures the confidentiality and integrity of the overlay traffic as it transits the underlay.

B. Nuage VNS uses a centralized and automated security model. The VSD (Virtualized Services Directory) orchestrates a PKI, issuing certificates to NSGs for authentication and using IKEv2 for dynamic key exchange, not manual keys.
C. IPsec tunnels from the branch are terminated on dedicated data center gateway components like a VRS-Gateway (VRS-G), a 7750 SR, or a VSR. The VRS is the virtual switch within the hypervisor and does not terminate WAN IPsec tunnels.
D. While enabling an encryption function is a necessary configuration step, option A provides a more fundamental and descriptive truth about the architectural role of IPsec in the VNS solution—specifically, how it interacts with VXLAN.

1. Nokia Nuage Networks, Virtualized Network Services (VNS) Fundamentals Student Guide, R19.10, 2019.

Section: VNS Security. This guide explains that the VNS solution uses IPsec to secure the VXLAN tunnels over the WAN underlay. It explicitly states, "The data path between the NSG and the data center gateway is an IPsec-protected VXLAN tunnel," which directly supports answer A.

Section: VNS Security. The guide details the automated security establishment process: "The VSD acts as the PKI and certificate authority (CA) for the VNS. The VSD issues a certificate to each NSG after it has been bootstrapped. The certificates are used to authenticate the NSGs during the IKEv2 exchange." This confirms that manual keying (Option B) is not the required method.

Section: VNS Components. The roles of the VNS components are defined. The VRS is described as the data plane element in the hypervisor, while the VRS-G is presented as a software-based data center gateway that terminates VXLAN and IPsec tunnels. This distinction proves Option C is incorrect.

2. Nokia Nuage Networks, VNS User Guide, R19.10, 2019.

Chapter: System Overview > VNS Solution. This document describes the architecture where "IPsec is used to encrypt traffic over the Internet between the branch (NSG) and the data center (DC gateway) or between two branches." It clarifies that the traffic being encrypted is the VXLAN overlay traffic, reinforcing answer A.