Free JN0-106 Practice Test Questions | Know You're Ready for Junos - Associate (JNCIA-Junos) Junos OS 21.2

Explanation:
The firewall filter term limit-icmp matches ICMP packets from source network 172.25.11.0/24. The then clause executes two actions: count count-icmp increments a counter, and discard silently drops the packet without sending any error notification.

Correct Option:

A: A counter will be incremented.
The count count-icmp action explicitly instructs the device to increment the counter named count-icmp each time a packet matches all conditions in the from statement. This is used for monitoring and statistics.

B: The packet will be discarded.
The discard action silently drops the matching packet. The packet is not forwarded to its destination, and no further processing occurs. No ICMP error message is generated unless explicitly configured.

Incorrect Option:

C: The packet will be forwarded.
This is incorrect because the discard action overrides any implicit accept behavior. The packet is dropped immediately after counting, so it never reaches the forwarding stage.

D: An ICMP destination unreachable message will be returned.
The discard action performs a silent drop. To send an ICMP unreachable message, you would need to use reject instead of discard. The discard action does not generate any notification to the source.

Reference:
Juniper TechLibrary – "Firewall Filter Term Actions": The count action increments a named counter; discard silently drops the packet without sending any ICMP error message. For ICMP notifications, use the reject action.

Explanation:
The authentication-order statement defines the sequence in which Junos checks authentication methods. In the exhibit, the order is RADIUS first, then TACACS+, then local password. When RADIUS is unavailable (timeout or no response), Junos automatically proceeds to the next configured method.

Correct Option:

D: Junos attempts the next configured authentication method.
With authentication-order [ radius tacplus password ], if RADIUS servers are unreachable or do not respond, Junos moves to TACACS+. If TACACS+ also fails, it falls back to the local password database. This ensures continued access even if an external server is down.

Incorrect Option:

A: The user is prompted to select a different authentication method.
Junos does not prompt the user to choose a method. The authentication order is system‑defined and automatic. The user simply provides credentials; the system tries each method sequentially.

B: The login attempt fails immediately.
The login attempt does not fail immediately when RADIUS is unavailable. Junos only fails after exhausting all configured authentication methods in the specified order.

C: Junos will continue to attempt to authenticate with the RADIUS server until it responds.
Junos does not retry the same unreachable server indefinitely for a single login attempt. It respects the timeout and then moves to the next method in the list.

Reference:
Juniper TechLibrary – "Authentication Order": Junos attempts authentication methods in the order specified. If a method is unavailable, the system proceeds to the next method in the list.

Explanation:
The exhibit shows R1 with two static routes: a default route (0.0.0.0/0) pointing to R2 (192.168.0.102), and a route for 10.1.0.0/16 pointing back to R1's own interface (192.168.0.101). No route exists on R2 back to the 10.1.0.0/16 network, creating potential asymmetry and loops.

Correct Option:

A: A routing loop can occur if one of the users sends packets to 10.1.99.1.
10.1.99.1 falls within the 10.1.0.0/16 summary route on R1. R1 forwards such packets toward 192.168.0.101 (itself?), which is problematic. More importantly, if R2 receives a packet for 10.1.0.0/16 and has only a default route back to R1, a loop forms between R1 and R2.

Incorrect Option:

B: Only User A can reach destinations beyond Router R1.
All users (10.1.0.0/24, 10.1.1.0/24, 10.1.2.0/24) are within the 10.1.0.0/16 network, so R1's summary route applies to all. However, the next-hop 192.168.0.101 is likely R1's own interface, which is invalid. No user will properly reach beyond R1 without correct next-hop.

C: Router R2 will drop packets destined for user B and user C.
R2 may have a default route pointing to R1, so it would forward packets toward R1 rather than dropping them. Dropping would occur only if no route exists, but default routes often exist in such topologies.

D: Router R1 will discard all packets from all three users.
R1 will not discard packets; it will attempt to route them according to its static routes. The issue is forwarding misconfiguration (next-hop pointing to itself), not discarding.

Reference:
Juniper TechLibrary – "Static Routing and Routing Loops": A routing loop occurs when two or more routers have inconsistent routing information, causing packets to bounce between them. Invalid next-hop addresses (pointing to self) also cause forwarding failures.

Explanation:
Junos OS maintains a committed configuration history (0 = active, 1 = most recent previous, up to 49). After committing a problematic change, the previous working configuration is stored as rollback 1. Using rollback 1 in configuration mode restores that configuration, which then takes effect after a commit.

Correct Option:

D: rollback 1
rollback 1 in configuration mode replaces the candidate configuration with the configuration that was active before the most recent commit. After issuing rollback 1, you must run commit to activate the reverted configuration.

Incorrect Option:

A: show | compare
This command displays the differences between the candidate configuration and the active configuration. It is used for viewing changes, not for reverting to a previous configuration.

B: save config
The save command writes the current configuration to a file. It does not revert or roll back any changes. This is used for backup purposes.

C: rollback 0
rollback 0 replaces the candidate configuration with the currently active (committed) configuration. Since the problematic change is already committed, rollback 0 discards any uncommitted edits but does not revert the active configuration.

Reference:
Juniper TechLibrary – "Rolling Back to a Previous Configuration": Use rollback 1 to revert to the configuration prior to the most recent commit. Follow with commit to activate the rolled‑back version.

Explanation:
Routing policies in Junos OS are used to control routing information flow. They evaluate routes based on conditions (prefix, protocol, next-hop, etc.) and apply actions such as accept, reject, or modify route attributes (preference, metric, tags) for routes being imported or exported by routing protocols.

Correct Option:

A: It controls which routes are accepted or advertised by a routing protocol.
This is the primary purpose. Routing policies are applied to protocol import/export statements (e.g., import my-policy under OSPF or BGP) to filter which routes enter the routing table or are advertised to neighbors. Policies can also modify route characteristics like local preference or MED.

Incorrect Option:

B: It determines the physical interface used for forwarding traffic.
Physical interface selection is determined by the forwarding table and routing decisions, not routing policies. Policies affect route acceptance and attributes, but the actual forwarding interface is chosen based on the active route's next-hop.

C: It sets the maximum number of routes in the routing table.
Route limits are configured using routing-options (e.g., maximum routes) or protocol-specific limits. Routing policies do not impose global maximums on the routing table size.

D: It enables automatic rollback of routing changes.
Automatic rollback is a configuration management feature (commit and rollback), unrelated to routing policies. Routing policies do not provide auto-rollback capabilities for routing changes.

Reference:
Juniper TechLibrary – "Routing Policy Overview": Routing policies control the import and export of routing information, allowing you to filter routes and set routing attributes for routes exchanged between routing protocols.

Explanation:
A static route in Junos becomes active (appears in the routing table) only if its next-hop address is resolvable. The next-hop must be directly connected via an interface with an active IP address, or recursively reachable through an existing route. In this case, 10.1.1.1 is not in the same subnet as ge-0/0/1 (which reaches 10.10.1.1), causing resolution failure.

Correct Option:

A: The next-hop address 10.1.1.1 is not directly connected or reachable through another route.
The exhibit shows next-hop 10.1.1.1, but the description states the actual gateway is 10.10.1.1. The mismatch means the router cannot resolve 10.1.1.1 to an active interface. For the route to install, the next-hop must be directly connected or recursively resolved via another active route.

Incorrect Option:

B: Static routes must include the outgoing interface as the next hop.
Junos static routes can use either a next-hop IP address or an outgoing interface (e.g., next-hop ge-0/0/1). Using an IP address is valid and commonly used; the issue here is an incorrect or unreachable IP address.

C: The static route requires a preference value to be specified or it will not install.
Static routes have a default preference value of 5. Specifying a preference is optional and only needed to override the default for route selection purposes. Lack of a preference value does not prevent installation.

D: The static route requires the retain keyword to remain active in the routing table.
The retain keyword keeps a static route in the forwarding table even if the next-hop becomes unreachable. It is not required for normal route activation. The route fails to install due to resolution failure, not because retain is missing.

Reference:
Juniper TechLibrary – "Static Routes: Next-hop Resolution": For a static route to be installed, the next-hop address must be reachable via an active directly connected interface or resolved through an existing route in the routing table.

Explanation:
In Junos CLI, the prompt indicates the current operational state. A prompt ending with # (e.g., user@router#) signifies that the user is in configuration mode. In this mode, commands like set, delete, and commit are available to modify the device's configuration.

Correct Option:

B: The user is in configuration mode.
When you enter configure from operational mode, the prompt changes from > to #. The hash symbol clearly indicates that you are now in configuration mode, where you can view and edit the candidate configuration.

Incorrect Option:

A: The user is in operational mode.
Operational mode is indicated by a > symbol at the end of the prompt (e.g., user@router>). In operational mode, you can run show, ping, monitor, and other operational commands but cannot change the configuration.

C: The user is in shell mode.
Shell mode (Unix shell) is accessed via the start shell command. The prompt changes to a system shell prompt (e.g., % or $), not a # after the hostname. Junos CLI # is not the shell prompt.

D: The user is in recovery mode.
Recovery mode is a special boot state used for password recovery or system rescue. It does not use the standard Junos CLI prompt format user@router#.

Reference:
Juniper TechLibrary – "CLI Modes": Operational mode prompt ends with >, configuration mode prompt ends with #. The hash symbol indicates the user has entered configuration mode via the configure command.

Explanation:
The request system zeroize command is the standard Junos method for securely erasing all configuration data, logs, and user-created files, then rebooting the device to factory default settings. This is used before redeploying or decommissioning a device to ensure no sensitive data remains.

Correct Option:

C: request system zeroize
This command permanently removes all configuration, commits, rollback files, logs, and user files, then reboots the device. After reboot, the device loads the factory-default configuration, ready for redeployment. The operation is irreversible and typically requires confirmation.

Incorrect Option:

A: show system storage
This command displays disk usage statistics (e.g., available space, filesystem usage). It provides visibility into storage but does not modify or clear any configuration or reset the device.

B: request system storage cleanup dry-run
This command simulates the storage cleanup process, showing which log and temporary files would be deleted without actually removing them. It does not reset configuration or restore factory defaults.

D: request system storage cleanup
This command deletes unnecessary log files, temporary files, and old core dumps to free up storage space. It does not clear configuration or perform a factory reset.

Reference:
Juniper TechLibrary – "request system zeroize": This command erases all user configuration, log files, and generates a new SSH key, then reboots the device to factory‑default settings. Use before redeployment or disposal.