JN0-352 Sample Questions Answers

The BGP finite state machine defined in RFC 4271 progresses through Idle, Connect, Active, OpenSent, OpenConfirm, and finally Established. The Active state is entered either directly after Idle, when the local router begins retrying a TCP connection setup toward the configured peer, or after a previous Connect attempt has failed and the ConnectRetry timer has expired, prompting the router to keep trying to complete the underlying TCP three-way handshake. Seeing a peer parked in Active therefore means the local device has a fully valid neighbor configuration and is persistently attempting to reach the remote address on TCP port 179, but the handshake is not succeeding — common root causes include a firewall or ACL blocking TCP 179 between the two endpoints, an unreachable or incorrect peer IP address, the remote BGP process not running or not listening, or an asymmetric routing path preventing the SYN/ACK from returning. It does not indicate a misconfiguration on the local box in the sense of a missing statement (that would typically leave the session as Idle), nor does it indicate an established, functioning session exchanging UPDATE messages (that state is Established), and it is not a deliberately idle/disabled condition, which Junos reports plainly as Idle. Recognizing Active as 'trying to connect' rather than 'connected' is essential for correct BGP troubleshooting sequencing. Reference topics: Junos Enterprise Routing – BGP Fundamentals, BGP Finite State Machine and Session Verification.

In the output of show ospf database, Junos marks every self-originated link-state advertisement with an asterisk immediately preceding the LSA's link-state ID. A self-originated LSA is one that was created and flooded by the router on which the command is being executed, as opposed to an LSA that was received from and originated by a neighboring router elsewhere in the area. In this exhibit, the asterisked Router LSA has an ID of 10.101.100.0 and an Advertising Router value of the same 10.101.100.0, confirming that this particular Router LSA describes the local device's own links, area membership, and interface costs, and that the local router itself flooded this LSA into the area's link-state database. This distinction matters operationally because when troubleshooting OSPF topology or SPF calculation issues, engineers frequently need to isolate their own router's advertised state from the states advertised by every other router in the area; the asterisk provides an immediate, unambiguous visual cue for that separation without needing to cross-reference the router's own ID separately. It has no relationship to designated router or backup designated router status — DR/BDR roles are indicated elsewhere in interface-level output, not through the asterisk convention in the LSA database dump, and a router that is neither DR nor BDR still self-originates and flags its own Router LSA the same way. Reference topics: Junos Enterprise Routing – OSPF, Interpreting the OSPF Link-State Database.

When storm control on an EX Series switch is configured with an action of interface-shutdown (rather than the default of simply dropping excess traffic), exceeding the configured bandwidth threshold for broadcast, multicast, or unknown-unicast traffic causes Junos to administratively disable the offending interface to protect the rest of the switching fabric. Recovery from this condition can happen automatically if a recovery-timeout interval has been configured, but when immediate manual recovery is required, the operational command clear ethernet-switching recovery-timeout interface interface-name explicitly clears the storm-control-triggered violation and re-enables the port without waiting for the timer to expire. This command is purpose-built for this exact condition and is distinct from more general troubleshooting commands: clear ethernet-switching table purges the learned MAC address database and has no bearing on a storm-control-disabled port; clear interface statistics resets traffic counters for diagnostic baselining but does not touch administrative state; and clear log messages simply flushes the local system log buffer. Administrators should also verify the underlying cause of the storm — a switching loop, a misbehaving host, or a misconfigured device — before manually clearing the condition, since without addressing the root cause the port is likely to trip again. This command and workflow are commonly tested as part of the Layer 2 security and resiliency features on EX platforms. Reference topics: Junos Enterprise Switching – Storm Control and Port Security, Recovering Interfaces Disabled by Storm Control.

OSPF relies on two IANA-reserved multicast addresses to distribute its control-plane traffic across broadcast and NBMA network types, and Link State Update (LSU) packets, which carry the actual LSAs being flooded, are addressed to one or the other depending on the role of the sending router. The address 224.0.0.5, designated AllSPFRouters, is used when any OSPF router — including a router that is itself the Designated Router or Backup Designated Router — needs to flood an LSU to every OSPF-speaking router on the segment; this is the address used for Hello packets universally and for LSU flooding directed at the entire segment. The address 224.0.0.6, designated AllDRouters, is used specifically by non-DR, non-BDR routers (DROthers) when they need to send an LSU or other update destined for the DR and BDR only, since only the DR and BDR actually listen on this address; the DR then takes responsibility for reflooding that information to the rest of the segment using 224.0.0.5. This two-address design is central to how OSPF achieves flooding efficiency on multi-access networks by funneling updates through the DR rather than requiring full-mesh flooding among every router pair. The addresses 224.0.0.8 and 224.0.0.9 are not used by OSPF at all; 224.0.0.9 is in fact reserved for RIPv2 multicast updates, making it a plausible-looking but incorrect distractor. Reference topics: Junos Enterprise Routing – OSPF, Multicast Addressing for Hello and Link State Update Packets.

Nonstop active routing is specifically engineered to be completely transparent to the rest of the network: rather than relying on neighboring routers to preserve state during a Routing Engine switchover the way graceful restart does, NSR keeps a fully synchronized instance of the routing protocol process (rpd) running continuously on the backup Routing Engine, mirroring protocol adjacencies, the RIB, and session state in real time. Because neighbors never observe a session reset or restart signal during an NSR-driven switchover, there is no dependency on those neighbors supporting or enabling graceful restart extensions at all — this is the core architectural advantage that distinguishes NSR from GR and is precisely why the first and third answer choices are incorrect distractors. What NSR does require locally is Graceful Routing Engine Switchover (GRES) enabled first, since NSR is built as an extension on top of GRES and depends on it to synchronize kernel and interface state between the two Routing Engines before protocol-level synchronization can occur. Additionally, Juniper's official guidance mandates that both Routing Engines run the identical Junos OS software version; mismatched versions between the primary and backup Routing Engine can introduce incompatible internal data structures or feature behavior during state replication, jeopardizing the integrity of a switchover and is explicitly called out as a hard operational requirement rather than a mere best practice. Reference topics: Junos Enterprise Routing – High Availability, Nonstop Active Routing Requirements and GRES Dependency.

The intent of this filter is to match and discard traffic from one single, specific host MAC address, which requires the source-mac-address match condition to reference the complete, exact 48-bit address using an explicit /48 mask (or no mask at all, which Junos treats as an implicit full match) so that only that one precise address is matched. As configured, the term instead specifies a /40 mask on 00:12:34:56:00:07, meaning only the first 40 bits (the first five octets, 00:12:34:56:00) are actually significant to the match, while the sixth octet is effectively wildcarded across its full range; this produces an imprecise, overly broad match criterion rather than the single-host match the administrator intended, and is a common configuration mistake that undermines the predictability and correctness of MAC-based filtering. The lesson tested here is that source and destination MAC address match conditions in Junos firewall filters must be specified with the correct, deliberate, and explicit prefix length appropriate to the intended scope — typically /48 for a single exact host — rather than an arbitrary or miscalculated mask value. Firewall filters under family ethernet-switching are fully capable of matching on both source-mac-address and destination-mac-address, which rules out that option entirely. Layer 2 MAC-based filters function correctly on both access and trunk interface modes, so interface type is not a limiting factor here. There is no indication in the exhibit that the filter's application direction (input versus output) is reversed. Reference topics: Junos Enterprise Switching – Layer 2 Security, MAC Address Match Conditions and Prefix Length Precision.

The Backup Designated Router exists specifically to provide immediate failover redundancy for the Designated Router role on a multi-access broadcast or NBMA segment: the BDR maintains full adjacencies with every other router on the segment concurrently with the DR, precisely so that if the DR ever fails or is withdrawn, the BDR can be promoted directly to DR essentially instantaneously, without needing to wait through a fresh, full DR/BDR election process, and a new BDR election then takes place separately among the remaining DROther routers to fill the now-vacant backup role. This immediate promotion behavior confirms the first statement as correct. The Designated Router's other core responsibility on the segment is originating the Type 2 Network LSA, which describes the multi-access network itself as a pseudonode, listing every router attached to that segment; this LSA type exists specifically to avoid the full-mesh explosion of Router LSA adjacency listings that would otherwise be needed to describe a shared broadcast segment, and only the DR — never the BDR, and never any DROther — is responsible for generating and maintaining this particular LSA under normal, stable conditions, which confirms the third statement while directly ruling out the fourth. There is no such thing as the DR 'electing' an area border router; ABR status is instead a role a router acquires organically by having interfaces in more than one OSPF area, entirely independent of any DR/BDR election process on any individual segment. Reference topics: Junos Enterprise Routing – OSPF, DR/BDR Roles and Type 2 Network LSA Origination.

The described symptom — excessive packet drops specifically attributed to exceeding the MTU on a GRE tunnel carrying full-size video streaming traffic across default-MTU gigabit Ethernet interfaces — is a direct consequence of the 24 bytes of GRE encapsulation overhead pushing packets that were already at or near the standard 1500-byte Ethernet MTU past the physical interface's transmission limit once the outer GRE and IP headers are added. The most durable fix is to proactively increase the physical member interfaces' MTU beyond the 1500-byte default — to 1524 bytes or higher — which provides sufficient headroom to absorb the full GRE encapsulation overhead without ever causing the fully encapsulated packet to exceed the interface's transmission capability, allowing full-size 1500-byte payloads to pass through the tunnel intact and without fragmentation or drops. As a complementary measure, configuring the clear-dont-fragment-bit option on the tunnel or member interfaces instructs Junos to clear the DF (don't fragment) bit on oversized packets rather than dropping them outright when they do exceed the available MTU, allowing the Packet Forwarding Engine to fragment and later reassemble the traffic instead of silently discarding it, which directly addresses the reported packet loss even under transient conditions. Simply raising the MTU only to 1500 bytes fails to account for the 24-byte GRE overhead and would not resolve the underlying oversize condition. Routing the tunnel over a higher-bandwidth link addresses potential congestion but does nothing to correct an MTU-based packet-size violation, which is the root cause explicitly identified in this scenario. Reference topics: Junos Enterprise Routing – Tunneling, GRE MTU Sizing and Fragmentation Handling for High-Throughput Applications.

RFC 4271 defines the BGP finite state machine as a strict, ordered progression of six states that a session must move through to successfully establish. A newly configured or reset session always begins in Idle, where BGP initializes resources and refuses connections until the ConnectRetry timer fires. From Idle, the router transitions to Connect and attempts to establish the underlying TCP transport session to the configured peer address on port 179. If that TCP attempt does not immediately succeed, the session falls back to the Active state, where the router continues retrying the TCP connection in the background; once the TCP handshake finally completes (from either Connect or Active), the session advances to OpenSent, during which the router transmits its own BGP OPEN message advertising its AS number, hold time, BGP identifier, and capabilities. Upon receiving and validating a compatible OPEN message from the peer, the session moves to OpenConfirm, where both sides exchange KEEPALIVE messages to confirm the parameters negotiated in the OPEN exchange are mutually acceptable. Only after this confirmation does the session reach Established, the final state in which UPDATE messages carrying actual routing information begin to flow between the peers. Any deviation from this Idle → Connect → Active → OpenSent → OpenConfirm → Established ordering, as presented in the other answer choices, does not reflect the standardized BGP state machine. Reference topics: Junos Enterprise Routing – BGP, The BGP Finite State Machine.

Correctly blocking SSH traffic originating from a specific network requires matching three precise conditions simultaneously in the from clause: the traffic's source-address must equal the 192.168.10.0/24 network, since the requirement is to block traffic coming from that network rather than traffic destined to it; the protocol must be explicitly set to tcp, since SSH operates exclusively over TCP; and the destination-port must be set to 22, because an inbound SSH connection request is always directed at the well-known SSH listening port 22 on the receiving side, regardless of which ephemeral source port the initiating client happens to use. The first option satisfies all three conditions correctly and pairs them with a discard action, cleanly dropping matching traffic. The second option incorrectly substitutes destination-address for source-address, which would match traffic heading toward that /24 rather than traffic originating from it, inverting the intended match direction. The third option incorrectly uses source-port 22 instead of destination-port 22; since the SSH client's source port is a randomly assigned ephemeral value rather than a fixed 22, this term would almost never match real SSH session-initiation traffic. The fourth option relies on a service ssh match condition, which is not valid syntax within the standard Junos firewall filter grammar for family inet; there is no such application-based keyword available at that hierarchy, making the term invalid regardless of the reject action chosen. Reference topics: Junos Enterprise Switching – Firewall Filters, Matching on Address, Protocol, and Port Conditions.

This detailed adjacency output shows R3 maintaining four separate, fully Up adjacencies, evenly split between the two IS-IS levels. R1 and R2 are both formed at Level 1, confirming that R3 is directly adjacent to exactly two Level 1 neighbors within its local area, which validates that statement. R4 and R5 are both formed at Level 2, and Level 2 adjacencies are, by definition, part of the IS-IS backbone that interconnects areas; a router maintaining any Level 2 adjacency is by that fact participating in and connected to the Level 2 backbone, confirming R3's backbone connectivity as well. Every one of the four listed adjacencies explicitly shows 'Speaks: IP, IPv6' in its detail output, which is Junos's way of indicating that both the IPv4 and IPv6 address families have been successfully negotiated and are active over that circuit; this directly contradicts, rather than supports, the claim that IPv6 is disabled on these neighbors — if IPv6 were disabled, the Speaks field would list only IP. Regarding authentication, the output contains no field, flag, or indication whatsoever referencing authentication configuration or state for the R5 adjacency (or any adjacency); Junos would typically surface authentication-related information separately if it were configured and relevant, and its complete absence here means no basis exists in the exhibit to conclude authentication is required for that specific adjacency. Reference topics: Junos Enterprise Routing – IS-IS, Level 1 and Level 2 Adjacencies and Address Family Negotiation.

Switch A is already fixed as the root bridge in this topology (priority 0), so the outcome being engineered here is not about root bridge election at all, but about which of Switch C's two available paths toward that already-established root — the direct C-to-A link, or the indirect C-to-B-to-A path — RSTP selects as the lower-cost, primary path. RSTP's path-cost calculation for any non-root switch sums the port costs of every link along a candidate path to the root and always selects whichever candidate path has the lowest total accumulated cost as that switch's active root path, placing the corresponding local port into the forwarding root port role while any higher-cost alternative path is placed into a non-forwarding (alternate) role. To force Switch C to prefer routing through Switch B rather than connecting to Switch A directly, the administrator must make the direct C-to-A link's cost higher than the combined cost of the C-to-B link plus the B-to-A link added together, so that the indirect, two-hop path through Switch B mathematically totals to a lower cumulative cost than the single direct hop, causing RSTP's cost comparison to favor the indirect path as primary. Setting Switch B's priority (to either 1 or 0) is irrelevant here, since Switch B is not a root bridge candidate in this scenario and priority manipulation would only affect a root bridge election, not path cost preference between a fixed root and a downstream switch. Lowering the direct link's cost, the inverse of the correct answer, would instead reinforce the direct path rather than override it. Reference topics: Junos Enterprise Switching – Spanning Tree Protocols, RSTP Path Cost and Root Port Selection.

The Complete Sequence Number PDU (CSNP) is the IS-IS mechanism used to summarize the entire contents of a router's link-state database, listing the LSP ID, sequence number, checksum, and remaining lifetime for every LSP the sending router currently believes should exist in the database for that level. On broadcast (LAN) circuits, the elected Designated Intermediate System periodically transmits CSNPs to all routers on the segment as a database-synchronization mechanism; any receiving router compares the summarized list against its own local database, and any discrepancy — an LSP it is missing entirely, or one for which it holds an older sequence number — triggers a targeted request for the specific, updated LSP content. On point-to-point circuits, a single CSNP is exchanged once when the adjacency first comes up, serving the identical synchronization purpose without needing periodic repetition. The Partial Sequence Number PDU (PSNP), by contrast, is used to acknowledge receipt of specific LSPs or to explicitly request specific LSPs identified as missing or outdated after a CSNP comparison, making it a partial, targeted PDU rather than a complete database listing. The LSP itself is the PDU that actually carries the detailed topology and reachability information being advertised, rather than a database summary. The IS-IS Hello PDU (IIH) is used purely for neighbor discovery and adjacency maintenance and carries no link-state database summary information whatsoever. Reference topics: Junos Enterprise Routing – IS-IS, CSNP and Link-State Database Synchronization.

A floating static route is a backup static route that remains present in the configuration but stays inactive in the routing table under normal conditions, only becoming active if the primary, preferred route to the same destination is withdrawn or otherwise becomes unavailable. Junos determines which of several competing routes to the same prefix becomes active strictly by comparing each route's preference value (administrative distance), with the numerically lowest preference always winning; every routing protocol and static routes themselves carry a default preference (5 for standard static routes), and this value can be explicitly overridden per route using the preference statement under the static route's configuration. To create a floating static route, the administrator deliberately configures a preference value higher (that is, numerically worse, less preferred) than the preference of the primary route it is meant to back up — for example, a value higher than the 5 default of an ordinary static route, or higher than a dynamic protocol's preference such as OSPF's 10 — ensuring the floating route only becomes active once the more-preferred primary route disappears from the table entirely. This preference-based mechanism is the essential, defining configuration element of a floating static route. Priority is not a valid Junos static-route statement, next-hop simply defines where matching traffic is forwarded without controlling route selection behavior, and qualified-next-hop is a related but distinct mechanism used to assign a per-next-hop preference within a single multi-next-hop static route statement rather than between the standalone static route and its dynamic counterpart. Reference topics: Junos Enterprise Routing – Protocol Independent Routing, Configuring Floating Static Routes with Preference.

Layer 2 MAC learning on an EX Series switch, as on any standard Ethernet bridge, is a passive, frame-driven process rather than an active polling or query-based mechanism. Every time a frame arrives on any interface, the switch inspects the frame's source MAC address field and, if that address is not already present in the Ethernet switching (bridge) table for the associated VLAN, creates a new dynamic entry recording the source MAC address, the VLAN it was learned on, and the specific ingress interface through which the frame arrived. Junos also stamps each learned entry with an aging timestamp, which is refreshed every time a subsequent frame from that same source MAC is received; entries that receive no refreshing traffic within the configured MAC aging interval (300 seconds by default) are eventually purged from the table to keep it current and to reclaim table space from hosts that have moved or gone offline. This source-address-driven, per-frame learning process happens continuously and automatically with no dependency on spanning-tree state changes — although a topology change notification can trigger accelerated aging of the table to flush potentially stale entries faster, learning itself is not gated by or contingent upon such an event occurring. The switch never learns addresses from the destination field of a frame, since the destination address, if already known, is used purely for the forwarding lookup decision, not for populating new table entries. Reference topics: Junos Enterprise Switching – Layer 2 Switching Fundamentals, Source MAC Learning and Table Aging.

Root protection (root guard) must always be applied on the ports of the switches you trust to remain root-bridge-eligible, specifically on the interfaces facing away from the legitimate root and toward parts of the network where an untrusted or rogue device could plausibly appear and begin transmitting superior BPDUs. In this topology, Switch-1 is the intended, permanent root bridge (lowest priority, 4k), and Switch-2 is its aggregation-layer peer; both sit above the access layer, where Switch-3 and Switch-4 connect downstream toward end-user-facing infrastructure and where an accidental or malicious rogue switch is realistically most likely to be introduced. The ge-0/0/6 and ge-0/0/8 interfaces on Switch-1 and Switch-2 are precisely the downlink ports facing that access layer, meaning they are the exact points at which a rogue switch's superior BPDU (one advertising a lower priority than the legitimate root) would first be received if such a device appeared beneath Switch-3 or Switch-4. Applying root protection on those specific interfaces causes Junos to immediately block (move to a root-inconsistent, discarding state) any port that receives a superior BPDU, preventing the rogue device from ever being accepted as root, while normal, non-superior BPDUs continue to be processed without disruption. Applying root guard on Switch-1 and Switch-2's peer link (ge-0/0/12/13) would be inappropriate, since that link legitimately connects two trusted, root-eligible switches. Reference topics: Junos Enterprise Switching – Spanning Tree Protocols, Root Protection Placement Strategy.