Re: networkd: learned DNS server not propagated to rdnss option in RA

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Mittwoch, 13. Dezember 2023, 09:01:46 CET schrieb Andrei Borzenkov:
> On Wed, Dec 13, 2023 at 10:46 AM Michael Heimpold <mhei@xxxxxxxxxxx> wrote:
> > Dear all,
> > 
> > I'm trying to setup an embedded system as IPv6 router using IPv6
> > prefix delegation. The system has two network interfaces, eth0 and
> > eth1. eth0 is the upstream interface, but it is part of a bridge
> > interface,
> > but I think this does not play an important role here.
> > The upstream interfaces acquires an IPv6 via RA and also learns
> > the DNS server from the upstream router. IPv6 and DNS resolving
> > works properly on the system.
> > (note: the upstream interface is dual-stack, IPv4 is also working as
> > usual).
> > 
> > The goal is to pass routable IPv6 addesses down to a system connected
> > via eth1 ("client"). In my understanding, this is what IPv6 prefix
> > delegation is for and it is working so far, that the client acquires an
> > IPv6 and I can ping IPv6 addresses on the Internet etc.
> > However, when I look at the IPv6 RA sent out on eth1 interface, the rdnss
> > option is missing, so that the client does not learn any DNS server over
> > the link.
> > 
> > Please find below my configuration files. My understanding of the
> > documentation is, that this should work out-of-the-box since all related
> > config options have reasonable defaults (EmitDNS, UseDNS...), so that
> > learned DNS server from upstream interfaces should propagate to the RAs
> > of the downstream interface. But this is not the case.
> > If I manually configure DNS=... option in the "IPv6SendRA" section, then a
> > rdnss field is part of the RA and then the client learns the DNS server
> > and
> > I also have DNS on the client working. So this is not an issue on the
> > client itself.
> > 
> > On my system, I'm using systemd-networkd v250.5 from Yocto kirkstone,
> > but I also tested v254.4 with no difference in behavior.
> > 
> > My question is whether I have a wrong understanding or might this be a
> > bug?
> > Any hints are appreciated.
> > 
> > Thanks,
> > Michael
> > 
> > 
> > --snip: /lib/systemd/network/br0.network--
> > [Match]
> > Name=br0
> > 
> > [Network]
> > DHCP=yes
> > IPv6AcceptRA=yes
> > 
> > [DHCPv4]
> > ClientIdentifier=mac
> > UseHostname=no
> > 
> > [DHCPv6]
> > UseHostname=no
> > --snap--
> > 
> > --snip: /etc/systemd/network/eth1.network--
> > [Match]
> > Name=eth1
> > 
> > [Network]
> > DHCP=no
> > IPv6AcceptRA=no
> > IPForward=ipv6
> > IPv6SendRA=yes
> > DHCPPrefixDelegation=yes
> > --snap--
> 
> Quoting documentation
> 
> --><--
> DNS servers from the uplink interface specified in UplinkInterface= will be
> used --><--
> 
> Try adding
> 
> UplinkInterface=br0


Quoting again the documentation:
--><--
UplinkInterface=

Specifies the name or the index of the uplink interface, or one of the special 
values ":none" and ":auto". When emitting DNS servers or search domains is 
enabled but no servers are specified, the servers configured in the uplink 
interface will be emitted. When ":auto", the value specified to the same 
setting in the [DHCPPrefixDelegation] section will be used if 
DHCPPrefixDelegation= is enabled, otherwise the link which has a default 
gateway with the highest priority will be automatically selected. When 
":none", no uplink interface will be selected. Defaults to ":auto".
--><--

So ":auto" should be the default, since I did not set it.

I tried to set it explicitly to "br0" as you suggested, but it does not change 
anything :-(

(More over, I'd also keep it unspecified since on another system where I want 
to use the same feature later, I have two upstream interfaces and I don't know
which one will actually be used by customer - so having a fixed configuration 
would be not that ideal for me - but this is not yet important).

But thanks for your hint,
best
Michael







[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux