JN0-352 Exam Dumps - Juniper JNCIS-ENT Questions and Answers

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.

OSPF neighbor state progression, as defined in RFC 2328 and displayed by Junos through show ospf neighbor, moves through a well-defined set of named states: Down, Attempt, Init, 2-Way, ExStart, Exchange, Loading, and Full. Down is the initial state, indicating no Hello packets have been recently received from a potential neighbor on that interface; it is a genuine, valid OSPF state and is correctly included here. Init indicates that a Hello packet has been received from the neighbor, but that neighbor has not yet listed the local router's own router ID within its Hello packet, so bidirectional communication has not yet been confirmed; this too is a standard, valid state. Loading occurs after the Exchange state, during which Database Description packets have been fully exchanged and the router is now actively requesting the specific, more-detailed LSAs it identified as missing or outdated from its neighbor via Link State Request packets; it is likewise a standard, valid OSPF neighbor state. 'Established' is not an OSPF state at all — that terminology belongs to BGP's finite state machine, where Established represents the fully operational session state; the OSPF equivalent concept is instead called Full. 'Reject' is not a recognized OSPF neighbor state under any circumstance and does not appear anywhere in the RFC 2328 state machine, making it an invalid distractor as well. Reference topics: Junos Enterprise Routing – OSPF, The OSPF Neighbor State Machine.

TLV 22, the Extended IS Reachability TLV defined in RFC 5305, is the modern and Junos-preferred mechanism for advertising a router's adjacent neighbors together with the metric associated with each link. It carries the seven-octet system ID and pseudonode number of each neighbor along with a 24-bit wide metric field, and supports an extensible set of sub-TLVs used for traffic-engineering data such as interface and neighbor IP addresses, bandwidth, and administrative groups. The original IS Reachability TLV, TLV 2, defined in the base ISO 10589 standard, carries similar neighbor and metric information but is constrained to a 6-bit narrow metric with a maximum value of 63, which is inadequate for expressing meaningful cost differentiation in modern, high-capacity enterprise and service-provider topologies; consequently, Junos deployments are commonly configured for wide-metrics-only, favoring TLV 22 over the legacy TLV 2 whenever traffic-engineering-capable or simply more granular metric representation is desired. TLV 132, the IP Interface Address TLV, only advertises the IPv4 addresses configured on the originating router's interfaces and carries no neighbor-adjacency or metric information. TLV 129, the Protocols Supported TLV, merely lists which network-layer protocols (such as IPv4 or IPv6) the originating router is capable of routing, and likewise has nothing to do with neighbor reachability or link cost. Reference topics: Junos Enterprise Routing – IS-IS, Extended IS Reachability and Wide Metrics.

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.

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.

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.

An integrated routing and bridging interface, configured as irb.x on an EX Series switch, is the mechanism that bridges the Layer 2 and Layer 3 forwarding planes for a given bridge domain or VLAN. By assigning an irb logical unit to a VLAN and configuring an IP address on that unit, the switch gains a routable Layer 3 gateway address that hosts within that VLAN can use as their default gateway, enabling traffic destined for other subnets to be routed off the local broadcast domain. Internally, when a frame destined for the gateway's MAC address arrives on any port belonging to that VLAN, the switch's integrated circuitry hands the packet from the Layer 2 bridging domain to the Layer 3 routing engine associated with the corresponding irb interface, and vice versa for the return path — hence the name 'integrated routing and bridging.' IRB does not eliminate the need for routing instances, which remain a separate mechanism for isolating routing tables; it does not itself perform inter-VLAN switching, since switching still happens strictly within a VLAN's own broadcast domain; and it has no relationship to trunk ports, which remain necessary for carrying multiple tagged VLANs between switches. IRB is the standard method for enabling inter-VLAN routing on a single EX Series switch without an external router. Reference topics: Junos Enterprise Switching – Routing VLANs, Configuring Integrated Routing and Bridging.

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.

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.

RSTP, as defined in IEEE 802.1w, introduces explicit, well-defined port roles that go beyond legacy 802.1D STP's simpler root/designated/blocking model, and the alternate port role is one of RSTP's key refinements. An alternate port is a port that receives BPDUs from a bridge other than the one through which the local switch's actual root port reaches the root bridge — in other words, it represents a second, redundant path toward the root bridge learned from a different upstream bridge than the one currently providing the best (root port) path. Because the existing root port already provides the lowest-cost, actively used path to the root, the alternate port is deliberately held in the discarding (non-forwarding) state during normal, stable operation, functioning purely as a pre-computed, ready-to-use backup; critically, RSTP's major performance advantage over legacy STP is that if the current root port fails, the switch can transition its alternate port directly and almost instantly into the forwarding root port role without needing to pass through the lengthy listening and learning timer-based states that classic STP required, since the alternate port's suitability as a backup was already continuously verified through ongoing BPDU reception. It is not simply 'not receiving BPDUs' (an alternate port receives BPDUs continuously, just inferior ones relative to the current root port), it is not itself the least-cost path (that describes the root port), and it does not forward based on designated-port overload, which is not a concept that exists in RSTP's port-role logic at all. Reference topics: Junos Enterprise Switching – Spanning Tree Protocols, RSTP Port Roles: Alternate and Backup Ports.