NSE7 Advanced Networking and SD-WAN Practice Question
An administrator runs 'get router info bgp summary' and sees that the BGP session to a neighbor is in the 'Idle' state. The neighbor IP is reachable via ping. The BGP configuration uses loopback interfaces with 'update-source loopback1'. What is the MOST likely reason for the Idle state?
⚠ Common exam trap
Many candidates assume ping reachability to the neighbor IP guarantees BGP session establishment, but they overlook that BGP packets are sourced from the loopback interface, requiring the neighbor to have a return route to that specific source IP.
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
✓
There is no route on the neighbor back to the FortiGate's loopback IP
The 'Idle' state in BGP indicates that the session cannot start, often due to a missing route to the neighbor's update-source IP. Since the neighbor IP is reachable via ping but the session uses loopback interfaces with 'update-source loopback1', the FortiGate's BGP packets will source from its loopback1 IP. If the neighbor does not have a route back to that loopback IP, it cannot respond to the TCP handshake, leaving the session stuck in Idle. This is a classic BGP loopback peering issue where reachability of the source IP is required, not just the physical interface IP.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
There is no route on the neighbor back to the FortiGate's loopback IP
Why this is correct
With update-source loopback1, the FortiGate sources BGP packets from its loopback address, so the neighbour must have a return route to that loopback. Ping to the neighbour succeeds, but without the reverse route the TCP session cannot establish, leaving BGP Idle.
- ✗
The loopback interface is down or has no IP address assigned
Why it's wrong here
A down or addressless loopback1 would break the update-source, but the stem already establishes the neighbour IP is pingable, which requires that loopback to be up and addressed. Loopback verification is genuinely useful when sessions fail silently, making this tempting. Here the reachability evidence rules it out.
- ✗
The BGP neighbor's remote-as is misconfigured
Why it's wrong here
A wrong remote-as produces a Notification and returns the peer to Idle, so it fits superficially. However, the stem's loopback and update-source detail points to the source address used for the TCP session, and a misconfigured remote-as would typically show Connect or Active before failing, not persistent Idle.
- ✗
The BGP timer values (keepalive/hold) are mismatched
Why it's wrong here
Timer mismatches cause sessions to flap or drop after establishment, not to sit permanently in Idle, because timers are negotiated in OPEN messages exchanged after TCP connects. Checking keepalive and hold values is a standard troubleshooting step, which makes this tempting. Idle means the session never reached that exchange.
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.