Important Juniper JN0-364 JNCIS-SP Exam Questions

Answer: A

Explanation:

In the BGP finite state machine, the Idle state is the 'stop' or 'start' point of the protocol. When a session is stuck in Idle, it means the BGP process is either administratively disabled or, more commonly, is unable to initiate the underlying TCP connection required for BGP.

According to Juniper Networks Service Provider documentation, the most common reason for a BGP session to remain in Idle is a lack of routing reachability. For BGP to move to the Connect state, the Junos kernel must have a route to the IP address specified in the neighbor statement. If the peer IP address is unreachable (Option A)---meaning there is no route in inet.0 (via OSPF, IS-IS, or static)---the router cannot initiate the TCP three-way handshake on port 179. Consequently, the state machine will never progress.

Analysis of incorrect options:

Option B: BGP does not care if the local AS is higher or lower than the peer's; it only cares if they match the configuration. AS numbers are identifiers, not priorities.

Option C: A mismatched Router ID does not prevent a session from leaving the Idle state. It would typically cause the session to reach the OpenConfirm state, and then fail with a 'Notification' message due to a collision or identification error.

Option D: While a mismatched group type (internal vs. external) will cause the session to fail, it usually fails during the Open message exchange (OpenSent state) because the AS numbers provided will not match the expected peer type (IBGP vs. EBGP).

Only the lack of a path to the neighbor (reachability) keeps the session at the very beginning of the process: the Idle state.

Answer: A

Explanation:

When troubleshooting OSPF in a service provider environment, distinguishing between 'stuck' adjacencies and 'flapping' adjacencies is the first step. A session that transitions frequently between Full and Down indicates that the relationship can be established successfully (meaning parameters match), but it cannot be maintained.

According to Juniper Networks documentation, the most common cause for a session to drop from Full to Down is the expiration of the Dead Interval. If a router does not receive a Hello packet within the Dead Interval (usually 40 seconds), it tears down the adjacency. A physical interface flapping (Option A) is the primary trigger for this. If the physical link or the underlying transport (like a leased line or a microwave link) goes down even momentarily, the OSPF process immediately detects the interface failure, flushes the neighbors, and moves the state to Down. As soon as the interface comes back up, the routers perform the Hello exchange and reach the Full state again, creating the flapping cycle.

Analysis of other options:

MTU Mismatch (Option D): This typically causes the adjacency to get 'stuck' in the Exchange or ExStart state. The routers can exchange small Hello packets, but when they try to send larger Database Description (DBD) packets that exceed the MTU, the packets are dropped, preventing the session from ever reaching 'Full.'

Area ID Mismatch (Option C): This prevents the adjacency from even reaching the Init state; the routers will never form a neighbor relationship.

Route Preference (Option B): This affects which route is chosen for the forwarding table but has no impact on the OSPF neighbor state machine itself.

Answer: B

Explanation:

In the IS-IS (Intermediate System to Intermediate System) protocol as implemented in Junos OS, routers can operate at two hierarchical levels: Level 1 (L1) for intra-area routing and Level 2 (L2) for inter-area backbone routing. By default, a Juniper router and its interfaces are configured to act as Level 1/2, meaning they will attempt to form adjacencies at both levels simultaneously.

According to Juniper Networks technical documentation, the show isis interface command provides a granular view of how the protocol is interacting with specific local links. In the provided exhibit, we must examine the L (Level) column and the DR (Designated Router) status columns to understand R1's operational state.

Level Configuration: Under the L column for both the physical interface ge-0/0/0.0 and the loopback lo0.0, the value is strictly 2. This indicates that these interfaces have been explicitly configured to operate only at Level 2.

Adjacency Capabilities: For the interface ge-0/0/0.0, the Level 1 DR field is marked as Disabled. This confirms that R1 is not participating in Level 1 operations on this link; it will not transmit Level 1 Hello PDUs, nor will it listen for them. Consequently, R1 is incapable of forming a Level 1 adjacency with R2 on this segment.

Metric Implications: The exhibit shows an L1/L2 Metric of 100/100. In Junos, 'narrow' metrics (the default) are limited to a maximum value of 63 per interface. A metric of 100 indicates that wide metrics (wide-metrics-only) have been enabled. Therefore, option A is incorrect because the router is using wide metrics.

Since the prompt states the adjacency is 'up,' and the interface is restricted to Level 2, we can conclude that R1 only forms a Level 2 adjacency with R2 (Option B). Even though an L1 metric of 100 is displayed in the table as a configured value, it is not actually 'advertised' in a Link-State PDU because the Level 1 protocol is disabled on that interface.

Answer: A, B, D

Explanation:

The Border Gateway Protocol (BGP) operates based on a strict set of advertisement rules designed to prevent routing loops while ensuring global reachability. These rules differ significantly depending on whether the relationship is External BGP (EBGP) or Internal BGP (IBGP).

1. EBGP Advertisement (Option A): In a standard EBGP scenario, a router acts as an exit/entry point for an Autonomous System. When an EBGP speaker receives a valid route from any peer (Internal or External), it will, by default, advertise that route to all of its other EBGP peers. This is the primary mechanism that allows prefixes to propagate across the global internet from one AS to another.

2. IBGP Split Horizon (Option D):

The most critical rule within an AS is the IBGP Split Horizon rule. To prevent loops within an AS, BGP dictates that a route learned from an IBGP peer must not be advertised to any other IBGP peer. This is why BGP requires a 'full mesh' of IBGP sessions or the use of Route Reflectors to ensure all internal routers learn all routes. Without this rule, a route could circulate infinitely within the AS because IBGP does not update the AS_PATH attribute.

3. EBGP to IBGP Propagation (Option B):

When a router learns a route from an EBGP peer, it is permitted to advertise that route to all of its IBGP peers. This ensures that everyone inside the network knows how to reach external destinations. However, it is important to remember that in Junos OS, the BGP Next Hop is not modified by default when sending routes to IBGP peers, often requiring a 'next-hop-self' policy to ensure internal reachability.

Options C and E are incorrect because they directly contradict these fundamental BGP loop-prevention and propagation mechanisms.

Answer: C

Explanation:

In the Junos OS, routing policy behavior is governed by default import and export rules that vary significantly between different protocols. For IS-IS (Intermediate System to Intermediate System), the default export policy is 'reject all.' This means that, by default, an IS-IS process will export nothing from the routing table into the IS-IS database.

According to Juniper Networks technical documentation, IS-IS automatically advertises its own direct interfaces that are configured under the [edit protocols isis] hierarchy. However, it does not automatically redistribute routes learned from other sources---such as Static routes, OSPF, or BGP---into the IS-IS domain. This is a safety mechanism designed to prevent accidental routing loops or the flooding of unnecessary prefixes into the link-state database (LSDB), which could impact the stability of the SPF (Shortest Path First) algorithm.

To move routes from the routing table (inet.0) into IS-IS, an administrator must explicitly create a routing policy and apply it as an export policy within the IS-IS configuration. For example:

Code snippet

set policy-options policy-statement REDIST-STATIC term 1 from protocol static

set policy-options policy-statement REDIST-STATIC term 1 then accept

set protocols isis export REDIST-STATIC

Without such a policy, the IS-IS LSPs (Link-State PDUs) will only contain information about the IS-IS enabled interfaces and the reachability of other IS-IS neighbors. This behavior contrasts with protocols like BGP, which has different default rules for exporting active BGP routes to EBGP peers. In the context of IS-IS in a Juniper environment, 'export nothing' is the standard operational baseline.