hi Gents,
just a quick question- can you configure a priority for routes learned from BGP like you do for static routes?
bgp config - i have changed the admin distance to match that on static routes
gbp route map - I have set the metric same as the one on static routes
what i want to achieve is have a static default route and a default route learnt from BGP peers in the routing-table, I have seen the route in the database
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.
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:
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:
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
I have changed the admin distance and metric for BGP learned default route to match the static route ones so it also gets installed onto the routing table.... The only thing I can seen to figure out is how to configure priority for a BGP learned route like you do with statically configured routes
Can you explain exactly what you're trying to accomplish?
Hi Gram,
I have 2x lines from one ISP and another from another ISP, they're running vrrp so with static routes that's my gateway. We have a different VIP range from the ISP, routes for that are injected onto the CE side - so my thinking is we can have BGP configured between my fgt and ISP 1 two CEs, they'll advertise a default route to me and I'll advertise out the VIP range, however the two routes need to appear in the routing table like they would if you have 2x static default routes with different priorities.
The reason I'd have BGP is that I also need to failover the VIP range between sites during a DR instead of having to log a call with the ISP 1 and have them statically failover the ranges.
Sorry it's a bit confusing. You have two ISPs, one provides two links with VRRP and the other is just a single link?
What do you mean you have a different VIP range from the ISP? Are you talking about FortiGate VIP or different type of VIP here? VRRP VIP?
I still don't really understand what you're trying to accomplish with the static route from ISP2 and the BGP routing table from ISP1.
It sounds like you want to advertside ISP2's routes into ISP1's BGP instance? That.... doesn't sound like a good idea to me.
Maybe you can clear it up a bit better though?
Hi @gfleming ,
Yes - 2x ISP (one with two links and another just a single link).
We have a Public range on the ISP with 2xLinks - our Virtual IP range.
Initial:
-The FGT has 2x default routes for both these ISPs and the route is in the routing table each with a different priority configured.
- the public range is advertised to us statically on the ISP with 2xLinks
- During a failover to a DR site, the public range routing needs to be moved from this site and be advertised the other side - done by ISP.
What could be good to automating failover:
- have BGP instance with ISP with 2xlinks and advertise to them our public range and they'll advert out a default route
- have the matric and admin distance of the default route from BGP match that of the static so the route appears in the routing table - done via GBP global config and route-maps.
challenge:
--with the BGP default route in the routing table together with a statically configured one, can I configure a priority for the BGP learned default route?
- this is to configure a priority of the route like one would on FortiGate static routes
OK More questions now that I Have a clearer idea of what's going on. For future I will refer to 2x link ISP as "ISP1" and the other as "ISP2".
Does ISP1 use BGP with you today? If not do they even support talking BGP with you?
Does ISP2 use BGP and/or support it?
IS your public range a /24 or larger block that you own? Or is it an ISP block that is provided to you from your ISP? I.e. can you use the same public range on ISP2 when ISP1 is down?
The question of moving the public range to the DR site leads me to believe you are just being given a public block assigned (and owned) by the ISP1 as they are the ones involved in moving it to the DR site.
Have you spoken to your ISP about this? Have they suggested they could use BGP to solve it?
If so and this is all cleared up now is the issue that you want BGP default route to co-exist with static default route to ISP2 for things like load balancing, SD-WAN, etc?
If that is the case have you spoken to ISP2 to see if they support BGP?
Hi @gfleming ,
apologies for late response. ISP1 currently is static routing - they support BGP.
BGP not supported for ISP2
public range is a /27 provided by ISP1 - can't be used on ISP2. ISP1 assigned us the public block and owns it.
ISP1 has agreed to BGP - we'll have to do the same on the DR site.
yes the BGP default route should co-exist with the static default for ISP2 on the routing table for load-balancing. we do not have an SD-WAN license.
You cannot have a BGP route and a static route active at the same time.
You do not need a license to activate SD-WAN. SD-WAN will use both BGP and static routes simultaneously and let you define granular rules on how to steer traffic.
Or, alternatively, you look at alternative methods of migrating your public range over to the DR site that does not involve BGP....
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 |
---|---|
1737 | |
1108 | |
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.