Systemd-networkd: Unterschied zwischen den Versionen

Aus Foxwiki
Keine Bearbeitungszusammenfassung
K Textersetzung - „== Syntax ==“ durch „== Aufruf ==“
 
(15 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''topic''' kurze Beschreibung
'''topic''' - Kurzbeschreibung
== Beschreibung ==
== Beschreibung ==
Der Netzwerk-DAEMON [https://wiki.ubuntuusers.de/systemd/networkd/#Links systemd-networkd] gehört zur systemd-Familie und konfiguriert Netzwerkschnittstellen auf den Ebenen 2 und 3 des [https://wiki.ubuntuusers.de/systemd/networkd/#Links ISO/OSI-Referenzmodells]. Mit diesem Programm kann man auch auf realen Schnittstellen aufbauende virtuelle Schnittstellen wie z.B. Brücken, Tunnel, VPN erstellen und diese konfigurieren. Das Programm kümmert sich aber nicht um Ebene 2 bei WLAN-Schnittstellen.
Der Netzwerk-DAEMON [https://wiki.ubuntuusers.de/systemd/networkd/#Links systemd-networkd] gehört zur systemd-Familie und konfiguriert Netzwerkschnittstellen auf den Ebenen 2 und 3 des [https://wiki.ubuntuusers.de/systemd/networkd/#Links ISO/OSI-Referenzmodells]. Mit diesem Programm kann man auch auf realen Schnittstellen aufbauende virtuelle Schnittstellen wie z. B. Brücken, Tunnel, VPN erstellen und diese konfigurieren. Das Programm kümmert sich aber nicht um Ebene 2 bei WLAN-Schnittstellen.


Bei Ubuntu-Server-Installationen wird systemd-networkd als [https://wiki.ubuntuusers.de/systemd/Units/ systemd-Unit] gestartet und als einziges Programm für die Konfiguration des Netzwerks verwendet. (Siehe jedoch [https://wiki.ubuntuusers.de/Netplan/ Netplan].)
Bei Ubuntu-Server-Installationen wird systemd-networkd als [https://wiki.ubuntuusers.de/systemd/Units/ systemd-Unit] gestartet und als einziges Programm für die Konfiguration des Netzwerks verwendet. (Siehe jedoch [https://wiki.ubuntuusers.de/Netplan/ Netplan].)
Zeile 15: Zeile 15:


== Anwendungen ==
== Anwendungen ==
=== Fehlerbehebung ===
=== Problembehebung ===
== Syntax ==
== Aufruf ==
=== Optionen ===
=== Optionen ===
=== Parameter ===
=== Parameter ===
=== Umgebungsvariablen ===
=== Umgebung ===
=== Exit-Status ===
=== Rückgabewert ===
== Konfiguration ==
== Konfiguration ==
=== basic configuration ===
=== basic configuration ===
Zeile 154: Zeile 154:
== Dokumentation ==
== Dokumentation ==
=== RFC ===
=== RFC ===
=== Man-Pages ===
=== Man-Page ===
=== Info-Pages ===
=== Info-Pages ===
== Siehe auch ==
== Siehe auch ==
Zeile 164: Zeile 164:
* [https://manpages.debian.org/man/systemd systemd].netdev - network device configuration (e.g. bridges, VLAN, tunnels, VPNs, etc)
* [https://manpages.debian.org/man/systemd systemd].netdev - network device configuration (e.g. bridges, VLAN, tunnels, VPNs, etc)
* [https://wiki.debian.org/CategoryNetwork CategoryNetwork]
* [https://wiki.debian.org/CategoryNetwork CategoryNetwork]
* [https://wiki.ubuntuusers.de/systemd/networkd-dispatcher/ systemd/networkd-dispatcher] - auf Zustandsänderungen bei den Netzwerkschnittstellen reagieren, um z.B. Programm zu starten
* [https://wiki.ubuntuusers.de/systemd/networkd-dispatcher/ systemd/networkd-dispatcher] - auf Zustandsänderungen bei den Netzwerkschnittstellen reagieren, um z. B. Programm zu starten
* [https://wiki.ubuntuusers.de/systemd/networkd/Anwendungsbeispiele/ systemd/networkd/Anwendungsbeispiele]
* [https://wiki.ubuntuusers.de/systemd/networkd/Anwendungsbeispiele/ systemd/networkd/Anwendungsbeispiele]
* [https://www.freedesktop.org/software/systemd/man/systemd-networkd.html Projekseite systemd-networkd]
* [https://www.freedesktop.org/software/systemd/man/systemd-networkd.html Projekseite systemd-networkd]
Zeile 170: Zeile 170:
* [https://de.wikipedia.org/wiki/OSI-Modell ISO/OSI-Referenzmodell Netzwerk (Netzwerk-Schichten)]
* [https://de.wikipedia.org/wiki/OSI-Modell ISO/OSI-Referenzmodell Netzwerk (Netzwerk-Schichten)]
* [https://standards.ieee.org/faqs/regauth.html#1 Erklärung EUI-48]
* [https://standards.ieee.org/faqs/regauth.html#1 Erklärung EUI-48]
=== Einzelnachweise ===
<references />
== Testfragen ==
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 1''
<div class="mw-collapsible-content">'''Antwort1'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 2''
<div class="mw-collapsible-content">'''Antwort2'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 3''
<div class="mw-collapsible-content">'''Antwort3'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 4''
<div class="mw-collapsible-content">'''Antwort4'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 5''
<div class="mw-collapsible-content">'''Antwort5'''</div>
</div>




Zeile 362: Zeile 337:
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| DHCP
|| DHCP
|| Mögliche Werte: <tt>yes</tt>, <tt>no</tt>, <tt>ipv4</tt>, <tt>ipv6</tt>. Vorgabe ist <tt>no</tt>, d.h. kein Start des DHCP-Client. Anderer Wert startet den DHCP-Client das angegebene IP-Protokoll bzw. bei <tt>yes</tt> für beide Protokolle. Der DHCPv6-Client kann aber auch unbeeinflusst von dieser Einstellung über empfangene Ankündigungen des Routers gestartet werden. Wenn man den DHCP-Client einschaltet, kann man in den Abschnitten <tt>[DHCPv4]</tt> bzw. <tt>[DHCPv6]</tt> dessen Verhalten konfigurieren.
|| Mögliche Werte: <tt>yes</tt>, <tt>no</tt>, <tt>ipv4</tt>, <tt>ipv6</tt>. Vorgabe ist <tt>no</tt>, d.h. kein Start des DHCP-Client. Anderer Wert startet den DHCP-Client das angegebene IP-Protokoll bzw.&nbsp;bei <tt>yes</tt> für beide Protokolle. Der DHCPv6-Client kann aber auch unbeeinflusst von dieser Einstellung über empfangene Ankündigungen des Routers gestartet werden. Wenn man den DHCP-Client einschaltet, kann man in den Abschnitten <tt>[DHCPv4]</tt> bzw.&nbsp;<tt>[DHCPv6]</tt> dessen Verhalten konfigurieren.
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| DHCPServer
|| DHCPServer
Zeile 389: Zeile 364:
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| Peer
|| Peer
|| IP-Adresse der Gegenstelle bei einer Punkt-zu-Punkt-Verbindung. Zur Definition einer Punkt-zu-Punkt-Verbindung sollte man hier und auch unter <tt>Address</tt> die Prefix-Länge <tt>32</tt> bei IPv4 bzw. <tt>128</tt> bei IPv6 verwenden. Bei mehrfacher Verwendung wird nur die letzte Angabe verwendet.
|| IP-Adresse der Gegenstelle bei einer Punkt-zu-Punkt-Verbindung. Zur Definition einer Punkt-zu-Punkt-Verbindung sollte man hier und auch unter <tt>Address</tt> die Prefix-Länge <tt>32</tt> bei IPv4 bzw.&nbsp;<tt>128</tt> bei IPv6 verwenden. Bei mehrfacher Verwendung wird nur die letzte Angabe verwendet.
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| [Route]
|| [Route]
Zeile 398: Zeile 373:
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| Destination
|| Destination
|| Der Zielbereich als Netzwerk-Prefix: Es muss eine IP-Adresse und optional deren Prefix-Länge angegeben werden, dabei können nur solche IP-Adressen verwendet werden, bei denen beim Host-Teil alle Bit 0 sind. Wenn keine Prefix-Länge angegeben wird, impliziert dies 32 bei IPv4 bzw. 128 bei IPv6 (Host-Route). Wenn diese Option fehlt, dann wird als Zielbereich <tt>0.0.0.0/0</tt> bzw. <tt>::/0</tt> verwendet.
|| Der Zielbereich als Netzwerk-Prefix: Es muss eine IP-Adresse und optional deren Prefix-Länge angegeben werden, dabei können nur solche IP-Adressen verwendet werden, bei denen beim Host-Teil alle Bit 0 sind. Wenn keine Prefix-Länge angegeben wird, impliziert dies 32 bei IPv4 bzw.&nbsp;128 bei IPv6 (Host-Route). Wenn diese Option fehlt, dann wird als Zielbereich <tt>0.0.0.0/0</tt> bzw.&nbsp;<tt>::/0</tt> verwendet.
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| Gateway
|| Gateway
Zeile 463: Zeile 438:
Wenn man das ausprobiert, wird es wahrscheinlich zunächst nicht funktionieren. Zu den Gründen und zur Abhilfe siehe [https://wiki.ubuntuusers.de/systemd/networkd/#Umbenennung-einer-Schnittstelle-funktioniert-nicht Problembehebung].
Wenn man das ausprobiert, wird es wahrscheinlich zunächst nicht funktionieren. Zu den Gründen und zur Abhilfe siehe [https://wiki.ubuntuusers.de/systemd/networkd/#Umbenennung-einer-Schnittstelle-funktioniert-nicht Problembehebung].


Die hier gezeigte Arbeitsweise ist potentiell unsicher, weil eine Klasse von Objekten auf ein einziges Element (den Namen) abgebildet wird. Solange es nur eine passende Schnittstelle gibt, ist das harmlos. Aber bei zwei und mehr passenden Objekten wird die Datei auch auf alle angewendet. Ab dem zweiten Umbenennungsversuch gibt es natürlich Fehlermeldungen und Fehlfunktionen. Sicherer ist in solchen Fällen eine Selektion z.B. über <tt>PermanentMACAddress</tt>.
Die hier gezeigte Arbeitsweise ist potentiell unsicher, weil eine Klasse von Objekten auf ein einziges Element (den Namen) abgebildet wird. Solange es nur eine passende Schnittstelle gibt, ist das harmlos. Aber bei zwei und mehr passenden Objekten wird die Datei auch auf alle angewandt. Ab dem zweiten Umbenennungsversuch gibt es natürlich Fehlermeldungen und Fehlfunktionen. Sicherer ist in solchen Fällen eine Selektion z.&nbsp;B.&nbsp;über <tt>PermanentMACAddress</tt>.


Hier wird auf Ungleichheit getestet, um USB/WLAN-Sticks, die leicht als zusätzliche zu den eingebauten Schnittstellen im System auftauchen könnten, von dieser Regel auszuschließen.
Hier wird auf Ungleichheit getestet, um USB/WLAN-Sticks, die leicht als zusätzliche zu den eingebauten Schnittstellen im System auftauchen könnten, von dieser Regel auszuschließen.
Zeile 485: Zeile 460:
  Unmanaged = yes
  Unmanaged = yes


Diese Technik ist auch sinnvoll für andere Schnittstellen, wenn diese nicht durch systemd-networkd konfiguriert werden sollen bzw. wenn ein Konfigurationsversuch ggf. nach langer Wartezeit ohnehin scheitern würde.
Diese Technik ist auch sinnvoll für andere Schnittstellen, wenn diese nicht durch systemd-networkd konfiguriert werden sollen bzw.&nbsp;wenn ein Konfigurationsversuch ggf. nach langer Wartezeit ohnehin scheitern würde.


==== Beispiel: DHCP oder statische Konfiguration ====
==== Beispiel: DHCP oder statische Konfiguration ====
Zeile 545: Zeile 520:
  DNS = 8.8.4.4
  DNS = 8.8.4.4


Beachte: systemd-networkd ignoriert die Angaben bei <tt>DNS=</tt>! Zur Konfiguration der DNS-Namensauflösung kann man z.B. [https://wiki.ubuntuusers.de/systemd/systemd-resolved/ systemd-resolved] starten, welches dann die hier gemachten Angaben für seine Konfiguration benutzt.
Beachte: systemd-networkd ignoriert die Angaben bei <tt>DNS=</tt>! Zur Konfiguration der DNS-Namensauflösung kann man z.&nbsp;B.&nbsp;[https://wiki.ubuntuusers.de/systemd/systemd-resolved/ systemd-resolved] starten, welches dann die hier gemachten Angaben für seine Konfiguration benutzt.


== Start und Stopp ==
== Start und Stopp ==
Zeile 562: Zeile 537:


== Dienstprogramm networkctl ==
== Dienstprogramm networkctl ==
Dieses Programm funktioniert eingeschränkt auch dann, wenn systemd-networkd nicht läuft bzw. die systemd-Unit '''systemd-networkd.service''' inaktiv ist und mit sehr eingeschränkter Funktionalität sogar dann, wenn systemd nicht installiert ist.
Dieses Programm funktioniert eingeschränkt auch dann, wenn systemd-networkd nicht läuft bzw.&nbsp;die systemd-Unit '''systemd-networkd.service''' inaktiv ist und mit sehr eingeschränkter Funktionalität sogar dann, wenn systemd nicht installiert ist.


=== Zustand ermitteln ===
=== Zustand ermitteln ===
Zeile 601: Zeile 576:


=== Schnittstelle aktualisieren ===
=== Schnittstelle aktualisieren ===
Bei Schnittstellen mit dynamischer IP-Konfiguration z.B. über DHCP kann man eine Aktualisierung auslösen:
Bei Schnittstellen mit dynamischer IP-Konfiguration z.&nbsp;B.&nbsp;über DHCP kann man eine Aktualisierung auslösen:
  # networkctl renew HUB
  # networkctl renew HUB


Zeile 610: Zeile 585:
  # networkctl reconfigure HUB
  # networkctl reconfigure HUB


Dies funktioniert bei systemd in der Version 237 gar nicht und in der Version 245 nicht immer wie erwartet, z.B. kann man über diese Methode nicht zuverlässig eine statisch zugewiesenen IP-Adresse ändern. Alternativ kann man die Software-Schnittstellen löschen und [https://wiki.ubuntuusers.de/systemd/networkd/#Start-und-Stopp systemd neu starten].
Dies funktioniert bei systemd in der Version 237 gar nicht und in der Version 245 nicht immer wie erwartet, z.&nbsp;B.&nbsp;kann man über diese Methode nicht zuverlässig eine statisch zugewiesenen IP-Adresse ändern. Alternativ kann man die Software-Schnittstellen löschen und [https://wiki.ubuntuusers.de/systemd/networkd/#Start-und-Stopp systemd neu starten].


=== Konfiguration erneut laden ===
=== Konfiguration erneut laden ===
Zeile 618: Zeile 593:
  * Für jede '''.netdev'''-Datei ohne dazu passende Schnittstellen wird eine Schnittstelle angelegt.
  * Für jede '''.netdev'''-Datei ohne dazu passende Schnittstellen wird eine Schnittstelle angelegt.
* '''.netdev'''-Dateien werden ignoriert, wenn es bereits eine passende Schnittstelle gibt.
* '''.netdev'''-Dateien werden ignoriert, wenn es bereits eine passende Schnittstelle gibt.
* '''.network'''-Dateien werden auf alle passenden Schnittstellen angewendet.
* '''.network'''-Dateien werden auf alle passenden Schnittstellen angewandt.


Dies funktioniert bei systemd in der Version 237 gar nicht und in der Version 245 nicht immer wie erwartet. Alternativ kann man die Software-Schnittstellen löschen und [https://wiki.ubuntuusers.de/systemd/networkd/#Start-und-Stopp systemd neu starten].
Dies funktioniert bei systemd in der Version 237 gar nicht und in der Version 245 nicht immer wie erwartet. Alternativ kann man die Software-Schnittstellen löschen und [https://wiki.ubuntuusers.de/systemd/networkd/#Start-und-Stopp systemd neu starten].
Zeile 627: Zeile 602:
  systemd --version
  systemd --version


Vor Version 245 können diese Befehle bzw. Schlüsselworte (sowie weitere, hier nicht behandelte Eigenschaften) nicht verwendet werden:* '''.link'''-Dateien: <tt>Property</tt>, <tt>NamePolicy=keep</tt>
Vor Version 245 können diese Befehle bzw.&nbsp;Schlüsselworte (sowie weitere, hier nicht behandelte Eigenschaften) nicht verwendet werden:* '''.link'''-Dateien: <tt>Property</tt>, <tt>NamePolicy=keep</tt>
* '''.link'''- und '''.network'''-Dateien: Werte für <tt>Type</tt> im Abschnitt <tt>[Match]</tt> inkompatibel bei Versionen 237/245
* '''.link'''- und '''.network'''-Dateien: Werte für <tt>Type</tt> im Abschnitt <tt>[Match]</tt> inkompatibel bei Versionen 237/245
* '''network'''-Dateien: <tt>WLANInterfaceType</tt>, für <tt>Type</tt> im Abschnitt <tt>[Route]</tt> sind nur zulässig: <tt>unicast</tt>, <tt>blackhole</tt>, <tt>unreachable</tt>, <tt>prohibit</tt>
* '''network'''-Dateien: <tt>WLANInterfaceType</tt>, für <tt>Type</tt> im Abschnitt <tt>[Route]</tt> sind nur zulässig: <tt>unicast</tt>, <tt>blackhole</tt>, <tt>unreachable</tt>, <tt>prohibit</tt>
Zeile 660: Zeile 635:


= Setting up Systemd-Networkd =
= Setting up Systemd-Networkd =
[[Kategorie:Linux:Netzwerk]]
[[Kategorie:Linux/Netzwerk]]

Aktuelle Version vom 12. November 2024, 19:42 Uhr

topic - Kurzbeschreibung

Beschreibung

Der Netzwerk-DAEMON systemd-networkd gehört zur systemd-Familie und konfiguriert Netzwerkschnittstellen auf den Ebenen 2 und 3 des ISO/OSI-Referenzmodells. Mit diesem Programm kann man auch auf realen Schnittstellen aufbauende virtuelle Schnittstellen wie z. B. Brücken, Tunnel, VPN erstellen und diese konfigurieren. Das Programm kümmert sich aber nicht um Ebene 2 bei WLAN-Schnittstellen.

Bei Ubuntu-Server-Installationen wird systemd-networkd als systemd-Unit gestartet und als einziges Programm für die Konfiguration des Netzwerks verwendet. (Siehe jedoch Netplan.)

Bei Ubuntu-Desktop-Installationen wird systemd-networkd lediglich installiert, aber nicht gestartet. Beim Start kann es wechselweise zu Störungen mit NetworkManager kommen, welcher bei Desktops normalerweise zur ausschließlichen Konfiguration des Netzwerks verwendet wird.

Zu systemd-networkd gehört das Dienstprogramm networkctl zur Kontrolle und Steuerung des DAEMONs.

Bei systemd-networkd erfolgt die Konfiguration ausschließlich über Deklarationen. Man kann aber mit dem Zusatzprogramm systemd/networkd-dispatcher auch Progamme starten.

Installation

systemd-networkd ist auf allen aktuellen Ubuntu-Installationen als fester Bestandteil von systemd bereits vorinstalliert.

Anwendungen

Problembehebung

Aufruf

Optionen

Parameter

Umgebung

Rückgabewert

Konfiguration

basic configuration

NOTE: If you are doing this remotely, please ensure that you can get to the physical machine in order to fix things should something go wrong. You can't work remotely on a machine whose networking isn't.

If you currently have a network running using /etc/network/, move the interfaces file there to another name so that it won't be used after systemd-networkd is set up:

mv /etc/network/interfaces /etc/network/interfaces.save

Next enable systemd-networkd. You don't need to start the service yet because your old network is still running and there is currently no systemd-networkd defined.

systemctl enable systemd-networkd

All configuration files are generally stored in /etc/systemd/network. Note that in the configuration files, case is important. Match is not the same as match.

Next you need to define a network. In the simplest case, this is just a single file in /etc/systemd/network. Let's use lan0.network and put in the following information:

[Match]
Name=eth0

[Network]
DHCP=ipv4

This tells systemd-networkd to use eth0 (which was set up by udev) and assign it an address using DHCP.

For a static IP, lan0.network could be:

[Match]
Name=enp8s0

[Network]
Address=192.168.1.20/24
Gateway=192.168.1.1
DNS=192.168.1.1

I recommend a reboot at this point to remove the currently running network and to ensure that your network comes up properly.

This is all it takes for a simple case.

beyond the basics

setting up a bond between 2 network interfaces

This is covered in https://wiki.debian.org/Bonding#Using_systemd-networkd

setting up a network bridge

If you are running virtual machines, you probably have set up a bridge in your interfaces file. Since that is no longer used, you need to set up a bridge using systemd-networkd. Fortunately this is very easy.

First you need to define the virtual network device using a .netdev file (in /etc/systemd/network of course). Let's call this br0.netdev. It should look like:

[NetDev]
Name=br0
Kind=bridge

Hint: in Debian Buster (probably also previous versions) systemd-networkd may assign a different MAC-Address to the bridge than your physical interface has. This may cause connection issues if your service provider uses some kind of MAC-filtering when routing your traffic. To circumvent such problems you may assign a MAC-address to your bridge (probably the same as your physical device, replace the 'xx' with valid MAC):

[NetDev]
Name=br0
Kind=bridge
MACAddress=xx:xx:xx:xx:xx:xx

Then you link it to the real network device using br0.network:

[Match]
Name=eth0
[Network]
Bridge=br0

Finally modify lan0.network to refer to br0 instead of eth0:

[Match]
Name=br0
[Network]
DHCP=ipv4

Restart systemd-networkd and your bridge should be up.

systemctl restart systemd-networkd

bridging over a bond

bridging over a bond is simply a matter of referring the bond device in your br0.network file instead of referring to a physical device. From the above bridge example, change br0.network to read:

[Match]
Name=bond0
[Network]
Bridge=br0

assuming your bond virtual device is called bond0.

Configuring the physical layer

In general you don't need a .link file since udev already identifies the device. However you can configure multiple options here that can't be set elsewhere. The most basic of these is the name.

uDev these days does a good job of consistently handling the naming of network devices. Unless you have legacy names like eth0 (which are now set up using uDev naming rules to override the way uDev would normally handle it), wired interfaces are usually something like "enp5s0". This is derived from its PCI address.

Issuing lspci will show you the addresses of all the PCI devices on your system. You should see a line describing your network interface like

05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

where the 05 part becomes the 5 in enp5s0 and the 00.0 part becomes the 0.

enp5s0 isn't very descriptive if you've got multiple NICs in your system, such as if you were bonding the NICs together for greater bandwidth on a server. To give the interface a more descriptive name. Simply create a .network file (say onboardnic.network) as

[Match]
Path=pci-0000:05:00.0

[Network]
Bond=bond0

and refer to onboardnic instead of enp5s0 in your bond0.network file.

You can also create a .link file to give it a more descriptive name.

manpage: https://manpages.debian.org/stretch/udev/systemd.link.5.en.html

Link level configuration files need to end in .link

So in order to configure the onboardnic you can create the file /etc/systemd/network/onboardnic.link such as:

[Match]
OriginalName=enp5s0

or more directly

[Match]
Path=pci-0000:05:00.0

Unfortunately outside of your systemd-networkd configuration, tools use the name given by udev.

Dateien

Sicherheit

Dokumentation

RFC

Man-Page

Info-Pages

Siehe auch

Links

Projekt

Weblinks


ubuntuusers

Konfiguration

Programm-Einstellungen

Die Hauptkonfigurationsdatei /etc/systemd/networkd.conf dokumentiert primär die bei der Übersetzung des Programms definierte Voreinstellung. Man darf diese Datei abändern; dabei sollte man die Kommentare füt die Voreinstellungen erhalten, weil man sonst keine Dokumentation über die Voreinstellung mehr hat. Alternativ kann man die hier folgend beschriebenen weiteren Konfigurationsdateien verwenden.

Nach der Hauptkonfigurationsdatei werden noch alle auf .conf endenden Dateien in diesen Verzeichnissen (sofern existierend) berücksichtigt:

  • /usr/lib/systemd/networkd.conf.d/
  • /usr/local/lib/systemd/networkd.conf.d/
  • /etc/systemd/networkd.conf.d/

Dateien in später genannten Verzeichnissen maskieren gleichnamige Dateien in früher genannten Verzeichnissen und die Dateien werden in lexikographischer Reihenfolge bearbeitet.

Eine gute Praxis besteht im Kopieren der Datei /etc/systemd/networkd.conf in das Verzeichnis /etc/systemd/networkd.conf.d/ (welches man möglicherweise erst anlegen muss) und Bearbeitung der Kopie. Die Einstellmöglichkeiten sind in der Datei aufgelistet und werden ausführlich in der Manpage erklärt:

man networkd.conf

Schnittstellen-Einstellungen

Für die Konfiguration von Netzwerkschnittstellen werden Dateien in folgenden Verzeichnissen berücksichtigt:* /usr/lib/systemd/network/

  • /usr/local/lib/systemd/network/
  • /run/systemd/network/
  • /etc/systemd/network/

Dateien in später genannten Verzeichnissen maskieren gleichnamige Dateien in früher genannten Verzeichnissen und die Dateien werden in lexikographischer Reihenfolge bearbeitet.

In den genannten Verzeichnissen finden sich drei anhand ihrer Endung zu unterscheidenden Arten von Konfigurationsdateien:* .netdev zum erstellen virtueller Netzwerk-Schnittstellen

  • .link konfigurieren Schnittstellen auf Layer 2. Dies wird tatsächlich von udev erledigt.
  • .network konfigurieren Schnittstellen auf Layer 3.

Alle Dateien obliegen der Syntax in Konfigurationsdateien von systemd. Diese ähnelt dem Ini-Format.

man systemd.syntax

Bei den Schlüsselworten für die Abschnittsnamen und die Einstellungsoptionen sind große und kleine Buchstaben bedeutsam. Die möglichen Optionen und deren richtige Schreibweise können den Manpages entnommen werden:

man systemd.netdev
man systemd.link
man systemd.network

Beachte: In den Manpages werden Abschnittsnamen in Versalien geschrieben, wenn sie als Überschrift verwendet werden. In den Konfigurationsdateien ist aber durchweg der Abschnittsname in vorgeschriebener Verwendung von Groß-/Kleinbuchstaben zu schreiben.

Die nachfolgenden Tabellen listen auszugsweise die Schlüsselworte, soweit sie für das Verständnis der Beispiele in diesem Artikel erforderlich sind. Kursiv dargestellte Schlüsselworte sind Pflichtangaben.

Optionen für .netdev-Dateien
Schlüsselwort Beschreibung
[Match] Abschnitt optional
Host Hostname oder Maschinen-Kennung (engl: machine-id) des Rechners. Effektiv wird die Zeichenfolge mit /etc/hostname und /etc/machine-id verglichen. Die machine-id kann aber auch beim Hochlauf temporär als Kernel Parameter gesetzt werden.
Virtualization Prüft ob und ggf. wie das System virtualisiert ist. Mögliche Werte: no, yes, vm, container, qemu, kvm, zvm, vmware, microsoft, oracle, xen, bochs, uml, openvz, lxc, lxc-libvirt, systemd-nspawn, docker, rkt und ggf. weitere. Effektiv wird gegen die Ausgabe von systemd-detect-virt verglichen.
KernelCommandLine Option auf der Kernel-Kommandozeile. Vergleicht effektiv, ob /proc/cmdline die Angabe enthält.
KernelVersion Kernel Version. Vergleicht effektiv mit uname -r, dabei sind auch Vergleiche auf größer-/kleiner-als usw. möglich.
Architecture Prüfe auf bestimmte Architektur. Beispiele: x86, x86-64, ppc, ppc-le, ppc64, ppc64-le, ia64, parisc, parisc64, s390, s390x, sparc, sparc64, mips, mips-le, mips64, mips64-le, alpha, arm, arm-be, arm64, arm64-be, sh, sh64, m86k, tilegx, cris. Vergleicht effektiv mit uname -m.
[NetDev] Abschnitt obligatorisch
Name Name der Schnittstelle. Pflichtangabe. Maximal 15 dieser zulässigen Zeichen: a-z, A-Z, 0-9 und Sonderzeichen: _ = + . -
Kind Typ der Schnittstelle. Pflichtangabe. Beispiele: dummy, bridge, tun, wireguard und viele weitere, siehe Manpage.
Optionen für .link-Dateien
Schlüsselwort Beschreibung
[Match] Abschnitt optional, aber Verwendung dringend empfohlen.
Beachte: Die unter .netdev angegebenen Prüfungen sind auch hier möglich.
Path Eine mit Leerzeichen getrennte Liste mit Werten für die udev-Eigenschaft ID_PATH. Es wird geprüft, ob der tatsächliche Wert einem dar angegebenen Werten entspricht.
Driver Eine mit Leerzeichen getrennte Liste mit Werten für die udev-Eigenschaft ID_NET_DRIVER. Es wird geprüft, ob der tatsächliche Wert einem dar angegebenen Werten entspricht.
Type Eine mit Leerzeichen getrennte Liste mit Werten für den von networkctl angezeigten Schnittstellentyp. (Achtung: Bei Version 237 sind nur die Werte der udev-Eigenschaft DEVTYPE zulässig!) Es wird geprüft, ob der tatsächliche Wert einem dar angegebenen Werten entspricht.
Property Eine mit Leerzeichen getrennte Liste mit udev-Eigenschaft=Wert Angaben. Es wird geprüft, ob für jede angegebene Eigenschaft tatsächlich der Wert dem hier angegebenen entspricht.
MacAddress Eine mit Leerzeichen getrennte Liste mit MAC-Adressen. Diese Option darf mehrfach angegeben werden; die Listen werden vereinigt. Es wird geprüft, ob die momentan eingestellte Unicast-MAC-Adresse in der Gesamtliste vorkommt.
PermanentMACAddress Eine mit Leerzeichen getrennte Liste mit permanenten EUI-48. Diese Option darf mehrfach angegeben werden; die Listen werden vereinigt. Es wird geprüft, ob der Identifizierer der Hardware in der Gesamtliste vorkommt.
[Link] Abschnitt obligatorisch
NamePolicy Eine Liste mit Bezeichnern für die zur Benennung dieser Schnittstelle auszuprobierenden Methoden. Bekannte Methoden: kernel, database, onboard, slot, path, mac, keep
Name Ein Name für die Schnittstelle. Dieser wird verwendet, wenn keine der angegebenen Methoden zu Benennung erfolgreich war. Maximal 15 dieser zulässigen Zeichen: a-z, A-Z, 0-9, und Sonderzeichen: _ = + . -
MACAddress Eine Unicast-MAC-Adresse, welche der Hardware zugewiesen wird.
MTUBytes Die maximale Paketlänge in Bytes wird für Netzwerkebene 2 auf den hier abgegebenen Wert gesetzt Die üblichen Suffixe wie K, M, G dürfen verwendet werden und; sie werden zur Basis 1024 interpretiert.
Optionen für .network-Dateien
Eintrag Beschreibung
[Match] Abschnitt optional, aber Verwendung dringend empfohlen.
Beachte: Alle unter .link angegebenen Prüfungen sind auch hier möglich.
Name Eine mit Leerzeichen getrennte Liste mit Mustern (Shell-Globs) für die Werte der udev-Eigenschaft INTERFACE. Es wird geprüft, ob der tatsächliche Wert einem der Muster entspricht.
WLANInterfaceType Eine mit Leerzeichen getrennte Liste von Betriebsarten der WLAN-Schnittstelle. Beispiele: ad-hoc, station, ap. Weitere siehe Manpage. Es wird geprüft, ob die Betriebsart der Schnittstelle mit einem Listeneintrag übereinstimmt.
[Link] Abschnitt optional
MACAddress Eine Unicast-MAC-Adresse, welche der Hardware zugewiesen wird.
MTUBytes Die maximale Paketlänge in Bytes wird auf den hier angegebenen Wert gesetzt Die üblichen Suffixe wie K, M, G dürfen verwendet werden; sie werden zur Basis 1024 interpretiert.
Unmanaged Vorgabe ist no. Kann auf den Wert yes gesetzt werden, dann wird der Schnittstelle keine .network-Datei zugewiesen, weil die Suche nach passenden Dateien an dieser Stelle beendet wird.
[Network] Abschnitt obligatorisch
Description Beschreibung der Schnittstelle. Dies dient nur der Darstellung.
DHCP Mögliche Werte: yes, no, ipv4, ipv6. Vorgabe ist no, d.h. kein Start des DHCP-Client. Anderer Wert startet den DHCP-Client das angegebene IP-Protokoll bzw. bei yes für beide Protokolle. Der DHCPv6-Client kann aber auch unbeeinflusst von dieser Einstellung über empfangene Ankündigungen des Routers gestartet werden. Wenn man den DHCP-Client einschaltet, kann man in den Abschnitten [DHCPv4] bzw. [DHCPv6] dessen Verhalten konfigurieren.
DHCPServer Standardwert no. Kann auf yes gesetzt werden und startet dann einen DHCPv4-Server. Dieser wird im Abschnitt [DHCPServer] konfiguriert.
Address Kurzform für einen Abschnitt [Address] zur Definition einer IP-Adresse und deren Prefix-Länge für ein Broadcast.Netzwerk. Kann verwendet werden, wenn man in einem Abschnitt [Address] nur den Schlüssel Address benötigt. Mehrfache Verwendung dieser Option ist möglich.
Gateway Kurzform für einen Abschnitt [Route]. Kann verwendet werden, wenn man in einem solchen Abschnitt nur den Schlüssel Gateway benötigt. Erzeugt eine default-Route zur angegebenen IP-Adresse. Mehrfache Verwendung dieser Option ist möglich, aber sinnlos.
DNS Einstellung für systemd-resolved; systemd-networkd ignoriert diesen Schlüssel. IP-Adresse eines DNS-Servers, der für die über diese Schnittstelle erreichbaren Rechner einer DNS-Domain die Namensauflösung erbringt. Mehrfache Verwendung dieser Option ist möglich.
Domains Einstellung für systemd-resolved; systemd-networkd ignoriert diesen Schlüssel. Eine mit Leerzeichen getrennte Liste von DNS-Domänen, für welche der/die DNS-Server an dieser Schnittstellen zuständig sind.
[Address] Dieser Abschnitt ist mehrfach zulässig.
Address Angabe einer IP-Adresse, optional mit deren Prefix-Länge. Zulässig sind für IPv4 beispielsweise 192.0.2.42/28 und 10.0.34.56/255.255.128.0 in diesen Schreibweisen. Es müssen stets alle 4 Bytes angegeben werden, auch wenn diese den Wert 0 haben. Für IPv6 sind nur die vollständige Angabe oder die Schreibweise wie im Beispiel fd00::1/64 zulässig. Pflichtangabe in diesem Abschnitt und nur genau einmal möglich. Es wird die Adresse zugewiesen und für die Schnittstelle (automatisch, aber abschaltbar) eine Route zum Netzwerk eingerichtet.
Broadcast Nur sinnvoll, wenn unter Address in diesem Abschnitt eine IPv4-Adresse angegeben wurde und man nicht die sich aus dieser Angabe ergebene Broadcast-Adresse, sondern diese IP-Adresse verwenden will.
Peer IP-Adresse der Gegenstelle bei einer Punkt-zu-Punkt-Verbindung. Zur Definition einer Punkt-zu-Punkt-Verbindung sollte man hier und auch unter Address die Prefix-Länge 32 bei IPv4 bzw. 128 bei IPv6 verwenden. Bei mehrfacher Verwendung wird nur die letzte Angabe verwendet.
[Route] Dieser Abschnitt ist mehrfach zulässig.
Type Der Typ der Route. Vorgabe ist unicast, mögliche Werte sind die üblichen Typen von Routen wie beispielsweise blackhole.
Destination Der Zielbereich als Netzwerk-Prefix: Es muss eine IP-Adresse und optional deren Prefix-Länge angegeben werden, dabei können nur solche IP-Adressen verwendet werden, bei denen beim Host-Teil alle Bit 0 sind. Wenn keine Prefix-Länge angegeben wird, impliziert dies 32 bei IPv4 bzw. 128 bei IPv6 (Host-Route). Wenn diese Option fehlt, dann wird als Zielbereich 0.0.0.0/0 bzw. ::/0 verwendet.
Gateway Eine IP-Adresse. IP-Pakete mit Zieladressen im Zielbereich dieser Route werden an diese Adresse geschickt.
Metric Ganze Zahl ohne Vorzeichen. Praktisch nur bedeutsam, wenn es zu einem Zeitpunkt mehrere Routen mit gleichem Ziel hinsichtlich Adresse und Prefix-Länge gibt. Diese müssen sich dann in dieser Angabe unterscheiden. Der Konflikt wird gelöst durch Auswahl der Route mit der kleinsten Metric.

.netdev-Dateien: Schnittstelle anlegen

Dateien mit der Endung auf .netdev werden bei jedem Start von systemd-networkd ausgewertet. Wenn es eine Datei mit Endung auf .netdev ohne eine dazu passende Schnittstelle gibt, wird die beschriebene Schnittstelle angelegt und konfiguriert.

Beispiel: Netzwerkbrücke

Eine Netzwerkbrücke ist eine Realisierung eines Hub/Switch in Software und verbindet mehrere Netzwerkschnittstellen auf Ebene 2. Dies kann als einfache Methode für eine Internetverbindungsfreigabe verwendet werden.

# /etc/systemd/network/20-bridge.netdev
[NetDev]
Kind = bridge
Name = HUB

[Bridge]
STP = yes
HelloTimeSec = 1
MaxAgeSec = 4
ForwardDelaySec = 4

Der gesamte Abschnitt [Bridge] ist hier optional. Abhängig vom Typ (Kind=) der Schnittstelle sind weitere Abschnitte zur Ausgestaltung der Schnittstelle zulässig. Dies wird hier benutzt, um das Spanning Tree Protokoll einzuschalten und zu parametrieren. Details siehe Artikel Netzwerkbrücke.

Die Schnittstellen, welche diesem HUB als Ports zugeordnet werden sollen, müssen in ihrer .network-Datei eine entsprechende Zuweisung erhalten:

# /etc/systemd/network/80-HUB-port.network
[Match]
Type =! wlan
Name =! HUB

[Network]
Description = Interface als Bridge-Port von HUB verwenden.
Bridge = HUB
LinkLocalAddressing = no

Wie im Beispiel gezeigt, kann man mit =! auch auf Ungleichheit testen. Dies wird hier benutzt, damit die Brücke nicht sich selbst als Port hinzugefügt wird.

Die Angabe "LinkLocalAddressing=no" ist hier optional. Sie verhindert, dass per Voreinstellung für jeden Port eine eigene IPv6-Link-Adresse vergeben wird. Bei Ubuntu 18.04 mit systemd-Version 237 hat dies den schönen Nebeneffekt, dass die voll funktionsfähige Schnittstelle nicht von networkctl als "degraded" angezeigt wird, weil nur Link-Local-Adressen vorhanden sind.

systemd-networkd löscht niemals eine Schnittstelle. Selbst wenn man die .netdev-Datei löscht, welche zu ihrer Erzeugung gedient hat, interessiert dies systemd-networkd nicht. Eine Schnittstelle, welche nicht zu realer Hardware gehört, kann man aber mit dem Dienstprogramm networkctl vernichten.

.link-Dateien

Die Dateien mit Endung auf .link dienen zu Konfiguration vorhandener (Hardware- und Software-) Schnittstelle auf Netzwerkebene 2, soweit es sich um statische Konfigurationselemente handelt. (Variable Einstellungen auf Ebene 2 können dagegen in .network-Dateien erfolgen.) Diese Dateien werden von dem in udev fest eingebauten Modul net_setup_link bearbeitet. Damit sind .link-Dateien verkappte udev-Regeln, die grundsätzlich auch in der herkömmlichen udev-Syntax formuliert werden könnten und früher war das auch der Fall. (Hierfür wurde z.B /etc/udev/rules.d/70-persistent-net.rules verwendet.)

Für jede vorhandene Schnittstelle werden nacheinander die .link-Dateien geprüft, ob alle genannten Selektionskriterien gemeinsam zutreffen. Die erste passende Datei wird der Schnittstelle zugewiesen, und die in der Datei aufgeführten Konfigurationsaufgaben werden durchgeführt. Selbst wenn dabei ein Fehler auftritt, wird keine weitere Datei beachtet.

Beispiel: Schnittstelle umbenennen

# /etc/systemd/network/10-rename-to-radio.link</ 
[Match]
Type = wlan wifi
Path =! pci*usb*

[Link]
Description = Radio-LAN
NamePolicy =
Name = radio

Wenn man das ausprobiert, wird es wahrscheinlich zunächst nicht funktionieren. Zu den Gründen und zur Abhilfe siehe Problembehebung.

Die hier gezeigte Arbeitsweise ist potentiell unsicher, weil eine Klasse von Objekten auf ein einziges Element (den Namen) abgebildet wird. Solange es nur eine passende Schnittstelle gibt, ist das harmlos. Aber bei zwei und mehr passenden Objekten wird die Datei auch auf alle angewandt. Ab dem zweiten Umbenennungsversuch gibt es natürlich Fehlermeldungen und Fehlfunktionen. Sicherer ist in solchen Fällen eine Selektion z. B. über PermanentMACAddress.

Hier wird auf Ungleichheit getestet, um USB/WLAN-Sticks, die leicht als zusätzliche zu den eingebauten Schnittstellen im System auftauchen könnten, von dieser Regel auszuschließen.

Beispiel: WLAN

WLAN-Schnittstellen werden auf Ebene 2 nicht von systemd-networkd verwaltet. Man muss die Betriebsbereitstellung der Schnittstelle mit anderen Mitteln erledigen, siehe: WLAN mit systemd-networkd.

Eine WLAN-Schnittstelle, welche über das externe WLAN-Einrichtungsprogramm bereits auf Ebene 2 als Bridge-Port einer Netzwerkbrücke zugeordnet wurde, bedarf gar keiner weiteren Konfiguration per systemd-networkd.

Die Konfiguration einer betriebsbereiten WLAN-Schnittstelle auf Ebene 3 erfolgt dagegen genauso wie bei jeder anderen Schnittstelle.

.network-Dateien

Beispiel: Schnittstelle ignorieren

Die System-Schnittstelle lo kann genau wie jede andere Schnittstelle durch Zuweisung einer .network-Datei konfiguriert werden. Dies ist normalerweise gar nicht erforderlich. Zur Vermeidung von Fehlfunktionen durch irrtümliche Zuweisung einer unpassenden .network-Datei kann man beispielsweise diese Datei verwenden:

# /etc/systemd/network/00-lo-unmanaged.network</ 
[Match]
Name = lo

[Link]
Unmanaged = yes

Diese Technik ist auch sinnvoll für andere Schnittstellen, wenn diese nicht durch systemd-networkd konfiguriert werden sollen bzw. wenn ein Konfigurationsversuch ggf. nach langer Wartezeit ohnehin scheitern würde.

Beispiel: DHCP oder statische Konfiguration

Mit diesem Satz von .network-Dateien kann man beim Hochlauf des Systems über eine Option auf der Kommandozeile des Kernels den DHCP-Client steuern:

# /etc/systemd/network/60-dhcp-all-hardware.network</ 
# Alle Hardware-Schnittstellen per DHCP konfigurieren.</ 
# Voreinstellung. Wird benutzt, wenn "noDHCP" nicht angegeben wird.</ 
[Match]
KernelCommandLine =! noDHCP
Path = pci*

[Network]
DHCP = ipv4

Zur Selektion der Hardware-Schnittstellen wird Path benutzt. Auch USB-Geräte schließt "pci*" mit ein, weil sie in der Regel über eine PCI/USB-Bridge in das System integriert sind. Bei exotischer Hardware kann es ggf. anders sein.

# /etc/systemd/network/60-dhcp-wlan-only.network</ 
# Alle WLAN-Schnittstellen (aber nur solche) per DHCP konfigurieren.</ 
[Match]
KernelCommandLine =! noDHCP=*wlan*
Path = pci*
Type = wlan

[Network]
DHCP = ipv4

Wenn man auf der Kernel-Kommandozeile "noDHCP=wlan" angibt, passt diese Datei nicht. Aber vielleicht die nächste:

# /etc/systemd/network/60-dhcp-ethernet-only.network</ 
# Alle Ethernet-Hardware-Schnittstellen (aber nur solche) per DHCP konfigurieren.</ 
[Match]
KernelCommandLine =! noDHCP=*ether*
Path = pci*
Type = ether
#Type =! wlan

[Network]
DHCP = ipv4

Diese Datei setzt voraus, dass Type=ether funktioniert, was bei Ubuntu 18.04 mit systemd-Version 237 nicht der Fall ist. Alternativ kann man voraussetzen, dass es nur die beiden Typen Ethernet und WLAN gibt, und dann Type=!wlan verwenden.

Wenn man auf der Kernel-Kommandozeile "noDHCP=ether" angibt, passt diese Datei nicht. Aber vielleicht die nächste:

# /etc/systemd/network/60-uplink-static.network</ 
# Nur die Hardware-Schnittstelle mit dem Namen "uplink" statisch konfigurieren.</ 
[Match]
KernelCommandLine = noDHCP=*
Path = pci*
Name = uplink

[Network]
DHCP = no
Address = 192.168.1.20/24
Gateway = 192.168.1.1
DNS = 8.8.8.8
DNS = 8.8.4.4

Beachte: systemd-networkd ignoriert die Angaben bei DNS=! Zur Konfiguration der DNS-Namensauflösung kann man z. B. systemd-resolved starten, welches dann die hier gemachten Angaben für seine Konfiguration benutzt.

Start und Stopp

systemd-networkd kann nötigenfalls über diese Befehle verwaltet werden:

systemctl restart systemd-networkd.service
systemctl enable systemd-networkd.service
systemctl status systemd-networkd.service
systemctl stop systemd-networkd.service
systemctl disable systemd-networkd.service

systemd-networkd macht nichts, wenn … * … es schon läuft und per start gestartet wird. Wenn Änderungen übernommen werden sollen, muss man es stoppen und neu starten, der Befehl restart von systemctl macht genau dieses.

  • … es läuft und man die Konfiguration ändert.
  • … es gestoppt wird.
  • … es beim erneuten Start bereits konfigurierte Schnittstellen findet. Lediglich neue Schnittstellen werden bearbeitet.

Dienstprogramm networkctl

Dieses Programm funktioniert eingeschränkt auch dann, wenn systemd-networkd nicht läuft bzw. die systemd-Unit systemd-networkd.service inaktiv ist und mit sehr eingeschränkter Funktionalität sogar dann, wenn systemd nicht installiert ist.

Zustand ermitteln

Liste der im System vorhandenen Schnittstellen

Der Befehlsteil list ist optional:

# networkctl list
IDX LINK  TYPE     OPERATIONAL SETUP 
  1 lo    loopback carrier     unmanaged
  2 cable ether    no-carrier  unmanaged
  3 radio wlan     routable    unmanaged
  6 HUB   bridge   no-carrier  configuring

networkctl zeigt hier auch Schnittstellen an, welche gar nicht von systemd-networkd betreut werden. Die Angabe unmanaged ist zu lesen als: „Nicht von systemd-networkd verwaltet, aber möglicherweise von einem anderen Programm“.

Kurze Übersicht der aktiven IP-Konfiguration des Systems:

networkctl status

Zusätzlich wird auch ein Auszug der relevanten Meldungen aus dem Systemlog angezeigt.

Ausführliche Übersicht der IP-Konfiguration einer Schnittstelle

Schnittstelle hier beispielhaft: lo

networkctl status lo

Hier wird auch angezeigt, welche .link- und .network-Datei tatsächlich zur Konfiguration der Schnittstelle verwendet wurde.

Ausführiche Übersicht der aktiven IP-Konfiguration des Systems

networkctl status --all

Schnittstelle löschen

Es können natürlich nur Software-Schnittstellen (hier als schlechtes Beispiel: lo) entfernt werden:

# networkctl delete lo    # <- Ersetze "lo" durch anderen Namen! </ 

Dies funktioniert bei systemd in der Version 237 gar nicht.

Der vorstehende Befehl macht das, was man über diesen Befehl auch machen könnte:

# ip link del lo    # <- Ersetze "lo" durch anderen Namen! </ 

Schnittstelle aktualisieren

Bei Schnittstellen mit dynamischer IP-Konfiguration z. B. über DHCP kann man eine Aktualisierung auslösen:

# networkctl renew HUB

Dies funktioniert bei systemd in der Version 237 gar nicht.

Schnittstelle ändern

Nach Änderung einer .network-Datei werden die Änderungen nicht automatisch übernommen. Man kann das für eine Schnittstelle (hier beispielhaft: HUB) mit diesem Befehl anstoßen:

# networkctl reconfigure HUB

Dies funktioniert bei systemd in der Version 237 gar nicht und in der Version 245 nicht immer wie erwartet, z. B. kann man über diese Methode nicht zuverlässig eine statisch zugewiesenen IP-Adresse ändern. Alternativ kann man die Software-Schnittstellen löschen und systemd neu starten.

Konfiguration erneut laden

Die erneute Auswertung aller (vielleicht geänderter) .netdev- und .network-Dateien kann man mit diesem Befehl erzwingen:

# networkctl reload  
* Für jede .netdev-Datei ohne dazu passende Schnittstellen wird eine Schnittstelle angelegt.
  • .netdev-Dateien werden ignoriert, wenn es bereits eine passende Schnittstelle gibt.
  • .network-Dateien werden auf alle passenden Schnittstellen angewandt.

Dies funktioniert bei systemd in der Version 237 gar nicht und in der Version 245 nicht immer wie erwartet. Alternativ kann man die Software-Schnittstellen löschen und systemd neu starten.

Problembehebung

Es funktioniert nicht!

Man überprüfe, ob die eingesetzte Version von systemd bereits die in diesem Artikel beschriebenen Eigenschaften besitzt. Die Version von systemd zeigt dieser Befehl:

systemd --version

Vor Version 245 können diese Befehle bzw. Schlüsselworte (sowie weitere, hier nicht behandelte Eigenschaften) nicht verwendet werden:* .link-Dateien: Property, NamePolicy=keep

  • .link- und .network-Dateien: Werte für Type im Abschnitt [Match] inkompatibel bei Versionen 237/245
  • network-Dateien: WLANInterfaceType, für Type im Abschnitt [Route] sind nur zulässig: unicast, blackhole, unreachable, prohibit
  • networkctl: delete, renew, reconfigure, reload

Es funktioniert immer noch nicht!

Diese Checkliste abarbeiten:# Wurde systemd-networkd überhaupt gestartet?

  1. Welche Meldungen von systemd-networkd stehen im Systemlog?
    journalctl -b -u systemd-networkd.service
  2. Welche Konfigurationsdateien wurden den Schnittstellen tatsächlich zugewiesen? Wenn hier nicht die erwarteten Dateien angezeigt werden, sind die Selektionskriterien unzureichend oder falsch oder es gibt syntaktische Fehler in den Dateien.
  3. Gibt es Kompetenzstreitigkeiten mit anderen Programmen zur Netzwerk-Konfiguration?
  4. systemd-networkd ist verwirrt und will neu gestartet werden!

Umbenennung einer Schnittstelle funktioniert nicht

udev hat eine eingebaute Restriktion: Schnittstellen werden nur einmal umbenannt! Diese einzige Chance wird bereits beim Hochlauf verbraucht.

Man muss also die geänderten Namensregeln bei bereits installierten Kerneln in deren initrd.img hinterlegen:

# update-initramfs -u

Bei der Installation neuer Kernel wird das automatisch mit erledigt.

Bei Ubuntu 18.04 mit systemd-Version 237 ist diese Restriktion fest in das Programm eingebaut und daher nicht abschaltbar.

Ab Ubuntu 20.04 mit systemd-Version 245 ist die Restriktion über die Einstellung "NamePolicy=keep"in der Datei /lib/systemd/network/99-default.link realisiert:

[Link] NamePolicy=keep kernel database onboard slot path

Man kann diese Systemdatei mit einer eigenen Datei /etc/systemd/network/99-default.link maskieren, indem man die Systemdatei kopiert und in der Kopie das Wort "keep" entfernt, und diese Datei wie vorstehend gezeigt in die initrd.img einfügen.

Verzögerung beim Hochlauf

Wenn die Konfiguration einer Schnittstelle misslingt, beispielsweise weil per DHCP keine Antwort eintrifft, blockiert die systemd-Unit systemd-networkd-wait-online.service bis zu 2 Minuten lang den Hochlauf bevor sie sich mit Fehler beendet. Wenn man anschliessend per networkctl eine Schnittstelle im Zustand "configuring" vorfindet, kann man die Zwangspause oft wie oben beschrieben abstellen.

Setting up Systemd-Networkd