Free 4A0-106 Practice Test

The Carrier Supporting Carrier (CSC) VPRN model is designed to scale by isolating the backbone provider from the routing and service complexity of its customer carriers. The backbone provider is shielded from the explosion in the number of end-customer routes and VPNs, as these are managed entirely by the customer carrier. However, the backbone provider must create a separate VPRN instance (a VRF) for each customer carrier it services. Therefore, as the number of customer carriers increases, the number of VRFs and associated BGP sessions on the backbone PE routers (CSC-PEs) grows linearly. This directly consumes resources and adds configuration overhead, making it a scaling consideration rather than an inherent scaling benefit of the architecture.

A. This is a primary benefit. The backbone provider is unaware of the individual VPNs offered by the customer carrier, so the solution scales independently of this factor.
B. This is a core benefit. The backbone provider only carries routes for the customer carrier's infrastructure, not the vast number of routes from the end-customers.
C. This is an operational benefit. The backbone provider's responsibility ends with providing transport to the customer carrier, who in turn manages all end-customer services.

1. RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)

Section 10, "Carrier's Carrier": This section details the CSC architecture. It states, "The backbone carrier's PE router that is attached to the customer carrier's network maintains a VRF for that customer carrier's network." This confirms that each customer carrier requires a dedicated VRF, directly linking the number of carriers to the state on the backbone PE. It also states, "The number of routes in the backbone carrier's P-routers and PE-routers is independent of the number of VPN customers and the number of destinations in the VPNs," which validates that options A and B are key benefits.

2. Nokia 7750 SR OS Services Guide, Release 21.10.R1

Section: VPRN Carrier Supporting Carrier: The guide explains, "A VPRN is created on the backbone provider PE router for each customer carrier." This explicitly states the one-to-one relationship between customer carriers and VPRN instances on the backbone network, supporting the reasoning that scaling by the number of carriers is a direct resource consideration, not a benefit. It also notes, "The backbone VPRN provider does not need to know the end-customer’s routes," confirming the benefits listed in options A and B.

The standard BGP loop prevention mechanism relies on the ASPATH attribute; a BGP router rejects any route update where it sees its own Autonomous System (AS) number in the path. In a VPRN environment, it is common for a customer to use the same private AS number across multiple geographically separate sites. When a route from one customer site is advertised across the service provider's MP-BGP network to another of the customer's sites, the receiving Customer Edge (CE) router will see its own AS number in the ASPATH. Consequently, the CE router will drop the update, detecting a loop. This is the primary BGP loop challenge specific to VPRN architectures.

A. Traditional BGP loop detection (ASPATH check) functions correctly in a VPRN; it detects the customer's own AS in the path and drops the route as designed.
C. While this statement is true, it describes a general, default BGP behavior. Option B is more specific and accurately describes the VPRN scenario that triggers this behavior.
D. The remove-private command is applied to outbound BGP advertisements sent to a peer, not on routes received from a peer, to strip private AS numbers from the ASPATH.

1. Nokia 7750 SR OS Services Guide, Release 21.10.R1, "VPRN Services" Chapter, Section: "BGP AS Number Scenarios in a VPRN": This section explicitly details the scenario where a customer uses the same AS number at different sites. It states, "If the customer is using BGP to exchange routes with the service provider, it is possible that the customer is using the same AS number for all their sites. In this case, the BGP loop prevention mechanism will prevent the customer from learning their own routes from a remote site." This directly supports option B as the correct description of the issue. The document then introduces as-override and allow-as-in as solutions. (Document ID: 3HE 17484 AAAD TQZZA, Edition 01)

2. Nokia 7750 SR OS Routing Protocols Guide, Release 21.10.R1, "BGP" Chapter, Section: "Removing Private AS Numbers from the AS Path": This section describes the remove-private-as command. It clarifies its function: "When enabled, any private AS numbers are removed from the AS path of BGP routes that are advertised to an eBGP peer." This confirms the command is for outbound updates, invalidating the premise of option D. (Document ID: 3HE 17483 AAAD TQZZA, Edition 01)

3. RFC 4364, "BGP/MPLS IP Virtual Private Networks (VPNs)", Section 8: "Loop Prevention, Detection, and Mitigation": While not a Nokia-specific document, it is the foundational standard for this technology. Section 8.1 discusses the "AS Path Loop Prevention" issue when a customer uses the same AS at different sites, confirming that this is the standard problem scenario in BGP/MPLS VPNs. This provides the theoretical underpinning for option B.

In a hub-and-spoke VPRN topology, direct spoke-to-spoke communication is prevented. All traffic between spoke sites must transit through the central hub site. To enforce this traffic pattern, the spoke PEs (PE2 and PE3) are configured with a static route within the VPRN instance. The displayed static route (static-route 10.1.0.0/16 next-hop 10.1.1.1) directs traffic destined for the VPRN address space towards the hub CE's IP address (10.1.1.1). The spoke PEs resolve this next-hop via the MP-BGP route to the hub PE (PE1), ensuring that packets from one spoke are sent to the hub for routing to the destination spoke.

A. PE1: The hub PE (PE1) learns routes to the spokes via MP-BGP from other PEs. It does not require a static route pointing to its own connected hub CE.
B. CE1: The hub CE (CE1) is the central router. It needs specific routes to the spoke subnets, not a summary route pointing to its own interface address.
D. CE2 and CE3: Spoke CEs typically have a simple configuration with a default route pointing to their upstream PE router, which handles the complex VPRN routing.

1. Nokia 7750 SR OS Services Guide, Release 21.10.R1, "VPRN services" chapter, Section: "Hub and Spoke VPRN". This section details the implementation of hub-and-spoke topologies. It explains that spoke PEs can be configured with a static route pointing to the hub to ensure all inter-spoke traffic is forwarded through the hub site. The PE resolves the static route's next-hop via BGP-advertised routes from the hub PE.

2. Nokia Virtual Private Routed Networks (4A0-106) Courseware, Module 3: "VPRN Implementation and Verification". The course material explicitly covers hub-and-spoke VPRN design. It illustrates that to force traffic from spokes through the hub, a static route (often a default or summary route) is configured in the VPRN context on the spoke PEs, with the next-hop set to an IP address at the hub site.

In a CSC deployment the service-provider (SP) PE keeps only the information it needs to reach (a) its own backbone, and (b) the directly-attached customer-carrier (CC) device.
• The CE-facing subnet 10.10.10.6/30 is created as a connected route and therefore lives in the PE’s global routing table.
• 192.50.1.1 is the SP loop-back carried by the SP IGP, so it is also in the global table.
• 192.60.100.0/24 is a customer prefix that has been leaked into the global table so that next-hop resolution can be performed when the PE imposes transport labels. The remote CC-PE loop-back 10.10.10.3, however, is exchanged as a labeled IPv4 route inside the CSC VPRN only; it is not exported to the PE’s global RIB. Hence 10.10.10.3 is absent.

A. 192.60.100.0 – Imported to GRT for next-hop resolution of traffic toward the customer carrier; therefore present.
B. 10.10.10.6 – Directly connected CE interface; connected routes always appear in the GRT.
D. 192.50.1.1 – SP backbone loop-back distributed by the SP’s IGP; necessarily present in the GRT.

1. Nokia “Service Routing Architect (4A0-106) Student Guide”, Module 11 – Carrier Supporting Carrier, Sect. 11.3 “Route propagation”, pp. 11-18.

2. Nokia 7750 SR OS Routing Protocols Guide R21.7, Chap. 13 “BGP”, Sect. 13.8.2 “CSC VPRN—route installation”, pp. 1871-1873.

3. Boutros, M. “Carrier Supporting Carrier Architecture”, IEEE Communications Magazine, Vol 42 No 7, 2004, pp. 122-128 (see p. 124, para 3). https://doi.org/10.1109/MCOM.2004.1313060

4. MIT OpenCourseWare 6.829 “Computer Networks”, Lecture 18 slides, “Carrier’s-Carrier VPN”, slide 17 – notes on leaking only CE-facing subnets to provider core.

In a CSC VPRN the super-carrier (CSC-PE1/PE2) treats the label that arrives from the customer carrier (the BGP-LU label) as the service label and leaves it untouched; it only adds (pushes) its own transport label for carriage across its backbone. Therefore CSC-PE1 never removes (“pops”) the BGP label nor alters (“swaps”) the VPN label. Options A, B and D accurately describe the standard push/swap/pop sequence at the ingress customer PE, the customer border (CSC-CE1) and the egress CSC-PE2 respectively, but statement C contradicts the defined data-plane behaviour and is false.

A. Correct – ingress customer PE1 imposes VPN, BGP-LU and internal LDP labels before sending into the customer backbone.
B. Correct – CSC-CE1 strips the customer-LDP label and swaps the BGP-LU label learned from its eBGP peer.
D. Correct – Egress CSC-PE2 receives LDP-PHP, removes remaining LDP and VPN labels, and adds the BGP-LU label expected by CSC-CE2.

1. Nokia 7750 SR OS Services Guide, Rel 20.10, “Carrier Supporting Carrier – Data-plane label stack”, pp 1778-1781.

2. Nokia 4A0-106 Student Workbook v8.0, Module 4 “BGP/MPLS CSC”, slides 68-72 (diagram of label actions at PE/CE).

3. Nokia 7750 SR OS MPLS Guide, Rel 20.10, Sec 3.3 “Label push, swap, pop operations”, pp 138-139.

4. RFC 4364 – BGP/MPLS IP VPNs, Sec 10 “Carrier’s Carrier Model”, pp 25-26.

5. MIT OCW 6.829 “Computer Networks”, Lecture 17 Notes, page 6 – example of hierarchical MPLS label stacks.

In an inter-AS model C VPRN deployment that uses dedicated route-reflectors (RRs), each PE forms an MP-iBGP session only to the RR in its own AS. The ASBR in each AS forms an MP-iBGP session to its local RR so that VPN-IPv4/6 prefixes received over the inter-AS MP-eBGP link can be reflected to the PEs. The two RRs then create a multi-hop MP-eBGP session between themselves to exchange the labeled VPN routes across the AS boundary. Consequently, RR1 must maintain:
1) an MP-iBGP session with its client PE1,
2) an MP-iBGP session with the local ASBR1, and
3) a multi-hop MP-eBGP session with the remote RR2. Total = 3 sessions, making option B correct.

A. ASBR2 only peers with RR2 (MP-iBGP) and ASBR1 (MP-eBGP); no VPN session with PE2, so only two sessions.
C. PE2 has a single MP-iBGP session to RR2; it does not peer with ASBR2 in model C.
D. No BGP session is formed directly between PEs in different ASes; PE1 only peers with RR1.

1. Nokia SR OS 22.5.R1 BGP Services Guide, “Inter-AS Option C Using Route Reflectors”, pp. 493-495, fig. 185 – details RR-to-RR MP-eBGP and RR-client sessions.

2. RFC 4364 (Rosen & Rekhter), sec. 10.3, para 4-5 – describes option C with RR exchange of VPN-IPv4 routes via eBGP.

3. J. Medved et al., “Inter-AS VPN Option C Deployment”, IEEE Communications Mag., vol 45(9), 2007, pp. 144-146 – diagram shows RR with three BGP sessions as above.

Inter-AS model C (RFC 4364 option C) only requires that each autonomous system have a transport MPLS tunnel of some sort (LDP, RSVP-TE, or SR). LDP itself is therefore optional. What is mandatory is:
• inside each AS, VPN-IPv4/-IPv6 routes are carried by MP-iBGP (normally PE–RR or PE–PE);
• between ASBRs the labeled VPN routes are exchanged with MP-eBGP;
• on Nokia SR OS routers that act as ASBRs the command enable-inter-as-vpn must be configured to permit advertisement of VPN‐labeled NLRI across an external BGP session. Thus, only statement B, which makes LDP compulsory, is false.

A. MP-iBGP is indeed needed within every AS for VPN-IPv4 route dissemination, so the statement is correct.
C. ASBRs must run MP-eBGP to exchange labeled VPN routes across the AS boundary; the statement is correct.
D. Nokia SR OS requires enable-inter-as-vpn on ASBRs for option C; the statement is correct.

1. Nokia SR OS 22.x VPRN Guide, “Inter-AS Option C,” section 9.4.2, pp. 604-606 – notes that intra-AS transport may be LDP or RSVP-TE and describes MP-iBGP & MP-eBGP requirements.

2. Nokia SR OS 22.x BGP Guide, “enable-inter-as-vpn command,” section 8.2.1, p. 331 – states the command is mandatory on ASBRs to advertise VPN-IPv4/6 NLRI over eBGP.

3. Rosen & Rekhter, RFC 4364, sec. 10 (Option C) – specifies only “some MPLS tunneling technology” inside each AS, not necessarily LDP.

4. MIT 6.829 Course Notes, “BGP/MPLS IP VPNs” (Fall 2020), pp. 12-13 – summarizes that any MPLS transport (LDP or RSVP) suffices for option C, highlighting MP-eBGP between ASBRs.

In Inter-AS Option B, each ASBR replaces the VPN label learned from its internal PE with a new label before advertising the route to the external ASBR. On SR OS the CLI field inter-as-label shows exactly the label that will be carried in the MP-eBGP update sent to the peer. From the exhibit, inter-as-label = 131068; therefore ASBR1 advertises label 131068 to ASBR2. The original service label 131069 (displayed only as “label”) is kept for traffic arriving from the internal side and is not exported across the AS boundary.

A. 131069 is the service label learned from PE1; ASBR1 does not pass it across AS-boundaries.
C. PE1 is an internal iBGP peer; the inter-as label is never sent to it.
D. Only a single VPN label (131068) is sent; MP-eBGP cannot carry two VPN labels.

1. Nokia SR OS Services Guide, 20.10.R1, “Configuring Inter-AS Option B,” pp. 1040-1042 – paragraph “ASBR allocates a new VPN label (displayed as inter-as-label) for advertisement to external ASBR.”

2. Nokia SR OS BGP Guide, 20.10.R1, §5.7.3 “show router bgp routes … detail” – field description: “inter-as-label: MPLS label sent in MP-eBGP update to external peer,” p. 287.

3. RFC 4364, Section 10 (“Inter-AS Option B”): “The ASBR MUST allocate a new label for each VPN-IPv4 route before advertising it to another AS.”

The router-id command configured within a VPRN service context is specifically used by routing protocols, such as BGP or OSPF, that are running within that VPRN instance (typically for PE-CE routing). The provided configuration snippet does not show any routing protocols being configured within the VPRN. Therefore, the router-id 10.10.10.1 command is superfluous and has no operational effect. In the absence of a specific need, a VPRN should inherit the main router's system-level router ID. Including unnecessary commands is considered incorrect configuration practice.

A. The VPRN service ID (100) is a locally significant identifier on the router and is independent of the VRF target (target:65500:101), which is a BGP extended community used for route distribution.
B. The VPRN service ID (100) is a locally significant identifier and has no required relationship with the route distinguisher (65500:101), which is used to ensure route uniqueness across the provider network.
D. By default, all newly created services on the Nokia 7750 SR are in a shutdown state. This is a valid administrative state, not a configuration error. The service is simply not enabled yet.

1. Nokia 7750 SR OS Services Guide, Release 21.10.R1, VPRN Services Command Reference.

Section: router-id (under config>service>vprn): The documentation states, "This command configures the router ID for the VPRN service. This is used as the BGP router ID for BGP instances configured in the VPRN, or the OSPF router ID for OSPF instances configured in the VPRN. If the router-id command is not configured, the VPRN inherits the system-level router ID." This confirms the command's purpose is tied to protocols running within the VPRN, which are absent here, making the command unnecessary.

Section: shutdown (under config>service>vprn): The documentation specifies, "The shutdown command administratively disables the VPRN service... By default, a VPRN service is created in the shutdown state." This confirms that the shutdown state is the default and intended behavior, not an error.

2. Nokia 4A0-106 Courseware Materials.

Module: Virtual Private Routed Network (VPRN) services. The course materials emphasize that the VPRN router-id is an optional parameter used to override the system router ID for routing protocols like OSPF or BGP when they are configured within the VPRN. Standard configuration examples for basic VPRNs without PE-CE dynamic routing omit this command, reinforcing that its inclusion without a corresponding protocol is superfluous.

The route 192.168.2.0/27 originates from CE2, which is in Autonomous System (AS) 64497. When CE2 advertises this route to PE2 via eBGP, it prepends its own AS number, making the AS-Path 64497. PE2 then advertises this route to PE1 as a VPN-IPv4 route using Multiprotocol iBGP (MP-iBGP). A fundamental rule of iBGP is that the AS-Path attribute is not modified when advertising routes to an internal peer. Therefore, PE1 receives the VPN-IPv4 route from PE2 with the AS-Path unchanged: 64497. The as-override command configured on PE1 is only relevant for routes being advertised from PE1 to CE1; it does not affect routes received by PE1.

A. 64496 64497: This would be the AS-Path advertised from PE1 to CE1 if as-override was not configured, as PE1 would prepend its own AS.
B. 64496: This AS-Path would imply the route originated within the provider's network (AS 64496), but it originates from the customer network AS 64497.
D. 64497 64497: This is an invalid AS-Path in this scenario. BGP loop prevention would typically prevent an AS from accepting a route with its own AS already in the path.

1. RFC 4271 - A Border Gateway Protocol 4 (BGP-4):

Section 5.1.2, ASPATH: "When a BGP speaker advertises the route to an internal peer, the advertising speaker SHALL NOT modify the ASPATH attribute." This directly supports why the AS-Path remains 64497 when advertised from PE2 to PE1.

2. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR MPLS Guide, Release 22.10.R1:

Section: VPRN BGP AS Path Loop Prevention: This section describes the as-override feature. It states, "When as-override is enabled, the PE replaces the AS number of the CE with the AS number of the PE in the AS path." This confirms that as-override is an outbound policy applied from PE to CE, and thus does not affect the inbound route received by PE1 in this question.

3. RFC 4364 - BGP/MPLS IP Virtual Private Networks (VPNs):

Section 4.3.4, Use of BGP for Distributing VPN-IPv4 Routes: This section details how BGP path attributes, including ASPATH, are carried with VPN-IPv4 routes between PE routers, following standard BGP procedures as defined in RFC 4271.