Free Juniper JN0-352 Practice Exam with Questions & Answers | Set: 2

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.

Configuring interface-type p2p under an OSPF interface tells Junos to treat that interface as a point-to-point network type regardless of the underlying physical medium, which removes the interface from the standard broadcast-network state machine entirely. On a true broadcast network, two routers must first complete a Designated Router and Backup Designated Router election, wait through the associated timers, and only then proceed through 2-Way, ExStart, Exchange, and Loading before reaching Full — a multi-step process. A point-to-point interface skips DR/BDR election altogether and proceeds directly from 2-Way into ExStart, so adjacencies form measurably faster, which is the first correct benefit. Because there is no DR on a point-to-point interface, Junos also does not generate a Type 2 Network LSA to describe the segment; the connected subnet is instead advertised as a simple stub-network entry inside the Router LSA itself, eliminating an entire LSA type from the area's link-state database and reducing its overall size, which is the second correct benefit. Point-to-point configuration is entirely incompatible with DR election, so a router configured this way cannot 'win' a DR election — there is no DR to win. Advertisement of the connected network happens on any operational OSPF interface irrespective of network type, so that option describes normal OSPF behavior rather than a benefit specific to the point-to-point setting. Reference topics: Junos Enterprise Routing – OSPF Network Types, Configuring OSPF Interface Type.

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.

OSPF's Designated Router election, as defined in RFC 2328 and implemented unchanged in Junos, is explicitly non-preemptive. Router priority is used only at the moment an election actually takes place — that is, when no DR or BDR currently exists on the segment. Once a DR and BDR have been elected and are functioning, a router with a numerically higher priority that joins the segment afterward does not trigger a new election and does not displace the incumbent DR or BDR, no matter how much higher its priority value is. In this scenario, R2 (priority 150) and R3 (priority 100) were already elected DR and BDR respectively while R1 was offline. When R1, whose priority of 200 would have made it the preferred DR had it been present during the original election, returns to the segment, it simply forms a full adjacency with the existing DR and BDR and takes on the DROther role like R4, without any re-election occurring. This design choice exists specifically to prevent unnecessary and disruptive Network LSA regeneration and adjacency churn every time a high-priority router reboots or rejoins a stable broadcast network. The only ways R1 could become DR going forward are if the current DR fails (promoting the BDR to DR and triggering a new BDR election) or if the entire segment's OSPF process is restarted, forcing a fresh election from a clean state. Reference topics: Junos Enterprise Routing – OSPF, Designated Router Election and Non-Preemption.

The 10.20.0.0/22 aggregate covers the four /24 blocks 10.20.0.0/24 through 10.20.3.0/24, but only the first three of those (10.20.0.0/24, 10.20.1.0/24, and 10.20.2.0/24) are configured and present as active contributing routes; 10.20.3.0/24, the block containing the destination address 10.20.3.100, has no corresponding contributing route in this configuration. Because no more-specific route exists for 10.20.3.100, the longest-match lookup falls through the missing /24 and matches only the broader /22 aggregate itself. By default, when Junos installs an aggregate route, it assigns that route a reject next hop rather than any usable forwarding next hop; this is a deliberate design choice so that traffic destined for gaps within an advertised summary block — gaps where no real, more-specific path actually exists — is not blindly forwarded toward whatever next hop happens to belong to one of the unrelated contributing routes. A reject next hop causes the router to drop the packet and generate and return an ICMP destination-unreachable message to the originating source, explicitly informing it that no path exists, which is functionally and behaviorally distinct from a silent discard next hop that would drop the packet without any such notification. Aggregate routes never adopt or forward through any single contributing route's next hop, which rules out the two forwarding-based answer choices entirely. Reference topics: Junos Enterprise Routing – Protocol Independent Routing, Default Reject Next Hop for Aggregate Routes.

By default, EBGP sessions are built with the expectation that peers are directly connected at Layer 3, and Junos enforces this by sending EBGP packets with a TTL of 1. When loopback addresses are used as the session endpoints instead of the directly connected physical interface addresses, the resulting IP packets must traverse at least one additional router hop between the two loopbacks, and a TTL of 1 will expire in transit before reaching the remote loopback, causing the TCP handshake — and therefore the BGP session — to fail even though a valid route to the peer's loopback exists. The multihop statement (configured as an EBGP multihop parameter with an accompanying TTL value, most commonly set to 2 for a single intermediate hop) instructs Junos to increase the TTL used for that peer's BGP packets so they survive the extra hop count between loopbacks. This is a mandatory addition any time an EBGP session is deliberately built against non-directly-connected addresses, whereas IBGP sessions, by contrast, do not have this default restriction because IBGP already assumes peers may be multiple hops apart within the same AS. Multipath affects load-balancing across equal-cost paths, damping suppresses flapping routes, and passive controls whether a router waits for the remote peer to initiate the TCP connection — none of these resolve the TTL expiration problem inherent to loopback-based EBGP peering. Reference topics: Junos Enterprise Routing – BGP, Configuring EBGP Multihop Sessions.

Because root bridge election is decided primarily by comparing bridge priority values — with the switch advertising the numerically lowest priority always winning, and MAC address serving only as a fallback tiebreaker when priorities are tied — the only deterministic, reliable way to guarantee that a specific switch is elected root regardless of any other switch's hardware characteristics is to explicitly configure that switch with a lower bridge priority than every other participating switch in the topology. Relying on MAC address alone, as the first distractor suggests, is fundamentally unreliable: MAC addresses are burned in at the factory, cannot be predicted or controlled by the administrator, and any future hardware replacement or newly introduced switch with a numerically lower MAC address could unexpectedly seize the root role since MAC comparison only comes into play at equal priority in the first place, meaning a 'highest MAC' strategy does not even align with how the tiebreak actually favors the lowest value. Port priority and port cost are entirely separate STP parameters that influence which port on a non-root switch is selected as its root port, or which port is selected as designated versus blocking on a given segment; neither parameter has any bearing whatsoever on which switch is elected root bridge for the whole topology, since that decision is made purely from the Bridge ID comparison, independent of any per-port settings. Explicitly and deliberately lowering Switch 1's configured bridge priority is the only correct, industry-standard method. Reference topics: Junos Enterprise Switching – Spanning Tree Protocols, Guaranteeing Root Bridge Placement via Bridge Priority.

The virtual-router routing-instance type in Junos is a general-purpose instance type intended for creating isolated, independent routing and forwarding contexts within a single physical device for applications that have nothing to do with MPLS-based VPN services — common use cases include multi-tenant network segmentation, filter-based forwarding deployments, and simple traffic isolation between departments or customers on a shared switch or router, all of which are non-VPN-related applications by nature. Layer 2 and Layer 3 VPN services, by contrast, rely on a different, dedicated routing-instance type specifically named vrf, which integrates with MPLS/BGP-based VPN signaling, route distinguishers, route targets, and PE-CE routing exchange; virtual-router instances do not participate in that VPN signaling framework at all, which is why the statement associating virtual-router with VPN use is incorrect. Whenever an administrator creates any user-configured routing instance — regardless of its specific type — Junos automatically allocates and generates a brand-new, dedicated routing table for that instance, named according to the pattern instance-name.inet.0 (or the appropriate address-family suffix), which is entirely separate from and independent of the default master inet.0 table used by the global/default routing context. Because each new routing instance receives its own distinct table rather than sharing or defaulting into the master inet.0 table, the statement claiming instances automatically fall back to using inet.0 unless configured otherwise is factually incorrect; instances are isolated by design from the outset. Reference topics: Junos Enterprise Routing – Protocol Independent Routing, Routing Instance Types and Table Allocation.

GRE is fundamentally a stateless encapsulation protocol: the encapsulating router simply wraps the passenger packet in a GRE header and an outer delivery IP header and forwards it based on ordinary IP routing table lookups toward the configured tunnel destination address. For that forwarding to succeed, the underlying (global or routing-instance) routing table on each endpoint must contain a valid, reachable route to the far-end tunnel address; without such a route, the tunnel interface will not come up or will be unable to deliver traffic, since GRE relies entirely on the existing IP infrastructure rather than any tunnel-specific signaling to establish reachability. Because GRE has no built-in state machine or session negotiation, it does not natively track whether the remote endpoint is alive — that requires an optional add-on such as GRE keepalives or BFD, neither of which is enabled by default; an operator must explicitly configure them if failure detection is required. GRE is also protocol-agnostic rather than IPv4-only: it can encapsulate IPv4, IPv6, MPLS, and other network-layer protocols as the passenger, which is one of its defining advantages over IP-in-IP tunneling. Finally, because GRE keeps no per-session state about the peer, it cannot detect or report tunnel failures on its own, reinforcing why route reachability is the one true prerequisite for tunnel operation. Reference topics: Junos Enterprise Routing – Tunneling, Understanding Generic Routing Encapsulation.