<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Liu,<br>
<br>
are you talking about the channel option `gateway recursive`
(<a class="moz-txt-link-freetext" href="https://bird.nic.cz/doc/bird-2.18.html#bgp-gateway">https://bird.nic.cz/doc/bird-2.18.html#bgp-gateway</a>) and that even
with it on it still does not work?<br>
<br>
If I understand your issue correctly, this should resolve the
issue you are having (keep in mind that the option in not
compatible with sorted tables).<br>
In BIRD v3 you should be able to see item host-entry in the route
info (via `show route table all all` or similar), unfortunately
this information is not present in v2.<br>
<br>
You are right that BIRD should do this better right away. However
to fix this, a much bigger refactor of the code is required.<br>
It is on our backlog, but we can not promise you that the changes
will made in time for the release of v2.19.<br>
<br>
Hope this helps a bit,<br>
David</p>
<pre class="moz-signature" cols="72">David Petera (he/him) | BIRD Tech Support | CZ.NIC, z.s.p.o.</pre>
<div class="moz-cite-prefix">On 1/11/26 22:40, Pysio wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAN3+gatxeyYzZbHVxR3U0=kGDoeUkBAQLeBtLo8XoNfPHfJqOg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi Alexander,<br>
<br>
Thanks for the tips!<br>
<br>
I just tried the multihop (recursive) approach, but
unfortunately, it didn't change anything. Even with multihop on,
BIRD still picks ens23 for the next hop resolution. It seems
like it's still looking at the global interface list instead of
sticking to the route in the specific table I've assigned.<br>
<br>
I'll give VRFs a shot later tonight to see if that fixes<br>
<br>
While VRFs should work as a workaround, I still feel like BIRD
should ideally handle this better out of the box. In a
multi-table setup, you'd expect it to prioritize the lookup
within the attached table first.<br>
<br>
Anyway, I’ll let you know how the VRF test goes!<br>
<br>
Best,<br>
<br>
Liu HaoRan</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Mon, Jan 12, 2026 at
3:03 AM Alexander Zubkov <<a href="mailto:green@qrator.net"
moz-do-not-send="true" class="moz-txt-link-freetext">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>I probably saw something like that bug for IPv6, so not
sure if it is the same. And I did not have separate tables
for the interfaces. But worth a check anyway. It seemed to
me that direct sessions created routes with the interface
and ip through that the bgi session was installed. And
recursive (multihop) sessions set the routes to the first
found interface (I remind, I had all them in one table).</div>
<div>So you can try to change protocol to recursive to check
(but it could have other drawbacks) if it would use the
appropriate route from the attached table.</div>
<div>Also, if you wander of the possible solutions, I think
you could play with vrfs to divide the interfaces routing,
bird is aware of vrfs.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Jan 11, 2026 at
7:09 PM Pysio <<a href="mailto:mcyouyousever@gmail.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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">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" target="_blank"
moz-do-not-send="true">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" target="_blank"
moz-do-not-send="true">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">
<div dir="ltr" class="gmail_attr">On Mon, Jan 12, 2026
at 1:57 AM Pysio <<a
href="mailto:mcyouyousever@gmail.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">203.163.222.0/23</a><br>
<a href="http://203.163.222.0/23"
rel="noreferrer" target="_blank"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>