Free JN0-664 Practice Test Questions | Know You're Ready for Service Provider Professional (JNCIP-SP)

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.

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).