[systemd-devel] networkd: Support setting mtu / mac address by interface name

[Tom Gundersen]

Thanks for the links William. Looks like most of that should be
covered by networkd. I now also added support for MTU and MACAddress
to be set in the .network files. The intention here is that if you
ever disable a network at runtime, we will revert to the default
(.link-defined) settings. However, runtime configuration is not yet
implemented, so for now the only distinction between setting this in a
.link and a .network is that you can now match on the real ifname.

HTH,

Tom

On Thu, Dec 4, 2014 at 9:07 PM, William Kennington
<william at wkennington.com> wrote:
> In regards to the OS and syntax, this is NixOS. NixOS uses its own
> expression language to configure the entire system, including the network
> stack. If a user wanted to configure their system's networking stack, they
> would modify the networking.* set of options in their
> /etc/nixos/configuration.nix. Currently this is done with a set of generated
> scripts run as systemd services with device based dependencies. Ideally this
> would be directly translated to networkd syntax.
>
> For example, a user might have this snippet as part of their config for
> statically configuring one of their ethernet interfaces:
>
> networking.interfaces."enp4s0" = {
>   macAddress = "de:ad:be:eef:ca:fe";
>   mtu = 9000;
>   ip4 = [
>     { address = "10.0.0.2"; prefixLength = 24; }
>     { address = "10.0.0.3"; prefixLength = 24; }
>   ];
> };
>
> For link configuration, we are currently generating a
> network-link-<ifname>.service which sets the mac address and mtu using
> iproute2:
> https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix#L691-L713
>
> The networking options are all defined in:
> https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix
>
> Our current translator to networkd is:
> https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces-systemd.nix
>
>
> Of course, the problem with just using kernel names is that our use case
> assumes that the interface was already renamed by udev. Therefore, our
> matching must be based on the post-udev name if it is to be backward
> compatible. Ultimately it might be best to continue using our set of scripts
> coupled with udev generated systemd device units, given our use cases.
>
> On Thu, Dec 4, 2014 at 9:53 AM, Tom Gundersen <teg at jklm.no> wrote:
>>
>> On Thu, Dec 4, 2014 at 4:11 PM, Lennart Poettering
>> <lennart at poettering.net> wrote:
>> > On Thu, 04.12.14 11:20, Tom Gundersen (teg at jklm.no) wrote:
>> >
>> >> > I mean, most of the times .link files are
>> >> > used to choose the name depending on other fields, but I think in all
>> >> > cases where the name is chosen at creation time of an interface (like
>> >> > for example for veth links), it should be Ok to match links based on
>> >> > the name they already have?
>> >>
>> >> So this we could do (i.e., allow name matches if and only if the name
>> >> is set at creation time). Though, if the name is set at creation time,
>> >> shouldn't also all the other properties have been?
>> >
>> > In nspawn we create veth links, and I *really* *really* don't want to
>> > add tons of options there to set the MTU or suchlike. Setting these
>> > properties really should be done within networkd I think.
>> >
>> > I think it would be really useful if we could match on the container's
>> > veth links by name, so that a .link file for it could be equally
>> > expressive as the .network file already is.
>> >
>> >> Moreover, if we
>> >> give people this feature I'm pretty sure we'll get lots of people
>> >> expecting it to work also for any other sort of name and getting
>> >> confused when it doesn't.
>> >
>> > Well, this is something we can fix by documentation, no?
>> >
>> > Or maybe name the match option differently, maybe OriginalName= or
>> > KernelName= or so, and then only matching interfaces where you know
>> > that the name was selected by userspace in the first place?
>>
>> I like the idea of OriginalName, much less likely to get people
>> confused. I now implemented that, with the restriction that we cannot
>> match on renamed names. For now I left it open to match on ethX style
>> names, as people in principle could do sensible things like
>> "OriginalName=eth*" or even "OriginalName=eth0" when we know there is
>> only one interface.
>>
>> One thing to consider would be to disallow renaming from a .link file
>> where the OriginalName was used to match. That way we don't have the
>> somewhat odd situation that a .link file can only be applied once (we
>> do not remember the original name, so cannot match on that the second
>> time around, as that would be a mess)...
>>
>> Testing and feedback welcome. Does this solve your problem William?
>>
>> Cheers,
>>
>> Tom
>
>