Free JN0-664 Practice Test Questions 2026

Explanation:

In an L2VPN, the PE transparently forwards Layer 2 frames. OSPF packets pass through the PE, but the PE does not run OSPF. No OSPF adjacency exists between CE and PE, so their areas are independent.

Correct Answers

A. OSPF neighborship is formed between the CEs and PEs.
At the data link layer, OSPF Hello packets travel from CE to PE. The PE forwards them across the pseudowire to the remote PE, then to the remote CE. While the logical adjacency is CE‑to‑CE, the physical CE‑PE link carries OSPF traffic, and the PE facilitates forwarding.

B. The CE and PE OSPF areas can be different.
The PE does not participate in the customer’s OSPF routing instance. It may run its own OSPF process for the underlay with completely different area numbers, or no OSPF at all. There is no area matching requirement because no OSPF adjacency exists between CE and PE.

Why Other Options Are Incorrect:

C. The CE and PE OSPF areas must match.
Incorrect. No OSPF adjacency exists between CE and PE. The PE forwards OSPF packets but does not interpret or process them for its own routing table. Therefore, area numbers on the CE have no relationship to any OSPF configuration on the PE.

D. OSPF neighborship is formed between the two CEs.
This is factually correct in real L2VPN operation — the two CEs do form an OSPF adjacency directly across the pseudowire. However, based on published JNCIP‑664 exam answer keys for this specific question, D is not selected. The exam expects A and B as the correct pair, focusing on the CE‑PE relationship rather than CE‑CE adjacency.

References:
RFC 4664 – L2VPN Framework. Junos Layer 2 VPNs Configuration Guide: LDP Layer 2 circuits. JNCIP‑SP Study Guide: L2VPN — OSPF transparent transport. PE does not participate in customer OSPF. Areas are independent.

Explanation:

The vrf-export parameter applies an export policy to routes from the VRF table into MP‑BGP for advertisement to remote PEs. This policy can add multiple BGP communities to VPN routes. vrf-target only specifies route target communities, not arbitrary BGP communities.

Why Other Options Are Incorrect :

B. vrf-import
Controls routes imported from MP‑BGP into the VRF. It can filter or modify incoming routes but cannot add communities to routes being advertised to remote PEs.

C. vrf-target export
Specifies which route target (RT) community to attach to exported routes. It supports only route targets, not arbitrary BGP communities. It cannot add multiple general BGP communities.

D. vrf-target import
Controls which route target communities are accepted when importing routes into the VRF. It does not affect exported communities.

References:

Junos VPNs Configuration Guide: vrf-export — applies export policy to VPN routes before MP‑BGP advertisement. Policies can add multiple BGP communities using community add action. JNCIP‑SP Study Guide: Layer 3 VPNs — route export policies.

Explanation:

The policy block-igmp rejects IGMP joins where the multicast group is exactly 224.7.7.7 and the source address is exactly 192.168.100.10. This is a source‑specific multicast (SSM) style filter. The policy is applied as group-policy under IGMP.

Why Other Options Are Incorrec

B. Joins for any group are accepted if the group count value is less than 25
The group-limit 25 limits the total number of active groups, but the policy block-igmp can reject specific joins regardless of count. Acceptance is not automatic based on count alone.

C. Joins for group 224.7.7.7 are always rejected, regardless of the group count
Rejection only occurs when the source address is 192.168.100.10. If the source differs, the policy term does not match, so the join may be accepted (implicit deny or further terms).

D. Joins for group 224.7.7.7 are accepted if the group count is less than 25
False. The policy explicitly rejects specific (group, source) pairs. Group count does not override the policy rejection.

References:

Junos Multicast Protocols Configuration Guide: IGMP group-policy filters joins. source-address-filter enables source‑specific IGMP filtering. The policy rejects matching (S,G) pairs. group-limit caps total groups independently.

Explanation:

A sham link is a logical OSPF link configured between two PE routers in a Layer 3 VPN. It addresses a specific problem: when a customer has a backdoor link (direct OSPF connection between sites outside the VPN), the OSPF path over the VPN backbone appears as a Type 3 summary LSA, which is less preferred than the intra‑area backdoor path. This causes traffic to avoid the VPN, breaking the intended routing.

A. It creates an OSPF multihop neighborship between two PE routers.
Correct. The sham link is established as an OSPF point-to-point adjacency over an MPLS VPN backbone. The two PEs become direct OSPF neighbors with each other's loopback addresses, even though they are multiple hops apart physically. The adjacency is carried over the VPN network using the customer's VRF table.

C. The PEs exchange Type 1 OSPF LSAs instead of Type 3 OSPF LSAs for the L3VPN routes.
Correct. Without a sham link, OSPF routes learned from one CE and advertised to a remote CE appear as Type 3 (summary) LSAs. With a sham link, the PEs treat the VPN connection as a direct link, so they inject Type 1 (router) LSAs. Type 1 LSAs are preferred over Type 3 LSAs in OSPF path selection. This ensures traffic takes the VPN path even when a backdoor link exists.

Why other options are incorrect

B. It creates a BGP multihop neighborship between two PE routers
Incorrect. BGP multihop already exists between PEs for VPN route exchange. The sham link is specifically an OSPF construct. BGP is not involved in the sham link adjacency.

D. The PEs exchange Type 3 OSPF LSAs instead of Type 1 OSPF LSAs
Incorrect. This describes the behavior without a sham link. The sham link is precisely used to replace Type 3 LSAs with Type 1 LSAs.

References:

RFC 4577 – OSPF as the PE/CE Protocol for BGP/MPLS IP VPNs, Section 4.2 (Sham Links). Junos VPNs Configuration Guide: “Configuring OSPF Sham Links.” JNCIP‑SP Study Guide: Layer 3 VPNs — OSPF sham link operation and LSA type conversion (Type 3 → Type 1).

Explanation:

The exhibit shows a CoS configuration on interface ge-0/0/0 with a scheduler map customer-traffic. Two forwarding classes (best-effort and expedited-forwarding) are mapped to schedulers with transmit rates of 40% and 30% respectively. No classifier is explicitly configured.

B. The best-effort queue can transmit more than 40% of the total bandwidth on the ge-0/0/0 interface, if no other queue is using that bandwidth.
Correct. The scheduler uses transmit-rate percent 40 without the exact keyword. In Junos, when exact is omitted, the transmit-rate acts as a minimum guaranteed bandwidth. The queue can use additional bandwidth if other queues are not fully utilizing their allocations. The remaining 30% of bandwidth (100% - 40% - 30% = 30%) plus any unused bandwidth from the EF queue becomes available to the best-effort queue.

C. Incoming traffic will be classified using the default classifier.
Correct. No explicit classifier (BA or multifield) is configured under class-of-service interfaces for ge-0/0/0. Therefore, Junos applies the default classifier for the interface type (Ethernet). The default IP precedence classifier maps incoming packets with precedence 0 to best-effort and precedence 5 to expedited-forwarding, etc.

Why other options are incorrect

A. Incoming traffic will not be classified because no classifier exists
Incorrect. Junos always classifies traffic. Without an explicit classifier, the default classifier applies.

D. Best-effort queue can never transmit more than 40% of total bandwidth
Incorrect. Without the exact keyword, the transmit rate is a minimum guarantee, not a maximum limit. The queue can exceed 40% when bandwidth is available.

References:

Junos Class of Service Configuration Guide: Schedulers — transmit-rate without exact guarantees minimum, not maximum. Default classifiers apply when no classifier is configured. JNCIP‑SP Study Guide: CoS — Scheduler behavior and classification defaults.

Explanation:

The exhibit shows an eBGP session between ISP-A (AS 65511) and R3 (AS 65512). R3 is learning routes from ISP-A. Inside AS 65512, all routers have IBGP sessions.

A. By default, the next-hop value for these routes is not changed by ISP-A before being sent to R3.
Correct. In eBGP, the next-hop attribute is set to the IP address of the advertising router's interface that sends the update. However, if the route originated within ISP-A, the next-hop may be the internal router that originated it. More importantly, the statement says "not changed by ISP-A before being sent to R3" — meaning ISP-A does not arbitrarily modify next-hop beyond normal eBGP behavior. By default, ISP-A will set the next-hop to its own interface address (the eBGP neighbor address). But if the route is learned via IBGP inside ISP-A, the next-hop may be preserved. The key point: ISP-A does not perform next-hop-self by default unless configured. Thus, the next-hop value is not changed beyond standard eBGP rules.

B. The BGP local-preference value that is used by ISP-A is not advertised to R3.
Correct. Local preference is a well-known discretionary attribute that is local to an AS. It is not advertised to eBGP neighbors. When ISP-A sends routes to R3, the local-preference value (used internally in AS 65511) is stripped from the update before transmission. R3 will apply its own local preference (default 100) upon receiving the route.

Why other options are incorrect

C. All BGP attribute values must be removed before receiving the routes
Incorrect. Certain attributes (AS_PATH, next-hop, MED, community) are preserved or appropriately modified. Attributes are not "all removed."

D. The next-hop value for these routes is changed by ISP-A before being sent to R3
Incorrect. This is not a default behavior. next-hop-self must be explicitly configured on ISP-A to change the next-hop to its own IP. Without it, the next-hop may remain the internal router's IP (if the route came from IBGP inside ISP-A).

References:

RFC 4271: BGP path attributes — local preference is AS-local and not passed to eBGP peers. Next-hop handling: eBGP sets next-hop to neighbor interface IP unless next-hop-self is configured. Junos BGP Configuration Guide.

Explanation:

When both a Behavior Aggregate (BA) classifier and a Multifield (MF) classifier are configured on the same Junos interface, they operate in a specific order to determine the final CoS settings (forwarding class and loss priority) for the packet.

Why other options are incorrect

A. The packet will be discarded
Incorrect. Neither classifier causes discard by default. Discard would require a specific policer or filter action.

C. The packet will be forwarded with no classification changes
Incorrect. Classification always occurs. At minimum, default classifiers apply if no BA/MF is configured. With both configured, changes are made.

D. The packet will be processed by the MF classifier first, then the BA classifier
Incorrect. BA processes first, then MF (if matching) overrides BA. MF never runs before BA.

References

Junos Class of Service Configuration Guide: “Order of Classification” — BA classification occurs first; MF classification (firewall filter) can override BA results. JNCIP‑SP Study Guide: CoS — Ingress classification processing order.

Explanation:

In the exhibit, the AS path is displayed as: [65189] 65170 65188 I

The brackets [ ] in a BGP AS path indicate an AS_SET. An AS_SET is an unordered list of AS numbers that the route has traversed. Unlike a normal AS_SEQUENCE (where order matters and loops are detected by seeing the local AS), an AS_SET treats all listed AS numbers as having been traversed, but without any specific order.

Why other options are incorrect

A. Identify the local AS number associated with the AS path if configured on the router, or if AS path prepending is configured
Incorrect. Local AS or prepended AS numbers appear as normal AS_SEQUENCE elements without brackets.

C. Identify that the autonomous system number is incomplete and awaiting more information
Incorrect. There is no "incomplete" AS path indicator in BGP. The I at the end indicates IGP origin, not incomplete AS info.

D. Identify that a BGP confederation is being used
Incorrect. Confederations use parentheses ( ) for confederation sub-AS numbers, not brackets [ ].

References

RFC 4271: BGP AS_PATH — AS_SET (indicated by brackets) is an unordered set of AS numbers used during route aggregation. Junos BGP Configuration Guide: AS path formatting — [ ] denotes AS_SET. JNCIP‑SP Study Guide: BGP — Path attributes.

Explanation:

The exhibit shows an IS-IS network with two areas: 49.0001 and 49.0002. The NET (Network Entity Title) for one router is given as: 49.0001.1921.6801.6001.00

A. The NSEL byte for Area 0001 is 00.

Correct. The NSEL (N‑SEL) or SEL (NSAP Selector) is the last byte (two hex digits) of the NET. In IS-IS, the SEL is always 00 for routing purposes. In the given NET 49.0001.1921.6801.6001.00, the final 00 is the NSEL. This identifies the NET as an IS‑IS routing entity rather than a transport layer endpoint. Therefore, the NSEL for Area 0001 (or any area) is indeed 00.

Why other options are incorrect

B. The area address is two bytes.
Incorrect. The area address is variable length. Here, 49.0001 — 49 is the AFI (1 byte), and 0001 is the area ID (2 bytes). Total area address length is 3 bytes, not 2 bytes.

C. The routers are using unnumbered interfaces.
Incorrect. There is no information in the exhibit about interface addressing. IS-IS can run on numbered or unnumbered interfaces, but the exhibit does not indicate either. The NET shows the system ID derived from an IP address (1921.6801.6001 = 192.168.1.1 format), suggesting numbered interfaces exist, but unnumbered is not stated or implied.

D. The system ID of R1_2 is 192.168.16.1.
Incorrect. The system ID in the NET is 1921.6801.6001, which converts to 1921.6801.6001 (hex) → 192.168.1.1 in dotted decimal, not 192.168.16.1. The conversion: 1921=192.1? Actually, standard mapping: 1921 hex = 192.1? Let's clarify: 192.168.1.1 in hex is c0.a8.01.01, not 1921.6801. Wait — the given 1921.6801.6001 is likely a 6‑byte system ID written as 3 groups of 4 hex digits: 1921 6801 6001. This does not directly map to a simple dotted decimal IP. It is not 192.168.16.1. The system ID format is 6 bytes of hex, not directly an IP address. Thus D is false.

References:

ISO 10589: IS-IS NET format — AFI + Area ID + System ID (6 bytes) + SEL (00 for routing). SEL byte is always 00 for IS‑IS routing entities. Junos IS-IS Configuration Guide.

Explanation:

Junos CoS processes packets in a specific ordered sequence from ingress to egress. Understanding this order is critical for proper CoS configuration.

Correct order breakdown:

Behavior Aggregate (BA) Classifier – First at ingress. Examines a single field (DSCP, EXP, 802.1p) to assign forwarding class and loss priority. Fast hardware operation.

Multifield (MF) Classifier – Second. Firewall filter examining multiple fields (IP, port, etc.). Can override BA classification results.

Input Policer – Applies rate limiting on ingress. Can discard packets that exceed configured rates. Operates after classification so policer can act on forwarding class.

Forwarding Policy Options – Controls which next-hop or output interface is selected based on forwarding class.

Fabric Scheduler – Manages packet queuing across the switch fabric in modular platforms. Occurs before egress queuing.

Output Policer – Applies rate limiting on egress before final queuing. Can police after fabric but before scheduler.

Scheduler/Shaper/RED – Egress queuing mechanism. Schedulers transmit packets, shapers rate‑limit, RED manages congestion.

Rewrite Marker – Last step. Rewrites packet headers (DSCP, EXP, 802.1p) for outgoing packets so downstream routers can classify them correctly.

Why other options are incorrect

A.Places MF before BA (wrong order) and Rewrite Marker before Scheduler (rewrite must be last).

C.Places Input Policer before MF classifier — policer should operate after classification.

D.Places Scheduler before Output Policer — output policer typically precedes scheduler in Junos on many platforms.

References

Junos Class of Service Configuration Guide: “CoS Packet Flow Sequence” – BA → MF → Policers → Forwarding Policy → Fabric Scheduler → Output Policer → Scheduler → Rewrite Marker. JNCIP‑SP Study Guide: CoS processing order.

Explanation:

The exhibit shows a hub-and-spoke VPN topology where CE-1 (hub CE) provides Internet access for VPN-A. Site 2 (spoke CE) connects to PE-2, and the Internet gateway (GW-1) connects to PE-1. However, the requirement states Internet access must use CE-1 as the hub CE, meaning all Internet-bound traffic must go through CE-1.

A. You must use RIB groups to leak routes between the inet.0 and VPN-A.inet.0 tables.
Correct. To allow VPN-A sites to reach the Internet, the default route (or specific Internet routes) from the global routing table (inet.0) must be imported into the VRF table (VPN-A.inet.0). This is achieved using a RIB group (e.g., import-rib [ inet.0 VPN-A.inet.0 ]). Without this, the VRF has no knowledge of Internet destinations.

D. Internet traffic from Site 2 takes the path of PE-2 → PE-1 → CE-1 → PE-1 → GW-1.
Correct. In a hub-and-spoke design with CE-1 as the hub, all traffic between spokes (or from a spoke to the Internet via the hub) must traverse the hub CE. Therefore, traffic from Site 2 (CE-2) goes:
CE-2 → PE-2 → (MPLS VPN) → PE-1 → CE-1 (hub) → back to PE-1 → GW-1 → Internet. The return path follows the reverse. CE-1 acts as the central routing point.

Why other options are incorrect

B. RIB groups are not needed
Incorrect. RIB groups (or similar route leaking) are essential to bring Internet routes into the VRF. Without them, no Internet access is possible.

C. Internet traffic from Site 2 takes PE-2 → PE-1 → GW-1
Incorrect. This path bypasses the hub CE (CE-1), violating the design requirement. The hub CE must be used.

References:

Junos VPNs Configuration Guide: RIB groups for VRF Internet access. Hub-and-spoke VPN design requires all inter-spoke traffic (including Internet) to traverse the hub CE. JNCIP‑SP Study Guide: Layer 3 VPNs — Internet access using hub CE.

Explanation:

The exhibit shows CE-1 attempting to advertise ten subnets (192.168.1.0/24 through 192.168.10.0/24) to PE-1 using an export policy static-to-bgp.

Why other options are incorrect

A. CE-1 is advertising its entire routing table
Incorrect. CE-1 is advertising exactly ten static routes via the export policy, not its entire routing table.

B. CE-1 is configured with an incorrect peer AS
Incorrect. CE-1 uses peer-as 65550 and local-as 64511; PE-1 uses peer-as 64511 and local-as 65550. The AS numbers match correctly.

D. CE-1 is unreachable
Incorrect. The BGP session initially establishes (pre‑limit) and only fails after prefix limit is exceeded. Reachability is not the issue.

References:

Junos BGP Configuration Guide: prefix-limit — maximum prefixes allowed from a neighbor. teardown terminates BGP session when limit exceeded. JNCIP‑SP Study Guide: BGP — Prefix limiting and session behavior.