JN0-664 Practice Questions

In an Interprovider VPN Option C (also known as BGP Labeled Unicast), the roles and routing information of the network devices are distinct.

PE Routers: Establish a direct, multi-hop BGP session with PEs in the remote AS to exchange L3VPN routes. To achieve this, they must learn the loopback addresses of the remote PEs, which are advertised by the ASBRs. They also run an IGP for internal reachability.

ASBR Routers: Exchange the loopback addresses of their internal PE routers with the peer ASBR in the other AS using BGP with the labeled-unicast address family. They do not carry the customer L3VPN routes.

P Routers: Function solely as label-switching routers within their own AS. They only need to maintain internal IGP routes to build LSPs towards the PEs and ASBRs in their AS. They have no visibility into external routes or L3VPN routes.

D. P routers do not need to know about PE loopbacks in other autonomous systems; their role is limited to label switching within their own AS.

E. The defining characteristic of Option C is that ASBRs do not carry the L3VPN routes, which provides better scaling. The L3VPN routes are exchanged directly between the PE routers.

1. Juniper Networks TechLibrary

Interprovider and Carrier-of-Carriers VPNs Overview. This document describes Option C

stating

"This method requires the ASBRs to exchange BGP labeled routes for the PEs in their respective ASs... The PEs then establish a BGP session with each other... and exchange VPN routes." This confirms the roles of the PE (exchanging VPN routes) and ASBR (exchanging PE loopbacks)

and implicitly the P router's limited role.

2. RFC 4364

BGP/MPLS IP Virtual Private Networks (VPNs)

Section 10

"Multi-AS Backbones". This RFC details option (c)

explaining that ASBRs advertise reachability to the PEs with MPLS labels

which allows LSPs to be set up between PEs in different ASes. The PEs then become direct BGP neighbors for exchanging VPN-IPv4 routes

isolating the ASBRs and P routers from customer VPN routing information.

3. Juniper Networks TechLibrary

Example: Configuring Interprovider VPNs. The configuration example for Option C shows family inet labeled-unicast on the ASBRs for exchanging PE loopbacks

a multi-hop BGP session between PEs for the VPN

and standard IGP/MPLS configuration on the P routers

reinforcing that P routers only maintain internal routes.

In a BGP-signaled Layer 2 VPN (also known as a Kompella L2VPN), each customer site connected to a PE router must be assigned a site identifier. This identifier must be unique for each site within a particular Layer 2 VPN routing instance. The site identifier, along with the route distinguisher and label block, is used to create a unique Layer 2 VPN Network Layer Reachability Information (NLRI) prefix that BGP advertises to other PE routers. This mechanism allows the remote PE routers to identify the specific customer attachment circuit for which the pseudowire is being established.

B. This type of VPN supports multiple Layer 2 encapsulations, including Frame Relay, ATM, and PPP, in addition to Ethernet.

C. This type of VPN uses the l2vpn address family (AFI 25, SAFI 128), not the inet-vpn NLRI, which is used for Layer 3 VPNs.

D. The route distinguisher (RD) is used to make routes unique and is typically configured to be unique per routing instance on each PE router.

1. Juniper Networks TechLibrary

"Layer 2 VPNs and VPLS Feature Guide for Routing Devices": In the section "Configuring BGP Signaling for Layer 2 VPNs

" the documentation states

"For each routing instance

you must configure a unique site identifier for each site." This directly confirms the requirement for a unique site number.

2. Juniper Networks TechLibrary

"Junos OS VPNs Library for Routing Devices": Under the "Layer 2 VPNs User Guide

" the section "Understanding BGP Signaling in Layer 2 VPNs" describes the NLRI format. It specifies that the NLRI is composed of the Route Distinguisher (RD)

Site ID

Label Offset

and Label Base

highlighting the fundamental role of the unique Site ID.

3. Juniper Networks TechLibrary

"Layer 2 VPNs and VPLS Feature Guide for Routing Devices": The section "Layer 2 VPNs Encapsulation" lists supported encapsulation types

including ethernet

ethernet-vlan

frame-relay

and atm-aal5

which explicitly refutes the claim that only Ethernet is supported.

The exhibit displays an OSPF neighbor in the Init state. This state signifies that the local router is receiving Hello packets from its neighbor, but bidirectional communication has not been established. This occurs because the neighbor's Hello packets do not contain the local router's ID, implying the neighbor is not processing the Hellos it receives.

For an OSPF adjacency to form, several parameters must match between neighbors on a common network segment. Among these are the Hello interval and the Dead interval. If either of these timers is mismatched, the receiving router will discard the Hello packet, preventing the establishment of two-way communication and causing the neighbor relationship to be stuck in the Init state.

C. OSPF does not use a "hold timer" for establishing neighbor adjacencies; this is a parameter associated with other protocols, such as BGP.

D. The poll interval is a timer specific to Non-Broadcast Multi-Access (NBMA) OSPF network types, not broadcast interfaces like Gigabit Ethernet (ge-0/0/0).

1. Juniper Networks Documentation

"OSPF Hello Protocol Overview." This document states

"To become OSPF neighbors

the following conditions must be met: ... The hello and dead intervals must be the same on the neighboring interfaces." This directly supports that a mismatch in the parameters mentioned in options A and B will prevent adjacency formation. (Source: Juniper Networks TechLibrary

OSPF for Junos OS

topics/concept/ospf-hello-protocol-overview.html)

2. Juniper Networks Documentation

"show ospf neighbor." The command reference describes the Init state as: "A hello packet has been seen from the neighbor

but two-way communication has not been established." This confirms the state shown in the exhibit and aligns with the scenario where a parameter mismatch prevents the neighbor from acknowledging received Hellos. (Source: Juniper Networks TechLibrary

CLI Explorer

command/show-ospf-neighbor.html)

3. RFC 2328

"OSPF Version 2

" Section 10.5

"Receiving Hello Packets." The official standard specifies that "The HelloInterval [and] RouterDeadInterval ... fields in the received Hello packet must be the same as the values configured for the receiving interface. If they are not

the Hello packet should be dropped." This explains the mechanism by which a timer mismatch leads to a one-way communication state (Init).

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 IS-IS, the Designated Intermediate System (DIS) on a broadcast multi-access network (like Ethernet) periodically sends Complete Sequence Number PDUs (CSNPs) to maintain Link-State Database (LSDB) synchronization among all routers on the segment. This makes statement A correct.

Partial Sequence Number PDUs (PSNPs) are used to explicitly request a missing Link-State PDU (LSP) or to acknowledge the receipt of an LSP. The PSNP itself does not contain the full LSP but rather a summary or description of it, typically including the LSP ID, sequence number, and checksum. This makes statement C correct.

B. PSNPs are flooded periodically.

This is incorrect. PSNPs are not sent periodically; they are transmitted on-demand in response to an event, such as requesting a missing LSP identified from a CSNP.

D. CSNPs contain only descriptions of LSPs.

This is subtly incorrect due to the word "only." Besides the LSP descriptions, a CSNP PDU also contains other fields in its body, such as "Start LSP ID" and "End LSP ID," which define the range of LSPs included.

1. Juniper Networks TechLibrary

IS-IS Overview. In the "IS-IS PDUs" section

it states

"Complete sequence number PDU (CSNP)—Contains a complete list of all LSPs in the IS-IS database. CSNPs are sent periodically by the designated router..." This directly supports answer A. The same document describes PSNPs as being "Sent by a router when it detects that it is missing an LSP

" confirming they are event-driven

not periodic

which invalidates answer B.

2. RFC 1195

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

Section 9.9

"Partial Sequence Numbers PDU (PSNP)". This section states

"This PDU contains a summary description of one or more LSPs from the source's LSP database." This supports the correctness of answer C.

3. RFC 1195

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

Section 9.8

"Complete Sequence Numbers PDU (CSNP)". The PDU format defined in this section shows that in addition to the list of LSP entries (descriptions)

the PDU contains "Start LSP-ID" and "End LSP-ID" fields. This supports the reasoning that statement D is incorrect because of the word "only".

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.

In an EVPN environment, the MAC mobility feature uses a sequence number to handle host moves. When a PE device learns a MAC address locally that was previously associated with a remote PE, it advertises the MAC in a Type 2 route with an incremented sequence number. Receiving PEs compare the sequence number of the new advertisement with any existing entry for that MAC. The advertisement with the higher sequence number is considered the most recent, or latest, update. This mechanism allows the network to correctly identify the new location of the MAC address, thereby resolving the conflicting information from the old and new PEs about the MAC's ownership.

A. It identifies MAC addresses that should be discarded.

The sequence number is used to update a MAC's location, not to mark the MAC address itself for deletion from the network.

D. It is advertised using a Type 2 message.

While true that the sequence number is in an extended community of a Type 2 route, this describes its transport, not its primary function of resolving moves.

1. Juniper Networks Documentation

EVPN-VXLAN MAC Mobility: "When a MAC address moves from one PE device to another

the new PE device sends out a MAC/IP advertisement route for the moved MAC address with a sequence number that is greater than the sequence number in the MAC/IP advertisement route that the old PE device sent. When the other PE devices in the EVPN receive the MAC/IP advertisement route with the higher sequence number

they update their forwarding tables to send traffic for the moved MAC address to the new PE device." This supports that the sequence number helps identify the latest advertisement (C) to resolve the move (B).

2. RFC 7432: BGP MPLS-Based Ethernet VPN

Section 15.1. MAC Mobility: "When a PE receives a MAC/IP Advertisement route for a MAC address that it has already learned from a different PE

it MUST compare the sequence numbers in the MAC Mobility extended community. If the new sequence number is greater than the old one

the PE MUST update its forwarding database to point to the new PE." This directly confirms the role of the sequence number in identifying the latest advertisement (C) and resolving the location conflict (B).

3. Juniper Networks Documentation

Understanding EVPN MAC Mobility: "To ensure that all PE devices in the EVPN have the most up-to-date information about the location of the MAC address

the MAC mobility extended community attribute is used... When another PE device receives a MAC/IP advertisement route with the MAC mobility extended community attribute

it compares the sequence number in the received route with the sequence number in the route that it has stored. If the received sequence number is higher

the PE device updates its path to the MAC address." This reinforces that the sequence number's purpose is to determine the latest path.

A sham link is a logical, unnumbered point-to-point link configured between two Provider Edge (PE) routers within a specific VRF instance. Its primary purpose in an MPLS L3VPN environment is to make the path over the MPLS backbone appear as an OSPF intra-area link. This is necessary when a customer has a direct "backdoor" link between two sites that are also connected via the VPN. By creating an OSPF adjacency over the sham link, the backbone path is advertised using Type 1 LSAs, which OSPF prefers over the inter-area path (Type 3 LSAs) that would otherwise be advertised. This ensures traffic correctly favors the MPLS backbone over the backdoor link.

B. A sham link is an OSPF-specific feature used for PE-CE routing. It does not create or modify BGP neighborships, which are handled separately by MP-BGP between PEs.

D. This statement is the inverse of the sham link's function. The sham link is specifically created to force the use of Type 1 LSAs instead of Type 3 LSAs for the backbone path.

1. Juniper Networks TechLibrary

"Understanding OSPF Sham Links for PE-to-PE Router Connectivity in VPNs": "To make the PE router advertise the routes as intra-area routes (type 1 LSAs)

you can configure a sham link between the PE routers. A sham link is an unnumbered point-to-point intra-area link between two PE routers." This source confirms that the sham link's purpose is to use Type 1 LSAs (Option C) and that it creates a link between two PE routers for OSPF (Option A).

2. RFC 4577

"OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)"

Section 4.2.7

"The Sham Link": "To make the path over the VPN backbone an intra-area path

a 'sham link' is created between the PEs... The sham link is advertised as a point-to-point link in a Type-1 LSA for the area." This RFC

which defines the standard

directly supports that the link is between PEs (Option A) and is advertised via a Type 1 LSA (Option C). The adjacency is formed over the MPLS core

which is inherently a multihop transport path.

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.

This question evaluates the understanding of default BGP next-hop advertisement rules.

1. (C) When R1 advertises the route to its external BGP (eBGP) peer R2, it sets the NEXTHOP attribute to its own IP address on the peering link, which is 192.168.1.1.

2. (B) When R2 advertises this eBGP-learned route to its internal BGP (iBGP) peer R3, the default behavior is to not change the NEXTHOP attribute. Therefore, R3 receives the route with the original next-hop of 192.168.1.1.

3. (A) When R2 advertises the route to its other eBGP peer R4, it again updates the NEXTHOP to its own IP address on that specific link, which is 172.16.1.1.

These three options correctly describe the default next-hop behavior for both iBGP and eBGP sessions.

D. This statement is also technically correct, as R1 will prepend its own AS number when advertising to an eBGP peer. However, the question requires selecting three options, and A, B, and C form a complete, thematic set testing next-hop behavior.

E. This is incorrect. When R4 advertises a route to its eBGP peer R6, the default rule requires it to change the next-hop to its own IP address on the link connecting to R6.

1. Juniper Networks TechLibrary

"BGP Overview". This document states

"For EBGP

the next hop is the IP address of the peer that sent the update. For IBGP

the protocol states that the next hop advertised by EBGP should be carried into IBGP." This directly supports the correctness of options A

B

and C.

2. Juniper Networks TechLibrary

"Example: Configuring an IBGP Peer Group with a Route Reflector". In the "Verification" section

the output of show route receive-protocol bgp demonstrates that the next-hop from an eBGP peer is passed unchanged to iBGP peers by default.

3. RFC 4271

"A Border Gateway Protocol 4 (BGP-4)"

Section 5.1.3

"NEXTHOP". This standard specifies that for eBGP

"The NEXTHOP attribute shall be set to the IP address of the sending speaker's interface". It also clarifies that this attribute is passed unmodified to iBGP peers. This validates the reasoning for A

B

C

and invalidates E.