Recursive nexthop via kernel route in proto static not working

Alexander Zubkov green at qrator.net
Tue Jun 27 16:58:19 CEST 2023


Also try to enable debugging. It might log something about why it
cannot resolve the recursive route.

On Tue, Jun 27, 2023 at 4:48 PM Alexander Zubkov <green at qrator.net> wrote:
>
> Hi,
>
> Not sure, but I would guess it can be related to the local address. It
> might try to pick the first interface with such network. Could you try
> your setup with some route that has the nexthop from a unique subnet
> configured on the interface? At least to check if it will become
> reachable or not.
> Or it might be that routes imported from the kernel are marked as
> recursive, so it does not resolve because Bird does not allow double
> recursion.
>
> On Tue, Jun 27, 2023 at 4:22 PM Daniel Gröber <dxld at darkboxed.org> wrote:
> >
> > Hi,
> >
> > I'm trying to configure a static route that uses the system's default
> > router. The default router is out of my control and is announced via IPv6
> > RA. Since the MAC might not be stable I'd prefer not to hardcode the
> > router's link-local address. So I tried:
> >
> >     protocol static static_export_kernel2 {
> >         ipv6;
> >         igp table master6;
> >         route 2001:db8::/48 recursive ::;
> >     }
> >
> > The thinking being that :: ought to be resolvable through the default route
> > imported from proto kernel:
> >
> >     birdc show route for :: all
> >     Table master6:
> >     ::/0                 unicast [kernel1 2023-03-22] * (10)
> >             via fe80::fc00:3ff:fec7:cd05 on enp1s0
> >             Type: inherit univ
> >             Kernel.source: 9
> >             Kernel.metric: 1024
> >             Kernel.hoplimit: 64
> >
> > However the static route ends up being "unreachable":
> >
> >     2a0d:f302:114::/48   unreachable [static_export_kernel2 13:59:32.819] * (200)
> >             Type: static univ
> >
> > Any ideas why this isn't working?
> >
> > Thanks,
> > --Daniel
> >
> > PS: The reason I have to create this static route when it's already covered
> > by the default route has to do with an esoteric policy routing setup and
> > multiple routing daemons ask for details at your own peril :)



More information about the Bird-users mailing list