Hi,
I am doing a lab setup where I have hit a problem with ebgp routes disappearing from the routing-database when ibgp routes shows up. I have not done any route manipulation on my BGP session at the moment. I would have thought that even if the route is not active it would appear in the routing-database (get router info routing-table database). I can see the routes being advertised and also received (get router info routing-table bgp neigh received-routes).
The BGP sessions are over the tunnel and I am assuming that there would not be any difference.
Any help is appreciated.
San
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.
Fortigate adds below config by default to set local-preference to 100.
FGT # config router bgp
FGT (bgp) # show full | grep local-pre
set default-local-preference 100
IBGP carries the local-prefernce values within same AS and due to that reason you get route with local-preference 100 and thats the reason IBGP route is getting activated.
You can either set the "set default-local-preference 0" on the advertising device (IBGP neighbor) or apply a route-map in the receiving fortigate to make local-preference 0 for IBGP or another route-map to increase the local-preference to 200 for EBGP route.
Here the IBGP route is preferred due to higher local-preference,which is expected behavior, not a bug.
Ok, I misread the previous post. So eBGP learded routes without route-map/no loca-pref adjustment get local-pref=0 by default. Isn't this a bug? Shouldn't it get local-pref=100 by default?
Toshi
eBGP-learned routes cannot have LOCAL_PREF equal 100, or any value for that matter - BGP RFC 4272 prohibits External BGP peers sending/receiving this attribute altogether, it is only set locally and exchanged between iBGP peers. So, to indicate that received from eBGP peer prefixes bear no Local Preference attribute at all, vendors decided to assign the value of 0, to mean "no local preference present for this incoming eBGP prefix".
I tried to find why they agreed on value 100 for the Local Preference as the default for iBGP, and not the same 0 , but couldn't - no BGP-related RFC tells any value to be set on LOCAL_PREF, nor states that by default iBGP routes should be more preferred to eBGP ones. If anyone could point me to the source, it would be awesome (Why 100 and not 50, or 200 or 300?)
Created on 05-16-2023 10:22 AM Edited on 05-16-2023 10:32 AM
I know local-pref is a local metric, not transitive. But if eBGP routes don't get any local-pref set, those routes should be treated as 100. At least it's written for Cisco's documentation. In this case, 0 = 100. Is this not the case for FortiGates? I thought all our customer's FGTs behaved that way, because we set only secondary eBGP routes to 99 by assuming the primary routes have 100 by default ant they're working as expected. Or is this assumption true only between eBGP routes? Actually we have many situations combining between iBGP and eBGP and this assumption seems to be working.
Toshi
<correction> between iBGP neighbors, local-pref is transitive.</correction>
Actually this seems to be true but the problem with the OP's case is the eBGP learned route has "local-pref=0" set without any routemaps. It shouldn't be there.
Below is my home 40F's BGP table. Please notice LocalPref is empty because I didn't set. I would expect the same for OP's eBGP routes.
Exactly - it means nothing - iBGP/eBGP for the Fortigate (as well as any other gear - Cisco/Juniper/etc) as long as the Local preference of a route is higher than the other one.
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 |
---|---|
1705 | |
1093 | |
752 | |
446 | |
230 |
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.