| Description |
This article describes how to resolve an issue where BGP neighborship stays up for 180 to 200 seconds and then it flaps and comes up by itself. |
| Scope | FortiGate, all firmware. |
| Solution |
This issue generally occurs due to an MTU mismatch on both BGP peers or on a device in between which has a lower MTU set on it and has DF bit set to 1, which eventually drops BGP Update packets (includes NLRI info) with a bigger MTU.
Topology:
FG1 (10.61.16.253) ======tunnel===========(10.61.16.158)FG2
For example:
In a scenario with BGP neighborship between 10.61.16.253 and 10.61.16.158 over IPsec tunnel, BGP neighborship is flapping between the peers after every 190 seconds. PCAPs were taken on the tunnel interfaces with port number 179 on both ends.
PCAP 1 taken from the 10.61.16.253 side:
As shown in the PCAP below, 10.61.16.253 is sending a BGP Update message with all the prefix information. The MTU size is 1390 and 10.61.16.253 has not received the ACK for the Update message, so 10.61.16.253 is stuck re-transmitting the Update message.
PCAP 2 taken from the 10.61.16.158 side:
On 10.61.16.158, no Update message is received from the 10.61.16.253 peer, hence 10.61.16.158 would not send any ACK to 10.61.16.253. BGP waits for 180 seconds, which is equal to the Hold Down timer, and eventually brings down the neighborship.
Conclusion:
BGP Update messages must be dropping somewhere between the two peers. In the above scenario, the issue is not on the FortiGate devices but on the devices between the FortiGates.
Solution 1:
The Network Admin has to make sure that the MTU size on the intermediate devices is set equal to or greater than the MTU size on the FortiGates.
Solution 2:
Reduce the MTU on the overlay tunnels so that FortiGate can send Update messages with lower MTU. Refer to the following Fortinet Community article: Technical Tip: MTU override of IPsec VPN interface
Note: Solution 2 can reduce the speed and increase the latency due to the reduction in MTU size. |
