Free JN0-664 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

The scenario describes two customer sites (R1, R4) using the same AS number (65000) connected via a transit network (R2, R3). By default, BGP's loop prevention mechanism will cause R4 to reject routes advertised by R1 because R4 will see its own AS in the ASPATH, and vice-versa.

There are two primary methods to solve this, both configured on the transit routers (R2 and R3):

1. as-override (Option B): This feature is configured on the transit routers' BGP sessions facing the customer. It modifies the ASPATH by replacing all occurrences of the customer's AS number with the transit router's own AS number. This effectively hides the customer's AS from the remote site, bypassing the loop prevention check.

2. advertise-peer-as (Option C): This is an alternative feature that allows a transit router to advertise routes learned from one external peer to another external peer within the same customer AS. This is the provider-side step of a two-part solution that also requires the customer routers (R1, R4) to be configured with the loops statement to accept routes containing their own AS.

A. Configure the BGP group with the advertise-peer-as parameter on R1 and R4.

This feature is configured on the transit provider routers (R2, R3), not the customer edge routers.

D. Configure the BGP group with the as-override parameter on R1 and R4.

This feature is configured on the transit provider routers (R2, R3), not the customer edge routers.

1. Juniper Networks TechLibrary

Junos OS Routing Protocols Library

as-override: "For use in BGP sessions with external BGP (EBGP) neighbors. When you include this statement

the local routing device replaces the autonomous system (AS) number of the neighbor with its own AS number in the AS path." This directly supports Option B as a solution.

2. Juniper Networks TechLibrary

Junos OS Routing Protocols Library

advertise-peer-as: "Allows a device to advertise routes to an external BGP (EBGP) peer that were learned from another EBGP peer in the same autonomous system (AS). This feature is used when a customer is multihomed to the same service provider at different locations and the customer is using the same AS number at these locations." This identifies the feature's purpose for the exact scenario in the question

supporting Option C.

3. Juniper Networks TechLibrary

BGP Feature Guide for Routing Devices

"Allowing a PE Router to Advertise Routes to a CE Router in the Same AS": This guide explicitly presents as-override and advertise-peer-as as the two alternative solutions for this problem. It states

"To allow a PE router to advertise routes to a CE router in the same AS

you can configure either the as-override statement or the advertise-peer-as statement in the BGP group that is configured on the PE router." This confirms both B and C are valid approaches configured on the transit routers.

The show route command output clearly displays Peer AS: 65001, indicating that both paths to the 10.1.1.1/32 prefix were learned from the same autonomous system, AS 65001. This validates statement C.

The output also shows two distinct next-hops (172.16.1.2 and 172.16.2.2) for the same route. The presence of multiple paths for a single BGP prefix is a direct result of a multipath configuration. The primary purpose of BGP multipath is to install multiple equal-cost paths into the forwarding table to enable load balancing over those paths. This makes statement D a correct description of the configuration's intent, even though the route is currently inactive.

A. The multihop configuration is used to establish eBGP peering between routers that are not directly connected; its primary function is not load balancing.

B. The output explicitly shows the route is learned from a single Peer AS: 65001, not from two different AS numbers.

1. Juniper Networks TechLibrary

BGP Multipath Overview: "When BGP multipath is enabled

the device selects multiple

equal-cost BGP paths to reach a common destination and all these paths are installed in the forwarding table. BGP then load-balances traffic across the multiple paths." This source confirms the purpose of multipath is load balancing.

2. Juniper Networks TechLibrary

show route (BGP-Specific Information): The documentation for the show route command specifies that the Peer AS field displays the "AS number of the peer from which the route was learned." In the exhibit

this value is consistently 65001

confirming the route is learned from a single AS.

3. Juniper Networks TechLibrary

BGP Multihop: "For external BGP (eBGP)

peers are often directly connected to each other... if the peers are not directly connected

you must configure eBGP multihop." This reference distinguishes the function of multihop from multipath.

Junos OS supports unequal-cost load balancing for BGP by utilizing the BGP link bandwidth extended community. This feature allows a router to advertise its link's bandwidth to a BGP peer. The receiving router can then be configured with a policy to use this advertised bandwidth information to distribute traffic proportionally across the available paths. This ensures that the 10 Gigabit Ethernet link carries a proportionally higher volume of traffic than the 1 Gigabit Ethernet link, fulfilling the requirement to use both links as efficiently as possible according to their capacity.

B. Disabling multipath would force the use of only a single best path, leaving the second link unused, which is contrary to the stated goal.

C. The metric-out parameter (MED) is used to influence how a remote AS sends traffic to the local router, not how the local router load-balances its outbound traffic.

D. Per-prefix load balancing is a method for distributing traffic, but it requires multiple paths to be considered equal and eligible for multipath first, which is not the case here due to different IGP costs.

1. Juniper Networks TechLibrary

Junos OS Routing Protocols Library for Routing Devices

"Understanding BGP Link Bandwidth": This document states

"The BGP link bandwidth extended community enables BGP to perform unequal-cost load balancing... The link bandwidth information is carried in an optional

non-transitive BGP extended community attribute. This allows BGP to load-balance traffic across different external BGP (EBGP) peers in proportion to the bandwidth of the links."

2. Juniper Networks TechLibrary

Junos OS Routing Protocols Library for Routing Devices

"Example: Configuring BGP Link Bandwidth": This configuration example demonstrates the exact solution. It shows creating a community bw-community and applying it via an export policy. The document notes

"To enable unequal-cost load balancing

you configure a BGP export policy that includes the bandwidth community."

3. Juniper Networks TechLibrary

Junos OS Routing Protocols Library for Routing Devices

"multipath (Protocols BGP)": The documentation for the multipath statement clarifies that for standard BGP multipath

several attributes

including the IGP cost to the BGP next hop

must be identical. The bandwidth community feature is the specific mechanism to override this requirement for proportional

unequal-cost load balancing.

No classifier is applied to ge-0/0/0, so ingress packets are not examined against any user-defined or predefined classifier and are therefore placed unchanged into the default forwarding-class; that is, classification in the CoS sense is not performed.

Inside a scheduler, transmit-rate percent 40 is a minimum bandwidth guarantee—not a ceiling. If the other queues are idle, the best-effort queue may borrow the unused bandwidth and exceed 40 percent of the interface rate.

C. Default BA or DSCP classifiers exist but are not automatically bound to an interface; without the ‘classifiers … apply’ statement they are not used.

D. transmit-rate sets a floor, not a cap; without a shaping-rate the queue is free to exceed the percentage when bandwidth is available.

1. Juniper Networks

“Junos OS Class of Service Configuration Guide

” Release 23.4R1

Section ‘Predefined and Default Classifiers’

paragraph 3 (p. 622).

2. Juniper Networks

“Junos OS Class of Service Configuration Guide

” Release 23.4R1

Section ‘Understanding Schedulers and the transmit-rate Statement’

paragraphs 1-2 (pp. 687-688).

3. Juniper Networks TechLibrary KB21133

“Transmit-rate vs. Shaping-rate in Junos”

‘Behaviour of transmit-rate’ paragraph

2022.

The BGP route is hidden on R5 because the BGP next-hop address (192.168.1.1, the IP of R1) is not reachable from R5's perspective. By default, when R4 advertises an EBGP-learned route to an IBGP peer (R5), it does not change the next-hop attribute.

There are two standard solutions to this problem:

1. Modify the next-hop attribute on R4 before advertising to R5. R4 can change the next-hop to its own IP address, a feature known as "next-hop-self". This makes the next-hop directly reachable for R5.

2. Ensure the original next-hop is reachable. This is done by advertising the external link prefix (192.168.1.0/30) into the Interior Gateway Protocol (IGP), allowing R5 to learn a route to 192.168.1.1.

A. This is a specific implementation of "next-hop-self" (Option B). While it would work, Option B describes the general, more common solution and is a better choice alongside the distinct method in Option D.

C. Advertising the internal IBGP link prefix into BGP does not help R5 resolve the unreachable external next-hop address (192.168.1.1).

1. Juniper Networks TechLibrary

Junos OS Routing Protocols Library

BGP Feature Guide

next-hop-self: "By default

BGP advertises routes that it learns from an external BGP (EBGP) peer to an internal BGP (IBGP) peer without modifying the next-hop address... To change the next-hop address

include the next-hop-self statement... This statement causes the advertising routing device to substitute its own IP address for the third-party next-hop address." This reference directly supports option B.

2. Juniper Networks TechLibrary

Junos OS Routing Protocols Library

OSPF Feature Guide

"Example: Redistributing Routes into OSPF": This documentation provides examples of configuring a routing policy to redistribute routes from other protocols (such as direct interface routes) into an IGP like OSPF. Applying this concept

R4 could redistribute its external link (192.168.1.0/30) into the IGP

making the BGP next-hop 192.168.1.1 reachable for R5. This reference supports the methodology in option D.

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

Section 5.1.3. NEXTHOP: This RFC specifies the behavior of the NEXTHOP attribute. It states

"The NEXTHOP attribute for a route learned via IBGP is the IP address of the BGP speaker that advertised the route to the local BGP speaker." This confirms that without intervention

R5 will receive the original next-hop from R4

which is the source of the problem.

An L2VPN provides a transparent Layer 2 transport service across a provider's network, effectively creating a virtual wire or LAN segment between customer sites. In this model, the Provider Edge (PE) routers are unaware of the customer's Layer 3 routing.

Consequently, the two Customer Edge (CE) routers, connected by the L2VPN, will see each other as if they are on the same local network segment. They will exchange OSPF Hello packets across the L2VPN and form a direct OSPF neighborship.

The OSPF process running on the PE routers is for the provider's internal IGP and is completely separate from the customer's OSPF domain. There is no OSPF interaction between the CE and PE, so their respective OSPF area configurations are independent and can be different.

A. OSPF neighborship is formed between the CEs and PEs.

This is incorrect. A CE-PE routing adjacency is a characteristic of an L3VPN, not an L2VPN where the PE is transparent to customer L3 traffic.

C. The CE and PE OSPF areas must match.

This is incorrect. Since no OSPF neighborship is formed between the CE and PE, there is no requirement for their OSPF areas to match.

1. Juniper Networks TechLibrary

Junos OS VPNs Library for Routing Devices

"Layer 2 VPNs Overview": This document states

"In a Layer 2 VPN

routing occurs on the customer's routers (called CE routers). ... The service provider's routers transparently pass the customer's traffic between the customer's sites." This supports the conclusion that CEs form a neighborship with each other (Option D) and not with the PEs (refuting Option A).

2. Juniper Networks TechLibrary

Junos OS VPNs Library for Routing Devices

"Layer 2 VPNs and VPLS Feature Guide

Layer 2 VPNs and VPLS Overview": This guide explains

"The service provider's edge routers (PEs) do not need to store or process the customer's routes. The PE routers only need to be configured to carry the traffic from the customer's site across the network." This confirms the separation between the provider's routing domain (where its OSPF area is defined) and the customer's

making their area configurations independent (supporting Option B and refuting Option C).

The vrf-export statement is used to apply a custom-defined routing policy to routes as they are exported from a specific VRF routing table (e.g., customer-A.inet.0) into the primary BGP Layer 3 VPN table (bgp.l3vpn.0) for advertisement to remote PE routers. This policy provides the necessary flexibility to perform advanced actions, such as attaching multiple BGP communities to the VPN routes. The vrf-target statement, by contrast, is a simplified macro that only attaches a single, specified route-target community.

B. vrf-import: This applies a policy to routes being imported into the VRF from remote PEs, not to routes being advertised from the VRF.

C. vrf-target export: This is a simplified configuration statement that automatically attaches only a single route-target community to exported routes.

D. vrf-target import: This statement filters which routes are accepted into the VRF based on their route-target community, it does not affect exported routes.

1. Juniper Networks TechLibrary

Junos OS VPNs Library for Routing Devices

"Configuring Routing Policies for VRF Tables in Layer 3 VPNs": This document explicitly states

"To apply an export policy to the VRF table

you include the vrf-export statement... The export policy is applied to routes being exported from the VRF routing table and advertised to other PE routers." It contrasts this with vrf-target

which is a simplified policy.

2. Juniper Networks TechLibrary

Junos OS VPNs Library for Routing Devices

"vrf-export": The documentation for the vrf-export statement specifies its function: "Apply an export routing policy to routes being exported from a VRF routing table into the local PE router’s primary routing table." A policy is the mechanism used to attach multiple communities.

3. Juniper Networks TechLibrary

Junos OS VPNs Library for Routing Devices

"Understanding the vrf-target Community": This guide explains

"The vrf-target statement is a simplified way of configuring a VPN policy... When you configure a vrf-target statement

a BGP extended community is created." It clarifies this is a simplified method for a single community

whereas vrf-export and vrf-import are used for more complex policies.

In an anycast RP environment, multiple Rendezvous Points (RPs) share the same IP address to provide redundancy and load balancing. A source's Designated Router (DR) will only register the source with its topologically closest RP. To ensure all RPs in the anycast set are aware of all active sources, a source-sharing mechanism is required.

Junos OS supports two primary methods for this:

1. MSDP (Multicast Source Discovery Protocol): RPs are configured as MSDP peers. When an RP learns of a new source, it sends a Source-Active (SA) message to its peers, informing them of the active source.

2. Anycast PIM: Using the rp-set statement, RPs within the set use PIM messages to exchange source registration information directly.

Both solutions are configured on the RP routers.

C. The rp-set statement is configured on the RP routers to define the anycast set members, not on the source DRs.

D. MSDP is a protocol that runs between RPs to share source information; it is not configured on source DR routers.

1. Juniper Networks TechLibrary. (2023). Understanding Anycast RP for PIM. Junos OS Documentation. Retrieved from https://www.juniper.net/documentation/us/en/software/junos/multicast/topics/concept/multicast-anycast-rp-understanding.html. In the "Anycast RP Methods" section

it states: "To enable anycast RP

you must configure the address of all the RPs in the anycast RP set. You can do this in one of two ways: ... Configure the rp-set statement on each RP router in the anycast-RP set. ... Configure Multicast Source Discovery Protocol (MSDP) on each of the RP routers in the anycast-RP set."

2. Juniper Networks TechLibrary. (2023). Example: Configuring Anycast RP. Junos OS Documentation. Retrieved from https://www.juniper.net/documentation/us/en/software/junos/multicast/topics/example/multicast-anycast-rp-configuring.html. This document provides a configuration example showing the rp-set statement configured under the [edit protocols pim rp] hierarchy on the RP routers.

3. Juniper Networks TechLibrary. (2023). MSDP Overview. Junos OS Documentation. Retrieved from https://www.juniper.net/documentation/us/en/software/junos/multicast/topics/concept/msdp-overview.html. The overview states

"MSDP is also used for anycast RP

which is a way to provide RP redundancy and load sharing." It clarifies that MSDP peering is established between RPs.

In an L3VPN using OSPF as the PE-CE protocol, the PE router advertises routes learned from the remote site (via MP-BGP) to the local CE router as OSPF external Type 5 LSAs. The PE router effectively acts as an OSPF ASBR. In the given scenario, CE-1 learns routes to Site-2 from two paths:

1. As external routes from PE-1.

2. As intra-area routes directly from CE-2 over the backdoor link.

According to the OSPF route selection algorithm, intra-area routes are always preferred over external routes, regardless of the metric. Therefore, by default, CE-1 will select the direct link to CE-2 as the best path to reach Site-2.

A. This describes a solution to make the L3VPN the primary path, not the default behavior. The backdoor link is preferred by default.

C. This is incorrect because OSPF's route preference rules prioritize the intra-area path (direct link) over the external path (L3VPN).

D. Increasing the metric on the PE-1 link would make the L3VPN path even less desirable, reinforcing the default preference for the direct link.

1. Juniper Networks TechLibrary

Junos OS VPNs Library for Routing Devices

"OSPF Sham Links Overview": This document explains the problem of OSPF backdoor links being preferred over the L3VPN backbone. It states

"By default

OSPF prefers an intra-area backdoor route over an inter-area route through the VPN backbone." This confirms that the direct link (an intra-area path) is preferred over the L3VPN path (which presents as an inter-area or external path).

2. Juniper Networks TechLibrary

Junos OS VPNs Library for Routing Devices

"Configuring OSPF in L3 VPNs": This section details the PE-CE OSPF interaction. It clarifies that "When you configure OSPF as a PE-to-CE routing protocol

the PE router advertises the routes it learns from the CE router to other PE routers through IBGP... The other PE routers forward these routes to their CE routers." These routes are injected into the CE's OSPF domain as external routes.

3. RFC 4577: OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)

Section 4.2.5.1: This RFC

which defines the standard behavior

states: "If there is a "backdoor" link between two sites of a VPN

OSPF will prefer this link over the VPN backbone path if the backdoor path is an intra-area or inter-area path." This is because the path over the VPN backbone is treated as a less-preferred inter-area or external path.

In interprovider VPN scenarios using BGP family inet labeled-unicast (RFC 3107), a PE router receives labeled IPv4 prefixes. For these routes to be considered valid and installed in the routing table, the BGP next-hop must be resolvable via a labeled path in the inet.3 routing table. If BGP cannot find a labeled path to the next-hop, the route is marked as hidden. The resolve-vpn parameter, configured under the [edit protocols bgp group family inet labeled-unicast] hierarchy, explicitly instructs the BGP process to perform next-hop resolution using the inet.3 table. This enables the router to find the required MPLS LSP or LDP path, resolves the next-hop, and makes the route active.

A. The explicit-null parameter is used to control penultimate-hop-popping (PHP) behavior, typically for QoS purposes, and does not influence BGP next-hop resolution.

B. Enabling traffic-engineering under OSPF allows the IGP to flood information for RSVP-TE, but it does not directly configure BGP's route resolution mechanism.

D. The traffic-engineering parameter under the protocols mpls hierarchy is a container for RSVP-TE configuration; it is a prerequisite for building LSPs but does not fix the BGP resolution logic itself.

1. Juniper Networks TechLibrary

BGP Feature Guide

resolve-vpn: "To resolve routes received with the BGP labeled-unicast address family

you must configure the resolve-vpn statement. This statement enables the router to resolve the next hop in the inet.3 routing table." This document directly states the function of the resolve-vpn parameter in solving the exact problem described.

Source: Juniper Networks

BGP Feature Guide

resolve-vpn topic.

2. Juniper Networks TechLibrary

MPLS Applications User Guide

"Understanding BGP Labeled Unicast for Inter-AS VPNs": "For the routes to be resolved

the PE router must have a labeled path to the BGP next hop... To enable the PE router to resolve labeled BGP routes

you must configure the resolve-vpn statement for the BGP labeled unicast address family." This guide explains the necessity of this command specifically within the context of Inter-AS (interprovider) VPNs.

Source: Juniper Networks

MPLS Applications User Guide

section on BGP Labeled Unicast for Inter-AS VPNs.

3. Juniper Networks TechLibrary

Routing Protocols Configuration Guide

"Configuring BGP Labeled Unicasts": This section details the configuration of the inet-labeled-unicast address family and notes that for proper operation

especially in VPN contexts

next-hop resolution must be correctly configured

pointing to the use of resolve-vpn to utilize the inet.3 table.

Source: Juniper Networks

Routing Protocols Configuration Guide

section on BGP Labeled Unicasts.

The IS-IS Shortest Path First (SPF) or Dijkstra algorithm calculates the shortest path from the local router to all other destinations. The algorithm maintains a 'tree' database for nodes with a confirmed shortest path and a 'candidate' database for nodes whose paths are being evaluated. The process iteratively selects the lowest-cost node from the candidate database and moves it to the tree database. Subsequently, it examines the neighbors of this newly added node (using the Link-State Database or LSDB) and adds them to the candidate database for future evaluation. Option B, despite its slightly imprecise wording, correctly describes this core iterative step of adding a neighbor of a node in the tree to the candidate list.

A. According to specific Juniper reference implementations, the algorithm is seeded by placing the local router directly into the tree database, not the candidate database.

C. Tuples are moved from the candidate database to the tree database, not the other way around. The LSDB is the input for the calculation and is not modified by it.

D. The algorithm terminates when the candidate database is empty, signifying that all reachable nodes have been processed and moved to the tree database.

1. Southwick

P.

Reynolds

H. (2010). Junos Enterprise Routing

2nd Edition. O'Reilly Media

Inc. Chapter 6

"The IS-IS Engine

" p. 258.

Quote: "The algorithm is seeded by adding the local router to the tree database with a cost of 0. The algorithm then examines the LSPs of the node just added to the tree and adds all of its neighbors to the candidate database... The algorithm then selects the entry in the candidate database with the lowest cost and moves it to the tree database. This process is repeated until the candidate database is empty." This source directly refutes option A and supports the logic of option B.

2. Juniper Networks. (2009). OSPF and IS-IS: Choosing an IGP [White paper].

Reference: Page 5 describes the SPF algorithm maintaining two lists: TENT (candidate list) and PATHS (tree list). It states

"TENT is the list of candidate nodes that are not yet on the SPF tree but are adjacent to it. PATHS is the list of nodes that are already on the SPF tree." This confirms the terminology used in the explanation.

3. Moy

J. (1991). RFC 1195: Use of OSI IS-IS for routing in TCP/IP and dual environments. IETF. Section 4.2.3

"The Decision Process."

Reference: This RFC provides the authoritative description of the SPF algorithm for IS-IS. Steps 3 through 5 detail the process of examining neighbors of a node just added to the tree (PATHS) and adding/updating them in the tentative list (TENT/candidate)

which aligns with the logic in option B.

In an OSPF-based Layer 3 VPN, routes learned from a CE router are advertised across the MPLS backbone and presented to the remote CE router as OSPF inter-area routes (Type 3 LSAs). This is a default loop-prevention mechanism. A direct, physical link between two customer sites, known as a "back door" link, is seen as an intra-area path. According to OSPF path selection rules, an intra-area path is always preferred over an inter-area path, regardless of the metric.

A sham link is a logical, unnumbered point-to-point intra-area link configured between the PE routers within the VPN routing instance. This makes the path over the MPLS backbone appear as an intra-area link to the CE routers. With both the backbone and the back door link now appearing as intra-area paths, OSPF will use the metric to determine the best route, allowing the VPN backbone to be preferred by configuring it with a lower cost.

A. Rejecting routes via policy would completely block the backup path, preventing failover if the primary VPN link fails, which is not the desired outcome.

B. OSPF traffic engineering (OSPF-TE) is used to advertise link attributes for MPLS-TE path calculation and does not change the fundamental OSPF preference for intra-area over inter-area routes.

C. The OSPF metric is only considered when comparing paths of the same type. An intra-area path will always be chosen over an inter-area path, irrespective of the metric.

1. Juniper Networks TechLibrary

"Understanding OSPF Sham Links": "If there is a backdoor link that connects two of the OSPF sites

the backdoor link is always preferred over the BGP/MPLS VPN backbone link. This is because OSPF prefers an intra-area link over an interarea link. To make the BGP/MPLS VPN backbone the preferred link

you can configure an OSPF sham link between the PE routers that are connected to the OSPF sites."

2. RFC 4577: OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)

Section 4.2.8. The Sham Link: "If there is a "backdoor" link between two CE routers that are in the same OSPF area

the path over that link will always be preferred to the path over the BGP/MPLS IP VPN backbone. This is because OSPF prefers intra-area paths to inter-area paths. To make the path over the backbone preferable to the backdoor path

one may create a "sham link" between the PEs."

3. Juniper Networks TechLibrary

"Example: Configuring an OSPF Sham Link for a VPN": This document provides a configuration example explicitly designed to "direct traffic between two customer sites across a VPN backbone rather than a backdoor OSPF link

" confirming the sham link's purpose.

The vrf-target is a BGP extended community attribute that controls the import and export policies for routes within a VRF. In the provided configuration, both vrf-a and vrf-b share the same vrf-target value of target:100:1. When a single target is configured this way, it is used for both import and export policies. Consequently, routes learned from CE-1 in vrf-a are exported with target:100:1, and vrf-b is configured to import routes with this same target. This reciprocal relationship allows routes to be shared between the two VRFs, enabling communication between CE-1 and CE-2.

B. A shared vrf-target is the mechanism that enables route sharing between VRFs, it does not prevent it.

C. The route-distinguisher's function is to make IPv4 prefixes globally unique within the BGP table, not to control route sharing policy.

D. The route-distinguisher ensures route uniqueness for overlapping address spaces but does not influence the route sharing policy between VRFs.

1. Juniper Networks TechLibrary

Junos OS VPNs Library for Routing Devices

"Configuring Routing Instances on PE Routers in VPNs": This document explains that the vrf-target statement specifies the route target extended community. When a single target: is configured

it is used for both import and export policies

controlling which routes are accepted into and advertised from the VRF. The shared target target:100:1 in the exhibit explicitly creates a policy for route exchange between the two VRFs.

2. Juniper Networks TechLibrary

Junos OS VPNs Library for Routing Devices

"Route Distinguishers in VPNs Overview": This source clarifies the role of the route distinguisher (RD). It states

"The main purpose of the route distinguisher is to create unique VPN-IPv4 addresses for use in the service provider’s network." This confirms that the RD's function is to ensure uniqueness

not to control route distribution policy

which is the role of the route target.

3. Juniper Networks TechLibrary

Junos OS VPNs Library for Routing Devices

"Understanding VRF Import and Export Policies in L3VPNs": This document details how route targets function. It specifies that for a route to be accepted into a VRF's routing table (e.g.

vrf-b.inet.0)

the route must have a route target community that matches one of the communities listed in the vrf-import policy of that VRF. The configuration in the exhibit establishes this matching condition between vrf-a and vrf-b.

The exhibit shows that the egress router, PE-2, is advertising label 3 (Implicit Null) to the penultimate hop router (P). This instructs the P router to perform Penultimate Hop Popping (PHP), removing the outer MPLS label before forwarding the packet to PE-2. When the outer label is removed, the associated MPLS EXP bits, which carry the Class of Service (CoS) information, are also lost. Consequently, PE-2 receives a plain IP packet (with the inner VPN label) and cannot classify it based on the outer label's EXP bits. To resolve this, the explicit-null option must be configured on the egress router, PE-2. This causes PE-2 to advertise the Explicit Null label (label 0), preventing PHP and ensuring the MPLS header with the EXP bits is preserved until it reaches PE-2 for proper CoS classification.

A. Configure the explicit-null statement on PE-1.

Configuring explicit-null on the ingress router (PE-1) affects LSPs terminating on PE-1, not those originating from it. This will not solve the PHP issue at the egress (PE-2).

C. Configure VPN prefix mapping for the PE-1toPE-2 LSP.

VPN prefix mapping is used to direct specific VPN prefixes into a particular traffic-engineered LSP. It does not influence the label advertisement behavior (PHP vs. explicit-null).

D. Set a static CoS value for the PE-1toPE-2 LSP.

This would override any differentiated CoS markings with a single static value for all traffic in the LSP, which is contrary to the goal of preserving and acting upon the original CoS markings.

1. Juniper Networks TechLibrary

MPLS Applications User Guide

"Configuring Explicit Null Labels for LSPs": "By default

penultimate-hop popping is enabled. When PHP is enabled

the quality-of-service (QoS) information is lost because the MPLS header is removed by the penultimate-hop router. The egress router is unable to examine the EXP bits in the MPLS header. To preserve the QoS information for a packet

you can disable PHP. The MPLS header and the QoS information are then available on the egress router for processing." This is achieved by configuring explicit-null on the egress router.

2. Juniper Networks TechLibrary

Junos OS CoS for Routers

"CoS on MPLS LSPs Overview": "For the egress PE router to classify a packet based on the EXP value

the packet must arrive at the egress PE router with the MPLS label stack intact. By default

the penultimate router pops the outer label. To prevent the penultimate router from popping the outer label

you must configure the explicit null label on the egress PE router."

3. Juniper Networks Day One: Deploying MPLS

Chapter 5: Class of Service

Page 65: "The problem with PHP is that the EXP bits are lost when the label is popped... To solve this problem

you can configure the egress PE router to advertise an explicit NULL label (label value 0) instead of an implicit NULL label (label value 3). This forces the penultimate router to send the labeled packet to the egress PE router

thus preserving the EXP bits."

On point-to-point links, an IS-IS router configured for both Level 1 and Level 2 sends a single, combined Point-to-Point Hello (P2P IIH) packet. A field within this single PDU indicates the router's capabilities (L1, L2, or both), allowing it to form both types of adjacencies efficiently.

Conversely, on broadcast network segments like Ethernet, an L1/L2 router must send two distinct types of Hello packets: an L1 LAN IIH to discover and maintain adjacencies with L1 neighbors, and a separate L2 LAN IIH for its L2 neighbors. This separation is necessary to manage different adjacencies on a shared, multi-access medium.

A. On point-to-point links, a single P2P Hello PDU is used to establish both L1 and L2 adjacencies, not separate ones.

D. On broadcast networks, separate L1 and L2 LAN Hello PDUs are required; a single combined message is not used for this network type.

1. Juniper Networks TechLibrary

"Understanding IS-IS Adjacencies": "On a broadcast subnetwork

a Level 1/Level 2 router sends separate hello packets for Level 1 and Level 2 adjacencies. On a point-to-point subnetwork

a Level 1/Level 2 router sends a single hello packet for both Level 1 and Level 2 adjacencies."

2. RFC 1195

"Use of OSI IS-IS for routing in TCP/IP and dual environments"

Section 3.7.2

LAN IIH PDU: This section states

"A router which is operating as both a Level 1 and Level 2 router shall transmit both Level 1 and Level 2 LAN Hellos." This directly supports the behavior on broadcast interfaces.

3. RFC 1195

"Use of OSI IS-IS for routing in TCP/IP and dual environments"

Section 3.7.1

Point to point IIH PDU: This section describes a single PDU type for point-to-point links where the "Circuit type field indicates whether the sender is a Level 1 router

a Level 2 router

or both

" confirming a single

combined message is used.