Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
MR-Fortinet
New Contributor

Dynamic BGP (Neighbor-group) over the ADVPN spokes in Fortigate Hub-Spoke solution

Hi everyone,

I am using 1 Hub, 2 spokes, FortiOS 7.6.3, ADVPN 2.0, BGP loopback peering without overlay IP.

So, every things is good, ADVPN works right, just a problem for peering dynamic BGP between spokes.

When spoke to spoke wants to speak (test by loopback addresses), auto shortucky is established, Good, but spokes cannot established BGP peering, based on my diagnose, TCP 179 will be drop due no match selector in IPsec, it seems that problem is the Tunnel between spokes but no, tunnel will established without any problem, but BGP cannot.

I should note that if I use 'execute restart router' , so spokes start to establish BGP peering! it means that tunnel is not problem.

The main problem is that BGP peering starts to etablish between spokes before complete establishing tunnel.

So, I am looking for a way to make some delay, just a second or 2 second in BGP peering process or restart BGP peering establishing between spokes after ADVPN establishing.

Can you help me how can I do it ?

4 REPLIES 4
Anthony_E
Community Manager
Community Manager

Hello Mister,


Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.


Thanks,

Anthony-Fortinet Community Team.
Jean-Philippe_P
Moderator
Moderator

Hello MR-Fortinet,

 

I found this solution. Can you tell me if it helps, please?

 

To address the issue of BGP peering starting before the ADVPN tunnel is fully established, you can consider the following steps:

 

  1. BGP Timer Adjustment: Adjust the BGP timers to delay the peering process. You can increase the BGP hold time and keepalive time to allow more time for the tunnel to establish before BGP peering begins.

  2. BGP Dampening: Implement BGP dampening to suppress flapping routes. This can help stabilize the BGP session by delaying the re-establishment of the session after a flap.

  3. Route Map with Delay: Use a route map to introduce a delay in the advertisement of routes. This can be done by setting a condition that delays the advertisement of BGP routes until the tunnel is confirmed to be up.

  4. Script Automation: Consider using a script to automate the restart of the BGP process after a short delay once the tunnel is established. This can be done using FortiGate's automation stitches or external scripting tools.

  5. Monitor Tunnel Status: Ensure that the tunnel status is being monitored correctly and that any issues with the tunnel establishment are addressed to prevent premature BGP peering attempts.

 

These steps should help in synchronizing the BGP peering process with the establishment of the ADVPN tunnel. Adjust the configurations based on your network requirements and test thoroughly in a controlled environment before applying to production.

Jean-Philippe - Fortinet Community Team
MR-Fortinet

Dear Philippe,

Thank you very much for the time you spent for my issue.

Let me answer your helps in order:

1-BGP Timer Adjustment:

As a default timers, hold-time or keepalive abour 60 or 120 seconds, they have not effect on my issue, I did try.

Really, my issue is happend under 1 second, just some millisecond, not very seconds :)

 

2- BGP Dampening:

This timer is used for flappig situation, when my BGP peering is failed, So I dont have BGP route to be flapped or some like issue.

However, I tried but no effect. 

 

3-  Route Map with Delay:

Any advertisment process to work/match by route map needs to BGP neighbor, So when I have no BGP neighbor or peering, it is not used.

 

4- Script Automation:

It is not god idea, because by 'execute router restart', all sessions and routing will be flushed in Fortigate, not only BGP.

However it works after this command and maybe I need to create condition that should be matched in this case.

 

5- Monitor Tunnel Status:

I have configured health check for tunnels, I did try with and without health check, unfortunately no effect.

 

Totally, because my peering is failed, and after tunnel establishment, there is no try to forming BGP peering, So there is no neighbor no BGP session to control.

First and first step is BGP peering that is failed in my case.

I sent the error in GUI log, they are happend during 1 second.

Good luck

 

bgp.png

Jean-Philippe_P

Hey again MR,

 

Please note that my answer was based from a GPT engine :)

 

I found these answers from it, does it help you?

 

Based on your detailed feedback, it seems the issue is related to the timing of BGP peering attempts relative to the establishment of the ADVPN tunnel. Here are some additional suggestions to consider:

  1. BGP Connect Timer Adjustment: Adjust the BGP connect timer to delay the initial connection attempt. This can be done by setting a higher value for the connect-timer in the BGP configuration. This will delay the initial BGP connection attempt, allowing more time for the tunnel to establish.

  2. BGP Session Retry: Ensure that the BGP configuration allows for retries if the initial peering attempt fails. This can be configured by setting appropriate retry intervals.

  3. Conditional BGP Peering: Use scripts or automation tools to conditionally initiate BGP peering only after the tunnel is confirmed to be up. This can be done by monitoring the tunnel status and triggering BGP peering once the tunnel is established.

  4. FortiOS Version and Configuration Review: Ensure that your FortiOS version is up to date and review the configuration for any settings that might affect BGP peering. Sometimes, specific versions may have known issues or require specific configurations.

  5. Fortinet Support: If the issue persists, consider reaching out to Fortinet Support for further assistance. They may have additional insights or patches that could resolve the issue.

 

These steps aim to synchronize the BGP peering process with the tunnel establishment, minimizing the chance of premature peering attempts.

Jean-Philippe - Fortinet Community Team
Announcements
Check out our Community Chatter Blog! Click here to get involved
Labels
Top Kudoed Authors