Exhibit
You are attempting to summarize routes from the 203.0.113.128/25 IP block on R8 to AS 64500. You implement the export policy shown in the exhibit and all routes from the routing table stop being advertised.
In this scenario, which two steps would you take to summarize the route in BGP? (Choose two.)
A. Remove the from protocol bgp command from the export policy
B. Add the set protocols bgp family inet unicast add-path command to allow additional routes to the RIB tables. -
C. Add the set routing-options static route 203.0.113.123/25 discard command.
D. Replace exact in the export policy with orlonger.
Explanation:
The exhibit shows R8 attempting to advertise a summary route 203.0.113.128/25 toward AS 64500. However, the export policy adv-routes contains:
from protocol bgp
route-filter 203.0.113.128/25 exact
After applying this policy, all routes stop being advertised because the policy matches nothing and the final reject blocks everything.
A. Remove the from protocol bgp command from the export policy.
R8 likely does not have a BGP route for 203.0.113.128/25 exactly. The route may be an aggregate, static, or directly connected route. By specifying protocol bgp, the policy matches only BGP-learned routes, excluding other route sources. Removing this allows the policy to match the summary route regardless of its protocol origin (e.g., aggregate or static discard).
D. Replace exact in the export policy with orlonger.
If R8 has only more‑specific routes (e.g., /26, /27, etc.) and no exact /25 route, the exact match fails. Changing to orlonger matches the prefix 203.0.113.128/25 and any more-specific routes. However, for proper summarization, you typically need an aggregate route or static discard route for the /25 itself. The orlonger alone is insufficient without a summary route in the table. But in combination with removing protocol bgp, R8 can generate the summary via an aggregate route. The question asks for two steps to summarize the route — A and D are the correct pair from the options given.
Why other options are incorrect
B. Add add-path command
add-path allows advertising multiple BGP paths for the same prefix. It does not help with route summarization or fix the “no routes advertised” problem.
C. Add static route 203.0.113.123/25 discard
The prefix is incorrect — should be 203.0.113.128/25, not .123/25. Even if corrected, a static discard route alone does not fix the policy match issue without also adjusting the policy.
References:
Junos BGP Configuration Guide:BGP export policies for route summarization. Aggregate routes require orlonger or separate aggregate term. Removing protocol restriction allows non‑BGP routes to be advertised. JNCIP‑SP Study Guide: BGP — Prefix aggregation.
Which two statements are correct about the customer interface in an LDP-signaled pseudowire? (Choose two)
A. When the encapsulation is vlan-ccc or extended-vlan-ccc, the configured VLAN tag is not included in the control plane LDP advertisement
B. When the encapsulation is ethernet-ccc, only frames without a VLAN tag are accepted in the data plane
C. When the encapsulation is vLan-ccc or extended-vlan-ccc, the configured VLAN tag is included in the control plane LDP advertisement
D. When the encapsulation is ethemet-ccc, tagged and untagged frames are both accepted in the data plane.
Explanation:
LDP-signaled pseudowires (Layer 2 circuits) use specific encapsulation types to determine how the PE handles Ethernet frames and how it communicates requirements to the remote peer via LDP.
VLAN-CCC / Extended-VLAN-CCC (Option C):
These encapsulations are "VLAN-aware." When the PE signals the pseudowire to its peer, it includes the specific VLAN ID in the LDP Label Mapping message (specifically within the Interface Parameters TLV). This ensures both sides agree on the VLAN tag being transported. If the tags do not match and "ignore-encapsulation-mismatch" is not set, the pseudowire will stay down.
Ethernet-CCC (Option D):
This is often referred to as "Port Mode" or "Raw Mode." In this mode, the PE treats the physical interface (or unit 0) as a transparent pipe. It does not look at the internal VLAN tags of the incoming frames; it simply takes the entire Ethernet frame (regardless of whether it is tagged, untagged, or Q-in-Q) and wraps it in an MPLS label for transport.
Why Other Options Are Incorrect
Option A:This is incorrect because the VLAN ID is a fundamental part of the LDP control plane signaling for VLAN-based circuits to ensure service consistency between PEs.
Option B: This is incorrect because ethernet-ccc is specifically designed for transparency. Restricting it to untagged frames only would defeat its purpose as a port-to-port tunneling mechanism; it is the most permissive encapsulation type.
References:
Junos OS VPNs User Guide: "Layer 2 Circuit Encapsulation Types" – Section detailing Ethernet-CCC vs. VLAN-CCC.
JNCIP-SP Certification Objectives: "Layer 2 VPNs" – Understanding LDP signaling and/ seudowire encapsulation.
You are a network architect for a service provider and want to offer Layer 2 services to your customers You want to use EVPN for Layer 2 services in your existing MPLS network.
Which two statements are correct in this scenario? (Choose two.)
A. Segment routing must be configured on all PE routers.
B. VXLAN must be configured on all PE routers.
C. EVPN uses Type 2 routes to advertise MAC address and IP address pairs learned using ARP snooping
D. EVPN uses Type 3 routes to join a multicast tree to flood traffic.
Explanation:
EVPN (Ethernet VPN) uses a BGP-based control plane to distribute reachability information. In an MPLS network, it relies on several specific BGP route types to handle different traffic scenarios:
MAC/IP Advertisement (Type 2):
Unlike traditional VPLS which relies on data plane learning, EVPN uses BGP Type 2 routes to distribute learned MAC addresses. If ARP snooping is enabled, the PE can also learn the associated IP address and advertise the MAC/IP pair together. This helps reduce network-wide ARP flooding by allowing the egress PE to respond to ARP requests locally (ARP suppression).
Inclusive Multicast Ethernet Tag Route (Type 3):
EVPN uses Type 3 routes for the "ingress replication" or multicast signaling. These routes are used to announce a PE's interest in receiving Broadcast, Unknown Unicast, and Multicast (BUM) traffic for a specific EVPN instance (EVI). They allow the PEs to build a flood tree to ensure BUM traffic is correctly replicated to all participating sites.
Why Other Options Are Incorrect
A. Segment Routing:
While EVPN can run over a Segment Routing (SR) transport, it is not a requirement. EVPN is transport-agnostic and functions perfectly over traditional LDP or RSVP-TE signaled LSPs.
B. VXLAN:
VXLAN is an alternative data plane encapsulation often used in data centers. However, since the scenario explicitly mentions an existing MPLS network, you would typically use EVPN-MPLS (where BGP labels are used for the service) rather than VXLAN.
References
Junos OS VPNs User Guide: "EVPN Overview" and "Understanding EVPN Route Types."
JNCIP-SP Certification Objectives: Under "Edge-routed Bridging (ERB) and EVPN-MPLS Operations."
RFC 7432: BGP MPLS-Based Ethernet VPN" – Section detailing the function of Route Types 2 and 3.
You are asked to protect your company's customers from amplification attacks. In this scenario, what is Juniper's recommended protection method
A. ASN prepending
B. BGP FlowSpec
C. destination-based Remote Triggered Black Hole
D. unicast Reverse Path Forwarding
Explanation:
Amplification attacks are a type of volumetric DDoS where an attacker sends small requests with a spoofed source IP (the victim) to publicly accessible services, which then send much larger responses to the victim.
BGP FlowSpec: Unlike traditional routing, which only looks at the destination IP, FlowSpec allows the propagation of traffic filtering rules via BGP. It can match traffic based on source, destination, protocol, and port, and then take action—such as rate-limiting or discarding—directly at the network edge. This is the recommended approach for amplification attacks because it allows the provider to drop only the malicious traffic (e.g., NTP traffic from specific sources) while keeping legitimate traffic flowing to the customer.
Why Other Options Are Incorrect
A. ASN Prepending:
This is a traffic engineering technique used to influence inbound path selection by making an AS Path look longer and less desirable. It provides no protection against the volume or nature of a DDoS attack.
C. Destination-based RTBH:
While effective at stopping an attack from reaching the customer, RTBH is a "sledgehammer" approach. It drops all traffic destined for the victim's IP address. For an amplification attack, this means the attacker succeeds in their goal of taking the customer offline.
D. unicast Reverse Path Forwarding (uRPF):
uRPF is used to prevent spoofing at the source. While it helps stop your own network from being an origin of spoofed traffic, it does not protect your customers from an external amplification attack already directed at them from the Internet.
References
Junos OS Routing Protocols User Guide: Section on "BGP Flow Specification (FlowSpec) Overview."
JNCIP-SP Certification Objectives: "High Availability and Network Security" – Implementation of BGP FlowSpec for DDoS mitigation.
Exhibit
Referring to the exhibit, which statement is correct?
A. The vrf-target configuration will allow routes to be shared between CE-1 and CE-2.
B. The vrf-target configuration will stop routes from being shared between CE-1 and CE-2.
C. The route-distinguisher configuration will allow overlapping routes to be shared between CE-1 and CE-2.
D. The route-diatinguisher configuration will stop routes from being shared between CE-1 and CE-2.
Explanation;
In a Layer 3 VPN environment, the exchange of routes between different routing instances (VRFs) is governed by the BGP community attributes known as Route Targets.
VRF-Target Functionality: The vrf-target command is a shortcut in Junos that simultaneously configures both the export and import targets for a routing instance.
Matching Targets: In the exhibit, both the CE-1 instance and the CE-2 instance are configured with the exact same target: target:65512:100.
CE-1 will export its routes with this community string.
CE-2 is configured to import any routes that carry the target:65512:100 community.
Result: Because the import and export targets match across both instances, the Provider Edge (PE) routers will successfully install and share routes between these two customer sites.
Analysis of Route Distinguishers (RD)
While the exhibit shows both instances using the same Route Distinguisher (65512:1), it is important to note that the RD's primary purpose is to make IP prefixes unique within the BGP table (transforming an IPv4 address into a 96-bit VPN-IPv4 address). While using the same RD in a small environment is possible, it is the VRF-Target, not the RD, that controls the actual sharing (import/export logic) of those routes between instances.
Why Other Options Are Incorrect
B: The configuration will allow sharing, not stop it, because the targets are identical.
C & D: These options incorrectly attribute the sharing logic to the Route-Distinguisher. The RD ensures uniqueness for overlapping address spaces, but it does not dictate which VRF a route is imported into; that is strictly the role of the VRF-Target.
References
Junos OS VPNs User Guide: "Understanding Route Targets" and "Understanding Route Distinguishers."
JNCIP-SP Certification Objectives: Layer 3 VPNs – Route Target and Route Distinguisher operation.
Click the Exhibit button.
You enabled a new router (R3) in your network but all destinations using IS-IS routes are not properly load balancing over this new router.
Referring to the exhibit, what is the problem?
A. R2 is missing internal routes for R1.
B. R1 is missing internal routes for R2.
C. R3 does not have wide-metrics enabled.
D. R1 does not have wide-metrics enabled.
Explanation:
The exhibit shows a critical mismatch in IS-IS metric types between routers. R3 advertises prefixes with narrow metrics (maximum value 63, as seen with metrics 63 in the output), while R2 uses wide metrics (values up to 1000).
Why other options are incorrect
A. R2 is missing internal routes for R1The output shows R2 advertises extended prefixes (10.100.12.0/24, 10.100.23.0/24, 10.100.24.0/24) successfully. R2 has proper routes.
B. R1 is missing internal routes for R2R1 receives and displays R2's extended prefixes. R1's routing table is populated correctly.
D. R1 does not have wide-metrics enabledR1 successfully processes R2's wide metrics (values up to 1000), proving wide metrics are enabled on R1.
References
ExamTopics JN0-664 Discussion — Most voted answer identifies wide-metrics mismatch
RFC 5305 (IS-IS Extensions for Traffic Engineering) — defines extended TLVs (type 135)
Juniper IS-IS Configuration Guide — wide-metrics-only command
Which statement is correct about IS-IS when it performs the Dijkstra algorithm?
A. The local router moves its own local tuples into the candidate database
B. When a new neighbor ID in the tree database matches a router ID in the LSDB, the neighbor ID is moved to the candidate database
C. Tuples with the lowest cost are moved from the tree database to the LSDB.
D. The algorithm will stop processing once the tree database is empty.
Explanation:
Why B is correct:
The LSDB holds the LSPs for all routers. When the SPF algorithm "processes" a router (Vertex X) from the Tree Database, it looks at Vertex X's LSP in the LSDB to find its neighbors. If a neighbor's Router ID listed in the LSP matches a Router ID in the LSDB, that neighbor is moved into the Candidate Database to be evaluated .
Why other options are incorrect
A. The local router moves its own local tuples into the candidate database.
This is incorrect because the local router is the starting point of the "root" of the shortest-path tree. It is immediately placed into the Tree Database (PATHS), not the Candidate Database (TENT). The algorithm initializes with itself as the first confirmed vertex .
C. Tuples with the lowest cost are moved from the tree database to the LSDB.
This is incorrect. Data flow is strictly one-way: the LSDB is the source of topology information used to build the Tree Database. Tuples (vertices) move from the Candidate Database to the Tree Database. The LSDB is never written to by the SPF algorithm; it is read from .
D. The algorithm will stop processing once the tree database is empty.
This is incorrect. The algorithm stops processing once the Candidate Database is empty. An empty Candidate Database means there are no more potential paths to evaluate or explore. The Tree Database contains the final results (the Shortest Path Tree) .
References
ExamTopics JN0-664 Discussion (AJSPR Course material references)
FRRouting IS-IS SPF Calculation Technical Documentation
Baidu百科 - Link State Routing Algorithm
Exhibit
Referring to the exhibit, which two statements are correct about the dual route reflectors within a cluster? (Choose two.)
A. RR1 and RR2 must have the same duster ID to exchange routes learned from the client.
B. RR1 and RR2 append the duster ID when advertising routes from dient to dient.
C. RR1 and RR2 advertise routes learned from the clients to EBGP peers, using itself as the next hop.
D. RR1 advertises routes from the client to RR2. using itself as the next hop.
Explanation:
Cluster ID and Loop Prevention
CLUST_LIST Attribute (Option B): When a Route Reflector (RR) reflects a route from one client to another client (or to a non-client), it prepends its Cluster ID to the CLUSTER_LIST attribute. This is a fundamental BGP loop prevention mechanism. If an RR receives a route containing its own Cluster ID in the list, it knows a routing loop has occurred and will discard the update.
EBGP Next-Hop Behavior
Next-Hop Self (Option C): Standard BGP rules dictate that when an IBGP router (including RRs) advertises a route to an EBGP peer, it must change the BGP next-hop to its own IP address. This ensures that the external peer knows where to send traffic to reach those internal destinations.
Why Other Options Are Incorrect
A. Cluster ID for RR Exchange:
RR1 and RR2 do not need the same Cluster ID to exchange routes. While they often share one in a redundant cluster to prevent redundant reflection between them, they are standard IBGP peers; they exchange routes based on IBGP peering rules and specific loop prevention checks (Originator ID and Cluster List).
D. IBGP Next-Hop Preservation:
By default, BGP Route Reflectors do not change the next-hop attribute when reflecting routes to other IBGP peers (including other RRs in the same AS). They preserve the original next-hop (e.g., the client's IP) to ensure the path remains optimal and the traffic follows the IGP shortest path.
References:
Junos OS Routing Protocols User Guide: Section on "BGP Route Reflection" and "Next-Hop Resolution."
JNCIP-SP Certification Objectives: "BGP Scaling" – Understanding Route Reflection and Loop Prevention (CLUSTER_LIST and ORIGINATOR_ID).
Exhibit
Which two statements about the output shown in the exhibit are correct? (Choose two.)
A. The PE is attached to a single local site.
B. The connection has not flapped since it was initiated.
C. There has been a VLAN ID mismatch.
D. The PE router has the capability to pop flow labels
Explanation:
The show l2vpn connections command provides the status of Layer 2 VPN (Kompella) signaled connections. We can determine the state of the network by analyzing the specific fields in the output:
Single Local Site (Option A):
Under the instance "vpn-A," the output displays Local site: CE1-2 (2). There is only one local site listed in this output, and it has a single remote connection listed below it (Site ID 1). This indicates that this PE is currently servicing only one local site for this specific VPN instance.
Connection Flaps (Option B):
The field # Up trans (Up transitions) indicates how many times the connection has transitioned to the "Up" state. The exhibit shows a value of 1. This means the connection has come up once and remained up; it has not "flapped" (dropped and come back up), which would have increased this counter to 2 or more.
Why Other Options Are Incorrect
C. VLAN ID Mismatch:
The legend indicates that a VLAN ID mismatch would be represented by the code VM. In the connection table, the status is clearly listed as Up, not VM. Furthermore, the local interface ge-0/0/6.610 is shown with a status of Up and encapsulation VLAN, indicating a healthy configuration.
D. Flow Label Capability:
The output explicitly states Flow Label Transmit: No and Flow Label Receive: No. This indicates that Flow Label support (RFC 6391) is either not configured or not supported/negotiated for this specific connection. There is no evidence in the exhibit that the router has the active capability to pop or process flow labels for this circuit.
References
Junos OS VPNs User Guide: "Monitoring Layer 2 VPN Connections" and "Understanding the show l2vpn connections Output."
JNCIP-SP Certification Objectives:"Layer 2 VPNs" – Troubleshooting Kompella L2VPNs and understanding connection status codes.
Click the Exhibit button.
Referring to the exhibit, which statement is correct?
A. VPN routes are exported with the target:65512:1 and target:65512:2 route targets.
B. You cannot use the vrf-target and vrf-export statements in the same VRF.
C. VPN routes with the target:65512:1 and target:65512:2 route targets are imported.
D. VPN routes are exported with only the target:65512:1 route target
Explanation:
The behavior of route targets in this scenario is determined by how Junos prioritizes export policies and the cumulative nature of community additions:
VRF-Target Interaction: The vrf-target target:65512:1 statement acts as a default for both import and export. It automatically applies the target:65512:1 community to routes leaving the VRF.
VRF-Export Policy: When a vrf-export policy is explicitly defined, it processes the routes as they are exported. In the exhibit, the policy vpn-a-export uses the community add command for two distinct communities:
vpn-a-target (which maps to target:65512:1).
vpn-m-target (which maps to target:65512:2).
Resulting Export Path: Because the policy uses community add rather than community set, the communities defined in the export policy are added to any existing communities. Consequently, the exported VPN routes will carry both target:65512:1 and target:65512:2.
Why Other Options Are Incorrect
B: You can absolutely use both vrf-target and vrf-export together. The vrf-target provides a baseline, while vrf-export allows for more granular control or additional target tagging.
C: While routes with target:65512:1 are imported due to the vrf-target statement, there is no vrf-import policy or additional vrf-target statement shown that would trigger the import of routes with target:65512:2.
D: This is incorrect because the vrf-export policy explicitly adds the second target (target:65512:2) via the vpn-m-target community definition.
References
Junos OS VPNs User Guide: "Understanding Route Targets and Export Policies in Layer 3 VPNs".
JNCIP-SP Certification Objectives: Layer 3 VPNs — "Advanced Routing Policy and Route Target Filtering".
Exhibit
The environment is using BGP All devices are in the same AS with reachability redundancy Referring to the exhibit, which statement is correct?
A. RR1 is peered to Client2 and RR2
B. RR2 is in an OpenConfirm State until RR1 becomes unreachable.
C. Client1 is peered to Client2 and Client3.
D. Peering is dynamically discovered between all devices.
Explanation:
The exhibit illustrates a standard BGP Route Reflection design intended to scale IBGP within a single Autonomous System (AS).
Peering Relationships (Option A):
In a route reflection topology, lines between routers represent BGP peering sessions. The diagram explicitly shows lines connecting RR1 to Client2 and RR1 to RR2. This confirms that RR1 maintains active BGP sessions with both that specific client and its redundant route reflector peer.
Why Other Options Are Incorrect
B. OpenConfirm State:
The OpenConfirm state is a temporary transitional phase in the BGP Finite State Machine (FSM) while waiting for a Keepalive or Notification message. It is not used as a "standby" mechanism for redundancy; BGP neighbors are either established and exchanging routes or they are not. Both RRs should be in an Established state simultaneously.
C. Client-to-Client Peering:
A primary benefit of Route Reflection is that clients do not need to peer with each other. The exhibit confirms this visually; there are no lines connecting Client1 to Client2 or Client3. They learn each other's routes through the RRs.
D. Dynamic Discovery:
Standard BGP requires explicit neighbor configuration (manual peering). While features like BGP Dynamic Neighbors exist (using listen ranges), there is no evidence in this standard architectural diagram to suggest that peering is dynamically discovered rather than manually defined.
References
Junos OS Routing Protocols User Guide: Section on "BGP Route Reflection" and "BGP Peering Sessions."
JNCIP-SP Certification Objectives: "BGP Scaling" – Understanding Route Reflection and peer relationships.
Which origin code is preferred by BGP?
A. Internal
B. External
C. Incomplete
D. Null
Explanation:
BGP prefers the path with the lowest origin type. The hierarchy is defined by how the route was first introduced into the BGP table:
IGP (i) / Internal: This indicates the route was learned from an interior gateway protocol (like OSPF or IS-IS) within the originating Autonomous System. This is the most preferred origin code because it implies the highest level of routing certainty.
EGP (e) / External:This signifies the route was learned via the Exterior Gateway Protocol (the historical predecessor to BGP). While still considered a "known" origin, it is ranked second.
Incomplete (?): This indicates the route origin is unknown, usually occurring when a route is redistributed into BGP from static routes or other protocols. This is the least preferred origin code.
Why Other Options Are Incorrect
B. External: While ranked higher than "Incomplete," it is mathematically and procedurally less desirable than an "Internal" (IGP) origin.
C. Incomplete: This code represents the lowest level of preference in the BGP selection hierarchy.
D. Null: "Null" is not a recognized BGP origin attribute in the standard path selection process.
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 5.1.1 (Origin Attribute).
| Page 3 out of 8 Pages |
| 234 |
| JN0-664 Practice Test Home |
Real-World Scenario Mastery: Our JN0-664 practice exam don't just test definitions. They present you with the same complex, scenario-based problems you'll encounter on the actual exam.
Strategic Weakness Identification: Each practice session reveals exactly where you stand. Discover which domains need more attention, before Service Provider Professional (JNCIP-SP) exam day arrives.
Confidence Through Familiarity: There's no substitute for knowing what to expect. When you've worked through our comprehensive JN0-664 practice exam questions pool covering all topics, the real exam feels like just another practice session.
Copyright © All Rights Reserved