|
From the message, there can be two possibilities:
- BGP Peer is not receiving the keepalive sent by the FortiGate and the hold-down timer is expiring (or vice-versa). The most common potential causes are as follows:
Network connectivity issues :
There could be network connectivity issues between the FortiGate device and the BGP peer, such as a link failure, routing misconfiguration, or firewall rules blocking BGP traffic.
These issues could prevent the keepalive messages from reaching the BGP peer, causing the peer to not acknowledge receipt of the keepalives and eventually triggering the hold-down timer to expire.
MTU issues:
Packets exceeding the underlying link MTU with higher MTU bytes can be dropped by the intermediate L2 network, sometimes especially when the BGP keepalives are piggybacked with other BGP messages.
- FortiGate is not sending the keepalive at all, which causes the BGP to flap and the hold-down timer to expire. The most common potential causes are as follows:
Software or hardware issues:
There could be software or hardware issues on the FortiGate device that are preventing the proper functioning of BGP keepalive messages. This could include bugs, memory or CPU utilization issues, or hardware failures.
Routing issues:
There may be routing issues, such as incorrect routing tables or route advertisements, that are preventing the FortiGate device from sending BGP keepalive messages to the BGP neighbor.
To find the root cause for this, the following information should be collected using multiple PuTTY/SSH sessions:
1st Putty Session:
diagnose sniffer packet any "port 179" 6 0 l
2nd Putty Session:
diag sys top 2 50
3rd Putty Session:
diagnose ip router bgp all enable
diagnose ip router bgp level info
diagnose debug console timestamp enable
diagnose debug enable
In the case of BGP over IPSEC, one other reason for this problem could be that you are advertising the connected routes to the remote BGP peer without any filters.
This advertisement will then include the IPSEC Tunnel interface IP and it is the same IP on which the BGP is established. Therefore, if the remote peer installs this learned route in its routing table (if it satisfies the conditions like longest-prefix), the BGP keepalives are then not sent back correctly.
To resolve this issue, please refrain from advertising connected routes which include the IP of the tunnel interface on which the BGP is established.
|
