Skip to main content
Unai_SecFnet
Unai_SecFnet
New Member
January 17, 2022
Question

SDWAN neighbor roles

  • January 17, 2022
  • 4 replies
  • 7075 views

Hi team,

 

I have recently found the neighbor roles feature in the sdwan configuration. I don't really understand the implication of primary and secondary configuration. 

 

Until now, I used parameters such as local preference to control BGP route announcements and receipts. Can I control 2 BGP sessions with both parameters? I explain myself, if one neighbor has the role secondary the BGP session is in "passive" mode until the primary BGP session fails. 

 

Thanks for teh help!

4 replies

AlexC-FTNT
Staff
AlexC-FTNT
Staff
January 17, 2022

This feature is explained here:

https://docs.fortinet.com/document/fortigate/6.2.0/new-features/638759/bgp-route-map-and-selective-rules-6-2-1

Traffic flows to the primary SD-WAN gateway, unless the link is outside of the SLA, or completely down. When that happens, traffic routes to the secondary gateway. So, in my understanding, the primary link is used until it fails. When this happens, the one configured as secondary comes up and negotiates the BGP neighborship.

Unai_SecFnet
Unai_SecFnetAuthor
New Member
January 17, 2022

Yes, I saw that document, but I don't understand at all which is the difference between configuring the role parameter or just not do it and declare both neighbors in the sdwan configuration piece and in the BGP configuration configuring the route-map-out-preferable.

Toshi_Esumi
SuperUser
Toshi_Esumi
SuperUser
January 19, 2022

I don't understand it either. The exmaple 1 says "The SD-WAN neighbor is configured to let BGP advertise different communities when the SLA status changes."

But the BGP neighbor config is for two different neighbors; 10.100.1.1 and 10.100.1.5. To accomplish what the problem statement says, "comm1" and "comm2" need to be configure on the SAME neighbor.

I think it's very poorly written, at least.

 

Toshi

Unai_SecFnet
Unai_SecFnetAuthor
New Member
January 31, 2022

Yes, I think so. Some features of Fortinet are hard to understand due to the lack of useful examples or explainations.

 

Does somebody control this feature?

 

Thanks for support_!

awhit
awhit
New Member
October 17, 2022

Not using it but I believe the idea behind this feature is to assist with controlling routes when you have two completely different devices (gateways) that are both up at any given time and are both possible entry points into the network. What if you want to forward to the second device only when the primary is completely down? Rather than path selection it is more of a device selection. Fortinet is working on features that allow SD-WAN to scale without a proliferation of specific steering rules you have to update every time you add a site, etc...and also without having unique health checks on both hub and spoke per site, so this I think is an attempt to provide a solution to the 2 separate entry points issue without adding rules.

Imagine your spoke connects up to two different gateways to your network. Both gateway firewalls have iBGP running on the back-side between them and depending on what community the remote spoke sends it you are updating local-preference for spoke routes inside your network. That allows you to draw your outbound traffic at the head end towards the edge device that has the best current path to the remote spoke.

J
justink84
New Member
May 15, 2026

I didn’t understand the intentions at first although this became very useful in the design choices. When I did not use the neighbor roles and both my hub’s were in same geographic location, latency, packet loss, and internet. It did not make sense for both of my neighbors to have the same neighbor role. There is no gain at the end of the day and the reason for the duel hub is redundancy for either a stale vpn tunnel on branch or datacenter issue and hub is not in service. 

 

The take I had was the Branch BGP weight for the primary neighbor was higher, and the BGP weight for the secondary neighbor was lower. This way I didn’t have routes to both peers at the same time. I would set a route-map with metric going to hubs. I also had used iBGP between the 2 hubs. The hub with lower metric would take the win when traffic was initiated at datacenter side. 

 

If I had more then 1 wan interface (2,3,4, etc). They would all participate in the primary neighbor at the same time. Since there is no gain between the hub. I can prioritize my traffic on what ever interface I want. 

 

If we get to a point where we have a hub in US-East, US-Central, and US-West. Then I would put the primary hub in the sdwan neighbor config for primary. This way my branch would determine if its going to east, central, or west due to the traditional sdwan packet-loss or latency rules you have defined. 

 

I hope that helps anyone who may need a more practical understanding of a use case. I was ending up with asymmetric flows as we have 2 hubs deployed in Azure vWAN as NVA’s. Azure uses a hidden load balancer to split traffic up. I was finding times that the bandwdith estimates would be wrong as hub2 was passing traffic over wan1, when it should have been hub1. Since each vpn tunnel is estimated on its own vs an aggregate as a physical wan interface. I was finding the algorithms were not syncing up the way I wanted to.  

Terms & ConditionsAccessibility statement