Free Juniper JN0-352 Practice Exam with Questions & Answers

The metric that OSPF assigns to a destination is visible from two complementary vantage points in Junos. The show route protocol ospf command displays the main routing table filtered to OSPF-learned prefixes, and each entry shows the computed cost alongside the next hop, exactly as it was installed after SPF calculation. The show ospf route command (which accepts filters such as intra-area, inter-area, and extern) presents the OSPF-specific routing table, organized by route type, and explicitly lists the metric column for every intra-area, inter-area, and external route the local router has calculated. Together these two commands give both the RIB-level and the protocol-level view of route cost. By contrast, show ospf database extensive dumps the raw link-state advertisements, where metrics appear only as link-level values buried inside Router or Network LSAs rather than as a resolved route cost, so it is not the direct tool for viewing a route's metric. show ospf interface reports interface operational state, area, and DR/BDR information but does not present a cost or metric field at all in its standard output. Candidates should be comfortable distinguishing the RIB-oriented and protocol-table-oriented verification commands, since JNCIS-ENT scenarios frequently test whether a candidate reaches for the correct show command layer during troubleshooting. Reference topics: Junos Enterprise Routing – OSPF Operation and Verification, Monitoring OSPF.

VLAN 5 and VLAN 7 are two entirely separate Layer 2 broadcast domains, each with its own distinct IP subnet, and devices in one VLAN can never reach devices in the other through switching alone — Layer 3 routing between the two subnets is mandatory for any inter-VLAN communication to occur, regardless of how the VLANs are configured at Layer 2. On a single EX Series switch, the correct and standard mechanism for enabling this routing without an external router is to create one integrated routing and bridging (IRB) logical interface for each VLAN, assign each IRB the appropriate gateway IP address for its respective subnet (192.168.5.1 for VLAN 5's irb.5 and 192.168.7.1 for VLAN 7's irb.7, for example), and ensure routing is active on the switch so that traffic arriving at one IRB's gateway address destined for the other VLAN's subnet is routed internally between the two IRB interfaces. Attempting to bind a single family inet interface with two distinct subnet addresses via secondary addressing conflates two separate broadcast domains onto one Layer 3 interface incorrectly and is not how VLAN routing is architected in Junos. Spanning tree exists purely to prevent Layer 2 loops and has no routing function whatsoever, so configuring it cannot enable inter-VLAN reachability. Placing both VLANs on a single trunk with Multiple VLAN Registration Protocol (MVRP) only automates VLAN membership propagation across trunk links; it does not provide any Layer 3 routing capability between the VLANs either. Reference topics: Junos Enterprise Switching – Routing VLANs, Configuring IRB Interfaces for Inter-VLAN Routing.

Local preference is a well-known, discretionary BGP path attribute carried exclusively in IBGP UPDATE messages, and Junos assigns every route a local preference value of 100 by default whenever a route is received without an explicit LOCAL_PREF value already attached, or when the attribute has not been otherwise modified through routing policy. This default of 100 becomes the implicit baseline against which any administrator-configured local preference adjustments are compared. Because higher local preference values are always preferred over lower ones during BGP best-path selection — and this evaluation happens before AS path length, origin, or MED are ever considered — network engineers commonly use local preference specifically to steer outbound traffic leaving the autonomous system toward a preferred exit peer or upstream provider, by assigning a higher local preference to routes learned from that preferred peer relative to routes learned from alternative peers, making the third statement correct as well. Local preference is explicitly excluded from advertisement to EBGP peers under the BGP specification; it is meaningful only within the boundaries of a single AS and is stripped before a route crosses an AS boundary outward, since a neighboring AS has no reason to trust or honor another organization's internal preference values. A local preference of 0 does not have any special 'drop' semantics in BGP — it is simply the lowest possible numeric preference value and is treated like any other value during comparison, not as a discard instruction. Reference topics: Junos Enterprise Routing – BGP, Local Preference Defaults and Outbound Traffic Engineering.

The show route advertising-protocol bgp command displays exactly what would be transmitted to a specific BGP neighbor after all configured export routing policy has already been evaluated and applied, meaning any prefixes shown in this output have successfully passed through the export policy chain — confirming the export routing policy has been processed. The command header explicitly states '7 destinations, 7 routes (7 active, ...)' and every listed prefix is preceded by an asterisk, Junos's standard marker for an active route, confirming all seven displayed routes are active in the local routing table. The routing table name shown, XYZ.inet.0, indicates these routes reside in a named routing instance called XYZ rather than the default master routing instance, whose table would instead be labeled simply inet.0; this rules out the statement claiming the routes belong to the default instance. The AS path column shows only the origin code 'I' (IGP) with no AS numbers prepended ahead of it, meaning the AS path is empty, which indicates these prefixes were originated locally within R1's own AS (through redistribution or local origination) rather than having been learned from and passed through an external AS, ruling out that statement as well. Finally, the Nexthop column explicitly shows 'Self' for every route rather than an actual peer or learned address, confirming R1 is rewriting the next-hop attribute to its own address before advertising — a deliberate next-hop-self policy action typically applied toward IBGP peers. Reference topics: Junos Enterprise Routing – BGP, Verifying Advertised Routes and Export Policy Effects.

Nonstop active routing's defining architectural feature is that the backup Routing Engine runs a fully live, active instance of the routing protocol daemon (rpd) in parallel with the primary Routing Engine's rpd instance, continuously, from the moment NSR and its prerequisite GRES are established — not merely at the instant a switchover begins. As protocol adjacencies form, routes are learned, and the RIB is updated on the primary Routing Engine, that same protocol and RIB state is mirrored in real time to the backup Routing Engine's rpd process through an internal synchronization mechanism, so the backup's protocol state remains a live, up-to-date replica of the primary's at essentially every moment during normal operation. When a switchover occurs, the backup Routing Engine simply assumes the primary role with protocol adjacencies, routing tables, and forwarding state already fully populated and current, allowing it to continue operating without re-establishing neighbor relationships or re-learning the network topology, which is what makes the switchover genuinely nonstop and invisible to neighboring routers. This is fundamentally different from graceful restart, where the restarting router must rebuild its state by requesting help from cooperating neighbors after the fact. The Packet Forwarding Engine plays no role in synchronizing protocol-layer information such as LSAs or BGP updates; that is strictly an rpd-to-rpd function coordinated through the Routing Engine synchronization infrastructure. Reference topics: Junos Enterprise Routing – High Availability, Nonstop Active Routing Architecture and rpd Synchronization.

Voice VLAN is the Junos feature specifically designed to allow a single access port to simultaneously handle two distinct traffic streams: untagged data traffic from a PC or workstation using the port's normal access VLAN, and separately tagged voice traffic generated by an IP telephone that is typically daisy-chained between the switch port and the connected PC. When voice VLAN is configured on an access interface, the switch instructs the attached IP phone (commonly via LLDP-MED) which VLAN ID to tag its voice traffic with, and the switch is then able to correctly classify and prioritize that tagged voice traffic into its designated voice VLAN while simultaneously continuing to treat any untagged frames arriving on that same physical port as belonging to the port's regular, untagged access VLAN — precisely satisfying the requirement to accept both tagged and untagged traffic together on one access port. Native VLAN, by contrast, is a trunk-port-only concept that designates which VLAN untagged frames on a trunk should be associated with; it has no applicability to an access port and does not enable simultaneous tagged traffic acceptance there. Default VLAN simply refers to the VLAN an interface belongs to absent other configuration and carries no dual-traffic capability. IRB interfaces provide Layer 3 gateway functionality for a VLAN and are unrelated to how tagged versus untagged frames are accepted at Layer 2 on a given physical port. Reference topics: Junos Enterprise Switching – VLANs, Configuring Voice VLAN on Access Interfaces.

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 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.

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.

This scenario describes end hosts — virtualization hosts running software switches or virtual bridging stacks — unexpectedly generating and transmitting BPDUs on ports that are supposed to be pure edge (host-facing) ports where no BPDUs should ever legitimately be received. BPDU protection (BPDU guard) is the Junos feature purpose-built for exactly this situation: when applied to an edge-designated interface, it continuously monitors that port for any incoming BPDU, and the moment one is detected, it immediately and automatically disables the port, preventing the unexpected BPDU source from ever participating in or influencing the spanning-tree topology calculation, thereby protecting the stable, intended topology from disruption caused by unauthorized or accidental BPDU generation at the access edge. This directly and precisely resolves the described problem at its source, since the root cause is illegitimate BPDUs arriving on ports that were never meant to see them. Increasing the max-age timer only adjusts how long stale topology information is retained before being aged out and has no effect on preventing rogue BPDUs from being processed in the first place. Disabling RSTP outright on access interfaces would eliminate spanning tree's loop-prevention protection on those ports entirely, introducing a much more severe risk of undetected Layer 2 loops. Root protection (root guard) defends specifically against a port attempting to become the root port by receiving a superior BPDU claiming a better path to root; it addresses a different threat model than blocking any BPDU outright on a true edge port. Reference topics: Junos Enterprise Switching – Spanning Tree Protocols, BPDU Protection on Edge Interfaces.