How should I use these Operational Monitoring and Maintenance practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

JN0-106 · topic practice

Operational Monitoring and Maintenance practice questions

Q: Can I practise just Operational Monitoring and Maintenance questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Operational Monitoring and Maintenance domain.

Practise Juniper Networks Certified Associate Junos JNCIA-Junos Operational Monitoring and Maintenance practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

20 questionsDomain: Operational Monitoring and Maintenance

Practice 10 questions Browse domain →

What the exam tests

What to know about Operational Monitoring and Maintenance

Operational Monitoring and Maintenance questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Operational Monitoring and Maintenance exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Operational Monitoring and Maintenance questions

20 questions · select your answer, then reveal the explanation

Question 1easymultiple choice

Read the full network assurance explanation →

A network engineer notices that a device is not sending SNMP traps to the NMS. Which operational command should be used to verify SNMP configuration?

Trap 1: show system uptime

The 'show system uptime' command displays system uptime, load averages, and the time since last reboot. It provides no visibility into SNMP protocol operations, trap generation, or the SNMP agent's configuration. While SNMP may report uptime as part of a MIB object, this command does not help determine why a device is failing to send SNMP notifications.

Trap 2: show route

The 'show route' command displays the routing table, including active routes and next hops, which is used for IP forwarding decisions. Although SNMP notifications are transported over IP, this command does not reveal whether the SNMP agent is enabled, whether trap destinations are configured, or if authentication/community strings are correct. It is irrelevant to diagnosing why SNMP traps are not being sent.

Trap 3: show interfaces terse

The 'show interfaces terse' command lists interface names, their administrative status, protocol status, and configured IP addresses. It only provides layer 2/layer 3 connectivity information, not the SNMP application-layer configuration. Even if all interfaces appear up, SNMP traps may fail to send due to misconfigured trap options or disabled agent, so this command cannot diagnose the root cause.

Study all Operational Monitoring and Maintenance common traps →

A
show system uptime
Why wrong: The 'show system uptime' command displays system uptime, load averages, and the time since last reboot. It provides no visibility into SNMP protocol operations, trap generation, or the SNMP agent's configuration. While SNMP may report uptime as part of a MIB object, this command does not help determine why a device is failing to send SNMP notifications.
B
show route
Why wrong: The 'show route' command displays the routing table, including active routes and next hops, which is used for IP forwarding decisions. Although SNMP notifications are transported over IP, this command does not reveal whether the SNMP agent is enabled, whether trap destinations are configured, or if authentication/community strings are correct. It is irrelevant to diagnosing why SNMP traps are not being sent.
C
show snmp
The 'show snmp' command is the correct diagnostic tool on Junos devices for verifying SNMP configuration and operation. It displays whether the SNMP agent is enabled, configured trap groups, target addresses, community strings, and various SNMP statistics. This command directly shows why a device might not send traps, such as missing trap-group definitions, incorrect targets, or an explicitly disabled SNMP service.
D
show interfaces terse
Why wrong: The 'show interfaces terse' command lists interface names, their administrative status, protocol status, and configured IP addresses. It only provides layer 2/layer 3 connectivity information, not the SNMP application-layer configuration. Even if all interfaces appear up, SNMP traps may fail to send due to misconfigured trap options or disabled agent, so this command cannot diagnose the root cause.

Full breakdown with real-world context →

Question 2mediummultiple choice

Review the full routing breakdown →

A network administrator is troubleshooting high CPU usage on a Juniper router. Which command helps identify which process is consuming the most CPU?

Trap 1: show log messages

The `show log messages` command retrieves messages written to the syslog buffer or a log file, such as interface events, user logins, or protocol errors. While a CPU spike might eventually be reflected in log entries, the command does not provide a real-time or per-process metric of CPU usage; it is asynchronous and historically framed. Even if high CPU were recorded in some log, you would not see which process consumed the cycles without inspecting process tables.

Trap 2: show system memory

The `show system memory` command reports memory utilization on the Routing Engine, including buffer pool usage, free memory, and a summary of allocated kernel and user memory. It does not expose the CPU load percentage, per-process CPU time, or scheduler state; a process that hogs CPU can do so with minimal memory footprint. This command is meant for diagnosing memory exhaustion or leaks, not for identifying the cause of high CPU utilization.

Trap 3: show interfaces

The `show interfaces` command displays per-interface operational statistics like input/output packet counts, error rates, and traffic bandwidth utilization. While extremely high interface traffic might contribute to overall CPU load due to interrupt handling or protocol queue processing, it does not show the internal CPU usage of the Routing Engine or enumerate processes. It is a command for link-level performance analysis, not for isolating which software component is consuming CPU cycles.

Study all Operational Monitoring and Maintenance common traps →

A
show log messages
Why wrong: The `show log messages` command retrieves messages written to the syslog buffer or a log file, such as interface events, user logins, or protocol errors. While a CPU spike might eventually be reflected in log entries, the command does not provide a real-time or per-process metric of CPU usage; it is asynchronous and historically framed. Even if high CPU were recorded in some log, you would not see which process consumed the cycles without inspecting process tables.
B
show system memory
Why wrong: The `show system memory` command reports memory utilization on the Routing Engine, including buffer pool usage, free memory, and a summary of allocated kernel and user memory. It does not expose the CPU load percentage, per-process CPU time, or scheduler state; a process that hogs CPU can do so with minimal memory footprint. This command is meant for diagnosing memory exhaustion or leaks, not for identifying the cause of high CPU utilization.
C
show system processes extensive
The `show system processes extensive` command is the correct diagnostic tool because it provides a detailed snapshot of every running process on the Junos device, including their IDs, CPU utilization percentages, and the cumulative time spent in user and system mode. The `extensive` keyword adds thread-level details and memory usage, enabling an administrator to pinpoint exactly which process is driving the high CPU load, such as rpd or mgd. This directly addresses the troubleshooting scenario.
D
show interfaces
Why wrong: The `show interfaces` command displays per-interface operational statistics like input/output packet counts, error rates, and traffic bandwidth utilization. While extremely high interface traffic might contribute to overall CPU load due to interrupt handling or protocol queue processing, it does not show the internal CPU usage of the Routing Engine or enumerate processes. It is a command for link-level performance analysis, not for isolating which software component is consuming CPU cycles.

Full breakdown with real-world context →

Question 3hardmultiple choice

Open the full BGP breakdown →

After a software upgrade, BGP sessions are not establishing. The engineer runs 'show bgp summary' and sees that all sessions are in Idle state. What is the most likely cause?

Trap 1: The interface is administratively down

An administratively down interface is a Layer 2/3 state that is independent of the BGP configuration. When an interface is disabled with 'set interfaces ge-0/0/0 disable' or the equivalent, the interface will be shown as 'Administratively down' in 'show interfaces', and all protocols on that interface will fail, not just BGP. BGP's inability to establish a session would be a secondary symptom; the interface state provides the clearest evidence of the cause. Additionally, if BGP had a configured group, the session state would be Active (attempting to connect) rather than Idle, because the peer address exists.

Trap 2: The router has a full BGP table

A full BGP table—referring to the ~750,000 Internet routes a default router receives—affects memory and CPU, but it does not interfere with the BGP state machine. The establishment of a BGP session occurs over TCP port 179 and only requires the configured peers to complete the OPEN, KEEPALIVE, and UPDATE exchanges. Even with a full table, two BGP peers can establish a session; the router may be slow to process updates, but the session will come up. BGP session establishment does not depend on the number of routes in the RIB.

Trap 3: The firewall filter is blocking ICMP

BGP relies on TCP port 179 for all peer communication, including session establishment, route exchanges, and keepalive messages. ICMP is neither required nor used for BGP session setup; while 'ping' is often used as a connectivity test, it is not a prerequisite for BGP to establish. A firewall filter blocking ICMP would prevent ping-based troubleshooting but would not affect the BGP TCP connection unless port 179 is also blocked. Therefore, ICMP filtering is an unrelated symptom, not the root cause of BGP sessions not being established.

Study all Operational Monitoring and Maintenance common traps →

A
The BGP group configuration is missing
BGP session establishment requires a configured BGP group or neighbor with a remote AS and peer address. If this group configuration is missing—for example, because the upgrade did not preserve the existing configuration—the routing protocol process has no peer definitions and cannot initiate the TCP handshake. The sessions remain in the Idle state, and no BGP messages are sent. This is a common cause of total BGP failure after a software upgrade and should be verified with 'show configuration protocols bgp'.
B
The interface is administratively down
Why wrong: An administratively down interface is a Layer 2/3 state that is independent of the BGP configuration. When an interface is disabled with 'set interfaces ge-0/0/0 disable' or the equivalent, the interface will be shown as 'Administratively down' in 'show interfaces', and all protocols on that interface will fail, not just BGP. BGP's inability to establish a session would be a secondary symptom; the interface state provides the clearest evidence of the cause. Additionally, if BGP had a configured group, the session state would be Active (attempting to connect) rather than Idle, because the peer address exists.
C
The router has a full BGP table
Why wrong: A full BGP table—referring to the ~750,000 Internet routes a default router receives—affects memory and CPU, but it does not interfere with the BGP state machine. The establishment of a BGP session occurs over TCP port 179 and only requires the configured peers to complete the OPEN, KEEPALIVE, and UPDATE exchanges. Even with a full table, two BGP peers can establish a session; the router may be slow to process updates, but the session will come up. BGP session establishment does not depend on the number of routes in the RIB.
D
The firewall filter is blocking ICMP
Why wrong: BGP relies on TCP port 179 for all peer communication, including session establishment, route exchanges, and keepalive messages. ICMP is neither required nor used for BGP session setup; while 'ping' is often used as a connectivity test, it is not a prerequisite for BGP to establish. A firewall filter blocking ICMP would prevent ping-based troubleshooting but would not affect the BGP TCP connection unless port 179 is also blocked. Therefore, ICMP filtering is an unrelated symptom, not the root cause of BGP sessions not being established.

Full breakdown with real-world context →

Question 4easymultiple choice

Review the full routing breakdown →

A junior engineer needs to collect a snapshot of the current system state, including routing tables, interfaces, and configuration, for a support ticket. Which command achieves this?

Trap 1: show configuration

This command displays the candidate or active configuration in Junos, showing only static device settings such as interfaces, protocols, and policies. It does not capture operational state, current system status, logs, or dynamic routing information, which are often necessary for full troubleshooting. As a result, it provides an incomplete snapshot of the system's current condition, making it unsuitable for comprehensive diagnostic data collection.

Trap 2: show interfaces

This command provides detailed operational information about interfaces, including traffic statistics, error counters, and link status. However, it is limited to interface-specific data and does not gather system-wide information like routing tables, logs, processes, or configuration. For a broad snapshot of the system's health, this command is too narrow and would miss critical components of the overall state.

Trap 3: show route

This command displays the routing table, including active routes, next hops, and protocol-specific entries. While useful for network reachability analysis, it only covers the routing plane and not the overall system state such as interfaces, logs, or configuration. Thus, it gives a narrow view that cannot serve as a comprehensive system snapshot.

Study all Operational Monitoring and Maintenance common traps →

A
show configuration
Why wrong: This command displays the candidate or active configuration in Junos, showing only static device settings such as interfaces, protocols, and policies. It does not capture operational state, current system status, logs, or dynamic routing information, which are often necessary for full troubleshooting. As a result, it provides an incomplete snapshot of the system's current condition, making it unsuitable for comprehensive diagnostic data collection.
B
show interfaces
Why wrong: This command provides detailed operational information about interfaces, including traffic statistics, error counters, and link status. However, it is limited to interface-specific data and does not gather system-wide information like routing tables, logs, processes, or configuration. For a broad snapshot of the system's health, this command is too narrow and would miss critical components of the overall state.
C
request support information
This is a Junos operational command that automatically collects a comprehensive set of system data, including configurations, interface statistics, routing tables, logs, system processes, and other diagnostic information into a single archive. It is designed specifically for troubleshooting and for providing a complete snapshot to Juniper support or for offline analysis. This one command aggregates far more data than any individual show command, making it the correct choice for a full system snapshot.
D
show route
Why wrong: This command displays the routing table, including active routes, next hops, and protocol-specific entries. While useful for network reachability analysis, it only covers the routing plane and not the overall system state such as interfaces, logs, or configuration. Thus, it gives a narrow view that cannot serve as a comprehensive system snapshot.

Full breakdown with real-world context →

Question 5mediummultiple choice

Read the full Operational Monitoring and Maintenance explanation →

A network engineer wants to schedule a reboot of a Juniper device at 3:00 AM. Which command should be used?

Trap 1: request system configuration rescue save

The `request system configuration rescue save` command saves the current active configuration as the rescue configuration in `/config/rescue.conf.gz`. It creates a known-good rollback snapshot that can be loaded if the normal configuration fails to commit or causes boot issues. This operation does not affect system uptime or schedule any reboot, so it cannot fulfill the engineer's requirement.

Trap 2: request system reboot

The plain `request system reboot` command triggers an immediate reboot of the Junos device, closing all active user sessions and restarting the control and forwarding planes. There is no time parameter, so Junos executes the reboot right away rather than waiting for a designated schedule. Since the engineer wants a reboot at 03:00, this command would reboot now, not at the intended time.

Trap 3: load override /config/juniper.conf.gz

The `load override /config/juniper.conf.gz` command is executed in configuration mode and replaces the candidate or active configuration with the contents of the specified file. It is a configuration-loading operation, not a system reboot command, and it has no scheduling effect on the device's power or restart cycle. Loading this file would alter the device's configuration but would not cause a reboot at 03:00.

Study all Operational Monitoring and Maintenance common traps →

A
request system configuration rescue save
Why wrong: The `request system configuration rescue save` command saves the current active configuration as the rescue configuration in `/config/rescue.conf.gz`. It creates a known-good rollback snapshot that can be loaded if the normal configuration fails to commit or causes boot issues. This operation does not affect system uptime or schedule any reboot, so it cannot fulfill the engineer's requirement.
B
request system reboot
Why wrong: The plain `request system reboot` command triggers an immediate reboot of the Junos device, closing all active user sessions and restarting the control and forwarding planes. There is no time parameter, so Junos executes the reboot right away rather than waiting for a designated schedule. Since the engineer wants a reboot at 03:00, this command would reboot now, not at the intended time.
C
request system reboot at 03:00
The `request system reboot at 03:00` command schedules the reboot to occur at 03:00 in the device's local time zone. Junos validates the time argument and queues the reboot, allowing the engineer to finish maintenance tasks before the device restarts. This is the exact operational command designed for a scheduled reboot at a specific time.
D
load override /config/juniper.conf.gz
Why wrong: The `load override /config/juniper.conf.gz` command is executed in configuration mode and replaces the candidate or active configuration with the contents of the specified file. It is a configuration-loading operation, not a system reboot command, and it has no scheduling effect on the device's power or restart cycle. Loading this file would alter the device's configuration but would not cause a reboot at 03:00.

Full breakdown with real-world context →

Question 6hardmultiple choice

Review the full routing breakdown →

A router is experiencing intermittent packet loss. The engineer runs 'show interfaces ge-0/0/0 extensive' and notices a high number of input errors but no output errors. What is the most likely cause?

Trap 1: The cable is too long

A cable run exceeding IEEE specifications (100m for twisted-pair) can introduce attenuation and crosstalk, but the immediate symptom is typically degraded signal-to-noise ratio, which may cause link flaps or excessive CRC errors — not the specific 'input errors' counter. Input errors on Junos interfaces are commonly tied to hardware or optics failures, not simple cable reach, and a length violation would likely cause sustained, not intermittent, issues.

Trap 2: MTU mismatch

MTU mismatch is a Layer 2/3 forwarding issue: when a frame arrives larger than the interface's configured MTU, it is discarded as a giant or fragmented, which appears in counters like 'giants' or as output drops, not as input errors. Input errors reflect physical-layer encoding or framing problems, whereas an MTU mismatch is a configuration mismatch that affects the transmit/receive path differently. Therefore, it would not cause the input error counter to increment in this scenario.

Trap 3: The interface is oversubscribed

Oversubscription occurs when aggregated ingress traffic exceeds an interface's egress capacity, causing packets to queue and eventually be dropped as output drops due to buffer exhaustion. This is a transmit-side congestion problem, entirely separate from the receive-side physical errors that the input error counter records. An oversubscribed interface would show output drops, not input errors, and would not produce the CRC or framing errors associated with this symptom.

Study all Operational Monitoring and Maintenance common traps →

A
The cable is too long
Why wrong: A cable run exceeding IEEE specifications (100m for twisted-pair) can introduce attenuation and crosstalk, but the immediate symptom is typically degraded signal-to-noise ratio, which may cause link flaps or excessive CRC errors — not the specific 'input errors' counter. Input errors on Junos interfaces are commonly tied to hardware or optics failures, not simple cable reach, and a length violation would likely cause sustained, not intermittent, issues.
B
A faulty transceiver
A faulty transceiver (SFP/SFP+/QSFP) is a classic source of receive-side errors: imperfect optical transmission or receiver degradation creates bit errors, FCS/CRC failures, and symbol errors that increment the input error counter. On Junos, an optics failure can appear intermittently as temperature or wavelength drifts, making it a prime suspect for sporadic packet loss with input errors. Swapping the optic is the standard first step to confirm.
C
MTU mismatch
Why wrong: MTU mismatch is a Layer 2/3 forwarding issue: when a frame arrives larger than the interface's configured MTU, it is discarded as a giant or fragmented, which appears in counters like 'giants' or as output drops, not as input errors. Input errors reflect physical-layer encoding or framing problems, whereas an MTU mismatch is a configuration mismatch that affects the transmit/receive path differently. Therefore, it would not cause the input error counter to increment in this scenario.
D
The interface is oversubscribed
Why wrong: Oversubscription occurs when aggregated ingress traffic exceeds an interface's egress capacity, causing packets to queue and eventually be dropped as output drops due to buffer exhaustion. This is a transmit-side congestion problem, entirely separate from the receive-side physical errors that the input error counter records. An oversubscribed interface would show output drops, not input errors, and would not produce the CRC or framing errors associated with this symptom.

Full breakdown with real-world context →

Question 7easymultiple choice

Read the full Operational Monitoring and Maintenance explanation →

An engineer needs to check the last time the configuration was changed. Which command provides this information?

Trap 1: show configuration | display set

show configuration | display set is incorrect because it only renders the current active configuration as a series of set commands, not a historical record. This output has no timestamp or metadata about when each statement was added or modified, so it cannot reveal the last configuration change time. It merely shows the final result of all previous commits, not the commit history itself.

Trap 2: show system alarms

show system alarms is incorrect because it displays only active system alarms, such as hardware faults, software failures, or environmental issues. While some alarms may be configuration-related, this command does not provide any commit history or timestamps for configuration changes. Its purpose is to indicate current operational problems, not to audit when the configuration was last modified.

Trap 3: show system uptime

show system uptime is incorrect because it reports the time since the last system reboot, the current time, and load averages. The uptime value is entirely unrelated to the last configuration commit; a router can run for months without a config change, or be rebooted shortly after a commit. Therefore, this command cannot be used to determine when the configuration was last changed.

Study all Operational Monitoring and Maintenance common traps →

A
show system commit
show system commit is correct because it directly displays the commit log, which records every configuration commit along with the timestamp, user, and commit comment. By listing each commit event, it provides the exact last time the configuration was changed and saved as an active operational state. This command is the standard way to audit configuration change history on Junos devices.
B
show configuration | display set
Why wrong: show configuration | display set is incorrect because it only renders the current active configuration as a series of set commands, not a historical record. This output has no timestamp or metadata about when each statement was added or modified, so it cannot reveal the last configuration change time. It merely shows the final result of all previous commits, not the commit history itself.
C
show system alarms
Why wrong: show system alarms is incorrect because it displays only active system alarms, such as hardware faults, software failures, or environmental issues. While some alarms may be configuration-related, this command does not provide any commit history or timestamps for configuration changes. Its purpose is to indicate current operational problems, not to audit when the configuration was last modified.
D
show system uptime
Why wrong: show system uptime is incorrect because it reports the time since the last system reboot, the current time, and load averages. The uptime value is entirely unrelated to the last configuration commit; a router can run for months without a config change, or be rebooted shortly after a commit. Therefore, this command cannot be used to determine when the configuration was last changed.

Full breakdown with real-world context →

Question 8mediummultiple choice

Open the full BGP breakdown →

A BGP session is flapping. The engineer runs 'show log messages' and sees 'BGP recv Notification' with error code 'Cease'. What does this indicate?

Trap 1: The BGP table is full

A full BGP table does not cause the router to send a BGP Cease notification. When the routing table reaches its limit, the router may experience memory pressure or drop new routes, but the BGP session itself remains operational. The Cease error code specifically indicates that the remote peer decided to terminate the session for administrative or policy reasons, not because of local resource exhaustion. Therefore, the table being full is not the correct explanation for the logged Cease message.

Trap 2: The hold timer expired

Hold timer expiry produces a different BGP notification code (Hold Timer Expired, code 4), not the Cease code (6) seen in the syslog. During a hold timer expiry, the local router has not received any keepalive or update messages within the configured hold interval, so it declares the peer unreachable and sends a Hold Timer Expired notification. In contrast, the log entry shows a Cease notification, which is sent when the peer actively closes the session. Thus, the hold timer scenario would generate a distinct error, making this option incorrect.

Trap 3: The interface went down

If the interface had gone down, the underlying TCP session would break immediately, resulting in a TCP reset or a loss of connectivity rather than a BGP Cease notification. BGP would eventually transition to the Idle state after the hold timer expires, but before that, the router would not have a chance to send a BGP NOTIFICATION. The Cease code in the log proves that a BGP protocol-level message was exchanged before the session terminated, which cannot happen if the link itself failed. Therefore, an interface down event is not the cause of this specific log entry.

Study all Operational Monitoring and Maintenance common traps →

A
The BGP table is full
Why wrong: A full BGP table does not cause the router to send a BGP Cease notification. When the routing table reaches its limit, the router may experience memory pressure or drop new routes, but the BGP session itself remains operational. The Cease error code specifically indicates that the remote peer decided to terminate the session for administrative or policy reasons, not because of local resource exhaustion. Therefore, the table being full is not the correct explanation for the logged Cease message.
B
The hold timer expired
Why wrong: Hold timer expiry produces a different BGP notification code (Hold Timer Expired, code 4), not the Cease code (6) seen in the syslog. During a hold timer expiry, the local router has not received any keepalive or update messages within the configured hold interval, so it declares the peer unreachable and sends a Hold Timer Expired notification. In contrast, the log entry shows a Cease notification, which is sent when the peer actively closes the session. Thus, the hold timer scenario would generate a distinct error, making this option incorrect.
C
The remote peer closed the connection
A BGP Cease notification indicates that the remote peer explicitly sent a NOTIFICATION message to terminate the BGP session. The Cease error code (6) covers several subcodes, such as administrative shutdown, peer de-configured, or local system restart, but all mean the remote peer closed the connection at the BGP protocol level. Because the log specifically records a Cease, the most direct inference is that the remote peer closed the connection, thereby causing the session to flap. This is why this is the correct answer.
D
The interface went down
Why wrong: If the interface had gone down, the underlying TCP session would break immediately, resulting in a TCP reset or a loss of connectivity rather than a BGP Cease notification. BGP would eventually transition to the Idle state after the hold timer expires, but before that, the router would not have a chance to send a BGP NOTIFICATION. The Cease code in the log proves that a BGP protocol-level message was exchanged before the session terminated, which cannot happen if the link itself failed. Therefore, an interface down event is not the cause of this specific log entry.

Full breakdown with real-world context →

Question 9mediummulti select

Read the full Operational Monitoring and Maintenance explanation →

Which THREE statements are true about the 'show interfaces ge-0/0/0 extensive' command output?

Trap 1: It includes only layer 1 information

This statement is false because 'show interfaces extensive' aggregates information from multiple layers of the OSI model. While it does include Layer 1 physical properties like link state and media type, it also reports Layer 2 statistics such as MAC packet counts and VLAN membership, and Layer 3 details like configured IP addresses and MTU size. Therefore, the output is a multi-layer snapshot rather than being limited to Layer 1 alone.

Trap 2: It shows the interface configuration

This is incorrect because 'show interfaces extensive' displays operational runtime data, such as link status, protocol state, and live counters, not the configured settings of the interface. The configuration is stored in a separate configuration database and can be viewed with 'show configuration interfaces' or 'edit' mode. The operational output may differ from the configuration if the daemon has not fully applied settings or if the interface is in a failed state.

Study all Operational Monitoring and Maintenance common traps →

A
It displays a detailed count of errors
The extensive output of 'show interfaces extensive' provides a granular breakdown of error counters for both received and transmitted traffic, including CRC errors, framing errors, runts, giants, and various drop counters. These counters help diagnose physical-layer issues such as cabling problems, duplex mismatches, or faulty hardware, and they are updated in real time as traffic passes through the interface. Without this detailed error information, isolating interface-level faults would require additional commands or packet captures.
B
It includes only layer 1 information
Why wrong: This statement is false because 'show interfaces extensive' aggregates information from multiple layers of the OSI model. While it does include Layer 1 physical properties like link state and media type, it also reports Layer 2 statistics such as MAC packet counts and VLAN membership, and Layer 3 details like configured IP addresses and MTU size. Therefore, the output is a multi-layer snapshot rather than being limited to Layer 1 alone.
C
It provides traffic statistics
The extensive command includes comprehensive traffic statistics, showing packet and byte counts for unicast, multicast, and broadcast traffic in both the input and output directions. It also provides instantaneous and average packet rate data, which is essential for monitoring interface utilization and identifying traffic anomalies. These statistics are critical for performance tuning and for verifying that traffic is being forwarded as expected.
D
It shows the interface configuration
Why wrong: This is incorrect because 'show interfaces extensive' displays operational runtime data, such as link status, protocol state, and live counters, not the configured settings of the interface. The configuration is stored in a separate configuration database and can be viewed with 'show configuration interfaces' or 'edit' mode. The operational output may differ from the configuration if the daemon has not fully applied settings or if the interface is in a failed state.
E
It indicates the administrative status
One key field in the extensive output is the administrative status, which indicates whether the interface has been administratively enabled ('up') or disabled ('down') by the operator. This is distinct from the operational status, which reflects the actual state of the link; an interface can be administratively up but operationally down due to a physical fault. Knowing this distinction is essential for troubleshooting, as it points to either a configuration issue or a hardware/cabling problem.

Full breakdown with real-world context →

Question 10hardmulti select

Review the full routing breakdown →

Which THREE commands are used for operational monitoring of routing protocols?

Trap 1: show interfaces terse

The show interfaces terse command does not provide routing protocol monitoring; it merely displays a summary of all configured interfaces with their administrative and link status. While it can indicate whether a physical or logical interface is Up, it cannot show whether a routing protocol neighbor is established or any protocol-specific state. Therefore, it is not useful for operational monitoring of OSPF, IS-IS, or BGP adjacencies.

Trap 2: show arp

The show arp command is irrelevant to routing protocol monitoring because it displays the Address Resolution Protocol cache, which maps IP addresses to physical MAC addresses on a local network. It has no visibility into the state of IS-IS, OSPF, or BGP adjacencies, nor does it show routing protocol sessions. Its purpose is purely for layer-2 connectivity verification, not for operational status of dynamic routing protocols.

Study all Operational Monitoring and Maintenance common traps →

A
show isis adjacency
The show isis adjacency command is the dedicated operational command for verifying IS-IS protocol peering. It displays the state of each adjacent neighbor (Up, Down, or Initializing), the interface via which the adjacency is formed, and the holdtime exchanged in hello PDUs. A network administrator uses this to confirm that Level 1 and/or Level 2 adjacencies are established and to troubleshoot IS-IS convergence.
B
show ospf neighbor
The show ospf neighbor command is the operational monitoring tool for OSPF adjacency status. It lists each neighbor router by its router ID, the local interface used for the adjacency, the neighbor's current state (e.g., Full, ExStart, or 2-Way), and the dead-time interval. This command allows an administrator to verify that OSPF neighbors have reached the Full state, confirming database synchronization and proper routing operation.
C
show interfaces terse
Why wrong: The show interfaces terse command does not provide routing protocol monitoring; it merely displays a summary of all configured interfaces with their administrative and link status. While it can indicate whether a physical or logical interface is Up, it cannot show whether a routing protocol neighbor is established or any protocol-specific state. Therefore, it is not useful for operational monitoring of OSPF, IS-IS, or BGP adjacencies.
D
show bgp summary
The show bgp summary command is specifically used for operational monitoring of BGP sessions. It displays each configured peer, its identifier, the current session state (such as Established, Active, or Connect), the number of routes received and advertised, and the up-time of the session. This command is essential for verifying whether BGP peering is established and for quickly assessing route exchange health across the network.
E
show arp
Why wrong: The show arp command is irrelevant to routing protocol monitoring because it displays the Address Resolution Protocol cache, which maps IP addresses to physical MAC addresses on a local network. It has no visibility into the state of IS-IS, OSPF, or BGP adjacencies, nor does it show routing protocol sessions. Its purpose is purely for layer-2 connectivity verification, not for operational status of dynamic routing protocols.

Full breakdown with real-world context →

Question 11mediummulti select

Read the full Operational Monitoring and Maintenance explanation →

Which TWO statements are correct about the 'monitor interface' command?

Trap 1: It shows a static snapshot

A static snapshot would show one instant of data and never change until you re-issue the command, but monitor interface repaints the entire screen with current values on every refresh cycle. Because counters increment and rates are recalculated continuously, the output is inherently dynamic and cannot be a static snapshot.

Trap 2: It requires a 'start' parameter

The command syntax is simply 'monitor interface <interface-name>' and monitoring begins immediately upon execution. There is no 'start' parameter to trigger the process; the Junos CLI starts the real-time display as soon as the command is entered, so any statement requiring a 'start' parameter is incorrect.

Trap 3: It provides historical statistics

This command shows only the current values and rates computed since the interface counters were last cleared or since the monitoring session began. It does not retrieve historical statistics such as past utilization trends or archived counter snapshots; historical data would have to be collected separately through SNMP polling, logging, or a management system.

Study all Operational Monitoring and Maintenance common traps →

A
It displays output in real-time
The monitor interface command on Junos enters an interactive display that refreshes at a fixed interval (one second by default), so interface counters, input/output rates, and error counts update live on the console. This real-time behavior is what makes it useful for observing transient link problems or verifying that traffic is flowing while you perform tests.
B
It shows a static snapshot
Why wrong: A static snapshot would show one instant of data and never change until you re-issue the command, but monitor interface repaints the entire screen with current values on every refresh cycle. Because counters increment and rates are recalculated continuously, the output is inherently dynamic and cannot be a static snapshot.
C
It can be terminated with Ctrl+C
Because monitor interface runs as a continuous, interactive process, it occupies the terminal until you stop it. Pressing Ctrl+C sends an interrupt that terminates the monitoring session and returns you to the Junos CLI prompt, making it the standard way to exit the display. No separate 'stop' command is needed.
D
It requires a 'start' parameter
Why wrong: The command syntax is simply 'monitor interface <interface-name>' and monitoring begins immediately upon execution. There is no 'start' parameter to trigger the process; the Junos CLI starts the real-time display as soon as the command is entered, so any statement requiring a 'start' parameter is incorrect.
E
It provides historical statistics
Why wrong: This command shows only the current values and rates computed since the interface counters were last cleared or since the monitoring session began. It does not retrieve historical statistics such as past utilization trends or archived counter snapshots; historical data would have to be collected separately through SNMP polling, logging, or a management system.

Full breakdown with real-world context →

Question 12mediummultiple choice

Review the full OSPF breakdown →

You are troubleshooting an OSPF issue on a Juniper router. The router has a single interface ge-0/0/1 with IP 10.1.1.1/30 connected to a neighbor with IP 10.1.1.2/30. OSPF is configured area 0. The 'show ospf neighbor' command shows no neighbors. 'show interfaces ge-0/0/1 terse' shows the interface is up. 'show configuration protocols ospf' shows:

area 0.0.0.0 {
       interface ge-0/0/1.0 {

passive;

}
   }

What is the problem?

Trap 1: The hello timer is too slow

A hello timer that is too slow still allows hellos to be sent, only at longer intervals than the default 10 seconds on broadcast interfaces. OSPF requires matching hello intervals between neighbors, but even a mismatched or slow timer would still generate packets and could eventually form an adjacency if intervals align. The absence of any neighbor in the OSPF database indicates that no hellos are being transmitted at all, which is characteristic of a passive interface, not a slow timer.

Trap 2: Authentication is missing

OSPF authentication is an optional feature and not enabled by default. If authentication were configured on one side but not the other, it would cause a checksum or key mismatch and prevent adjacency formation. However, the problem statement gives no indication that authentication is configured on the router, and OSPF operates normally without it. The lack of neighbors is better explained by a passive interface, which suppresses hellos regardless of authentication settings.

Trap 3: The interface is administratively down

An administratively down interface would be displayed in a 'down' state in the interface terse output, and OSPF would not run on it because the physical or logical link is disabled. The provided terse output explicitly shows the interface is up, ruling out any administrative shutdown as the cause. Administrative down is also a deliberate action that disables all traffic, whereas a passive interface leaves the interface operational but restricts only OSPF hello processing.

Study all Operational Monitoring and Maintenance common traps →

A
The OSPF interface is configured as passive
Setting an OSPF interface to passive in Junos disables hello packet transmission entirely on that interface. Without hellos, the router cannot discover neighbors or form an adjacency, so the OSPF neighbor state remains Down. The interface stays administratively and protocol up, but OSPF treats it as a stub network, advertising the subnet while never establishing a neighbor relationship. This directly matches a terse output showing the interface up and no OSPF neighbors.
B
The hello timer is too slow
Why wrong: A hello timer that is too slow still allows hellos to be sent, only at longer intervals than the default 10 seconds on broadcast interfaces. OSPF requires matching hello intervals between neighbors, but even a mismatched or slow timer would still generate packets and could eventually form an adjacency if intervals align. The absence of any neighbor in the OSPF database indicates that no hellos are being transmitted at all, which is characteristic of a passive interface, not a slow timer.
C
Authentication is missing
Why wrong: OSPF authentication is an optional feature and not enabled by default. If authentication were configured on one side but not the other, it would cause a checksum or key mismatch and prevent adjacency formation. However, the problem statement gives no indication that authentication is configured on the router, and OSPF operates normally without it. The lack of neighbors is better explained by a passive interface, which suppresses hellos regardless of authentication settings.
D
The interface is administratively down
Why wrong: An administratively down interface would be displayed in a 'down' state in the interface terse output, and OSPF would not run on it because the physical or logical link is disabled. The provided terse output explicitly shows the interface is up, ruling out any administrative shutdown as the cause. Administrative down is also a deliberate action that disables all traffic, whereas a passive interface leaves the interface operational but restricts only OSPF hello processing.

Full breakdown with real-world context →

Question 13mediummultiple choice

Review the full routing breakdown →

A network engineer notices that traffic to a critical server is being dropped intermittently. The server is reachable via a static route on the Juniper router. The engineer checks the routing table and sees the route is present. Which operational command should the engineer use next to isolate the issue?

Trap 1: show interfaces terse

show interfaces terse displays a compact summary of physical and logical interface status, including administrative and operational states and IP addresses. It offers no visibility into the Packet Forwarding Engine's (PFE) forwarding decisions, next-hop resolution, or any packet drops for a specific destination. Since the problem is traffic not reaching a critical server, this command cannot reveal why forwarded packets are being dropped.

Trap 2: show route 10.0.0.1

show route 10.0.0.1 queries the Routing Engine's inet.0 routing table (RIB), confirming that the route is present in the control plane. However, the very issue is that traffic is not reaching the server despite the route existing, meaning the control plane has the route but the forwarding plane may not. This command does not inspect the kernel forwarding state or the PFE's forwarding table, so it cannot diagnose a missing or stale FIB entry or an incorrect next hop that causes drops.

Trap 3: show arp

show arp displays the Address Resolution Protocol cache, mapping IP addresses to MAC addresses for directly connected neighbors. It would be relevant only if the critical server were on a local subnet and you suspected an L2 adjacency problem. In this scenario, the traffic forwarding is failing despite the route present, so ARP is not the right diagnostic; it cannot reveal forwarding drops, next-hop issues, or FIB inconsistencies that occur in the PFE.

Study all Operational Monitoring and Maintenance common traps →

A
show interfaces terse
Why wrong: show interfaces terse displays a compact summary of physical and logical interface status, including administrative and operational states and IP addresses. It offers no visibility into the Packet Forwarding Engine's (PFE) forwarding decisions, next-hop resolution, or any packet drops for a specific destination. Since the problem is traffic not reaching a critical server, this command cannot reveal why forwarded packets are being dropped.
B
show route 10.0.0.1
Why wrong: show route 10.0.0.1 queries the Routing Engine's inet.0 routing table (RIB), confirming that the route is present in the control plane. However, the very issue is that traffic is not reaching the server despite the route existing, meaning the control plane has the route but the forwarding plane may not. This command does not inspect the kernel forwarding state or the PFE's forwarding table, so it cannot diagnose a missing or stale FIB entry or an incorrect next hop that causes drops.
C
show arp
Why wrong: show arp displays the Address Resolution Protocol cache, mapping IP addresses to MAC addresses for directly connected neighbors. It would be relevant only if the critical server were on a local subnet and you suspected an L2 adjacency problem. In this scenario, the traffic forwarding is failing despite the route present, so ARP is not the right diagnostic; it cannot reveal forwarding drops, next-hop issues, or FIB inconsistencies that occur in the PFE.
D
show route forwarding-table destination 10.0.0.1
show route forwarding-table destination 10.0.0.1 is the correct command because it queries the Packet Forwarding Engine's forwarding table (FIB) for the specific destination. While show route only shows the RIB in the Routing Engine, this command reveals the actual entry the PFE uses to forward packets, including the resolved next hop and output interface. If the route exists in the RIB but traffic is dropped, this command can expose a missing or stale forwarding entry, an incorrect next hop, or a drop caused by a firewall filter applied in the forwarding path.

Full breakdown with real-world context →

Question 14hardmulti select

Read the full Operational Monitoring and Maintenance explanation →

Which THREE statements about the 'request system snapshot' command are true? (Choose three.)

Trap 1: It compresses the backup to save space.

Snapshots in Junos do not perform any form of compression. The operation copies the root filesystem's contents verbatim to the destination media, preserving the exact files, permissions, and structure needed to make the media bootable. Compressing the image would prevent the media from being used as a direct boot device, since the device would need a separate unpacking step before booting. Therefore, the size of the snapshot equals the installed software and configuration, not a compressed archive.

Trap 2: It copies the active partition to the alternate partition on the…

This option incorrectly describes the behavior of 'request system partition' or 'request system software add' operations. A snapshot does not copy partitions to another partition on the same physical disk; instead, it duplicates the entire system to a completely separate, bootable medium. The internal partitioning commands are used for software installation or partitioning the internal storage, not for creating recovery media. Misunderstanding this distinction can lead you to expect a snapshot to work during a primary disk failure when it actually requires a different destination.

Study all Operational Monitoring and Maintenance common traps →

A
It creates a recovery media for the device.
A 'request system snapshot' creates a complete, bootable image of the running Junos OS and its configuration, written to a designated alternate media such as a USB drive or a second internal flash device. This media becomes a recovery medium, allowing you to boot the device from it in the event the primary boot disk fails or becomes corrupted. Unlike a simple configuration backup, this is a full system image that can independently boot the router or switch.
B
It compresses the backup to save space.
Why wrong: Snapshots in Junos do not perform any form of compression. The operation copies the root filesystem's contents verbatim to the destination media, preserving the exact files, permissions, and structure needed to make the media bootable. Compressing the image would prevent the media from being used as a direct boot device, since the device would need a separate unpacking step before booting. Therefore, the size of the snapshot equals the installed software and configuration, not a compressed archive.
C
It backs up the current Junos OS and configuration to alternate media.
The fundamental purpose of 'request system snapshot' is to back up the current Junos OS, configuration, and all associated files to an alternate medium. This creates a standby copy that is identical and immediately usable. The alternate media can be a USB drive, a removable compact flash card, or a second internal disk, depending on the platform. This full-system backup is essential for disaster recovery because it captures everything needed to run the device, not just the configuration files.
D
It copies the active partition to the alternate partition on the same media.
Why wrong: This option incorrectly describes the behavior of 'request system partition' or 'request system software add' operations. A snapshot does not copy partitions to another partition on the same physical disk; instead, it duplicates the entire system to a completely separate, bootable medium. The internal partitioning commands are used for software installation or partitioning the internal storage, not for creating recovery media. Misunderstanding this distinction can lead you to expect a snapshot to work during a primary disk failure when it actually requires a different destination.
E
It can be used to restore the software and configuration in case of failure.
Snapshots are explicitly designed for restoration after a system failure or upgrade mishap. If the device loses its primary boot software, you can boot from the snapshot media and restore the system to the exact state captured at snapshot time. This restoration process typically includes reloading the Junos OS, configuration, and any saved data. The ability to restore from a snapshot makes it a critical component of a high-availability and disaster-recovery strategy for Junos devices.

Full breakdown with real-world context →

Question 15easymultiple choice

Read the full Operational Monitoring and Maintenance explanation →

Based on the exhibit, which protocol is enabled on interface ge-0/0/0.0?

Exhibit

Refer to the exhibit.

user@router> show interfaces ge-0/0/0.0
  Logical interface ge-0/0/0.0 (Index 70) (SNMP ifIndex 521)
    Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2
    Input packets : 1500
    Output packets: 1200
    Security: Zone: Trust
    Allowed host-inbound traffic : any-service
    Protocols:
      inet:
        10.0.0.1/24
      iso:
      mpls:
        Maximum labels: 3
      multiservice:
        encapsulation: ethernet-ccc

Trap 1: IS-IS

In the exhibit, the interface configuration contains no IS-IS adjacency configuration. IS-IS would appear under 'protocols isis' with an 'interface' statement, not as a protocol family like 'family mpls'. Unless the interface is explicitly listed in the IS-IS configuration, the protocol is not enabled there. Since no such configuration is shown, IS-IS is not enabled on this interface.

Trap 2: BGP

BGP is not a Layer 2 or Layer 3 protocol family that you enable on an interface in Junos; it is a TCP-based protocol whose sessions are configured at the [edit protocols bgp] hierarchy level. The exhibit only displays per-interface family settings, and BGP does not appear as one of those families. Therefore BGP cannot be the protocol enabled on this interface; it would require an IP address family like 'inet' for its underlying TCP transport, not a dedicated BGP family.

Trap 3: OSPF

OSPF is a routing protocol that is enabled by referencing an interface in a protocol stanza, not by setting a protocol family directly in the interface hierarchy. In Junos, OSPF adjacency parameters are configured under 'protocols ospf area', and the interface is merely listed there; no 'family ospf' exists in the interface unit. The exhibit does not show such an OSPF area or interface statement, so OSPF is not enabled on this interface; the only protocol family present is MPLS.

Study all Operational Monitoring and Maintenance common traps →

A
IS-IS
Why wrong: In the exhibit, the interface configuration contains no IS-IS adjacency configuration. IS-IS would appear under 'protocols isis' with an 'interface' statement, not as a protocol family like 'family mpls'. Unless the interface is explicitly listed in the IS-IS configuration, the protocol is not enabled there. Since no such configuration is shown, IS-IS is not enabled on this interface.
B
BGP
Why wrong: BGP is not a Layer 2 or Layer 3 protocol family that you enable on an interface in Junos; it is a TCP-based protocol whose sessions are configured at the [edit protocols bgp] hierarchy level. The exhibit only displays per-interface family settings, and BGP does not appear as one of those families. Therefore BGP cannot be the protocol enabled on this interface; it would require an IP address family like 'inet' for its underlying TCP transport, not a dedicated BGP family.
C
MPLS
MPLS is enabled on the interface because the exhibit shows 'family mpls' under the interface unit, which instructs the router to process MPLS-labeled packets on that logical interface. This family is required before you can configure MPLS applications like LDP, RSVP, or a static label-switched path. That is why MPLS is the correct protocol indicated by the exhibit; it is the only protocol family explicitly present under the interface configuration.
D
OSPF
Why wrong: OSPF is a routing protocol that is enabled by referencing an interface in a protocol stanza, not by setting a protocol family directly in the interface hierarchy. In Junos, OSPF adjacency parameters are configured under 'protocols ospf area', and the interface is merely listed there; no 'family ospf' exists in the interface unit. The exhibit does not show such an OSPF area or interface statement, so OSPF is not enabled on this interface; the only protocol family present is MPLS.

Full breakdown with real-world context →

Question 16hardmultiple choice

Review the full routing breakdown →

You are the network administrator for a large enterprise with a Juniper MX480 router running Junos 18.2R3. The router has two Routing Engines (RE0 and RE1) in a graceful Routing Engine switchover (GRES) configuration. During a scheduled maintenance window, you need to upgrade the Junos OS to a newer version while minimizing traffic loss. The upgrade process requires a reboot of both REs. You have staged the software on both REs. Which sequence of commands should you use to perform the upgrade with minimal disruption?

Trap 1: On both REs: request system software add <image>; then request…

Issuing the add and reboot commands on both REs at the same time removes chassis redundancy during the upgrade window. Both control planes go offline concurrently, which drops routing, management, and any services that rely on the Routing Engine. The whole point of a dual-RE system is to keep one RE available while the other is upgraded, so this approach guarantees an outage and is never acceptable.

Trap 2: On RE0: request system software add <image> re0; on RE1: request…

This sequence stages the new image on both REs but then reboots them together, without first making the backup active. Because the primary is still running when both REs restart, the system loses its active control plane at the same time as the backup. A clean NSSU-style upgrade requires upgrading and rebooting the backup, switching mastership, and only then rebooting the old primary. Skipping the switchover means the new software on the old primary is never properly validated before it is used.

Trap 3: On RE0 (primary): request system software add <image> re0; request…

Upgrading RE0 (primary) first and rebooting it leaves the backup RE1 running the old version as the only control plane, and the primary reboot triggers a switchover before the new image has been verified. More importantly, the primary is rebooted while it is still the active Routing Engine; even if RE1 takes over, the disruption is unnecessarily large because the proper procedure dictates that the backup be upgraded and rebooted first. The accepted approach is to make the backup the mastership target, not to force the primary down while it is still active.

Study all Operational Monitoring and Maintenance common traps →

A
On both REs: request system software add <image>; then request system reboot both REs simultaneously.
Why wrong: Issuing the add and reboot commands on both REs at the same time removes chassis redundancy during the upgrade window. Both control planes go offline concurrently, which drops routing, management, and any services that rely on the Routing Engine. The whole point of a dual-RE system is to keep one RE available while the other is upgraded, so this approach guarantees an outage and is never acceptable.
B
On RE0: request system software add <image> re0; on RE1: request system software add <image> re1; then request system reboot both.
Why wrong: This sequence stages the new image on both REs but then reboots them together, without first making the backup active. Because the primary is still running when both REs restart, the system loses its active control plane at the same time as the backup. A clean NSSU-style upgrade requires upgrading and rebooting the backup, switching mastership, and only then rebooting the old primary. Skipping the switchover means the new software on the old primary is never properly validated before it is used.
C
On RE0 (primary): request system software add <image> re0; request system reboot re0. After reboot, on RE1: request system software add <image> re1; request system reboot re1.
Why wrong: Upgrading RE0 (primary) first and rebooting it leaves the backup RE1 running the old version as the only control plane, and the primary reboot triggers a switchover before the new image has been verified. More importantly, the primary is rebooted while it is still the active Routing Engine; even if RE1 takes over, the disruption is unnecessarily large because the proper procedure dictates that the backup be upgraded and rebooted first. The accepted approach is to make the backup the mastership target, not to force the primary down while it is still active.
D
On RE1 (backup): request system software add <image> re1; request system reboot re1. After reboot, request chassis routing-engine master switch. On RE0 (now backup): request system software add <image> re0; request system reboot re0.
This is the correct minimal-disruption procedure for a dual-RE upgrade. The backup RE1 is upgraded and rebooted first while RE0 continues to carry the control plane; after RE1 returns, a mastership switch makes RE1 active. Only then is the old primary RE0 (now backup) upgraded and rebooted, so at least one Routing Engine is always up. With graceful Routing Engine switchover (GRES) and nonstop routing/active routing configured, the switchover can be hitless.

Full breakdown with real-world context →

Question 17mediummulti select

Read the full Operational Monitoring and Maintenance explanation →

Which THREE statements correctly describe the use of the 'monitor traffic' command in Junos?

Trap 1: It captures packets from the Routing Engine only.

This statement is incorrect because 'monitor traffic' captures packets on the specified network data path interface, not exclusively from or to the Routing Engine. While the command is executed from the RE, it sees all traffic that crosses the selected interface, including forwarding-plane traffic that never reaches the RE. To capture only RE-specific control-plane traffic, you would need a different mechanism, such as 'monitor traffic interface lo0' or traceoptions on specific protocols, but the default behavior covers both planes on the chosen interface.

Trap 2: It requires a reboot to start capturing packets.

This statement is incorrect because 'monitor traffic' is a CLI-based operational command that starts capturing packets immediately after invocation, without any need to reboot the device. A reboot would actually terminate the monitoring session and is completely unnecessary for initiating packet capture. The command runs in the foreground and can be stopped with Ctrl+C, making it a lightweight, on-demand diagnostic tool.

Study all Operational Monitoring and Maintenance common traps →

A
It captures packets from the Routing Engine only.
Why wrong: This statement is incorrect because 'monitor traffic' captures packets on the specified network data path interface, not exclusively from or to the Routing Engine. While the command is executed from the RE, it sees all traffic that crosses the selected interface, including forwarding-plane traffic that never reaches the RE. To capture only RE-specific control-plane traffic, you would need a different mechanism, such as 'monitor traffic interface lo0' or traceoptions on specific protocols, but the default behavior covers both planes on the chosen interface.
B
It can filter packets using the 'matching' option to capture only specific traffic.
This statement is correct because the 'matching' option in 'monitor traffic' accepts a Berkeley Packet Filter (BPF) expression, such as 'host 192.0.2.1' or 'tcp port 443', to restrict which packets are captured and displayed. This allows the engineer to focus on specific traffic of interest, reducing the volume of output and making troubleshooting more efficient. The BPF syntax is identical to that used by tcpdump, so those familiar with packet filtering can apply the same knowledge directly.
C
It captures packets on a specific interface and displays them in real-time.
This statement is correct because the 'monitor traffic' command in Junos, when used with the 'interface' option, binds to a specific network interface and immediately starts displaying captured packets in real time on the terminal. It functions similarly to tcpdump, showing packet headers and payloads as they traverse the interface without requiring any preliminary steps. This is the standard operational mode for live troubleshooting and zeroing in on traffic patterns as they occur.
D
It requires a reboot to start capturing packets.
Why wrong: This statement is incorrect because 'monitor traffic' is a CLI-based operational command that starts capturing packets immediately after invocation, without any need to reboot the device. A reboot would actually terminate the monitoring session and is completely unnecessary for initiating packet capture. The command runs in the foreground and can be stopped with Ctrl+C, making it a lightweight, on-demand diagnostic tool.
E
It reads packets from a previously saved pcap file.
This statement is correct because the 'file' option in 'monitor traffic' allows Junos to read and replay packets from a previously saved pcap file, which could have been generated by the same command or another packet capture tool. This enables offline analysis of traffic that was captured at an earlier time or possibly on a different device. The command processes the file as a live source, applying the same display and filtering options, which is particularly useful for post-incident review without affecting the network.

Full breakdown with real-world context →

Question 18hardmultiple choice

Read the full Operational Monitoring and Maintenance explanation →

Refer to the exhibit. A network engineer sees repeated 'PFE interrupt error' messages in the log for fpc0. What is the most likely impact and recommended action?

Exhibit

Refer to the exhibit.

user@router> show log messages | match "fpc0"
Dec 10 14:22:01 router fpc0 MCSCHED: PFE interrupt error, restarting...
Dec 10 14:22:05 router fpc0 MCSCHED: PFE interrupt error, restarting...
Dec 10 14:22:09 router fpc0 MCSCHED: PFE interrupt error, restarting...
Dec 10 14:22:13 router fpc0 MCSCHED: PFE interrupt error, restarting...
Dec 10 14:22:17 router fpc0 MCSCHED: PFE interrupt error, restarting...

Trap 1: Remove and reinsert the PIC on FPC0 to reseat the connection.

Re-seating a PIC only remakes the mechanical/electrical connection between the PIC and the FPC midplane. The PFE is an integral hardware component of the FPC itself, containing the forwarding ASICs and memory, so a PIC reseat cannot affect the PFE's state. The reported repeated PFE interrupts indicate a failure on the FPC's own forwarding hardware, not a loose interface card.

Trap 2: Restart the PFE process using 'restart pfe' command.

The 'restart pfe' command would only restart the forwarding process flow, but the FPC has already automatically restarted and flapped itself offline due to repeated PFE hardware faults. A software-level restart cannot heal physical degradation such as ECC memory errors or ASIC overheating on the line card. After a manual restart, the same failing interrupt pattern would reoccur, so this is at best a temporary and ineffective measure.

Trap 3: Perform a software upgrade on the router to fix a known bug.

Upgrading Junos is only appropriate when the PFE interrupt pattern matches a known, fixed software bug, and the FPC recovers after the upgrade. Here, the error repeats continuously on FPC0, persists through reboots, and is accompanied by actual traffic loss, all of which point to failing silicon rather than a bug. A software upgrade will not replace damaged hardware or alter the mechanical/electrical behavior of the faulty line card.

Study all Operational Monitoring and Maintenance common traps →

A
Remove and reinsert the PIC on FPC0 to reseat the connection.
Why wrong: Re-seating a PIC only remakes the mechanical/electrical connection between the PIC and the FPC midplane. The PFE is an integral hardware component of the FPC itself, containing the forwarding ASICs and memory, so a PIC reseat cannot affect the PFE's state. The reported repeated PFE interrupts indicate a failure on the FPC's own forwarding hardware, not a loose interface card.
B
Restart the PFE process using 'restart pfe' command.
Why wrong: The 'restart pfe' command would only restart the forwarding process flow, but the FPC has already automatically restarted and flapped itself offline due to repeated PFE hardware faults. A software-level restart cannot heal physical degradation such as ECC memory errors or ASIC overheating on the line card. After a manual restart, the same failing interrupt pattern would reoccur, so this is at best a temporary and ineffective measure.
C
Perform a software upgrade on the router to fix a known bug.
Why wrong: Upgrading Junos is only appropriate when the PFE interrupt pattern matches a known, fixed software bug, and the FPC recovers after the upgrade. Here, the error repeats continuously on FPC0, persists through reboots, and is accompanied by actual traffic loss, all of which point to failing silicon rather than a bug. A software upgrade will not replace damaged hardware or alter the mechanical/electrical behavior of the faulty line card.
D
Replace the line card (FPC0) as it is experiencing hardware failures causing traffic loss.
Repeated PFE interrupts on FPC0 indicate that the Packet Forwarding Engine hardware on that line card is failing; each interrupt corresponds to the FPC being reset and taken out of service. Since the FPC cannot forward traffic and the errors are contiguous, the only correct remediation is to physically remove and replace the line card. Junos will then re-initialize the new FPC and restore forwarding.

Full breakdown with real-world context →

Question 19mediumdrag order

Review the full OSPF breakdown →

Arrange the steps to configure OSPF on a Junos router in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Step 1: Configure the OSPF area and assign interfaces

This is incorrect because OSPF may use an automatically derived router ID if not set, but it is best practice to set the router ID before assigning interfaces to avoid instability or mismatched router IDs.

Trap 2: Step 1: Verify OSPF neighbor relationships

Attempting to verify OSPF neighbors before configuring the router ID and assigning interfaces to areas is logically impossible: OSPF has not been enabled on any interface, so no HELLO packets are sent and the OSPF neighbor table is empty. The 'show ospf neighbor' command would return no output, not a failure state, because the OSPF process has no active interface to establish adjacencies with. Router ID and area/interface configuration are prerequisites for the OSPF protocol to operate, so verification must always come last.

Trap 3: Step 1: Configure the router ID

Though setting the router ID first is a good practice, inserting verification as step 2 is premature because OSPF adjacencies cannot form unless at least one interface is explicitly assigned to an OSPF area. Without an area-to-interface association, OSPF does not actively send HELLOs on any link, so the router has no neighbors to report even after a router ID is configured. Verification of neighbor relationships is only meaningful after interfaces are bound to areas and DR/BDR or point-to-point transitions have had time to complete.

Study all Operational Monitoring and Maintenance common traps →

A
Step 1: Configure the router ID. Step 2: Configure the OSPF area and assign interfaces. Step 3: Verify OSPF neighbor relationships.
Setting the OSPF router ID first is critical because it is a unique 32-bit identifier used in HELLO packets and LSRAs; if left unconfigured, Junos automatically selects the highest loopback or interface IP, which can change if interfaces are added or removed, causing adjacency instability. After the router ID is fixed, assigning interfaces to OSPF areas enables HELLO transmission on those links, allowing neighbors to be discovered. Finally, verifying adjacencies with 'show ospf neighbor' confirms that the configuration produced the expected neighbor states, such as Full for point-to-point links.
B
Step 1: Configure the OSPF area and assign interfaces. Step 2: Configure the router ID. Step 3: Verify OSPF neighbor relationships.
Why wrong: This is incorrect because OSPF may use an automatically derived router ID if not set, but it is best practice to set the router ID before assigning interfaces to avoid instability or mismatched router IDs.
C
Step 1: Verify OSPF neighbor relationships. Step 2: Configure the router ID. Step 3: Configure the OSPF area and assign interfaces.
Why wrong: Attempting to verify OSPF neighbors before configuring the router ID and assigning interfaces to areas is logically impossible: OSPF has not been enabled on any interface, so no HELLO packets are sent and the OSPF neighbor table is empty. The 'show ospf neighbor' command would return no output, not a failure state, because the OSPF process has no active interface to establish adjacencies with. Router ID and area/interface configuration are prerequisites for the OSPF protocol to operate, so verification must always come last.
D
Step 1: Configure the router ID. Step 2: Verify OSPF neighbor relationships. Step 3: Configure the OSPF area and assign interfaces.
Why wrong: Though setting the router ID first is a good practice, inserting verification as step 2 is premature because OSPF adjacencies cannot form unless at least one interface is explicitly assigned to an OSPF area. Without an area-to-interface association, OSPF does not actively send HELLOs on any link, so the router has no neighbors to report even after a router ID is configured. Verification of neighbor relationships is only meaningful after interfaces are bound to areas and DR/BDR or point-to-point transitions have had time to complete.

Full breakdown with real-world context →

Question 20mediumdrag order

Read the full DHCP explanation →

Arrange the steps to configure a DHCP server on a Junos router.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Step 1: Configure a DHCP pool with subnet and range

This sequence is invalid because you cannot configure a DHCP pool before the DHCP service is enabled. In Junos, all pool definitions live under the [edit system services dhcp] hierarchy; without first issuing 'set system services dhcp', there is no parent container to attach a pool to. The commit will fail with a 'missing hierarchy' or 'statement not found' error. Thus, enabling the service is a mandatory prerequisite, which is exactly why the correct procedure starts with Step 1 as enabling DHCP services.

Trap 2: Step 1: Enable DHCP services

This order incorrectly attempts to set DHCP options before defining a pool. On Junos, options like router and domain-name-servers are not top-level settings; they are subordinate statements inside a specific pool. Without first configuring the pool with its subnet and range, there is no context or location to attach these options, and the CLI will reject the commands. The pool must exist before its options can be specified, so Step 2 must be the pool definition.

Trap 3: Step 1: Enable DHCP services

In this arrangement, addresses are excluded before DHCP options are set, which violates the preferred logical ordering. Although both exclusions and options are pool-level statements in Junos, the standard workflow is to configure lease parameters (gateway, DNS) first, then reserve/exclude addresses. This prevents a client from receiving an address that should have been excluded during a brief window, and it keeps the configuration readable and maintainable. Setting options after exclusions is illogical because the pool's basic behavior is not fully defined at the time exclusions are made.

Study all Operational Monitoring and Maintenance common traps →

A
Step 1: Enable DHCP services. Step 2: Configure a DHCP pool with subnet and range. Step 3: Set DHCP options (gateway, DNS). Step 4: Exclude specific addresses.
This is the correct sequence for configuring a DHCP server on a Junos router. First, you must enable the DHCP service at the [edit system services dhcp] hierarchy level, which creates the top-level container for all DHCP configuration. Next, define a pool with its subnet and address range, e.g., set system services dhcp pool 192.168.1.0/24 address range low 192.168.1.10 high 192.168.1.200. After the pool exists, attach DHCP options such as router (gateway) and domain-name-servers to that specific pool. Finally, exclude specific addresses using excluded-address statements so static IPs are never dynamically assigned. This order reflects the hierarchical dependency in Junos—service first, then pool, then pool's children.
B
Step 1: Configure a DHCP pool with subnet and range. Step 2: Enable DHCP services. Step 3: Set DHCP options. Step 4: Exclude specific addresses.
Why wrong: This sequence is invalid because you cannot configure a DHCP pool before the DHCP service is enabled. In Junos, all pool definitions live under the [edit system services dhcp] hierarchy; without first issuing 'set system services dhcp', there is no parent container to attach a pool to. The commit will fail with a 'missing hierarchy' or 'statement not found' error. Thus, enabling the service is a mandatory prerequisite, which is exactly why the correct procedure starts with Step 1 as enabling DHCP services.
C
Step 1: Enable DHCP services. Step 2: Set DHCP options. Step 3: Configure a DHCP pool with subnet and range. Step 4: Exclude specific addresses.
Why wrong: This order incorrectly attempts to set DHCP options before defining a pool. On Junos, options like router and domain-name-servers are not top-level settings; they are subordinate statements inside a specific pool. Without first configuring the pool with its subnet and range, there is no context or location to attach these options, and the CLI will reject the commands. The pool must exist before its options can be specified, so Step 2 must be the pool definition.
D
Step 1: Enable DHCP services. Step 2: Configure a DHCP pool with subnet and range. Step 3: Exclude specific addresses. Step 4: Set DHCP options.
Why wrong: In this arrangement, addresses are excluded before DHCP options are set, which violates the preferred logical ordering. Although both exclusions and options are pool-level statements in Junos, the standard workflow is to configure lease parameters (gateway, DNS) first, then reserve/exclude addresses. This prevents a client from receiving an address that should have been excluded during a brief window, and it keeps the configuration readable and maintainable. Setting options after exclusions is illogical because the pool's basic behavior is not fully defined at the time exclusions are made.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Operational Monitoring and Maintenance sessions

Start a Operational Monitoring and Maintenance only practice session

Every question in these sessions is drawn from the Operational Monitoring and Maintenance domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Operational Monitoring and Maintenance questions →Mixed JN0-106 session

Frequently asked questions

What does the JN0-106 exam test about Operational Monitoring and Maintenance?: Operational Monitoring and Maintenance questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Operational Monitoring and Maintenance questions in a focused session?: Yes — the session launcher on this page draws every question from the Operational Monitoring and Maintenance domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other JN0-106 topics?: Use the topic links above to move to related areas, or go back to the JN0-106 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the JN0-106 exam covers. They are not copied from any real exam or dump site.

Operational Monitoring and Maintenance only

10 questions 20 questions 30 questions 50 questions

Mixed JN0-106 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All JN0-106 questions Operational Monitoring and Maintenance domain overview JN0-106 exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Operational Monitoring and Maintenance practice questions

What to know about Operational Monitoring and Maintenance

Common Operational Monitoring and Maintenance exam traps

Operational Monitoring and Maintenance questions

A network engineer notices that a device is not sending SNMP traps to the NMS. Which operational command should be used to verify SNMP configuration?

A network administrator is troubleshooting high CPU usage on a Juniper router. Which command helps identify which process is consuming the most CPU?

After a software upgrade, BGP sessions are not establishing. The engineer runs 'show bgp summary' and sees that all sessions are in Idle state. What is the most likely cause?

A junior engineer needs to collect a snapshot of the current system state, including routing tables, interfaces, and configuration, for a support ticket. Which command achieves this?

A network engineer wants to schedule a reboot of a Juniper device at 3:00 AM. Which command should be used?

A router is experiencing intermittent packet loss. The engineer runs 'show interfaces ge-0/0/0 extensive' and notices a high number of input errors but no output errors. What is the most likely cause?

An engineer needs to check the last time the configuration was changed. Which command provides this information?

A BGP session is flapping. The engineer runs 'show log messages' and sees 'BGP recv Notification' with error code 'Cease'. What does this indicate?

Which THREE statements are true about the 'show interfaces ge-0/0/0 extensive' command output?

Which THREE commands are used for operational monitoring of routing protocols?

Which TWO statements are correct about the 'monitor interface' command?

Which THREE statements about the 'request system snapshot' command are true? (Choose three.)

Based on the exhibit, which protocol is enabled on interface ge-0/0/0.0?

Exhibit

Which THREE statements correctly describe the use of the 'monitor traffic' command in Junos?

Refer to the exhibit. A network engineer sees repeated 'PFE interrupt error' messages in the log for fpc0. What is the most likely impact and recommended action?

Exhibit

Arrange the steps to configure OSPF on a Junos router in the correct order.

Arrange the steps to configure a DHCP server on a Junos router.

Track your progress over time

Start a Operational Monitoring and Maintenance only practice session

Related JN0-106 topic practice pages

User Interfaces practice questions

Junos Configuration Basics practice questions