Technical Tip: FortiGate BGP flapping due to overlapping peer IP

To narrow down this problem, a concurrent packet capture on both FortiGates is required to review the BGP connection when it flaps.

Here is the example scenario :

FortiGate A IP address: 10.52.50.1.

FortiGate B IP address: 10.52.50.2.

1. Findings at FortiGate A packet capture : 

It is shown that it was receiving a TCP reset from FortiGate B IP address, terminating the BGP connection (TCP 179), thus causing the flap. 

Looking at the packet details in Wireshark, it is shown that the RST packet is sourced from another device's MAC address, not directly from FortiGate A MAC address. 

Side note: Looking at the BGP debug logs on FortiGate A, it will show this message : 

2025-12-19 14:45:12 BGP: 10.52.50.2-Outgoing [ENCODE] Keepalive: 888054 KAlive msg(s) sent
2025-12-19 14:45:24 BGP: 10.52.50.2-Outgoing [NETWORK] FD=29, Sock Status: 104-Connection reset by peer

2. Findings at FortiGate B packet capture:

Looking at the packet capture file that was captured at the same time and the same specific BGP session (TCP port: 16920).

It is shown that it never sent the RST packet at all. 

Looking at the packet details in Wireshark, it is expected to show the correct source and destination mac-address.

In this scenario, it is shown that 00:09:0f:09:00:13 should be the correct source MAC address. 

From here, trace the unexpected non-Fortinet vendor mac-address and check the IP address set on its physical port settings. 

In this particular scenario, these packet capture findings lead to the root cause :

1. Where another third-party layer 3 switch has the same IP address of 10.52.50.2.
2. It received the BGP ACK packet response from FortiGate A, because it does not have BGP service enabled, it sends a reset with the same IP address, and causes FortiGate A to end the BGP neighborship.
3. BGP flap triggered.