Juniper Service Provider Routing and Switching Specialist (JNCIS-SP) (JN0-364)

✅ Option C (Correct)

An import policy is the correct mechanism to control which routes, including external routes learned via IS-IS, are accepted and installed into the routing table. When configured under the IS-IS protocol, an import policy filters routes that IS-IS has learned and is attempting to install into the Juniper device's main routing information base (RIB).

❌ Why the other choices are incorrect:

• Option A is incorrect: An export policy controls which routes are advertised out of a routing protocol (e.g., from IS-IS to its neighbors, or from the routing table into IS-IS for advertisement) or redistributed to another protocol. It does not control which routes are installed into the routing table.
• Option B is incorrect: Route preference (also known as administrative distance) is a numerical value used to determine the trustworthiness of a route source. If a router learns about the same destination from multiple routing protocols, the route with the lower preference value is preferred. While it influences the best path selection, it is not a policy mechanism to filter specific routes from being installed based on criteria other than their source protocol's default or configured preference.
• Option D is incorrect: An interface metric is a cost value assigned to a link, which IS-IS uses to calculate the shortest path to a destination within its routing domain. Metrics influence IS-IS's internal path selection but are not a policy tool to filter which routes are installed in the global routing table.

During OSPF neighbor establishment, after the two-way state is reached, routers transition to the ExStart and Exchange states. In these states, Database Description (DBD) packets are exchanged. DBD packets contain a summary of the originating router's link-state database, allowing neighbors to identify which Link State Advertisements (LSAs) they might be missing or have outdated versions of. This process ensures synchronization of the link-state databases between adjacent routers.

Reference: https://www.juniper.net/documentation/us/en/software/junos/ospf/topics/topic-map/ospf-overview.html

Official explanation included in the full bundle.

In IS‑IS, interfaces can participate in Level 1 (intra‑area) and Level 2 (inter‑area/backbone) adjacencies.

When an interface is configured to run both Level 1 and Level 2, Junos displays this as Level 3.

This shorthand means the interface is active in both LSDBs (Level 1 and Level 2).

In the exhibit, the interface is specifically configured as point‑to‑point, so Junos shows it as Level 3.

By default, IS-IS in Junos OS does not export routes from the routing table into its Link-State Packet (LSP) advertisements. This means that routes originating from other protocols (such as OSPF or BGP), static routes, or direct routes for interfaces not explicitly configured under the [edit protocols isis] hierarchy, are not automatically redistributed into IS-IS. Only the interfaces explicitly enabled for IS-IS and routes learned natively from other IS-IS neighbors within its area/level are advertised. To advertise other types of routes into IS-IS, an explicit export policy must be configured. Hence, it exports nothing beyond its intrinsic protocol operations without specific policy configuration.

Reference: https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/topic-map-junos-os-routing-policies-firewall-filters-and-traffic-policers-overview.html

Let's analyze the provided options against default BGP advertisement rules:

• B: IBGP peers do not advertise routes received from IBGP peers to other IBGP peers. This is a fundamental BGP rule known as IBGP split-horizon. It prevents routing loops within an Autonomous System (AS). Therefore, this option is correct.
• C: EBGP peers advertise routes learned from IBGP or EBGP peers to other EBGP peers. An EBGP router will advertise routes learned from its IBGP peers or from other EBGP peers to its EBGP neighbors. This allows routes to be propagated between different ASes. Therefore, this option is correct.
• D: IBGP peers advertise routes received from EBGP peers to other IBGP peers. This is necessary for external routes (learned from EBGP) to be distributed throughout the internal network (IBGP peers) of an AS. Therefore, this option is correct.

The incorrect options are:

• A: IBGP peers do not advertise routes received from EBGP peers to other IBGP peers. This is incorrect. IBGP peers *do* advertise routes received from EBGP peers to other IBGP peers to ensure reachability of external networks within the AS.
• E: IBGP peers advertise routes received from IBGP peers to other IBGP peers. This is incorrect and directly contradicts the IBGP split-horizon rule (Option B).

✅ Option B (Correct)
Reasoning: The IPv6 routing extension header is specifically designed to allow a source node to specify a list of one or more intermediate nodes (routers) that an IPv6 packet must visit on its path to the destination. This mechanism is known as source routing and directly addresses the requirement of specifying intermediate nodes for a packet's path.

❌ Why the other choices are incorrect:

• Option A is incorrect: The hop-by-hop options header carries optional information that must be examined by every hop along a packet's delivery path. It is not used to specify the intermediate nodes defining the path itself.
• Option C is incorrect: The destination options header carries optional information that is examined only by a packet's ultimate destination node, or by an intermediate destination if a routing header is present. It does not define intermediate nodes for the packet's route.
• Option D is incorrect: The fragment header is used when an IPv6 packet is larger than the Path MTU and must be fragmented. It contains information required for reassembling the fragmented packet at the destination and has no role in specifying intermediate nodes for the path.

IPv6 uses extension headers to provide optional internet-layer information. These headers are placed between the main IPv6 header and the upper-layer protocol header. Unlike IPv4, which often includes options directly in the main header, IPv6 streamlines the main header and uses a chain of zero or more extension headers.

• B: Hop-by-Hop Options Header: Used to carry optional information that must be examined by every node along a packet's delivery path.
• D: Destination Options Header: Used to carry optional information that is examined only by the packet's destination node(s).
• E: Fragment Header: Used by a source host to send a packet that is too large to fit in the path MTU to its destination. This header contains information needed for reassembly.

A: Protocol is a field within the IPv6 header (Next Header field), not an extension header itself. It indicates the type of the next header following the current one.C: Header checksum is present in IPv4 headers but is explicitly removed from the IPv6 header to improve performance and simplify router processing. IPv6 relies on upper-layer protocols for error detection and link-layer checksums.

Official explanation included in the full bundle.

A BGP session stuck in the Idle state typically indicates that the underlying TCP connection on port 179 cannot be established. The Idle state is the initial state where the BGP process is waiting for a BGP Start event, which is triggered by a successful TCP connection. If the peer IP address is incorrect, the router attempts to initiate a TCP connection to the wrong destination or an unroutable address. This prevents the TCP 3-way handshake from completing, and consequently, the BGP session cannot progress beyond the Idle state. This is a very common reason for BGP session establishment failure.

• A: The BGP hold time is too short. The BGP hold time is negotiated during the OpenSent/OpenConfirm states and is relevant after the session is established. It dictates how long a router waits for a keepalive or update message before declaring the neighbor down. This would not prevent the initial TCP connection from forming or cause the session to be stuck in Idle.
• B: The BGP group type is set to internal instead of external. While an incorrect group type can cause BGP routing issues or even prevent session establishment under certain circumstances (e.g., eBGP peer in the same AS), it typically doesn't prevent the initial TCP connection. Issues related to group type often manifest in later states or with routing policies.
• C: The local AS number is missing. A missing local AS number (e.g., the autonomous-system statement under [edit routing-options]) is a fundamental BGP configuration error. Without knowing its own AS, the BGP process cannot properly initialize or form valid BGP Open messages. This would indeed prevent the session from coming up and keep it in Idle. However, an incorrect peer IP address (D) is a more direct cause for the failure of the TCP connection attempt itself, which is the immediate prerequisite to moving out of Idle. In many troubleshooting scenarios, incorrect peer IP or reachability is the primary check for Idle state issues. Both C and D are strong contenders, but D directly addresses the TCP connection failure that keeps BGP in Idle.