<div dir="ltr"><div>Hi Lui,</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Alexander</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Jan 11, 2026 at 3:14 PM HaoRanLiu <<a href="mailto:mcyouyousever@gmail.com">mcyouyousever@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I am writing to report a potential issue (or seek clarification on <br>
resolution logic) in BIRD 2.17.1 regarding how next hops are resolved <br>
when multiple interfaces exist in the same subnet.<br>
<br>
[ Environment ]<br>
- BIRD version: 2.17.1<br>
- OS: Linux<br>
- Setup: Multiple physical interfaces (ens4, ens23, ens2) are configured <br>
with IP addresses in the same prefix: <a href="http://203.163.222.0/23" rel="noreferrer" target="_blank">203.163.222.0/23</a>.<br>
<br>
[ Observation ]<br>
Within a specific routing table (table_tpix_210440_v4), BIRD's recursive <br>
resolution for a BGP route does not seem to honor the "Direct/Device" <br>
route present in that same table.<br>
<br>
[ Evidence ]<br>
<br>
1. The Direct Route in table "table_tpix_210440_v4" points to ens4:<br>
<br>
bird> show route for <a href="http://203.163.222.39/32" rel="noreferrer" target="_blank">203.163.222.39/32</a> table table_tpix_210440_v4 all<br>
Table table_tpix_210440_v4:<br>
<a href="http://203.163.222.0/23" rel="noreferrer" target="_blank">203.163.222.0/23</a> unicast [direct_tpix_210440 2026-01-11 21:10:29] * <br>
(240)<br>
dev ens4<br>
Type: device univ<br>
<br>
2. However, a BGP route in the SAME table resolves via ens23:<br>
<br>
bird> show route for 1.1.1.1 table table_tpix_210440_v4 all<br>
Table table_tpix_210440_v4:<br>
<a href="http://1.1.1.0/24" rel="noreferrer" target="_blank">1.1.1.0/24</a> unicast [cloudflare_tpix_210440_v4 2026-01-11 <br>
21:33:43] * (100) [AS13335i]<br>
via 203.163.222.39 on ens23<br>
Type: BGP univ<br>
BGP.origin: IGP<br>
BGP.as_path: 13335<br>
BGP.next_hop: 203.163.222.39<br>
...<br>
<br>
[ System Network State ]<br>
The OS kernel shows three interfaces in this subnet:<br>
<br>
# ip route show <a href="http://203.163.222.0/23" rel="noreferrer" target="_blank">203.163.222.0/23</a><br>
<a href="http://203.163.222.0/23" rel="noreferrer" target="_blank">203.163.222.0/23</a> dev ens23 proto kernel scope link src 203.163.223.49<br>
<a href="http://203.163.222.0/23" rel="noreferrer" target="_blank">203.163.222.0/23</a> dev ens2 proto kernel scope link src 203.163.223.50<br>
<a href="http://203.163.222.0/23" rel="noreferrer" target="_blank">203.163.222.0/23</a> dev ens4 proto kernel scope link src 203.163.223.48<br>
<br>
[ Questions ]<br>
1. Is this a bug in the recursive resolution logic? It appears BIRD <br>
might be picking an interface from the global interface list (perhaps <br>
the first one UP) rather than following the best route available in the <br>
specific table being queried.<br>
2. Why does the BGP route's "via" field not honor the interface (ens4) <br>
defined by the device route in the same table?<br>
3. Is there any configuration to force BIRD to resolve next hops <br>
strictly based on the current table's best path in such multi-homed <br>
scenarios?<br>
<br>
Any insights would be appreciated.<br>
<br>
Best regards,<br>
Liu HaoRan<br>
<br>
</blockquote></div>