JN0-106 Operational Monitoring and Maintenance Practice Question
A network administrator notices that the CPU utilization on an MX240 router has been consistently above 90% for the past hour. Users are reporting intermittent connectivity issues. The administrator logs in and runs 'show system processes extensive' which shows the Routing Protocol Daemon (rpd) consuming 70% of the CPU. Further investigation reveals that the router has over 5000 BGP prefixes from multiple peers. The administrator suspects that the high CPU is due to continuous route processing. What should the administrator do to immediately reduce CPU load while maintaining network stability?
⚠ Common exam trap
Candidates often confuse diagnostic actions (like checking logs) or disruptive resets (like clearing all BGP sessions) with immediate corrective measures, overlooking the targeted, non-disruptive solution of applying prefix limits to control route processing load.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Apply a prefix-limit on each BGP session to restrict the number of prefixes received
Applying a prefix-limit on each BGP session immediately restricts the number of prefixes the router will accept from peers. This prevents the Routing Protocol Daemon (rpd) from processing excessive BGP updates, reducing CPU load while maintaining network stability by keeping existing sessions and routes intact. The prefix-limit action (e.g., with a teardown threshold) ensures the router does not accept more prefixes than it can handle, directly addressing the root cause of high CPU usage.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Perform a 'show log messages' to check for errors before taking action
Why it's wrong here
Checking 'show log messages' is purely a diagnostic step; it can help identify the cause of high CPU but does nothing to reduce the processing load on rpd. The BGP sessions continue to send updates, and rpd still parses and processes every received prefix. While logging is a sensible troubleshooting step, it should follow or accompany an active mitigation, not replace it.
- ✓
Apply a prefix-limit on each BGP session to restrict the number of prefixes received
Why this is correct
Applying a prefix-limit on each BGP session directly caps the number of routes that rpd must read, parse, and install in the RIB and BGP table. By rejecting excess updates (or tearing down the session when a threshold is exceeded), you stop route churn and table bloat at the source, which is the most effective way to lower CPU utilization. It also protects the router from a peer that advertises an abnormally large table due to misconfiguration or a route leak.
- ✗
Bounce all BGP sessions by clearing them with 'clear bgp neighbor *'
Why it's wrong here
Clearing all BGP sessions with 'clear bgp neighbor *' is disruptive and counterproductive under high CPU. It forces every neighbor to re-establish and re-send its complete routing table, causing a burst of route-processing activity that can spike rpd CPU even higher. This approach also drops all active traffic that depends on those BGP-learned routes and widens the impact of whatever issue is driving the CPU load.
- ✗
Disable BGP multipath to reduce route processing
Why it's wrong here
BGP multipath allows multiple equal-cost routes to be installed in the forwarding table, which requires rpd to perform additional path computation only when best-path selection runs; it is not the primary driver of CPU utilization. The sustained high CPU is almost always caused by the number of received updates, prefixes, or peers, not by multipath. Disabling multipath could even harm traffic distribution without meaningfully reducing the work rpd does for every incoming BGP message.
Quick reference
Routing Protocol Comparison
| Protocol | Metric | Max Hops | Algorithm | Type |
|---|---|---|---|---|
| RIP v2 | Hop count | 15 | Bellman-Ford | Distance vector |
| OSPF | Cost (bandwidth) | Unlimited | Dijkstra (SPF) | Link state |
| EIGRP | Composite metric | Unlimited | DUAL | Hybrid |
| IS-IS | Cost | Unlimited | Dijkstra | Link state |
| BGP | Policy / attributes | Unlimited | Path vector | Path vector |
RIP's 15-hop limit makes it unsuitable for large networks. OSPF and EIGRP dominate modern enterprise deployments.
Go deeper
Related to this question
About these practice questions
One of 156 original JN0-106 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This JN0-106 practice question is part of Courseiva's free Juniper Networks certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the JN0-106 exam.