Potential bug: Inconsistent next-hop resolution in multi-homed same-subnet setup

[Pysio]

Hi Alexander,

Thank you for your response. To answer your question: yes, I am using
specific tables (e.g., table_tpix_210440_v4) for each BGP session, and I
have corresponding protocol direct instances to populate those tables with
the respective interface routes.

However, despite having a valid direct route in the specific table, BIRD
still resolves the BGP next hop via ens23 (the first interface in the
kernel's subnet list) instead of honoring the device route defined in the
local table.

Below is the relevant part of my configuration for your review.

```config
table table_tpix_210440_v4;
table table_tpix_210440_v6;

protocol direct direct_tpix_210440 {
    ipv4 { table table_tpix_210440_v4; };
    ipv6 { table table_tpix_210440_v6; };
    interface "ens4";
}


protocol bgp cloudflare_tpix_210440_v4 {
    local as 210440;
    source address 203.163.223.48;
    neighbor 203.163.222.39 as 13335;
    ipv4 {
        table table_tpix_210440_v4;
        import keep filtered on;
        import where import_filter_v4();
        export where export_filter_tpix_210440();
        graceful restart on;
        export limit 99 action block;
    };
}

```

Even though table_tpix_210440_v4 contains a direct route for
203.163.222.0/23 via ens4, BIRD's show route output for the BGP session on
ens4 indicates the next hop is resolved via ens23.

On Mon, Jan 12, 2026 at 1:06 AM Alexander Zubkov <green at qrator.net> wrote:

> Hi Lui,
>
> Does cloudflare_tpix_210440_v4 bgp protocol use table_tpix_210440_v4 as
> IGP table also? It might be better to have an overview of your config file.
>
> Regards,
> Alexander
>
> On Sun, Jan 11, 2026 at 3:14 PM HaoRanLiu <mcyouyousever at gmail.com> wrote:
>
>> Hello,
>>
>> I am writing to report a potential issue (or seek clarification on
>> resolution logic) in BIRD 2.17.1 regarding how next hops are resolved
>> when multiple interfaces exist in the same subnet.
>>
>> [ Environment ]
>> - BIRD version: 2.17.1
>> - OS: Linux
>> - Setup: Multiple physical interfaces (ens4, ens23, ens2) are configured
>> with IP addresses in the same prefix: 203.163.222.0/23.
>>
>> [ Observation ]
>> Within a specific routing table (table_tpix_210440_v4), BIRD's recursive
>> resolution for a BGP route does not seem to honor the "Direct/Device"
>> route present in that same table.
>>
>> [ Evidence ]
>>
>> 1. The Direct Route in table "table_tpix_210440_v4" points to ens4:
>>
>> bird> show route for 203.163.222.39/32 table table_tpix_210440_v4 all
>> Table table_tpix_210440_v4:
>> 203.163.222.0/23     unicast [direct_tpix_210440 2026-01-11 21:10:29] *
>> (240)
>>          dev ens4
>>          Type: device univ
>>
>> 2. However, a BGP route in the SAME table resolves via ens23:
>>
>> bird> show route for 1.1.1.1 table table_tpix_210440_v4 all
>> Table table_tpix_210440_v4:
>> 1.1.1.0/24           unicast [cloudflare_tpix_210440_v4 2026-01-11
>> 21:33:43] * (100) [AS13335i]
>>          via 203.163.222.39 on ens23
>>          Type: BGP univ
>>          BGP.origin: IGP
>>          BGP.as_path: 13335
>>          BGP.next_hop: 203.163.222.39
>>          ...
>>
>> [ System Network State ]
>> The OS kernel shows three interfaces in this subnet:
>>
>> # ip route show 203.163.222.0/23
>> 203.163.222.0/23 dev ens23 proto kernel scope link src 203.163.223.49
>> 203.163.222.0/23 dev ens2 proto kernel scope link src 203.163.223.50
>> 203.163.222.0/23 dev ens4 proto kernel scope link src 203.163.223.48
>>
>> [ Questions ]
>> 1. Is this a bug in the recursive resolution logic? It appears BIRD
>> might be picking an interface from the global interface list (perhaps
>> the first one UP) rather than following the best route available in the
>> specific table being queried.
>> 2. Why does the BGP route's "via" field not honor the interface (ens4)
>> defined by the device route in the same table?
>> 3. Is there any configuration to force BIRD to resolve next hops
>> strictly based on the current table's best path in such multi-homed
>> scenarios?
>>
>> Any insights would be appreciated.
>>
>> Best regards,
>> Liu HaoRan
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20260112/8bbc5c21/attachment.htm>