Juniper JN0-352 Dumps

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.

The factory-default storm control configuration on EX Series switches operates in a purely rate-limiting mode rather than an interface-shutdown mode. When broadcast, multicast, or unknown-unicast traffic on a port exceeds the configured bandwidth-percentage threshold, the default action is simply to police the offending traffic type and silently drop only the packets that exceed that threshold, while all traffic within the allowed rate continues to be forwarded normally and the interface itself remains administratively and operationally up throughout the event. This explains the observed symptom precisely: during the burst of unknown-unicast frames, the switch dropped the excess volume above the configured limit, producing a brief period of packet loss, but as soon as the burst subsided and traffic fell back under the threshold, storm control simply stopped dropping packets and normal forwarding resumed automatically — no administrative shutdown, recovery timer, or manual intervention was ever involved, because the interface was never taken down in the first place. This default drop-only behavior is distinct from the optional interface-shutdown action, which must be explicitly configured if an administrator wants storm control to disable a port outright on violation (as seen in a related scenario requiring the clear ethernet-switching recovery-timeout command). Storm control by default covers broadcast, multicast, and unknown-unicast traffic types together, not multicast alone, and it has no functional relationship to GRES, which governs Routing Engine redundancy rather than Layer 2 traffic policing. Reference topics: Junos Enterprise Switching – Storm Control, Default Drop Behavior Versus Interface Shutdown Action.

A native VLAN is a trunk-port concept, not an access-port concept. On an 802.1Q trunk, every frame is normally expected to carry a VLAN tag identifying its membership; the native VLAN is the single exception that Junos permits an administrator to define using the native-vlan-id statement under the trunk interface's family ethernet-switching hierarchy. Any untagged frame arriving on that trunk port is automatically classified into the configured native VLAN, and conversely, outbound frames belonging to the native VLAN are transmitted untagged rather than with an 802.1Q header. This behavior exists chiefly for interoperability with legacy or third-party devices that either cannot generate 802.1Q tags or intentionally send management or default traffic untagged across an otherwise tagged trunk. Access ports, by definition, only ever carry a single VLAN's traffic and never receive tagged frames in normal operation, so the native VLAN mechanism has no relevance there — which eliminates the access-port-oriented answer choices. The native VLAN also does not restrict a trunk to a single VLAN; the trunk continues to carry all configured tagged VLANs simultaneously, with the native VLAN simply being the designated untagged exception. Misconfiguring or mismatching native VLAN IDs between two trunk peers is a classic Layer 2 troubleshooting scenario on the exam. Reference topics: Junos Enterprise Switching – VLANs, Configuring the Native VLAN on a Trunk Interface.

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.

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.

The show ethernet-switching table command displays the Layer 2 forwarding database (the bridge or MAC table) that an EX Series switch builds dynamically by inspecting the source MAC address of every frame it receives. Each entry records the learned MAC address, the VLAN it was learned on, the type of entry (dynamic, static, or persistent), and the specific interface through which that address was seen, which is precisely the information needed to confirm whether the switch has learned the host connected to ge-0/0/3. If the host's MAC address is absent from the table, that immediately points to a Layer 1/2 issue — no frames have been received from the host, a cabling or port problem exists, or the interface is administratively down or blocked by spanning tree — rather than a Layer 3 routing or VLAN membership problem. show interfaces terse only reports administrative and link state along with any assigned protocol family addresses, offering no MAC-learning visibility. show vlans lists VLAN definitions and their member interfaces but does not display learned host addresses. show interfaces extensive provides detailed physical-layer counters and error statistics, useful for diagnosing frame loss or interface errors, but it does not expose the switching table. For intra-VLAN reachability troubleshooting, verifying MAC learning is always the first and most direct Layer 2 checkpoint. Reference topics: Junos Enterprise Switching – Layer 2 Switching Fundamentals, Monitoring the Ethernet Switching Table.

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.

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.

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.

IS-IS is a link-state protocol that, like OSPF, runs Dijkstra's Shortest Path First algorithm independently on each router against its own copy of the synchronized link-state database to compute the best path toward every reachable destination. Each link within the topology carries an administrator-assigned or default metric, and as the SPF algorithm walks the topology graph from the local router outward, it sums the metrics of every link traversed along a candidate path to produce that path's total accumulated cost. Among all possible paths to a given destination prefix, IS-IS always selects and installs the path (or, in the case of equal-cost multipath, the set of paths) with the numerically lowest total accumulated metric, exactly mirroring the 'lowest cost wins' principle shared by essentially all link-state IGPs. A higher accumulated metric value is by definition a less preferred, more costly path, making that option the direct inverse of correct IS-IS behavior. Level 2 proximity to the destination has no independent bearing on path selection beyond however it happens to be reflected in the accumulated metric itself — IS-IS does not apply a separate rule preferring paths merely for passing near a Level 2 router. Likewise, LSP recency (sequence number or freshness) governs which version of a given LSP is trusted and flooded during database synchronization, ensuring the topology database itself is accurate and loop-free, but it plays no role in the SPF cost comparison once the database is synchronized and consistent. Reference topics: Junos Enterprise Routing – IS-IS, SPF Calculation and Metric-Based Path Selection.

The destination address 172.16.200.5 falls within the 172.16.0.0/16 aggregate's summarized range but does not fall within either of the two active, more-specific contributing routes actually present in the table — 172.16.10.0/24 and 172.16.99.0/24 — meaning no route more specific than the /16 itself exists to cover it. Under Junos's longest-match forwarding logic, the lookup for 172.16.200.5 therefore resolves to the aggregate route itself, and since aggregate routes are installed by default with a reject next hop rather than any real forwarding path, the router drops the packet and simultaneously generates an ICMP destination-unreachable message back to the originating source, explicitly signaling that no valid path exists for that specific destination even though a covering summary is being advertised. This reject behavior is precisely why aggregate routes are valuable for reducing the number of routes advertised upstream while still providing clear, immediate feedback for traffic aimed at address space within the summary that has no genuine underlying route, rather than silently black-holing it or misdirecting it toward an unrelated contributing route's next hop. The aggregate route itself remains active and installed throughout this process — a gap in contributing coverage does not deactivate the aggregate, since the aggregate's activation depends only on at least one contributing route being active, which is satisfied here by both existing /24 blocks. There is also no default route present in this scenario to fall back upon. Reference topics: Junos Enterprise Routing – Protocol Independent Routing, Aggregate Route Reject Behavior for Uncovered Address Space.

A GRE tunnel's outer, delivery-layer packets are forwarded using the router's ordinary underlay routing table, meaning the tunnel destination address (192.168.0.1 in this case) must itself be resolvable to a physical, non-tunnel next hop for the encapsulated packets to actually leave the router. Before this configuration change, the default route (or some more specific route) presumably pointed toward a real physical next hop, allowing the router to reach 192.168.0.1 and keep the tunnel operational. When the administrator commits a static default route of 0.0.0.0/0 with a next hop of gr-0/0/0, every destination lookup that previously fell back to the default route — including the lookup for the tunnel's own destination address, 192.168.0.1, since no more specific route exists for it — now recurses through the GRE interface itself. This creates a circular dependency: the router needs to route to 192.168.0.1 to keep the tunnel up, but the only route it has to reach 192.168.0.1 now points back into the tunnel that requires 192.168.0.1 to already be reachable, so the interface's next-hop resolution fails and the tunnel drops. This is an entirely valid and common GRE design pitfall rather than any platform restriction; GRE interfaces can be legitimately used as static route next hops, do not require loopback-sourced encapsulation, and do not require a /32 host route to resolve their destination, provided that route does not recursively point back through the tunnel. Reference topics: Junos Enterprise Routing – Tunneling, Route Recursion and GRE Tunnel Destination Resolution.

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 entire purpose of route aggregation is summarization — replacing a set of more-specific contributing routes with a single, broader prefix advertised outward — and this summarization inherently hides internal routing instability from external peers: if one of the underlying contributing /24 blocks within a summarized /16 flaps up and down due to a local link issue, external peers who only see the stable, unchanging /16 aggregate are completely insulated from that churn, since the aggregate itself remains active and advertised as long as at least one contributing route is present, regardless of how much internal fluctuation occurs among the individual contributors. This stability-hiding characteristic is one of the primary operational benefits that motivates using aggregate routes in the first place, confirming that statement as correct. Regarding next-hop behavior, official Juniper documentation is explicit and unambiguous: when an aggregate route is installed in the routing table, Junos assigns it a reject next hop by default, meaning traffic matching only the aggregate (and no more-specific contributor) is dropped and an ICMP unreachable message is returned to the source; a discard next hop is available only as an optional, explicitly configured alternative when silent dropping without ICMP notification is preferred, but it is not the default. Aggregate routes categorically do not advertise their individual contributing routes; suppressing those specific, more-granular prefixes from onward advertisement in favor of the single summary is the aggregate's defining function, directly contradicting the first statement. Reference topics: Junos Enterprise Routing – Protocol Independent Routing, Default Reject Next Hop and Route Summarization Benefits.

RFC 2328 specifies a precise set of parameters that two OSPF routers on a broadcast network must agree upon before a valid neighbor relationship can be established, and a mismatch in any of these mandatory fields causes the routers to reject each other's Hello packets outright rather than forming even a basic 2-Way state. The network mask carried in each Hello packet must match between neighbors on a broadcast segment, since OSPF uses this field to confirm both routers agree on the subnet boundaries of the shared segment; a mismatched mask (for example, one router configured with a /24 and its neighbor with a /25 on the same physical wire) is treated as a configuration error and blocks adjacency formation. The router dead interval, which defines how long a router will wait without receiving a Hello before declaring a neighbor down, must likewise match exactly between neighbors, alongside the closely related hello interval, since these timers govern the shared expectations both sides have for how frequently Hellos should arrive and how quickly a failure should be detected; Junos explicitly checks and rejects Hello packets carrying a mismatched dead interval value. Router priority, by contrast, is intentionally allowed to differ between neighbors on the same segment — it exists precisely so that administrators can differentiate router preference for the DR/BDR election, and differing values are expected and normal rather than being blocked. The designated router field, as advertised within each Hello, is informational about the sender's current view of the segment's DR and is not a value that must be identical between the two Hello senders to permit adjacency formation. Reference topics: Junos Enterprise Routing – OSPF, Required Hello Parameter Matching on Broadcast Networks.

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.

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.

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.

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.