|
A common cause of this is ISP connectivity or packet loss.
Step 1. Check connectivity by pinging the neighbor.
Step 2. Sniff the packets and check the flow and event log.
diag sniffer packet <connected port or any> “host port 179” 6 0 l
Debug flow:
diag debug flow filter dport 179
diag debug flow filter addr <neighbor ip>
diag debug flow show iprope enable
diag debug en
diag debug flow trace start
Check the event log if the port is going and going down
If the issue is not solved by verifying, connectivity is working with no loss.
Run BGP debug:
diag ip router bgp all enable
diag ip router bgp level info
diag debug en
diag debug console timestamp enable.
Here is an example of BGP debug showing the symptoms :
BGP: <neighbor ip>-Outgoing [NETWORK] FD=26, Sock Status: 110-Connection timed out
BGP: <neighbor ip>-Outgoing [FSM] State: Connect Event: 18
In this example, FortiGate was not receiving a reply from a neighbor to establish a BGP session, it will try again until it receives the neighbor BGP protocol packet.
MTU should also be consistent in the path. Though MTU is not a requirement for BGP neighborship to come up, however when the NLRI is exchanged in the BGP update packets, it will try to send a packet as large as the MTU of the outgoing interface. In the path, if fragmentation is not allowed and a lower MTU is present in the path, these packets will get dropped. Consequently, the BGP neighborship will flap every 180 seconds or after the time configured in the hold down timer.
Related articles:
|
