Hi All,
I am trying to have Dual Hubs for my spoke.
I just set up Hub A using the built-in Wizard of Fortigate.
All branches and Hub A are working well on day one.
We are going to have a new Firewall at DataCenter as DR second Hub now.
All traffic will only go through Hub A and only use Hub B if my Hub A goes offline.
To achieve this, we set up the route-map-out for both Hub A and B BGP settings.
The metric for Site A is 5, and Hub B is 100.
We tested the connection, Both Hubs VPN up and seem good for traffic.
We tried to shut down Hub A VPN then, all traffic was routed to Hub B.
When Hub A resumed, we found that the Branch learned BGP from A again and the Metric is 5.
However, the route with Metric 100 from B is still the best path for the branch and does not go through the Hub A.
Please advise.
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Created on 04-03-2024 09:47 AM Edited on 04-03-2024 10:09 AM
Before seeing your BGP config in show router bgp on both Hubs, I'm guessing you're using different AS for Hub A and B.
If so, try "set always-compare-med enable" option under "config router bgp" on the branch sides to see if this would give you your expecting behavior.
config router bgp
set always-compare-med enable
end
This is probably not configurable in GUI.
Toshi
Yes, that is exactly what I just made few days ago and worked for me now.
Thank you.
And that is Gui available on 7.0.X OS.
Created on 04-04-2024 05:35 PM Edited on 04-04-2024 11:58 PM
The reason was MED is originally designed to work only between two neighboring ASes. It's written in the original BGP RFC4271 and more explanation in RFC4451.
So if both HubA and B are in the same AS, say 65535 and a remote is 65534, MED is considered to decide the best route at the remote/AS 65534 side. Because both came from AS:675535.
In Cisco's and Juniper's doc for BGP best route selection algorithm they clealy state "it would be ignored" in the situation you have.
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
Unfortunately Fortinet's doc/KB never mentions about it.
https://community.fortinet.com/t5/FortiGate/Technical-Tip-BGP-route-selection-process/ta-p/195932
The option you adjusted "bends" the rule a little bit to extend the usage of MED wider.
In other words, MED is a tricky metric and need to be used carefully if you decide to use it in complex situations while some other higher priority/easier metrics in BGP are available.
In your particular case, you just need to set "local-preference" higher like 200 for routes from Hub-A and set it lower like 100 for routes from Hub-B at each remote location, which would be probably the best method. Unlike MED, nothing else other than "weight" can override local-preferences.
So this is for your future consideration.
Toshi
Um... Seem I find a way to fix the issue.
I can have the lowest path back to routing table after I enable one feature on Fortigate.
I am checking on it and let me update the result later.
What do you mean by "metric"? BGP doesn't have any metric named as "metric". It has to be either weight, AS path, MED, or local preference decided by received community, etc.
Can you share those route-maps you set on both Hub A and B, and the route-map on the spoke side to use the received "metric"?
Toshi
""BGP doesn't have any metric named as "metric"."" - Are you serious?
As I said it's called "MED" in the KB.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1733 | |
1106 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.