Troubleshooting Tip: eBGP sessions remain Idle when multiple neighbors are connected to the same interface

[Umer221]

Description	This article explains how to troubleshoot a FortiGate scenario where multiple eBGP neighbors are configured on the same interface, but the sessions remain in the Idle state even though ICMP and TCP/179 connectivity are working correctly. This typically occurs in cloud deployments (for example, FortiGate-VM in Azure or AWS) where multiple peers are connected through a single vNIC or interface.
Scope	FortiOS, FortiGate-VM.
Solution	Sample Topology: The FortiGate interface port2 uses the IP address 10.110.1.4/24. The Device-1 peer connects from the 10.100.0.0/24 subnet using IP 10.100.0.4, and the Device-2 connects from the 10.100.2.0/24 subnet using IP 10.100.2.4. The FortiGate operates in AS 65010, while both neighbor devices use AS 65100. In this scenario, two devices establish eBGP sessions with a FortiGate-VM deployed in Azure. All peers connect through the same FortiGate interface (port2) because the Azure VM operates with a single vNIC per subnet. The FortiGate advertises internal Azure VNet routes (for example, 10.64.0.0/11) to both peers, and each neighbor device advertises its local LAN subnets back to the FortiGate. Although ping and TCP reachability are confirmed, the BGP sessions remain in Idle. get router info bgp summary VRF 0 BGP router identifier 10.110.1.4, local AS number 65010 BGP table version is 1 Neighbor AS MsgRcvd MsgSent InQ OutQ Up/Down State/PfxRcd 10.100.0.4 65100 0 0 0 0 never Idle 10.100.2.4 65100 0 0 0 0 never Idle Verify Interface and Connectivity: The peers are connected to the same interface and are reachable over Layer-3. get system interface physical == [port2] ip: 10.110.1.4/24 status: up execute ping 10.100.0.4 execute ping 10.100.2.4 Both neighbors reply successfully, confirming that connectivity and routing are correct. Analyze TCP Session Using Sniffer: A sniffer capture shows the TCP handshake completes, followed immediately by a TCP RST packet from FortiGate. diagnose sniffer packet any "host 10.100.0.4 or host 10.100.2.4 and port 179" 4 0 a 10.100.0.4.38925 -> 10.110.1.4.179: SYN 10.110.1.4.179 -> 10.100.0.4.38925: SYN/ACK 10.110.1.4.179 -> 10.100.0.4.38925: RST This behavior indicates that the FortiGate BGP process is rejecting the TCP connection at the application layer. Review BGP Debug Logs: To analyze why the FortiGate rejects the connection, debug logs are collected. diagnose debug reset diagnose debug enable diagnose debug application bgp -1 BGP: [NETWORK] Accept Thread: Incoming conn from host 10.100.0.4 BGP: [NETWORK] Accept Thread: Incoming conn from host 10.100.2.4 BGP: 10.100.0.4-Outgoing [FSM] State: Idle Event: 14 BGP: 10.100.2.4-Outgoing [FSM] State: Idle Event: 14 BGP: bgp_ipc_on_close:8 delete ipc_handler=0x7fe99cb6a980 for sock=29 The debug logs indicate that FortiGate accepts incoming TCP connections from both BGP peers but immediately transitions each neighbor’s Finite State Machine (FSM) back to the Idle state. No OPEN or KEEPALIVE messages are exchanged, and the TCP socket is closed immediately after connection acceptance. This behavior confirms that while the FortiGate is reachable over TCP/179, the BGP process does not progress beyond the Idle state because the neighbors are connected through the same interface and are treated as multi-hop peers. In this condition, eBGP multihop must be enabled for the sessions to establish successfully. Root Cause: When multiple eBGP neighbors are connected to the same interface, FortiGate treats them as multi-hop peers rather than directly connected neighbors. Without enabling 'ebgp-enforce-multihop', FortiGate rejects the BGP OPEN message and resets the TCP session, resulting in the session remaining in the Idle state. Solution: To allow BGP sessions to establish successfully when multiple neighbors share the same interface, enable eBGP multihop on each neighbor configuration. config router bgp     set as 65010     set router-id 10.110.1.4     set ebgp-multipath enable         config neighbor             edit "10.100.0.4"                 set interface "port2"                 set remote-as 65100                 set ebgp-enforce-multihop enable                 set soft-reconfiguration enable             next                 edit "10.100.2.4"                     set interface "port2"                     set remote-as 65100                     set ebgp-enforce-multihop enable                     set soft-reconfiguration enable                 next             end         end After updating the configuration, restart the BGP process: execute router clear bgp all execute router restart After enabling eBGP multihop, both BGP sessions establish successfully. get router info bgp summary Neighbor AS MsgRcvd MsgSent InQ OutQ Up/Down State/PfxRcd 10.100.0.4 65100 6 2 0 0 00:00:44 130 10.100.2.4 65100 4 5 0 0 00:00:43 124 Both neighbors transition from Idle to Established. Route exchange occurs as expected. Additional Verification: get router info bgp neighbors 10.100.0.4 received-routes get router info bgp neighbors 10.100.2.4 received-routes get router info bgp neighbors 10.100.0.4 advertised-routes get router info bgp neighbors 10.100.2.4 advertised-routes When multiple eBGP neighbors are connected through the same FortiGate interface, the firewall may treat the peers as multi-hop neighbors. This results in the BGP sessions remaining in the Idle state and TCP resets being observed in packet captures. By enabling 'ebgp-enforce-multihop' under each neighbor configuration, the FortiGate allows the sessions to form successfully, establishing stable eBGP peering and route exchange.