handling of the onlink next hop

[Maria Matejka]

Thanks, Radu!

If I interpret this correctly, you run `from_kubernetes` in two places:

- BGP import
- kernel export

I expect that in the table, there are routes from:

- BGP
- Direct
- Kernel

While the BGP routes (should) have the `from` attribute properly set
(and therefore the `gw` setting works), the Direct and Kernel routes
have no such attribute, and on export to kernel, the filter complains.

There is actually an undocumented difference between BIRD 2 and 3
(mea culpa, gonna fix that soon in the documentation) → in BIRD 2, all
routes have the `from` attribute available but ony BGP, Babel and RIP
set it to a meaningful value. Notably, Direct and Kernel set `::` there.

In BIRD 3, only BGP, Babel and RIP routes have the `from`
attribute and in others, the attribute is undefined, therefore the
filter complains.

And because the filter is run on export to the kernel, it also runs on
the Direct routes, and exactly as I checked with our test setup, the
final behavior of the filter looks the same in v2 and v3. It lets BGP
routes pass (because they have `from` set) and rejects Direct routes.

The only difference is that with Direct routes, the :: nexthop is
considered invalid in BIRD 2 (yielding the "Invalid gw address" error),
whereas in BIRD 3, it's caught one step earlier and the report is more
cryptic.

The occassional "Invalid gw address" error in the logs, as well as the
new error message should be possible to tame by this piece of filter:

```
if ! defined(from) || (from = ::) then reject "from not set for ", net;
```

… or just `… then reject;` if you want it silent.

Now I hope that I have deciphered your situation correctly and this
brings some help to you.

I may obviously be wrong and there may be a bug, but to help locate it,
I'll need a log with `debug channels all;` on toplevel of your config,
and logs including the `trace` level. This will pin the error message to
the actual offending route, and in turn to the source of that route
which we can then investigate for missing the `from` attribute.

Have a nice day! 
Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.


On Wed, May 28, 2025 at 05:31:16PM +0200, Radu CARPA wrote:

> Hi, Maria,
> 
> Hereafter is the (very slightly modified) full configuration.
> Please tell me if you need any more context information about it.
> 
> Regards,
> Radu
> 
> On 5/28/25 3:04 PM, Maria Matejka wrote:
> > 
> > Which protocol originates the routes which are filtered by
> > |from_kubernetes|? It looks like the |from| attribute is not set (which
> > is probably another bug).
> > 
> 
> ```
> router id from "-tun*", "*";
> 
> filter from_kubernetes {
>  if ( net ~ 10.0.0.0/16  ) then {
>    ifname = "tunl0";
>    onlink = true;
>    gw = from;
>    accept;
>  }
>  reject;
> }
> 
> filter direct_tunl0 {
>  if ( net ~ 10.0.0.0/16 && source = RTS_DEVICE ) then {
>    accept;
>  }
>  reject;
> };
> 
> protocol direct {
>  debug { states };
>  ipv4;
>  interface "tunl0";
> }
> 
> protocol kernel {
>  merge paths on limit 32;
>  learn;
>  persist;
>  scan time 2;
>  ipv4 {
>     table master4;
>     import all;
>     export filter from_kubernetes;
>  };
>  graceful restart;
> }
> 
> protocol device {
>  debug { states };
>  scan time 2;
> }
> 
> template bgp bgp_template {
>  passive on; # Kubernetes nodes will connect to us.
>  debug { states };
>  password "password";
>  local as 64512;
>  ipv4 {
>    import filter from_kubernetes;
>    export filter direct_tunl0;
>    add paths on;
>  };
>  graceful restart;
>  connect delay time 2;
>  connect retry time 5;
>  error wait time 5,30;
> }
> 
> protocol bgp kube_nodes from bgp_template {
>  neighbor range 10.0.0.0/16 internal;
> }
> 
> log syslog all;
> ```
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20250528/6370d177/attachment.htm>