BGP Route Priority

If the same routes are from different protocols, which one would be in the routing-table is decided by the admin distances of the protocols.

https://community.fortinet.com/t5/FortiGate/Technical-Note-FortiGate-IP-route-selection-and-how-to-change/ta-p/191612

You can either change static route's distance or change the admin distance of eBGP or iBGP to be the same with static route like below:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configuring-admin-distance-for-routes-received/ta-p/190738

However, as described in the first KB the ECMP is applicable only to static and OSPF, basically. There is a way to allow ECMP inside of BGP:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-ECMP-routes-for-recursive-BGP-next-hop-resolution/ta-p/191461

But I'm not sure if this option makes ECMP possible between static routes and BGP routes.

Probably somebody from FTNT can answer to your question. Or, you just need to test it yourself since these would be simple changes. My guess is still the static default route is preferred over the BGP learned default route when admin distances are the same. Because I vaguely remember the same conversation was in this forum years ago and the conclusion at that time was the poster couldn't make them equal.

Toshi
 

Can you explain exactly what you're trying to accomplish? 

Hi Rat1001,

For the routes learnt from different routing protocol, the AD value is used for the route preference. For example if same prefix learnt from  static routing and bgp, in this scenario AD value would be deciding factor.
If you have multiple routes learnt from the BGP, in this scenario bgp path attributes are used to prefer 1 bgp learnt route over another.  Kindly check below link for more detail:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-BGP-route-selection-process/ta-p/195932

Regards,
Parteek

Hi @parteeksharma ,

I have tweaked the BGP route AD and metric to match that of the static default route- will have to test with ISP1. What I am unsure of is how to set a priority- Fortigate static route like priority on a route learnt from BGP, not sure if this is even possible.

Hi Rat1001

I think I have a nearly similar use case : 

2 ISP (1 corporate ISP and an end consumer ISP)

The corporate ISP provide 2 links, one in L2 on vlan 950 (so connected route + static routing have t be used) and one in L3 (with BGP) transiting on vlan 952

The end consumer ISP provide 1 link transiting on vlan 951 in L2 (trough bridge mode and I can configure the public IP directly on the fortigate wan interface) or in L3 through a router with a private IP as a gateway for the fortigate but in both case (L2 or L3) it's only support static routing

So as you can imagine, dealing with fortigate special proprietary attribute named 'priority', I was able to deal with 2 default route between the 2 internet links.

For my use case, I need to have the 2 links of the corporate ISP (ISP1) active at the same time because I need to migrate all services currently using public IP configured on vlan 950 to the new L3 subnet I advertise with bgp to the ISP backbone over vlan 952 (soft migration IP by IP, service by service, everything is in production..). 

For internet traffic to work on vlan 952, I need to recieve a default route with eBGP from the ISP1 backbone.

As said earlier in this thead, it's not possible to mix a BGP default route and a static default route at the same time in the routing table, and if you play 'get router info routing-table all' on the fortigate, you will never find the BGP default route in the fortigate routing table when a static route is configured, even if you recieve it (get router info bgp neighbor xxx.xxx.xxx.xxx recieved-route) .

To handle this use case, I solved it using VRF and isolating vlan 952 in a specific VRF so the default BGP route is in the routing table of this VRF.

To make the 2 VRF communicated, I did use BGP VRF leaking between the 2 VRF using inter vdom-link and subnet overlapping.

Now I'am able to use the 3 internet links with 3 default gateway at the same time on a uniq fortigate AND without using VDOMS.

This way, I will be able to migrate all services hosted on the public subnet of vlan 950 (L2 and using a static default route) to the new L3 subnet I advertise to ISP1 with BGP and to use vlan 951 (ISP2) as a fallback ISP using the same scheme 

If someone is interrested in the detailed configuration I can post it here, let me know (that was not that easy to make this design work).

Regards,

nbanba

Hello, just to add , below kb might help you in BGP routes using metrics:

https://community.fortinet.com/t5/FortiGate/Technical-Note-Influencing-BGP-routes-using-Metric/ta-p/196950

Thanks @sahmed_FTNT  for the KB !

@Rat1001 : 

Maybe SD-WAN could had been an option with some complexe setup but wasn't considered because as I need to migrate all traffic reaching us from internet from one link with it's own public IP to the second link using it's own public IP (which would be part of the SD-WAN agregate interface)  I cannot use a single agregate interface of the 2 links 

From my experiments at our customers, SD-WAN is a nice way to handle use case like the following one : 

Having several sites connected by a MPLS network to a "central" site which hold most of all ressources : servers, ip phone appliances, ... , firewalls, and the internet connection. All sites have end users (like in an office) and some sites have some servers. All sites access the central site through mpls and access internet through the central site.

After studying the cost of the MPLS network on the 11 + 1 sites (the farest site from the central site is about 1000km), it appears that having less than 10Mb/s mpls link between every site and the central site and having 2*1G internet connections on each site cost the same (one with a corporate ISP and the second with an end consumers ISP)

So it was decide to replace the old MPLS by SD-WAN using 2 ISP. 

Cisco mpls routers were replace by Fortigate on every site + FortiAnalyzer & FortiManager in the central site and mpls links to the central site (datacenter) were replaces by HA IPSEC tunnels over the corporate internet link which are monitored by a second tunnel which get up on the end consumer internet link as soon as the corporate link goes down.

Users of each site are now reaching internet directly from their site (and not from the central site) using SD-WAN sith an agregate interface of the 2 links.

SD-WAN policies are deployed to offload traffic of the corporate internet link to the end consumer internet link for everythings which can use heavy bandwidth or not previsible like Windows update, some allowed youtube channels, etc... and handle all traffic if the latency of the corporate link reach a certain value.

To go back to my actual use-case, except for IPSEC tunnels, I'm not sure that after agregating wan interfaces to a single sd-wan interface it's sitll possible to make policies using only one of the agregate interface (think it's not possible) and I don't know if it's also possible to adress intra sd-wan zone traffic between the 2 or more interfaces agregated to a single sd-wan interface. Also, I did not test VRF support with sd-wan interfaces (does 2 interfaces of 2 differents VRF could be agregated in a single sd-wan zone ? if yes, does it work as expected ? the customer is working in medical so different traffic had to be separated into at least different VRFs / VDOM or better on different hardware which is not the case here )

And to be honnest, I did not think about SD-WAN for this use case because of two things :

- Systems are in production and have an heavy history and I cannot have an enough big downtime timeframe where I can put the production offline to rewrite and to test all (hundreads and hundreads) policies with the SD-WAN interface and I do not have any QA system to POC it 

- SD-WAN is OSI-L7 and the customer I'm working for had nearly no network team (that's why I'm working for him) and already have some difficulties in understanding  OSI-L2 and OSI-L3 protocoles, so I didn't want to grow the OSI level and prefer to stay at the lowest possible level 

(It's quiete cheap and easy to find NSE4 or CCNA/CCNP people on the market who can easily handle use case with VRFs and dynamic routing, it's more difficult to find some real SD-WAN experts)

Kind regards

nbanba

Apologies for reviving an old topic, but I could not find a more relevant one, since the issue I am facing could be potentially solved by having simultaneously in the routing table 0/0 routes that are of static and BGP origin.

We are running a small SD-WAN setup with basically default settings on the 7.2 code train, where the client insists on using central Internet breakout, to inspect traffic on their own HQ FWs.

I don't think I am the first one hitting this issue, but somehow I am unable to find a proper solution for the spoke sites (the hub is easy, as you have competing static routes and you can have ECMP there).

Each spoke has a static 0/0 towards wan1 and also learns 0/0 via iBGP from the hub. Changing AD or priority leads to one or the other 0/0 being installed in the routing table, but never simultaneously.

I don't really need ECMP for this case, just both 0/0 routes present in the routing table simultaneously, to apply SD-WAN rules and have them actually steer traffic.

This is how the routing table looks like:

Routing table for VRF=0
B *> 0.0.0.0/0 [200/0] via 10.50.63.253 (recursive is directly connected, HUB1-VPN1), 00:00:39, [1/0]
S 0.0.0.0/0 [200/0] via [GW-ip-redacted], wan1, [1/0]

If the static 0/0 wins - customer can't use the central breakout. SD-WAN rules require a valid route, so one option would be to disable this check as described here - https://community.fortinet.com/t5/FortiGate/Technical-Tip-Explaining-the-SD-WAN-rule-matching-process/ta-p/284325

I'd really like to avoid using this option, if I can help it.

If the BGP 0/0 wins - great for the customer, but the FGT connections to FMG/FAZ/Fortiguard and so on are out of luck, as I have to set /32 static routes for them on the individual FGTs, otherwise this traffic goes to the customer HQ FW.

Has anyone hit this issue and if so - what solution did you use, as I don't see any option beside disabling the SDWAN check for a valid route in the routing table or some wild PBR setup.

First, why don't you start a new thread? Using an old thread always causes trouble for all parties for searching/status control/other management issues.

If all internet-bound traffic needs to go through the HUB locations/FW, spoke locations can't have 0/0 route toward wan/wan1 interface (underlay). The spokes needs to have a /32 route to wan/wan1 to get to the HUB to establish the VPN tunnel. Then either the HUB-advertised 0/0 route or local static 0/0 pointing to the tunnel takes all traffic to the HUB.

Toshi