Free JN0-664 Practice Test Questions 2026

Explanation:

The problem illustrated in image_c38646.jpg is a classic BGP loop prevention scenario. Both R1 and R8 reside in AS 65412. When R1 advertises a route, the AS Path attribute is prepended with 65412. As this update traverses the provider networks and reaches R6/R7 to be sent to R8, the AS Path still contains 65412. Upon receipt, R8 detects its own AS number in the path and discards the prefix to prevent a potential routing loop.

To resolve this without using non-standard workarounds, the provider must hide or replace the customer's AS number:

Option B (as-override):
This is the primary solution for Provider Edge (PE) routers. By configuring as-override on the neighbor statement toward R8, the PE router replaces the occurrence of 65412 in the AS Path with its own AS (64500). R8 then receives an update that appears to originate from the provider, bypassing the loop check.

Options A & C (remove-private):
The intermediate ASNs (64497 through 64500) are within the private AS range. In many service provider designs, especially when spanning multiple sub-segments or organizations, remove-private is used to strip these ASNs before the update is passed to another peer. This shortens the AS Path and ensures that private AS numbers do not leak into different routing domains, which helps maintain clean path information between the two customer sites.

Why Other Options Are Incorrect

Options D & E (loops and advertise-peer-as):
These commands are "Customer Edge" (CE) side fixes rather than "Provider" side fixes. While configuring loops allows a router to accept a path containing its own AS, it is generally discouraged in professional ISP environments as it weakens loop prevention. advertise-peer-as is typically used in specific complex hub-and-spoke topologies and is not the standard or most efficient method for the linear provider transit shown in the exhibit.

References

Juniper Networks Technical Publication: Junos OS Routing Protocols User Guide – Section on "BGP AS-Override and Loop Prevention."

JNCIP-SP Certification Objectives: Service Provider Routing Policy – Specifically covering BGP path attribute manipulation and scaling techniques.

Explanation:

An LDP Layer 2 circuit is the ideal choice because it maps directly to all stated requirements:

LDP Signaling: It utilizes the Label Distribution Protocol (LDP) to signal the Virtual Circuit (VC) labels between PE routers, fulfilling the requirement for LDP-based signaling.

BGP-Free Control Plane: Unlike BGP-based VLLs or VPLS, LDP Layer 2 circuits do not require a BGP control plane for service discovery or signaling.

Scalability & Multiplexing: This solution supports multiple VPN connections over a single transport LSP (Label Switched Path). It uses a two-level label stack where the outer label handles transport to the egress PE and the inner label identifies the specific Layer 2 circuit.

Routing Autonomy: As a Layer 2 service, the provider's routers operate at the Data Link layer and do not participate in the customer's Layer 3 routing. This ensures the customer maintains complete control over their private routing environment.

Why Other Options Are Incorrect

A. Circuit Cross-Connect (CCC):
CCC is not scalable for this RFP because it requires a unique, dedicated LSP for every connection (a 1:1 ratio). It cannot multiplex multiple circuits over a single LSP.

B. BGP Layer 2 VPN:
While highly scalable, this option is explicitly disqualified by the requirement to avoid using BGP for the implementation.

D. Translational Cross-Connect (TCC):
TCC is primarily used to connect disparate Layer 2 media (e.g., Ethernet to PPP). Like CCC, it lacks the scalability of LDP circuits as it requires dedicated LSPs and does not support the "many circuits over one LSP" model required by the customer.

References

Junos OS VPNs User Guide: "Layer 2 Circuits (LDP-Signaled) Overview" and "Comparing Layer 2 VPNs and Layer 2 Circuits."

JNCIP-SP Certification Objectives: Section on MPLS Layer 2 VPNs and LDP-based signaling mechanisms.

Explanation:

BGP path selection follows a deterministic, hierarchical process. When the primary attributes are tied, the router evaluates the next attribute in the sequence.

According to the Junos BGP path selection algorithm, the attributes are evaluated in this order:

Verify that a next hop is reachable.
Highest Local Preference. (Tied in this scenario)
Shortest AS-Path. (Tied in this scenario)
Lowest Origin Code (IGP < EGP < Incomplete). (Tied in this scenario)
Lowest Multi-Exit Discriminator (MED).

Since the local preference, AS-path length, and origin codes are all identical, the BGP process will next compare the Multi-Exit Discriminator (MED) values. MED is specifically designed to influence how neighboring autonomous systems enter your network, but it is also used by your local AS to choose between multiple entry points from different neighbors when all higher-priority attributes are equal.

Why Other Options Are Incorrect

D. IGP Metric:
The IGP metric to the BGP next hop is only considered after the MED comparison (assuming the neighbors are in the same AS or always-compare-med is enabled).

A. Router ID:
The Router ID is one of the final tie-breakers, used only after Local Preference, AS-Path, Origin, MED, and IGP metrics have failed to produce a single best path.

C. Peer IP Address:
The peer (neighbor) IP address is the very last tie-breaker in the Junos BGP selection process, used only if the Router IDs are also identical (which can happen in certain cluster configurations).

References

Junos OS Routing Protocols User Guide: Section on "BGP Path Selection Algorithm."
JNCIP-SP Certification Objectives: Under "BGP Path Selection and Attributes."
RFC 4271: A Border Gateway Protocol 4 (BGP-4) – Section 9.1.2.2 (Breaking Ties).

Explanation:

In a PIM-SM domain with Anycast RP, multiple RPs share the same IP address for load balancing and redundancy. However, when a source registers with one RP, other RPs must also learn about that active source so that receivers registered to different RPs can receive the multicast stream. Sharing active source information between RPs is the critical requirement.

A. Configure MSDP on each RP router.
Multicast Source Discovery Protocol (MSDP, RFC 3618) is the industry‑standard solution. RP routers form MSDP TCP peerings and exchange Source Active (SA) messages. Each SA contains the source address, group address, and originating RP. When one RP learns of a new source via a PIM Register, it sends SA messages to all MSDP peers. This synchronizes the active source database across all anycast RPs. MSDP is configured only on RP routers, not on DRs.

B. Configure anycast PIM with the rp-set statement on each RP router.
Junos offers an MSDP‑free alternative using PIM extensions (RFC 4610). The rp-set statement defines a group of RPs that form a anycast RP set. When configured on each RP router, these RPs automatically share register information using PIM messages directly, eliminating the need for MSDP. This method is lighter and simpler in pure Junos environments. The rp-set must be on the RP routers themselves – not on DRs – because RPs need to announce their membership in the set and exchange source information.

Why other options are incorrect

C. Configure anycast PIM with the rp-set statement on each source DR router.
The DR (Designated Router) only sends PIM Register messages to the anycast RP address. It does not participate in inter‑RP communication or source synchronization. Putting rp-set on DRs has no effect on sharing active sources between RPs; the DR simply forwards registers to the closest RP based on IGP routing.

D. Configure MSDP on each source DR router.
MSDP is an RP‑to‑RP protocol. Source DRs do not run MSDP. They are unaware of MSDP peerings and do not generate or forward SA messages. Configuring MSDP on a DR is both unnecessary and operationally incorrect.

References

RFC 4610: Anycast-RP Using PIM (PIM‑based RP‑set)
RFC 3618: Multicast Source Discovery Protocol (MSDP)
Junos Multicast Protocols Configuration Guide: "Configuring Anycast RP" and "Configuring MSDP"

Explanation:

Junos uses classifiers to evaluate incoming traffic for CoS purposes. Classifiers examine packet headers and assign each packet to a forwarding class and loss priority. Three types operate on ingress:

B. Behavior Aggregate Classifiers (BA classifiers)
Examine a single field (DSCP, IP precedence, MPLS EXP, or 802.1p) and map it directly to a forwarding class. Fast and efficient, used on trusted interfaces where markings are already set.

D. Fixed classifiers
Assign all traffic on an interface to one forwarding class and loss priority, ignoring packet headers. Simplest method, used on untrusted interfaces or when no differentiation is needed.

E. Multifield classifiers (MF classifiers)
Examine multiple fields (source/destination IP, protocol, port numbers) using firewall filters. Provide granular control but higher processing overhead. Used at network edges for policy‑based classification.

Why other options are incorrect

A. Rewrite rules
Rewrite rules modify packet headers (set DSCP/EXP bits) at egress. They do not evaluate incoming traffic; they mark outgoing packets so downstream routers can classify them.

C. Traffic shapers
Shapers are egress mechanisms that delay packets to enforce rate limits. They act on already‑classified traffic leaving the router and do not perform any ingress evaluation.

References

Junos Class of Service Configuration Guide: "Classifiers Overview" (BA, Fixed, Multifield)
RFC 2474/2475: Differentiated Services Architecture
JNCIP‑SP Study Guide: CoS – Classification mechanisms

Explanation:

IS-IS uses Sequence Number Packets (SNPs) to maintain link-state database consistency.

A. CSNPs are flooded periodically.
Complete SNPs (CSNPs) are sent periodically by the DIS on broadcast networks (every 10 seconds by default) and on point-to-point links when a neighbor comes up. They contain a complete list of all LSPs in the local database.

D. CSNPs contain only descriptions of LSPs.
CSNPs list LSP IDs, sequence numbers, and checksums — not the full LSP data. Receivers compare these descriptions with their own database and request missing or outdated LSPs using PSNPs.

Why other options are incorrect

B. PSNPs are flooded periodically
Partial SNPs (PSNPs) are not periodic. They are sent in response to CSNPs or LSPs — as acknowledgments on point-to-point links or as requests on broadcast networks. They are triggered, not timed.

C. PSNPs contain only descriptions of LSPs
While PSNPs do contain LSP descriptions, this statement is misleading and incomplete. PSNPs primarily serve as acknowledgments or requests, not just descriptions. More importantly, option C is not paired with a correct periodic statement (B is false), and the exam expects A and D as the established correct pair.

References

ISO 10589: IS‑IS routing protocol
Junos Routing Protocols Guide: IS‑IS — CSNP/PSNP operation
JNCIP‑SP Study Guide: IS‑IS database synchronization

Explanation:

The exhibit shows a RIB group (inet0_VPN-A) configured on PE-1 that imports routes from inet.0 (global routing table) into VPN-A.inet.0 (VRF table). This is a common method to provide Internet access to a VPN customer (VRF Internet access) over a single connection.

A. You must use the RIB group to move a default route, which is learned through BGP, from the inet.0 table to the VPN-A.inet.0 table.
Correct. The default route (0.0.0.0/0) learned via BGP from the Internet (e.g., from GW-1) resides in inet.0. To make it available to VPN‑A, the RIB group imports it into VPN-A.inet.0. Without this, VPN‑A routes cannot reach the Internet.

B. You do not need to use the RIB group to move interface routes from the inet.0 table to the VPN-A.inet.0 table.
Correct. Interface routes (direct and local) for the customer-facing interface on PE-1 belong to VPN-A.inet.0 automatically because that interface is bound to the VRF. They are never present in inet.0. Therefore, no RIB group is needed to move them.

Why other options are incorrect

C. You do not need to use the RIB group default route, which is learned through BGP, from the inet.0 table to the VPN-A.inet.0 table.
False. The default route is in inet.0 (global table). Without a RIB group import, VPN-A.inet.0 has no path to the Internet. The RIB group is required for the default route.

D. You must use the RIB group to move interface routes from the inet.0 table to the VPN-A.inet.0 table.
False. Interface routes for VRF‑bound interfaces never appear in inet.0. They are installed directly into the VRF table. No RIB group is needed or possible for them.

References

Junos VPNs Configuration Guide: "VRF Internet Access Using RIB Groups"
JNCIP‑SP Study Guide: Layer 3 VPNs — Internet access options
Juniper TechLibrary: "RIB Groups for Route Leaking Between Routing Tables"

Explanation:

The exhibit shows a VRF routing instance named CE-1 with:
instance-type vrf
A static route to 10.101.1.0/24 with next-hop 10.1.1.100
route-distinguisher 65512:1
vrf-target target:65512:100

In Junos, static routes defined inside a VRF routing instance are not automatically exported into MP‑BGP (i.e., not shared with remote PEs) unless explicitly configured to do so.

D. The 10.101.1.0/24 route will be shared if the auto-export parameter is configured.
Correct. The auto-export statement under the routing instance causes all routes present in the VRF's routing table (including static routes, connected routes, and routes learned from CE neighbors) to be automatically exported into MP‑BGP and advertised to remote PEs, provided they match the export policy (usually the VRF target community). Without auto-export, only routes learned via BGP from the CE are advertised by default.

Why other options are incorrect

A. The 10.101.1.0/24 route will be shared if the vrf-table-label parameter is configured.
vrf-table-label assigns a single MPLS label to the entire VRF for downstream traffic. It does not control route export into MP‑BGP. It affects data plane forwarding, not route advertisement.

B. The 10.101.1.0/24 route will only be shared if BGP is configured in the routing instance.
BGP is already implicitly present for VRF route exchange (MP‑BGP between PEs). However, having BGP configured does not automatically export static routes. auto-export or a manual export policy is still required.

C. The 10.101.1.0/24 route will be shared if there are other VRFs that use the same route target community.
Other VRFs using the same route target affects import behavior on remote PEs, not export from the local VRF. The local VRF still needs a mechanism to inject the static route into MP‑BGP.

References

Junos VPNs Configuration Guide: "VRF Route Export — auto‑export Statement"
JNCIP‑SP Study Guide: Layer 3 VPNs — Exporting non‑BGP routes from VRF
Juniper TechLibrary: "auto‑export (Routing Instances)"

Explanation:

In EVPN (Ethernet VPN), multihomed Ethernet segments (where a customer device is connected to two or more PEs) require specific route types for auto‑discovery and designated forwarder (DF) election. Two route types are directly used:

A. Type 1 – Ethernet Auto‑Discovery Route
Used to advertise the presence of an Ethernet Segment Identifier (ESI) from a PE. It signals which PEs are part of the same multihomed segment and is essential for split‑horizon and aliasing. Each PE advertises a Type 1 route per ESI.

C. Type 4 – Ethernet Segment Route
Used specifically for Designated Forwarder (DF) election in multihomed all‑active or single‑active scenarios. It contains the ESI and a DF election priority. PEs exchange Type 4 routes to determine which PE forwards BUM (Broadcast, Unknown unicast, Multicast) traffic for that segment.

Why other options are incorrect

B. Type 3 – Inclusive Multicast Route
Used for multicast (BUM) traffic forwarding and to discover other PEs in the same EVPN instance. It is not specific to multihomed Ethernet segments.

D. Type 2 – MAC/IP Advertisement Route
Used to advertise MAC addresses and (optionally) IP addresses learned on a given Ethernet segment. It is used for regular MAC learning and mobility, not for multihoming discovery or DF election.

References

RFC 7432: BGP MPLS‑Based Ethernet VPN – Sections 7.1 (Type 1), 7.4 (Type 4)
Junos EVPN Configuration Guide: Multihoming – Ethernet Segment routes
JNCIP‑SP Study Guide: EVPN – Route types and multihoming

Explanation:

To correctly implement summarization between IS-IS levels in Junos, the export policy must be precise in how it handles the aggregate route versus the contributing specific routes:

Option C (Match "exact"):
The current configuration uses longer for the $/61$ filter. This is incorrect because the policy needs to match the generated aggregate route itself to accept it for export. Changing this to exact ensures the $/61$ summary is specifically targeted for the accept action.

Option B (Delete "longer"):
You must remove the existing longer match condition from the summary term to prevent the policy from incorrectly grouping the more specific routes under the "accept" action intended for the summary.

Option A (Reject Specifics):
In the exhibit, the suppress term is set to then accept. This allows the $/64$ routes to be leaked into Level 2 alongside the summary, defeating the purpose of summarization. Changing this to reject ensures that only the $/61$ summary is advertised to R1 and R3, while the $/64$ routes are blocked.

Why Other Options Are Incorrect

Options D & E: Summarization from Level 1 to Level 2 is strictly an export operation from the perspective of the IS-IS protocol. Deleting the export statement (Option D) or attempting to use an import policy (Option E) would fail because import policies control how routes enter the routing table from the protocol, not how they are leaked between levels.

References

Junos OS Routing Protocols User Guide: Section on "Configuring IS-IS Route Summarization".
JNCIP-SP Certification Objectives: "IS-IS Routing Operations" – Policy-based Route Summarization and Level Leaking.

Explanation:

The exhibit shows a VRF (routing instance) configuration with:
instance-type vrf → Layer 3 VPN (not Layer 2)
vrf-target target:64512:1234 → exports/imports routes using route target community
BGP configured between PE and CE (neighbor 10.0.0.1, peer-as 64512)
as-override configured under the BGP group

D. A Layer 3 VPN is configured.
Correct. instance-type vrf plus vrf-target and BGP peering with a CE indicates a BGP/MPLS Layer 3 VPN (RFC 4364). The PE exchanges IP routes (family inet unicast) with the CE.

B. This VPN connects customer sites that use the same AS number.
Correct. The as-override statement is used when multiple customer sites share the same AS number. Without as-override, the PE would receive routes from CE1 with AS 64512, then advertise them to CE2 (also AS 64512). CE2 would see its own AS in the AS path and reject the routes. as-override replaces CE2's AS (64512) with the PE's AS before sending to CE2, preventing loop detection. This proves the customer uses the same AS at multiple sites.

Why other options are incorrect

A. This VPN connects customer sites that use different AS numbers.
Incorrect. If sites used different AS numbers, as-override would not be needed. The as-override command explicitly solves the "same AS across sites" problem.

C. A Layer 2 VPN is configured.
Incorrect. instance-type vrf and BGP family inet unicast indicate a Layer 3 VPN. Layer 2 VPNs use instance-type l2vpn or evpn.

References

RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)
Junos VPNs Configuration Guide: "as-override for BGP/MPLS Layer 3 VPNs"
JNCIP‑SP Study Guide: Layer 3 VPNs — CE‑PE routing with same AS

Explanation:

The ISO NSAP address follows the format: Area ID (variable length) + System ID (exactly 6 bytes / 12 hex digits) + SEL (1 byte / 00 for IS-IS). In 49.0001.00a0.c96b.c490.00, the area ID is 49.0001, the system ID is 00a0.c96b.c490, and the SEL is 00. Thus, option A is correct.

Why Other Options Are Incorrect

B. 0001.00a0.c96b.c490 is the system identifier.
This option incorrectly includes the area ID (0001) as part of the system ID. In ISO NSAP addressing, the area ID and system ID are distinct fields. The area ID identifies the IS-IS area, while the system ID uniquely identifies the router within that area. The system ID is fixed at exactly 6 bytes (12 hexadecimal digits). Adding the area ID extends the length beyond 6 bytes, violating the ISO 10589 specification and Junos implementation. This would cause neighbor adjacency failures because routers expect a 6‑byte system ID for identification and LSP generation.

C. c96b.c490 is the system identifier.
This option provides only 4 bytes (8 hex digits), omitting the first 4 hex digits (00a0). A system ID shorter than 6 bytes is invalid in IS-IS. Junos typically pads or rejects incomplete system IDs. In practice, missing bytes would break IS-IS operation because the router cannot be uniquely identified within the domain.

D. c490 is the system identifier.
This option supplies only 2 bytes (4 hex digits), far too short for a system ID. Such a truncated value cannot serve as a unique router identifier. IS-IS adjacencies would fail to form due to invalid NSAP length.

Reference :

ISO 10589 and Junos IS-IS Configuration Guide specify NSAP format: Area ID (variable) + System ID (6 bytes) + SEL (00). The system ID 00a0.c96b.c490 uniquely identifies the IS-IS router.