NSE7 Troubleshooting and Diagnostics Practice Question
A BGP peering between two FortiGates is not establishing. The administrator runs 'get router info bgp neighbor' and sees that the neighbor state is 'Idle' and the BGP configuration appears correct. What should the administrator check next?
⚠ Common exam trap
The trap here is that candidates often jump to debugging or assume a configuration error (like AS number mismatch) when the neighbor state is Idle, but the most fundamental cause—IP reachability—is frequently overlooked.
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
✓
Verify that the BGP neighbor IP is reachable via the routing table
When a BGP neighbor is stuck in the 'Idle' state, it typically indicates that BGP cannot initiate the TCP connection to the neighbor. The most common cause is that the neighbor IP address is not reachable via the routing table. Even if the BGP configuration (AS number, neighbor IP) is correct, BGP will remain Idle until it can successfully open a TCP session on port 179. Therefore, verifying IP reachability (e.g., with 'ping' or checking the routing table) is the logical next step.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Run 'diagnose ip router bgp all enable' to enable debug
Why it's wrong here
Enabling BGP debug produces verbose logging but does not itself test whether TCP port 179 is reachable, which is the likely cause of an Idle neighbour. Debugging is tempting for diagnosis, yet the administrator should first verify IP connectivity and that the peer is listening on TCP 179.
- ✗
Check the BGP AS number configuration
Why it's wrong here
The stem states the BGP configuration appears correct, so rechecking the AS number duplicates work already done; a mismatched peer AS would typically show Active or Connect, not Idle. Verifying AS numbers is tempting as a basic sanity check, but Idle points to reachability or TCP-level failure.
- ✓
Verify that the BGP neighbor IP is reachable via the routing table
Why this is correct
An Idle BGP state means the router cannot reach the neighbour, so the TCP session never opens. Verifying the neighbour IP is reachable in the routing table confirms whether a missing or incorrect route is blocking the peering, before checking timers or authentication.
- ✗
Increase the BGP timers
Why it's wrong here
Timers govern keepalive and hold-down intervals once a session is Established; they cannot move a neighbour out of Idle, which precedes any timer negotiation. Adjusting timers is tempting when sessions flap, but Idle indicates the TCP connection to port 179 was never formed.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 718 original NSE7 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 NSE7 practice question is part of Courseiva's free Fortinet 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 NSE7 exam.