Important Juniper JN0-352 JNCIS-ENT Exam Questions

Answer: A

Explanation:

A link aggregation group bundles multiple physical Ethernet links into a single logical interface (an ae interface) specifically to provide both increased aggregate bandwidth and link-level redundancy. By default, the aeX interface remains operationally up as long as at least one member link within the bundle remains active and passing traffic; the LAG does not require every member link to be functional to continue operating. When one of the four 1-GbE member links in this scenario fails, LACP (if in use) or the underlying link-status monitoring detects the failure, removes that specific link from the active forwarding set, and redistributes traffic hashing across the three remaining healthy member links automatically and without operator intervention. End devices and upper-layer protocols continue to see a single, continuously up ae interface throughout this process, experiencing only a proportional reduction in available aggregate bandwidth rather than any interruption in connectivity. This default behavior is precisely why LAG is a foundational building block for resilient EX Series switch interconnects in enterprise and data center designs, since it allows individual optic, cable, or transceiver failures to be absorbed transparently. None of the distractor behaviors --- full administrative shutdown of the bundle, forwarding limited to broadcast traffic only, or a temporary disabling of all member links during renegotiation --- reflect actual Junos LAG behavior, which is designed explicitly to avoid any such disruption. Reference topics: Junos Enterprise Switching -- Layer 2 Switching, Link Aggregation Group Resiliency.

Answer: A, C

Answer: A

Explanation:

On EX Series switches, aggregated Ethernet (ae) interfaces do not exist by default; before any ae interface can be created, referenced, or brought into service, an administrator must first reserve the desired number of aggregated Ethernet device slots by configuring set chassis aggregated-devices ethernet device-count number at the [edit chassis] hierarchy. This statement allocates the internal resources needed for that many ae interfaces to exist as valid, configurable objects; until it is committed, any interface-level configuration referencing ae0 (such as the aggregated-ether-options and family ethernet-switching stanzas shown in the exhibit) is accepted syntactically by the CLI but never actually instantiates a live ae0 device, which is exactly why show interfaces ae0.0 returns 'device ae0 not found' despite the interface appearing fully configured. Increasing the device-count to at least 1 (or higher, to cover the number of LAG bundles planned) immediately resolves this and allows ae0 to appear as an operational interface once its member links are also associated with it. This is a foundational and frequently overlooked prerequisite step in LAG deployment on Juniper switches. There is no separate licensing requirement for aggregated Ethernet functionality on EX Series switches, a reboot is not needed since the chassis statement takes effect upon commit, and the LACP mode (active versus passive) is unrelated to whether the ae interface object itself exists in the first place. Reference topics: Junos Enterprise Switching -- Link Aggregation, Configuring the Aggregated Ethernet Device Count.

Answer: C

Explanation:

Once the two candidate routes have equal route preference and equal local preference (both defaulting to 100 unless modified by policy), the Junos BGP algorithm proceeds to its third decision step, which compares the length of each candidate's AS path attribute and selects whichever path carries the shortest AS path, since a shorter path is interpreted as traversing fewer autonomous system hops to reach the origin. This step occurs well before the algorithm ever reaches the specific EBGP-over-IBGP preference rule, which is only evaluated later, after local preference, AS path length, origin type, and MED have all already been compared and found equal between the candidates; because an IBGP-learned copy of a route typically retains the identical AS path that was originally received from the external AS (IBGP does not prepend the local AS number the way crossing an AS boundary does), it is entirely possible, and often the deciding scenario, for AS path length to differ between competing paths well before the algorithm would ever need to fall back on the IBGP-versus-EBGP tiebreak. Selecting a route purely because it was 'learned through IBGP' is not a rule that exists anywhere in the algorithm and would in fact typically be the opposite of Junos's later EBGP-preference tiebreak. Neither next-hop IP address value nor router ID value is compared with a 'highest wins' rule at any point in the standard path selection sequence --- where router ID is used at all, Junos prefers the lowest value, not the highest, making both of those distractors doubly incorrect. Reference topics: Junos Enterprise Routing -- BGP, Path Selection Order: AS Path Length Precedes EBGP/IBGP Preference.

Answer: B

Explanation:

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.