Bird v3 BGP route selection

[Ondrej Zajicek]

On Tue, Feb 25, 2025 at 12:39:29AM +0000, Nigel Kukard via Bird-users wrote:
> Hi there,
> 
> I'm wondering if someone can point out how the best path is being selected
> below in Bird 3.0.1?
> 
> In Bird v2 the route via 100.201.0.2 was selected. With the exact same
> configuration in Bird v3, the route via 100.201.0.4 is being selected.

Hi

I do not think this is really a change. If two routes have the same
preference and are originated by the same protocol 'class' (e.g. BGP),
they are compared using protocol-specific strategy (e.g. comparing
bgp_local_pref, bgp_path length, ... in case of BGP). But in your case
these two routes are from different protocols 'classes' (bgp_originate4
-> BGP a static4 -> Static), in that case there is only fixed arbitrary
ordering, and that may changed between Bird v2 and v3.

I would suggest that different protocol 'classes' should always use
different preference.



> In this case R1 is connected to R2. Both with the same ASN. The below table
> is the table I have facing R2.
> 
> In terms of my routing tables...
> - originate4 =exports to=> bgp4
> - static4 =exports to=> master4
> - master4 <=exports/imports=> bgp4
> - bgp4 <=exports/imports=> t_bgp4_AS65000_r2_peer (below)
> 
> 
> 1007-Table t_bgp4_AS65000_r2_peer:
>  0.0.0.0/0            unicast [bgp_originate4 2025-02-24 23:21:13] * (200)
>        via 100.201.0.4 on eth2
>  1012- preference: 200
>        source: static
>        bgp_local_pref: 930
>        bgp_large_community: (65000, 3, 1)
>  1008- Internal route handling values: 0L 24G 0S id 1
>  1007-                     unicast [static4 2025-02-24 23:21:13] (200)
>        via 100.201.0.2 on eth2
>  1012- preference: 200
>        source: static
>        bgp_local_pref: 940
>        bgp_large_community: (65000, 3, 1) (65000, 5000, 1)
> 1008- Internal route handling values: 0L 22G 0S id 6
> 
> 
> Kind Regards
> Nigel
> 

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
"To err is human -- to blame it on a computer is even more so."