FRRouting
bgpd: Use src path attr under a knob, for bestpath calculation
When a BGP route is leaked from source VRF foo to destination VRF bar, a route-map can be configured to strip off AS path attributes during the import process. Consider a scenario, a route in VRF foo has an AS path length of 5 hops. After the route-map strips certain ASes during the leak to VRF bar, the resulting route/path has an AS path length of 1 hop. The problem occurs during bestpath selection in VRF bar when comparing this leaked route/path against a remote route/path (also imported into VRF bar) with an AS path length of 3 hops. Instead of using the current AS path length of 1 hop from the leaked route's attributes in VRF bar, the bestpath algorithm traverses back to the parent route in source VRF foo and uses its original AS path length of 5 hops for comparison. The comparison becomes 5 hops versus 3 hops, causing the leaked route to lose even though its actual AS path in VRF bar is only 1 hop. This results in suboptimal routing .
Rather than unconditionally using attribute from source path, do that under a BGP level configuration.
With use-imported-attributes>> BGP routing table entry for 203.0.118.0/24, version 37 Paths: (2 available, best #1, vrf vrf2) Advertised to peers: ext-1(192.0.2.5) Imported from 192.0.2.2:3:203.0.118.0/24 4200000188 10.0.0.30(bordertor-11) from 0.0.0.0 (192.0.2.6) vrf vrf1(8) Origin incomplete, valid, sourced, local, bestpath-from-AS 4200000188, best (AS Path) Originator: 10.0.0.1 Last update: Mon Dec 8 04:12:15 2025 Imported from 10.0.0.30:5:[5]:[0]:[24]:[203.0.118.0], VNI 104002 651001 652000 651004 650030 4200000000 4200000034 4200000188 10.0.0.30(leaf-11) from leaf-11(10.254.0.2) (10.0.0.24) announce-nh-self Origin incomplete, valid, external, bestpath-from-AS 651001 Last update: Mon Dec 8 04:12:14 2025
Without use-imported-attributes>>> BGP routing table entry for 203.0.118.0/24, version 45 Paths: (2 available, best #2, vrf vrf2) Advertised to peers: ext-1(192.0.2.5) Imported from 192.0.2.2:3:203.0.118.0/24 4200000188 10.0.0.30(bordertor-11) from 0.0.0.0 (192.0.2.6) vrf vrf1(8) announce-nh-self Origin incomplete, valid, sourced, local Originator: 10.0.0.1 Last update: Mon Dec 8 04:12:16 2025 Imported from 10.0.0.30:5:[5]:[0]:[24]:[203.0.118.0], VNI 104002 651001 652000 651004 650030 4200000000 4200000034 4200000188 10.0.0.30(leaf-11) from leaf-11(10.254.0.2) (10.0.0.24) announce-nh-self Origin incomplete, valid, external, bestpath-from-AS 651001, best (First path received) Last update: Mon Dec 8 04:12:14 2025
So the scenario here is that a user has explicitly configured policy to modify path attributes as routes are leaked, but then they want a knob to have bestpath pretend like the attributes were never modified? That sounds convoluted, which generally means it's not the right solution.
It seems to me like the right answer here is to configure policy the right way and avoid this issue altogether. i.e. If you don't want bestpath in VRF bar to use manipulated attributes, then don't manipulate the attributes when leaking routes from VRF foo. Instead, manipulate them outbound towards the peers in VRF bar.
How many users have you heard from who encountered this situation and couldn't realistically address this using alternative policy configuration? Even if this does get accepted as a new bestpath knob, why should it be the new default for the DC profile?
So the scenario here is that a user has explicitly configured policy to modify path attributes as routes are leaked, but then they want a knob to have bestpath pretend like the attributes were never modified? That sounds convoluted, which generally means it's not the right solution.
User didnt ask for a new knob, they have policy to strip off AS path attribute when leaking from foo to bar, and they want to use modified ASes in bar. but current code doesnt allow it, still uses src path attr, so from user perspective, it defeats their purpose, they can't utilize route policy modification.
But current code behavior also existing since 2020, via da0c0ef70cfb413450539581de2508fb6a385fc3. It seems, code committer had something in mind, so did it intentionally. That's rather completely getting rid off that change, we want to have it under a new config, so that if there is any use case, where usage of src path attr is needed, user can still use it via new config.
It seems to me like the right answer here is to configure policy the right way and avoid this issue altogether. i.e. If you don't want bestpath in VRF bar to use manipulated attributes, then don't manipulate the attributes when leaking routes from VRF foo. Instead, manipulate them outbound towards the peers in VRF bar.
Customer wanted to manipulate via policy when leaking from foo to bar, they have some use case.
How many users have you heard from who encountered this situation and couldn't realistically address this using alternative policy configuration? Even if this does get accepted as a new bestpath knob, why should it be the new default for the DC profile? > For this could not decide, I will take it out, so basically , open to opinion , the new config 1) tells to use src path attr or 2) dst path attr, use DC profile accordingly.
Ok, the situation makes more sense now, thanks for elaborating.
I'm not sure I agree with the current code behavior (using source vrf's path info), but regardless of whether we use source or destination path info I think it should be configurable.
As for defaults, I try to follow the principal of least surprise. If a new default has a significant chance of breaking something for an existing deployment (like tweaking bestpath in an otherwise stable network), then I lean towards not changing the default. If there's a really good reason to update the default (e.g. it's a noticeable improvement to most deployments and is highly unlikely to break an existing deployment) then that's fine, but there should still be some kind of migration plan rather than a sudden change.
Could you add a JSON (and non-JSON) outputs to the show commands for the route to see if this was ultimate (source) or imported?
1)If we have to track per path, then we need to introduce/use some kind of path flag, which normally is scarce, if not supercritical to consume a bit flag. Currently we have uint32_t flags and it seems Bits 21-31 (11 bits free) are free, but we should be really careful to consume a bit here 2) Alternately, if just check the bgp->flags, BGP_FLAG_BESTPATH_USE_SRC_ATTRS, and use for show command, that is as good as seeing the configuration applied or not running show run. So dont see much gain. Please let know what do you think.