Free Juniper JN0-106 Practice Exam with Questions & Answers | Set: 3

In the Junos OS architecture, maintaining a reliable recovery point is a critical post-installation task. While the system automatically archives previous configurations as " rollback " files every time a commit is performed, these files are transient and can eventually be rotated out of the default 50-file history as new changes are made. To ensure a permanent and reliable recovery state, a Senior Architect should manually create a rescue configuration .

The rescue configuration is a specifically designated file used to restore a device to a known-working state if it becomes unreachable or the configuration becomes corrupted. Unlike standard rollbacks, the rescue configuration is only created or updated when an administrator explicitly issues the operational mode command request system configuration rescue save. This ensures that even if several subsequent commits flush the desired initial state from the standard rollback archive, the " safe harbor " configuration remains intact on the storage media. This state can then be re-activated via the rollback rescue command in configuration mode followed by a commit. Setting a rescue configuration after the initial setup is a foundational best practice for disaster recovery and operational stability, providing a " last resort " configuration that is immune to the automated rotation of the commit history.

The Juniper MX204 is a fixed-configuration router that utilizes a specific hierarchical naming convention for its physical interfaces: type-fpc/pic/port. In the MX204 architecture, there is a single built-in Flexible PIC Concentrator (FPC), which is always designated as FPC 0 . This FPC is subdivided into two logical Physical Interface Cards (PICs): PIC 0 and PIC 1 .

As shown in the exhibit, PIC 0 contains four high-speed ports (labeled 0/0 through 0/3) that typically support 40GbE or 100GbE speeds. PIC 1 contains eight ports (labeled 1/0 through 1/7) designed for 1GbE or 10GbE connectivity. These ports are arranged in a stacked, $2 \times 4$ grid. The labeling system on the chassis indicates the port numbers for each column. In the fourth column of the PIC 1 block, the top port is identified as 1/6 and the bottom port as 1/7 .

The blue arrow in the exhibit points directly to the bottom-right interface in the PIC 1 section. Correlating this physical location with the chassis labels confirms that the port number is 7. When combined with the FPC and PIC identifiers, the full interface name is xe-0/1/7 (assuming a 10GbE transceiver is installed). Understanding this physical-to-logical mapping is essential for accurate cabling and configuration within the Junos OS, ensuring that administrators apply the correct logical unit and protocol settings to the intended physical hardware.

In Junos OS, standard firewall filters operate as a primary security and traffic management tool within the forwarding plane. These filters are fundamentally stateless, meaning they evaluate each packet individually and in isolation without maintaining a session table or tracking the state of network connections. This stateless nature allows the Packet Forwarding Engine (PFE) to process filters at hardware speeds, ensuring minimal latency for transit traffic. This distinguishes them from the stateful security policies found on Junos security devices like the SRX Series, which track the entire lifecycle of a flow.

Furthermore, firewall filters are designed to inspect and match header information up to Layer 4 of the OSI model. This capability allows administrators to define terms based on parameters such as source and destination IP addresses (Layer 3) as well as TCP or UDP port numbers and protocol types (Layer 4). While they provide granular control over packet flow, they do not natively inspect Layer 7 application payloads, which is typically reserved for advanced services like Intrusion Detection and Prevention (IDP). By combining stateless execution with Layer 4 matching, Junos firewall filters provide an efficient method for implementing transit protection, rate limiting through policing, and protecting the local Routing Engine through loopback interface filtering. Reference: Routing Policy and Firewall Filters, Firewall Filter Framework.

==========

The Address Resolution Protocol (ARP) is a fundamental Layer 2 utility used within the IPv4 suite to resolve a known network-layer (Layer 3) address to its corresponding physical media access control (MAC) or hardware address (Layer 2). In a typical Ethernet environment, when a Junos device needs to forward a packet to a next-hop on a local subnet, the Packet Forwarding Engine (PFE) requires the destination MAC address to properly encapsulate the frame.

The process begins with an ARP Request, which is broadcast to all hosts on the segment asking, " Who owns this IP address? " The host assigned that specific IP responds with an ARP Reply containing its MAC address. The Junos device then stores this mapping in its ARP cache (viewable via the show arp command) to avoid repeated broadcasts for subsequent packets. This resolution is essential because while IP addresses facilitate end-to-end logical routing, the actual delivery of data across a physical wire or switch fabric relies entirely on hardware addresses. Without successful ARP resolution, the device cannot complete the Layer 2 header, and the traffic will be dropped as " encapsulation failed. "

In Junos OS, the rescue configuration is a specifically designated file that stores a known-working configuration, intended to be used for emergency recovery when the device becomes unreachable or unstable due to recent changes. This configuration is not created automatically; an administrator must proactively save a stable state using the operational mode command request system configuration rescue save. This differs from the standard rollback archive, which automatically stores up to 50 previous configurations but can eventually rotate out the specific " last known good " state needed for recovery.

When a device loses network connectivity, console access becomes the only viable management path. To restore the rescue configuration, the administrator must enter configuration mode using the configure command. Once inside the candidate configuration buffer, the rollback rescue command is issued. This command directs the Junos OS to locate the designated rescue file and load its contents over the current candidate configuration. Upon receiving the " load complete " confirmation, the administrator must execute a commit to promote the candidate configuration to the active, running state. Sequence C correctly follows this logic. Sequence A is technically incorrect for standard rescue restoration as load override typically targets specific file paths or URLs, whereas rollback rescue is the built-in mechanism for this function. Sequences B and D are destructive or counter-productive, either deleting the rescue file or overwriting it with the current, non-functional configuration state. Reference: Operational Monitoring and Maintenance, Configuration Recovery, Rescue Configuration.

==========

In Junos OS, the Routing Engine (RE) performs a validation check on every entry in the Routing Information Base (RIB). For a static route to be considered valid and transition to an active state in the inet.0 table, its designated next hop must be resolvable . A next-hop address is resolvable only if the router has an existing route (typically a directly connected route) to that specific IP address.

According to the exhibit, the static route for 10.10.10.0/24 has been configured with a next hop of 10.1.1.1 . However, the scenario states that the actual gateway router is located at 10.10.1.1 . If the local interface (ge-0/0/1) is configured with an IP in the 10.10.1.0/x subnet, the router will have a direct route to 10.10.1.1, but it will likely have no path to the 10.1.1.1 address provided in the exhibit.

Because the router cannot resolve the next hop 10.1.1.1 , the static route is placed in an " inactive " or " hidden " state. It will not be installed in the forwarding table pushed to the Packet Forwarding Engine (PFE), and standard show route commands will not display it unless specific flags like hidden or all are used. This logic ensures that the router does not attempt to forward packets into a " black hole " where the gateway is logically unreachable. To fix this, the administrator must modify the configuration to point to the correct, reachable next-hop address of 10.10.1.1.

When you initially unbox and power on a Juniper MX Series router, it loads a factory-default configuration . Unlike some consumer-grade or lower-end enterprise switches that might have all ports active in a default VLAN, high-performance routers like the MX Series prioritize security and intentionality. In the factory-default state, the transit interfaces are not configured .

While the physical hardware interfaces (such as ge-0/0/0 or xe-0/1/0) are detected by the Junos kernel, they lack any logical unit or protocol family definitions (like family inet or family inet6). Without a logical unit—even a simple unit 0—the Packet Forwarding Engine (PFE) will not accept or forward any traffic arriving on those ports. Furthermore, as discussed in previous questions, the device is essentially in a " locked " state; you cannot even commit new changes to enable these interfaces until you have defined a root-authentication password. This " blank slate " approach ensures that no traffic accidentally flows through a newly installed provider-edge device until an architect has explicitly defined the routing policies, firewall filters, and interface parameters required for the specific network environment. To begin passing traffic, you must manually define the logical units and assign the appropriate IP addresses or switching parameters to each interface.

Secure remote administrative access to a Junos OS device is performed by using SSH (Secure Shell) . Therefore, ssh 172.16.10.1 is the correct command. Juniper defines the Junos CLI ssh operational command as a mechanism for opening a secure connection between a local router or switch and a remote system. The destination can be specified by hostname or IP address.

SSH provides authenticated and encrypted remote access, protecting login credentials and management traffic while the administrator performs configuration, monitoring, or maintenance operations. Junos devices can accept incoming SSH sessions when SSH is enabled under the [edit system services ssh] configuration hierarchy.

telnet 172.16.10.1 can establish a remote terminal session, but Telnet does not provide the encryption required for secure administrative access. ftp is principally a file-transfer protocol and is not the appropriate mechanism for interactive device maintenance. traceroute is an operational diagnostic utility used to identify the Layer 3 path toward a destination; it does not provide device login functionality.

Study Guide Reference Topics: User Interfaces — CLI remote access; Junos OS Fundamentals — system services; Operational Monitoring and Maintenance — secure device management.

In the Junos OS architecture, configuration groups (defined under the [edit groups] hierarchy) provide a powerful mechanism for template-based management. This approach is specifically designed to handle scenarios where multiple configuration objects, such as twenty different Ethernet interfaces, require identical parameters like a specific description or MTU value. By defining these common settings once within a group, an administrator can then apply that group to multiple interfaces using the apply-groups statement.

This methodology drastically reduces the number of repetitive commands required and, more importantly, ensures strict consistency across the device. If the MTU needs to be adjusted in the future, the change is made in a single location—within the configuration group—and is automatically inherited by all interfaces to which the group is applied. This inheritance model prevents " configuration drift " where individual interfaces might otherwise end up with mismatched settings due to manual entry errors. Using configuration groups is considered a best practice for Senior Architects managing high-density platforms, as it simplifies the candidate configuration file and makes the management of bulk interface settings both scalable and error-resistant.