Free Juniper JN0-352 Practice Exam with Questions & Answers

Junos firewall filters evaluate terms sequentially from top to bottom, and a term is only terminal for a packet if its then clause contains an explicit terminating action such as accept, discard, reject, or next term without a match. The count and log actions used in track-icmp are non-terminating; they update statistics and generate a log entry but do not stop evaluation, so a matching ICMP packet falls through to the next term after being counted. The second term, allow-tcp-established, matches only TCP packets carrying the ACK or RST flags as defined by the tcp-established keyword; an ICMP echo request does not satisfy protocol tcp, so this term is skipped entirely and does not accept the packet. Evaluation therefore reaches the implicit catch-all term block-rest, which has no from conditions and matches every remaining packet, incrementing blocked-counter and discarding it. The net effect for the described ICMP ping is that icmp-counter is incremented by the first term, the packet is neither accepted nor rejected by the second term, and blocked-counter is incremented immediately before the packet is silently discarded by the final term. This layered-term behavior, where counting is independent of the accept/discard decision, is a frequently tested nuance of Junos firewall filter processing logic. Reference topics: Junos Enterprise Switching – Layer 2 Security and Firewall Filters, Filter Term Evaluation Order.

The diagnostic output explicitly states the root cause: the local router has only the inet6-unicast address family configured for this peer, while the remote router advertised inet-unicast and inet-vpn-unicast in its OPEN message, and BGP requires at least one common negotiated address family (NLRI type) between two peers for a session to remain established; with zero overlap between the two sides' configured families, the session is torn down immediately after the OPEN exchange, which is precisely why the peer state shows Active rather than Established. This confirms the mismatched-address-family statement directly and unambiguously from the exhibit's own Down reason and Detail reason fields. The diagnostic tool's own embedded Suggestion text goes further, explicitly advising the administrator to additionally verify that the local-address configured for the peer matches the remote router's configured neighbor address and vice versa — a secondary, commonly encountered condition in which mismatched or effectively duplicated/incorrect address bindings between the two sides' neighbor statements can independently prevent a session from completing correctly, even once the family mismatch is resolved. This is why address-configuration consistency between the peers is flagged as a second concern worth checking in this scenario. Nothing in the exhibit references NTP or time synchronization at all, nor does anything in the output reference authentication, an MD5 mismatch, or any related failure signature; both of those conditions would present through entirely different diagnostic messages than the one shown here. Reference topics: Junos Enterprise Routing – BGP, Address Family Negotiation and the show bgp diagnostics neighbor Command.

A BGP NOTIFICATION message is one of the four core message types defined in RFC 4271, alongside OPEN, UPDATE, and KEEPALIVE, and it serves a very specific and narrow purpose within the protocol: whenever a BGP speaker detects an unrecoverable, fatal condition in the session — such as a malformed OPEN message, an unsupported capability, a hold-timer expiration, a finite-state-machine error, or an administratively initiated reset — it transmits a NOTIFICATION message to its peer immediately before closing the underlying TCP connection and tearing down the session entirely. This confirms that a NOTIFICATION always signals the termination of the session upon a fatal error, never a routine, in-session update. Structurally, every NOTIFICATION message carries a defined error code and error subcode field, which together precisely classify the category and specific nature of the fault that triggered the termination (for example, 'Cease' with a subcode indicating administrative shutdown, or 'Update Message Error' with a subcode indicating a malformed attribute), giving the receiving peer's administrator concrete diagnostic information about exactly why the session was torn down. Updating route attributes while keeping a session alive is the role of the UPDATE message, not NOTIFICATION, and refreshing a neighbor's table without resetting the session describes the optional Route Refresh capability (a separate, distinct BGP mechanism), neither of which describes NOTIFICATION's function. Reference topics: Junos Enterprise Routing – BGP, BGP Message Types and the NOTIFICATION Message.

Each of the 24 end-device-facing interfaces in this scenario needs to carry traffic for exactly one VLAN, and the end devices themselves are ordinary hosts that neither expect nor generate 802.1Q-tagged frames. This is precisely the definition of an access port in Junos: family ethernet-switching interface-mode is set to access, and a single vlan members statement assigns the port to VLAN 70. Access mode ensures frames egressing toward the host are untagged and any frames received are implicitly treated as belonging to the configured VLAN, which is both simpler to manage and more efficient than trunking, since access ports do not carry the 802.1Q tag overhead nor process VLAN pruning logic relevant only to multi-VLAN links. Trunk mode, by contrast, is reserved for switch-to-switch or switch-to-router links that must simultaneously carry frames for multiple VLANs, such as the uplink toward the distribution switch that transports VLANs 30, 50, and 70 together — configuring the 24 host-facing ports as trunks (with or without a native VLAN) would be functionally incorrect and operationally wasteful, since end devices have no need to interpret VLAN tags. There is also no such behavior in Junos where VLAN-ID numeric value dictates default port behavior, making the 'no configuration needed' option a distractor with no basis in EX Series switching architecture. Reference topics: Junos Enterprise Switching – VLANs, Configuring Access and Trunk Port Modes.

MACsec (IEEE 802.1AE) secures a point-to-point Ethernet link independently of how the logical unit above it is configured for VLAN tagging, so neither trunk mode nor access mode has any bearing on whether the MACsec Key Agreement (MKA) protocol can establish a secure channel. What does determine success is the pre-shared key material: when static CAK security mode is used, the Connectivity Association Key (CAK) and the Connectivity Association Key Name (CKN) must be configured identically on both ends of the link. If they do not match, MKA never completes the exchange, no secure channel is created, and all traffic on that interface is dropped rather than merely left unencrypted. Equally important, and frequently overlooked, is that MACsec adds up to 32 bytes of overhead per frame for the security tag (SecTAG) and integrity check value (ICV); Juniper's official guidance is to ensure the difference between the interface's physical MTU and the protocol MTU is large enough to absorb this overhead, or frames will be silently discarded once encryption is active, producing symptoms that look identical to a failed session. Both the CAK/CKN and MTU checks are documented first-line troubleshooting steps for MACsec on EX Series switches. Reference topics: Junos Enterprise Switching – Layer 2 Security, Configuring and Troubleshooting MACsec on EX Series Switches.

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.

IEEE 802.3ad LACP defines two distinct negotiation modes, active and passive, and the standard's fundamental requirement for successful negotiation is that at least one end of the point-to-point link must be configured in active mode; an actively configured device initiates LACPDU transmission on its own, while a passively configured device waits and only responds once it receives an LACPDU from its peer. If both ends of the bundle were left in passive mode simultaneously, neither side would ever initiate the exchange, and no negotiation — and therefore no functioning aggregated bundle — would ever occur; at least one active participant is therefore mandatory, though having both sides active (active-active) is also fully valid and is in fact the most common production deployment. Junos does not enable LACP automatically on aggregated Ethernet interfaces; unlike some competing platforms, LACP must be explicitly configured under the aggregated-ether-options lacp hierarchy, and specifying no LACP configuration at all results in a 'static' LAG that relies purely on physical link-state rather than any protocol negotiation — there is no implicit default active mode. There is likewise no requirement to configure differing LACP system priority values between the two peer switches; system priority is used only to determine which side of the link controls port selection during negotiation and has no bearing on whether the bundle can form. Both sides being mandatorily active is a stricter requirement than the actual standard specifies. Reference topics: Junos Enterprise Switching – Link Aggregation, LACP Active and Passive Mode Negotiation.

A GRE-encapsulated packet consists of the original passenger packet wrapped inside a GRE header and a new outer IP delivery header, and the combined size of these two additions is what constitutes GRE's per-packet overhead. The base GRE header, as defined in RFC 2784 and used in its minimal, non-keyed, non-checksummed form (the default and most common deployment), is exactly 4 bytes in length, containing the flags/version field and the protocol type field identifying the encapsulated payload's ether type. Layered around that GRE header is a completely new outer IPv4 header, which itself consumes a standard 20 bytes, containing the tunnel source and destination addresses used for delivery across the underlying network. Adding these two components together — 4 bytes for the GRE header plus 20 bytes for the new outer IPv4 header — yields a total of exactly 24 bytes of overhead imposed on every encapsulated packet, which is precisely why Junos automatically sets the default protocol MTU on gr- tunnel interfaces to 1476 bytes (1500 minus 24) to prevent oversized, post-encapsulation packets from requiring fragmentation on a standard 1500-byte Ethernet path. The 20-byte figure alone describes only the new IP header in isolation and omits the GRE header itself, while 12 and 32 bytes do not correspond to any standard, non-keyed GRE encapsulation configuration and are included purely as plausible-looking distractors. Reference topics: Junos Enterprise Routing – Tunneling, GRE Header Overhead and MTU Planning.

Root bridge election in Spanning Tree Protocol is governed entirely by the Bridge Identifier, an 8-byte value formed by concatenating the configured bridge priority (the higher-order, more significant portion of the comparison) with the switch's MAC address (used strictly as a tiebreaker when priorities are identical). Every participating switch compares Bridge IDs, and the switch advertising the numerically lowest Bridge ID is elected root. In this exhibit, the three switches have distinctly different priority values — EX-1 at the Junos/IEEE default of 32768, EX-2 at 8192, and EX-3 at 16384 — meaning the comparison is decided entirely at the priority stage and never needs to proceed to a MAC address tiebreak at all. Since 8192 is numerically the lowest of the three priority values, EX-2 is elected root bridge purely on the strength of its lower priority, regardless of what its MAC address happens to be. This is precisely why the correct answer cites priority rather than MAC address as the deciding factor: MAC address only becomes relevant as a tiebreaker in the specific case where two or more switches share an identical priority value, which is not the situation presented here. Understanding that priority is evaluated first and is independently sufficient to decide the outcome whenever it differs is a foundational and heavily tested Spanning Tree concept on the JNCIS-ENT exam. Reference topics: Junos Enterprise Switching – Spanning Tree Protocols, Bridge ID and Root Bridge Election.

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.