<div dir="ltr">Additionally, I should mention that the issue persists even when I explicitly declare the IGP table using the following configuration file.<div><br></div><div>protocol bgp cloudflare_tpix_210440_v4 {<br> local as 210440;<br> source address 203.163.223.48;<br> neighbor 203.163.222.39 as 13335;<br> ipv4 {<br> table table_tpix_210440_v4;<br> import keep filtered on;<br> import where import_filter_v4();<br> export where export_filter_tpix_210440();<br> graceful restart on;<br> export limit 99 action block;<br> igp table table_tpix_210440_v4;<br> };<br>}</div><div><br></div><div>BIRD 2.17.1 ready.<br>Table table_tpix_210440_v4:<br><a href="http://1.1.1.0/24">1.1.1.0/24</a> unicast [cloudflare_tpix_210440_v4 2026-01-12 02:07:03] * (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> BGP.local_pref: 100<br> BGP.aggregator: 162.158.240.1 AS13335<br> BGP.community: (13335,10080)<br> BGP.large_community: (213605, 10, 1) (213605, 10, 4)<br><br><br></div><div>BIRD 2.17.1 ready.<br>Table table_tpix_210440_v4:<br><a href="http://203.163.222.0/23">203.163.222.0/23</a> unicast [direct_tpix_210440 2026-01-12 02:04:33] * (240)<br> dev ens4<br> Type: device univ</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jan 12, 2026 at 1:57 AM Pysio <<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"><div dir="ltr"><p>Hi Alexander,</p>
<p>Thank you for your response. To answer your question: yes, I am using specific tables (e.g., <code>table_tpix_210440_v4</code>) for each BGP session, and I have corresponding <code>protocol direct</code> instances to populate those tables with the respective interface routes.</p>
<p>However, despite having a valid direct route in the specific table, BIRD still resolves the BGP next hop via <code>ens23</code> (the first interface in the kernel's subnet list) instead of honoring the device route defined in the local table.</p>
<p>Below is the relevant part of my configuration for your review.</p>
<p>```config<code><br>
table table_tpix_210440_v4;<br>
table table_tpix_210440_v6;<br>
<br>
protocol direct direct_tpix_210440 {<br>
ipv4 { table table_tpix_210440_v4; };<br>
ipv6 { table table_tpix_210440_v6; };<br>
interface "ens4";<br>
}<br>
<br>
<br>
protocol bgp cloudflare_tpix_210440_v4 {<br>
local as 210440;<br>
source address 203.163.223.48;<br>
neighbor 203.163.222.39 as 13335;<br>
ipv4 {<br>
table table_tpix_210440_v4;<br>
import keep filtered on;<br>
import where import_filter_v4();<br>
export where export_filter_tpix_210440();<br>
graceful restart on;<br>
export limit 99 action block;<br>
};<br>
}<br>
</code><br>
</p>
<p>```</p>
<p>Even though <code>table_tpix_210440_v4</code> contains a direct route for <code><a href="http://203.163.222.0/23" target="_blank">203.163.222.0/23</a></code> via <code>ens4</code>, BIRD's <code>show route</code> output for the BGP session on <code>ens4</code> indicates the next hop is resolved via <code>ens23</code>.</p></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 12, 2026 at 1:06 AM Alexander Zubkov <<a href="mailto:green@qrator.net" target="_blank">green@qrator.net</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"><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"><div dir="ltr" class="gmail_attr">On Sun, Jan 11, 2026 at 3:14 PM HaoRanLiu <<a href="mailto:mcyouyousever@gmail.com" target="_blank">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>
</blockquote></div>
</blockquote></div>