Free JN0-351 Practice Test Questions | Know You're Ready for Enterprise Routing and Switching Specialist (JNCIS-ENT)

Explanatio:

The show route protocol bgp 192.168.10.0/24 output displays two BGP routes for the same prefix. The active (best) route is marked with * and > and is via R1 (10.100.24.2). The second route via R2 (10.100.25.2) is shown but is not the active route. BGP path selection is deterministic, following a series of attributes in a specific order.

Why other options are wrong:

A. R2's route is not the best path due to loop prevention.
Incorrect. Loop prevention in BGP typically involves AS path loops (detecting own AS number in the path). The exhibit shows R2's route having multiple repetitions of AS 64533, but that alone does not indicate a loop — and even if it were a loop, the route would be hidden, not presented as an alternate. Loop prevention is not the primary reason here; local preference overrides.

B. R2's route is not the best path due to a lower origin code. Incorrect. Origin code (I vs ?) is compared after local preference, AS path length, and origin type. Even if R2 had a better origin (which it does not — ? is considered less preferred than I), local preference has already decided the winner. The statement implies origin is the reason, but it is not.

D. R1's route is the best path due to the shorter AS path.
Incorrect. R1's AS path length is 1 (just 64533). R2's AS path length is 4 (64533 64533 64533 64534). Shorter AS path is generally better, but BGP compares local preference before AS path length. Here, local preference already selects R1; the shorter AS path is consistent but not the deciding factor. The question asks for the reason given the exhibited data — localpref is the clear, highest-priority differentiator.

Reference:

Juniper TechLibrary: “BGP Path Selection Algorithm”
– “BGP selects the best route based on the following order: highest local preference, shortest AS path, lowest origin type, lowest MED, eBGP over iBGP, lowest IGP metric to next hop, lowest router ID.”

JNCIS‑ENT Study Guide (BGP chapter)
– “Local preference is the most influential attribute for outbound route selection within an AS; higher value wins.”

Explanation:

B. IBGP peers advertise routes received from EBGP peers to other IBGP peers.
This is correct. When an IBGP router receives a route from an EBGP peer, it advertises that route to all other IBGP peers within the same autonomous system (AS). This is the fundamental method for distributing external routing information throughout the AS. However, note that IBGP does not readvertise routes learned from another IBGP peer to other IBGP peers (to prevent routing loops). This is the "IBGP split horizon" rule.

D. EBGP peers advertise routes received from IBGP peers to other EBGP peers.
This is also correct. When an EBGP router receives a route from an IBGP peer (i.e., a route learned internally within the AS), it advertises that route to its EBGP neighbors in different autonomous systems. This allows external ISPs to learn about routes originated inside or transiting your AS. This is standard EBGP behavior.

Why other options are wrong:

A. IBGP updates the next-hop attribute to ensure reachability within an AS.
Incorrect. IBGP does not change the next-hop attribute by default. When an EBGP route is learned, the next-hop attribute is set to the IP address of the external neighbor. When that route is advertised via IBGP, the next-hop attribute remains unchanged. To ensure reachability within the AS, you typically need an interior gateway protocol (IGP) that has a route to that next-hop address, or you must configure next-hop self on IBGP peers. IBGP itself does not "update" the next-hop.

C. IBGP peers advertise routes received from IBGP peers to other IBGP peers.
Incorrect. This violates the IBGP split horizon rule. To prevent routing loops inside the AS, a router does not advertise an IBGP-learned route to another IBGP peer. All IBGP routers must be fully meshed (or use route reflectors or confederations) so each IBGP router receives routes directly from an EBGP router or a route reflector. Option C describes behavior that is explicitly disabled in BGP.

References:
Juniper TechLibrary: “BGP Route Advertisement Rules” – “EBGP learned routes are advertised to all IBGP and EBGP peers. IBGP learned routes are advertised only to EBGP peers, not to other IBGP peers (split horizon).”

JNCIS‑ENT Study Guide (BGP chapter) – “IBGP does not change next hop by default; IBGP split horizon prevents advertising IBGP routes to other IBGP peers.”

Explanation:

In IS-IS, each router is configured with a Network Entity Title (NET). The NET has three parts:

Area ID (variable length, 1–13 bytes)
System ID (6 bytes, or 12 hexadecimal digits)
SEL (1 byte, always 00 for routing)
The given NET for the existing Level 1 router is 49.0011.1111.2222.3333.00.
49 is the AFI (Authority and Format Identifier), not the area ID.
0011 is the area ID.
1111.2222.3333 is the system ID.
00 is the SEL.

For two routers to form a Level 1 adjacency, they must be in the same area, meaning their area IDs must match exactly. Therefore, the new router must use the area ID 0011.

Why other options are wrong:

A. 00 – Incorrect. This is the SEL (selector), used to identify OSI endpoints, not the area ID.

B. 49 – Incorrect. This is the AFI, indicating private intra‑domain routing. Routers can share AFI 49 but still be in different areas (e.g., 49.0011 vs 49.0022). The AFI alone is insufficient for Level 1 adjacency.

D. 3333 – Incorrect. This is part of the system ID (3333 is the last two bytes of the 6‑byte system ID). System IDs must be unique per router; matching this does not place routers in the same area.

References:

Juniper TechLibrary:“Understanding IS‑IS Network Entity Titles (NETs)” – “A Level 1 adjacency requires that the area IDs of the two routers match exactly. The area ID is the portion of the NET following the AFI (usually 49) and preceding the system ID.”

JNCIS‑ENT Study Guide (IS‑IS chapter) – “The NET format: AFI.areaID.systemID.SEL. For Level 1 routing, area IDs must be identical; system IDs must be unique.”

Explanation:

You need a default route (0.0.0.0/0) advertised into OSPF that prefers ISP1 primarily, with ISP2 and ISP3 as backups only when ISP1 is unavailable. This requires a static default route with multiple next hops and different preference values (administrative distance). On Juniper devices, static routes support a primary next hop and one or more qualified next hops with adjusted preference values. Lower preference is more preferred. ISP1 should have the default preference (e.g., 5 for static routes) or an explicitly lower value, while ISP2 and ISP3 should have higher preference values (e.g., 6, 7), making them less preferred. The route is then redistributed into OSPF using set protocols ospf export policy.

Why this matches option A:

Option A states: "Create a default static route with ISP1's address as the next hop while specifying the addresses for ISP2 and ISP3 as qualified next hops with a preference value of six or higher." Assuming ISP1 uses default preference (5), ISP2/ISP3 with preference 6 or higher will be used only when ISP1's next hop is unreachable. This meets the requirement exactly.

Why other options are wrong:

B. Create a default generate route that includes an import policy to match BGP routes from ISP1 and assign a preference value of four or less.
Incorrect. Generate routes are used to create aggregate-like routes based on contributing routes. Import policy filtering BGP routes does not directly control backup next hops for a single default route. Preference 4 is lower than static default (5), but this approach overcomplicates and does not clearly provide primary/backup behavior on a per‑next‑hop basis.

C. Create a default static route with each neighbor address as the next hop.
Incorrect. Without qualified next hops and different preference values, Juniper will perform equal‑cost multi‑path (ECMP) load balancing across all three next hops. This does not ensure ISP1 is always preferred when available.

D. Create a default aggregated route.
Incorrect. Aggregate routes are used to summarize specific prefixes, not to create a default route with primary/backup next hops. Aggregates do not forward traffic unless more specific contributing routes exist.

Reference:

Juniper TechLibrary: "Static Routes with Qualified Next Hops" – "Qualified next hops allow you to specify different preference values for backup paths. The route with the lowest preference is used when available."

JNCIS‑ENT Study Guide (Routing Policy & Static Routes)– "Set a primary static route (preference 5) and qualified next hops with higher preferences for failover."

Explanation:

B. If the active link fails, then the secondary link automatically takes over.
This is correct. When the active link in a redundant trunk group (RTG) fails, the secondary link immediately begins forwarding data traffic without waiting for Spanning Tree Protocol (STP) convergence, minimizing network downtime . This failover is automatic and does not require manual intervention.

C. Layer 2 control traffic is permitted on the secondary link.
This is correct. While data traffic is blocked on the secondary link, Layer 2 control traffic (such as LLDP) is still permitted to pass . This allows monitoring and management protocols to function even on the standby link, which is a key design feature of RTGs.

Why other options are wrong:

A. Redundant trunk groups load-balance traffic across two designated uplink interfaces.
Incorrect. RTGs do not perform load balancing. Data traffic is forwarded only on the active link; the secondary link remains in standby mode, blocking data traffic . This is an active/standby redundancy mechanism, not an active/active load-balancing solution.

D. Redundant trunk groups must be connected to the same aggregation switch.
Incorrect. RTGs are designed specifically for connecting an access switch to two different distribution or aggregation switches for redundancy . The example topology shows Switch 3 (access) connected to Switch 1 and Switch 2 (two separate distribution switches) . This provides device-level redundancy, which would be defeated if both links went to the same switch.

References:

Juniper TechLibrary: "Understanding Redundant Trunk Links on EX Series Switches" – "If the active link fails, the secondary link automatically starts forwarding data traffic without waiting for normal STP convergence. While data traffic is blocked on the secondary link, Layer 2 control traffic is still permitted"

Explanation:

B. Tunnel endpoints must have a valid route to the remote tunnel endpoint.
This is correct. For any tunnel (GRE, IP-IP, MPLS, etc.), the local endpoint must have a route to the destination IP address of the remote tunnel endpoint. This route is typically through the underlying physical network. Without this, the encapsulated packets cannot be delivered to the remote peer, and the tunnel interface cannot transition to the Up state.

D. Tunnels add additional overhead to packet size.
This is correct. Tunneling encapsulates the original packet inside a new outer header (e.g., GRE adds 4 bytes; IP-IP adds 20 bytes; GRE over IPv4 adds 24 bytes total). Each tunnel type has its own encapsulation overhead. This added overhead increases the overall packet size, which can cause fragmentation if the resulting frame exceeds the MTU of the physical interface. To compensate, tunnel MTU is often reduced.

Why other options are wrong:

A. BFD cannot be used to monitor tunnels.
Incorrect. BFD (Bidirectional Forwarding Detection) can be and frequently is used to monitor tunnels. Many tunnel types, including GRE and IP-IP, support BFD over the tunnel interface. BFD provides rapid failure detection, faster than standard protocol timers (e.g., GRE keepalives or routing protocol hellos). This is a common design for high‑availability networks. Juniper devices support BFD over GRE and IP-IP tunnels.

C. IP-IP tunnels are stateful.
Incorrect. IP-IP tunnels (RFC 2003) are stateless. They simply encapsulate an IPv4 packet inside another IPv4 header with protocol 4. No state information is maintained about the tunnel session, no sequence numbers, no flow control, and no retransmission. The tunnel interface is Up as long as the endpoint IPs are reachable. In contrast, stateful tunnels (e.g., IPsec in tunnel mode with certain features) maintain security association state. IP-IP is purely stateless.

References:

Juniper TechLibrary: “Tunnel Overview” – “The tunnel source and destination addresses must be routable in the underlying network. All tunnels add encapsulation overhead.”

Juniper TechLibrary: “BFD for GRE Tunnels” – “BFD can be configured over GRE tunnels to provide fast failure detection.”

Explanation:

B. FBF uses the forwarding routing instance type.
This is correct. Filter‑Based Forwarding (FBF) is Juniper's equivalent to Policy‑Based Routing (PBR) on other platforms . To implement FBF, you create a routing instance with instance-type forwarding . This type creates a separate routing table (e.g., instance-name.inet.0) but does not require interfaces to be bound to it. Instead, interfaces remain in the default instance (inet.0), and a firewall filter redirects selected traffic to the forwarding routing instance for path selection . This is precisely what you need for source‑based load balancing between two ISPs.

C. RIB groups are used to copy routes from the inet.0 routing table.
This is correct. RIB (Routing Information Base) groups allow you to share routes between different routing tables . In an FBF scenario where you create a forwarding routing instance (e.g., ISP-A.inet.0), that instance initially has no routes. To make it functional, you need to copy the necessary routes (default routes, ISP routes) from the main routing table inet.0 into the instance's table. This is accomplished by configuring a RIB group that specifies export-rib inet.0 and import-rib [ inet.0 instance-name.inet.0 ] . The export-rib statement defines the source table from which routes are advertised .

Why other options are wrong:

A. FBF uses the no-forwarding routing instance type.
Incorrect. The no-forwarding instance type creates a separate routing table in the control plane but does not create a corresponding forwarding table in the Packet Forwarding Engine (PFE) . As confirmed by Juniper community experts, "FBF into that instance does not work by design" because there is no hardware forwarding entry for the redirected traffic to use . The no-forwarding type is useful for running multiple routing protocol instances without traffic separation, but it cannot support FBF .

D. RIB groups are used to hide routes in the inet.0 routing table.
Incorrect. RIB groups are used to copy, share, or import routes between tables — not to hide them . The export-rib statement specifies the source table for route advertisement, while import-rib specifies destination tables . Hiding routes is not a function of RIB groups; route filtering and hiding are performed using routing policies and firewall filters.

References:

Juniper CLI Explorer: "instance-type forwarding" – "Provide support for filter‑based forwarding, where interfaces are not associated with instances"

Juniper Community: "FBF and routing-instance no-forward" – "no-forwarding does not have a corresponding forwarding table, hence FBF does not work by design"

Explanation:

For a static route to be successfully redistributed into BGP (or any dynamic routing protocol), the route must first be active in the routing table. A route is marked as active only if its next hop is valid and recursively resolvable through other active routes in the table.

Why Other Options Are Incorrect

B. The as-path parameter must be specified.
— Incorrect. The AS path attribute is automatically added by BGP when a route is advertised. You do not need to manually specify an AS path for static routes to be redistributed into BGP.

C. A community string must be configured.
— Incorrect. BGP communities are optional transitive attributes used for tagging and policy application. They are never a requirement for redistributing static routes into BGP.

D. The no-readvertise feature is specified.
— Incorrect. The no-readvertise parameter is a specific static route option that prevents a route from being exported from the routing table into any dynamic routing protocol. If no-readvertise were configured, the static routes would still appear in show route (as they do in the exhibit), but the export policy would not be able to readvertise them. However, the question asks what causes the static routes to not show as BGP routes after attempting redistribution. While no-readvertise is a valid reason, it is not the most correct answer here because:

The question implies a general troubleshooting scenario rather than a specific misconfiguration
The exhibit shows a routing table without indicating no-readvertise is configured
With static route redistribution, the first and most common issue to verify is next-hop validity

References

Juniper TechLibrary: "Static routes are eligible to be readvertised... To mark an IPv4 static route as being ineligible for readvertisement, include the no-readvertise statement"

Pupuweb (JN0-351 exam discussion): "For successful redistribution of static routes into BGP, the static routes must have a valid next hop"