Gilt für SUSE Linux Enterprise Server 15 SP3

19 Grundlegendes zu Netzwerken #

Linux stellt die erforderlichen Netzwerkwerkzeuge und -funktionen für die Integration in alle Arten von Netzwerkstrukturen zur Verfügung. Der Netzwerkzugriff über eine Netzwerkkarte kann mit YaST konfiguriert werden. Die manuelle Konfiguration ist ebenfalls möglich. In diesem Kapitel werden nur die grundlegenden Mechanismen und die relevanten Netzwerkkonfigurationsdateien behandelt.

Linux und andere Unix-Betriebssysteme verwenden das TCP/IP-Protokoll. Hierbei handelt es sich nicht um ein einzelnes Netzwerkprotokoll, sondern um eine Familie von Netzwerkprotokollen, die unterschiedliche Dienste zur Verfügung stellen. Die in Verschiedene Protokolle aus der TCP/IP-Familie aufgelisteten Protokolle dienen dem Datenaustausch zwischen zwei Computern über TCP/IP. Über TCP/IP verbundene Netzwerke bilden zusammen ein weltweites Netzwerk, das auch als „das Internet“ bezeichnet wird.

RFC ist das Akronym für Request for Comments. RFCs sind Dokumente, die unterschiedliche Internetprotokolle und Implementierungsverfahren für das Betriebssystem und seine Anwendungen beschreiben. Die RFC-Dokumente beschreiben das Einrichten der Internetprotokolle. Weitere Informationen zu RFCs finden Sie unter http://www.ietf.org/rfc.html.

Verschiedene Protokolle aus der TCP/IP-Familie #

TCP: Transmission Control Protocol: Ein verbindungsorientiertes sicheres Protokoll. Die zu übertragenden Daten werden zuerst von der Anwendung als Datenstrom gesendet und vom Betriebssystem in das passende Format konvertiert. Die entsprechende Anwendung auf dem Zielhost empfängt die Daten im ursprünglichen Datenstromformat, in dem sie anfänglich gesendet wurden. TCP ermittelt, ob Daten bei der Übertragung verloren gegangen sind oder beschädigt wurden. TCP wird immer dann implementiert, wenn die Datensequenz eine Rolle spielt.
UDP: User Datagram Protocol: Ein verbindungsloses, nicht sicheres Protokoll. Die zu übertragenden Daten werden in Form von anwendungsseitig generierten Paketen gesendet. Es ist nicht garantiert, in welcher Reihenfolge die Daten beim Empfänger eingehen, und ein Datenverlust ist immer möglich. UDP ist geeignet für datensatzorientierte Anwendungen. Es verfügt über eine kürzere Latenzzeit als TCP.
ICMP: Internet Control Message Protocol: Dies ist kein Protokoll für den Endbenutzer, sondern ein spezielles Steuerungsprotokoll, das Fehlerberichte ausgibt und das Verhalten von Computern, die am TCP/IP-Datentransfer teilnehmen, steuern kann. Außerdem bietet es einen speziellen Echomodus, der mit dem Programm „ping“ angezeigt werden kann.
IGMP: Internet Group Management Protocol: Dieses Protokoll steuert das Verhalten des Computers beim Implementieren von IP Multicast.

Der Datenaustausch findet wie in Abbildung 19.1, „Vereinfachtes Schichtmodell für TCP/IP“ dargestellt in unterschiedlichen Schichten statt. Die eigentliche Netzwerkschicht ist der unsichere Datentransfer über IP (Internet Protocol). Oberhalb von IP gewährleistet TCP (Transmission Control Protocol) bis zu einem gewissen Grad die Sicherheit des Datentransfers. Die IP-Schicht wird vom zugrunde liegenden hardwareabhängigen Protokoll, z. B. Ethernet, unterstützt.

Abbildung 19.1: Vereinfachtes Schichtmodell für TCP/IP #

Dieses Diagramm bietet für jede Schicht ein oder zwei Beispiele. Die Schichten sind nach Abstraktionsstufen sortiert. Die unterste Schicht ist sehr Hardware-nah. Die oberste Schicht ist beinahe vollständig von der Hardware losgelöst. Jede Schicht hat ihre eigene spezielle Funktion. Die speziellen Funktionen der einzelnen Schichten gehen bereits aus ihrer Bezeichnung hervor. Die Datenverbindungs- und die physische Schicht repräsentieren das verwendete physische Netzwerk, z. B. das Ethernet.

Fast alle Hardwareprotokolle arbeiten auf einer paketorientierten Basis. Die zu übertragenden Daten werden in Paketen gesammelt (sie können nicht alle auf einmal gesendet werden). Die maximale Größe eines TCP/IP-Pakets beträgt ca. 64 KB. Die Pakete sind in der Regel jedoch sehr viel kleiner, da die Netzwerkhardware ein einschränkender Faktor sein kann. Die maximale Größe eines Datenpakets in einem Ethernet beträgt ca. 1500 Byte. Die Größe eines TCP/IP-Pakets ist auf diesen Wert begrenzt, wenn die Daten über ein Ethernet gesendet werden. Wenn mehr Daten übertragen werden, müssen vom Betriebssystem mehr Datenpakete gesendet werden.

Damit die Schichten ihre vorgesehenen Funktionen erfüllen können, müssen im Datenpaket zusätzliche Informationen über die einzelnen Schichten gespeichert sein. Diese Informationen werden im Header des Pakets gespeichert. Jede Schicht stellt jedem ausgehenden Paket einen kleinen Datenblock voran, den so genannten Protokoll-Header. Ein Beispiel für ein TCP/IP-Datenpaket, das über ein Ethernetkabel gesendet wird, ist in Abbildung 19.2, „TCP/IP-Ethernet-Paket“ dargestellt. Die Prüfsumme befindet sich am Ende des Pakets, nicht am Anfang. Dies erleichtert die Arbeit für die Netzwerkhardware.

Abbildung 19.2: TCP/IP-Ethernet-Paket #

Wenn eine Anwendung Daten über das Netzwerk sendet, werden diese Daten durch alle Schichten geleitet, die mit Ausnahme der physischen Schicht alle im Linux-Kernel implementiert sind. Jede Schicht ist für das Vorbereiten der Daten zur Weitergabe an die nächste Schicht verantwortlich. Die unterste Schicht ist letztendlich für das Senden der Daten verantwortlich. Bei eingehenden Daten erfolgt die gesamte Prozedur in umgekehrter Reihenfolge. Die Protokoll-Header werden von den transportierten Daten in den einzelnen Schichten wie die Schalen einer Zwiebel entfernt. Die Transportschicht ist schließlich dafür verantwortlich, die Daten den Anwendungen am Ziel zur Verfügung zu stellen. Auf diese Weise kommuniziert eine Schicht nur mit der direkt darüber bzw. darunter liegenden Schicht. Für Anwendungen spielt es keine Rolle, ob Daten über eine drahtlose oder drahtgebundene Verbindung übertragen werden. Ähnlich spielt es für die Datenverbindung keine Rolle, welche Art von Daten übertragen wird, solange die Pakete das richtige Format haben.

19.1 IP-Adressen und Routing #

Die in diesem Abschnitt enthaltenen Informationen beziehen sich nur auf IPv4-Netzwerke. Informationen zum IPv6-Protokoll, dem Nachfolger von IPv4, finden Sie in Abschnitt 19.2, „IPv6 – das Internet der nächsten Generation“.

19.1.1 IP-Adressen #

Jeder Computer im Internet verfügt über eine eindeutige 32-Bit-Adresse. Diese 32 Bit (oder 4 Byte) werden in der Regel wie in der zweiten Zeile in Beispiel 19.1, „IP-Adressen schreiben“ dargestellt geschrieben.

Beispiel 19.1: IP-Adressen schreiben #

IP Address (binary):  11000000 10101000 00000000 00010100
IP Address (decimal):      192.     168.       0.      20

Im Dezimalformat werden die vier Byte in Dezimalzahlen geschrieben und durch Punkte getrennt. Die IP-Adresse wird einem Host oder einer Netzwerkschnittstelle zugewiesen. Sie kann weltweit nur einmal verwendet werden. Es gibt zwar Ausnahmen zu dieser Regel, diese sind jedoch für die folgenden Abschnitte nicht relevant.

Die Punkte in IP-Adressen geben das hierarchische System an. Bis in die 1990er-Jahre wurden IP-Adressen strikt in Klassen organisiert. Dieses System erwies sich jedoch als zu wenig flexibel und wurde eingestellt. Heute wird das klassenlose Routing (CIDR, Classless Interdomain Routing) verwendet.

19.1.2 Netzmasken und Routing #

Mit Netzmasken werden die Adressräume eines Subnetzes definiert. Wenn sich in einem Subnetz zwei Hosts befinden, können diese direkt aufeinander zugreifen. Wenn sie sich nicht im selben Subnetz befinden, benötigen sie die Adresse eines Gateways, das den gesamten Verkehr für das Subnetz verarbeitet. Um zu prüfen, ob sich zwei IP-Adressen im selben Subnetz befinden, wird jede Adresse bitweise mit der Netzmaske „UND“-verknüpft. Sind die Ergebnisse identisch, befinden sich beide IP-Adressen im selben lokalen Netzwerk. Wenn unterschiedliche Ergebnisse ausgegeben werden, kann die entfernte IP-Adresse, und somit die entfernte Schnittstelle, nur über ein Gateway erreicht werden.

Weitere Informationen zur Funktionsweise von Netzmasken finden Sie in Beispiel 19.2, „Verknüpfung von IP-Adressen mit der Netzmaske“. Die Netzmaske besteht aus 32 Bit, die festlegen, welcher Teil einer IP-Adresse zum Netzwerk gehört. Alle Bits mit dem Wert 1 kennzeichnen das entsprechende Bit in der IP-Adresse als zum Netzwerk gehörend. Alle Bits mit dem Wert 0 kennzeichnen Bits innerhalb des Subnetzes. Je mehr Bits den Wert 1 haben, desto kleiner ist also das Netzwerk. Da die Netzmaske immer aus mehreren aufeinander folgenden Bits mit dem Wert 1 besteht, ist es auch möglich, die Anzahl der Bits in der Netzmaske zu zählen. In Beispiel 19.2, „Verknüpfung von IP-Adressen mit der Netzmaske“ könnte das erste Netz mit 24 Bit auch als 192.168.0.0/24 geschrieben werden.

Beispiel 19.2: Verknüpfung von IP-Adressen mit der Netzmaske #

IP address (192.168.0.20):  11000000 10101000 00000000 00010100
Netmask   (255.255.255.0):  11111111 11111111 11111111 00000000
---------------------------------------------------------------
Result of the link:         11000000 10101000 00000000 00000000
In the decimal system:           192.     168.       0.       0

IP address (213.95.15.200): 11010101 10111111 00001111 11001000
Netmask    (255.255.255.0): 11111111 11111111 11111111 00000000
---------------------------------------------------------------
Result of the link:         11010101 10111111 00001111 00000000
In the decimal system:           213.      95.      15.       0

Ein weiteres Beispiel: Alle Computer, die über dasselbe Ethernetkabel angeschlossen sind, befinden sich in der Regel im selben Subnetz und sind direkt zugreifbar. Selbst wenn das Subnetz physisch durch Switches oder Bridges unterteilt ist, können diese Hosts weiter direkt erreicht werden.

IP-Adressen außerhalb des lokalen Subnetzes können nur erreicht werden, wenn für das Zielnetzwerk ein Gateway konfiguriert ist. In den meisten Fällen wird der gesamte externe Verkehr über lediglich ein Gateway gehandhabt. Es ist jedoch auch möglich, für unterschiedliche Subnetze mehrere Gateways zu konfigurieren.

Wenn ein Gateway konfiguriert wurde, werden alle externen IP-Pakete an das entsprechende Gateway gesendet. Dieses Gateway versucht anschließend, die Pakete auf dieselbe Weise – von Host zu Host – weiterzuleiten, bis sie den Zielhost erreichen oder ihre TTL-Zeit (Time to Live) abgelaufen ist.

Spezifische Adressen #

Netzwerkbasisadresse: Dies ist die Netzmaske, die durch UND mit einer Netzwerkadresse verknüpft ist, wie in Beispiel 19.2, „Verknüpfung von IP-Adressen mit der Netzmaske“ unter Result dargestellt. Diese Adresse kann keinem Host zugewiesen werden.
Rundrufadresse: Dies lässt sich auch wie folgt beschreiben: „Zugriff auf alle Hosts in diesem Subnetz.“ Um die Broadcast-Adresse zu generieren, wird die Netzmaske in die binäre Form invertiert und mit einem logischen ODER mit der Netzwerkbasisadresse verknüpft. Das obige Beispiel ergibt daher die Adresse 192.168.0.255. Diese Adresse kann keinem Host zugeordnet werden.
Lokaler Host: Die Adresse 127.0.0.1 ist auf jedem Host dem „Loopback-Device“ zugewiesen. Mit dieser Adresse und mit allen Adressen des vollständigen 127.0.0.0/8-Loopback-Netzwerks (wie bei IPv4 beschrieben) kann eine Verbindung zu Ihrem Computer eingerichtet werden. Bei IPv6 gibt es nur eine Loopback-Adresse (::1).

Da IP-Adressen weltweit eindeutig sein müssen, können Sie keine Adresse nach dem Zufallsprinzip wählen. Zum Einrichten eines privaten IP-basierten Netzwerks stehen drei Adressdomänen zur Verfügung. Diese können keine Verbindung zum Internet herstellen, da sie nicht über das Internet übertragen werden können. Diese Adressdomänen sind in RFC 1597 festgelegt und werden in Tabelle 19.1, „Private IP-Adressdomänen“ aufgelistet.

Tabelle 19.1: Private IP-Adressdomänen #

Netzwerk/Netzmaske	Domäne
`10.0.0.0`/`255.0.0.0`	`10.x.x.x`
`172.16.0.0`/`255.240.0.0`	`172.16.x.x` – `172.31.x.x`
`192.168.0.0`/`255.255.0.0`	`192.168.x.x`

19.2 IPv6 – das Internet der nächsten Generation #

Wichtig: IBM Z: Unterstützung für IPv6

IPv6 wird von den CTC- und IUCV-Netzwerkverbindungen der IBM Z-Hardware nicht unterstützt.

Aufgrund der Entstehung des WWW (World Wide Web) hat das Internet in den letzten 15 Jahren ein explosives Wachstum mit einer immer größer werdenden Anzahl von Computern erfahren, die über TCP/IP kommunizieren. Seit Tim Berners-Lee bei CERN (http://public.web.cern.ch) 1990 das WWW erfunden hat, ist die Anzahl der Internethosts von ein paar tausend auf ca. 100 Millionen angewachsen.

Wie bereits erwähnt, besteht eine IPv4-Adresse nur aus 32 Bit. Außerdem gehen zahlreiche IP-Adressen verloren, da sie aufgrund der organisatorischen Bedingtheit der Netzwerke nicht verwendet werden können. Die Anzahl der in Ihrem Subnetz verfügbaren Adressen ist zwei hoch der Anzahl der Bits minus zwei. Ein Subnetz verfügt also beispielsweise über 2, 6 oder 14 Adressen. Um beispielsweise 128 Hosts mit dem Internet zu verbinden, benötigen Sie ein Subnetz mit 256 IP-Adressen, von denen nur 254 verwendbar sind, da zwei IP-Adressen für die Struktur des Subnetzes selbst benötigt werden: die Broadcast- und die Basisnetzwerkadresse.

Unter dem aktuellen IPv4-Protokoll sind DHCP oder NAT (Network Address Translation) die typischen Mechanismen, um einem potenziellen Adressmangel vorzubeugen. Kombiniert mit der Konvention, private und öffentliche Adressräume getrennt zu halten, können diese Methoden den Adressmangel sicherlich mäßigen. Das Problem liegt in der Konfiguration der Adressen, die schwierig einzurichten und zu verwalten ist. Um einen Host in einem IPv4-Netzwerk einzurichten, benötigen Sie mehrere Adressen, z. B. die IP-Adresse des Hosts, die Subnetzmaske, die Gateway-Adresse und möglicherweise die Adresse des Nameservers. Alle diese Einträge müssen bekannt sein und können nicht von anderer Stelle her abgeleitet werden.

Mit IPv6 gehören sowohl der Adressmangel als auch die komplizierte Konfiguration der Vergangenheit an. Die folgenden Abschnitte enthalten weitere Informationen zu den Verbesserungen und Vorteilen von IPv6 sowie zum Übergang vom alten zum neuen Protokoll.

19.2.1 Vorteile #

Die wichtigste und augenfälligste Verbesserung durch das neuere Protokoll ist der enorme Zuwachs des verfügbaren Adressraums. Eine IPv6-Adresse besteht aus 128-Bit-Werten und nicht aus den herkömmlichen 32 Bit. Dies ermöglicht mehrere Billiarden IP-Adressen.

IPv6-Adressen unterscheiden sich nicht nur hinsichtlich ihrer Länge gänzlich von ihren Vorgängern. Sie verfügen auch über eine andere interne Struktur, die spezifischere Informationen zu den Systemen und Netzwerken enthalten kann, zu denen sie gehören. Weitere Informationen hierzu finden Sie in Abschnitt 19.2.2, „Adresstypen und -struktur“.

In der folgenden Liste werden andere Vorteile des neueren Protokolls aufgeführt:

Automatische Konfiguration

IPv6 macht das Netzwerk „Plug-and-Play“-fähig, d. h., ein neu eingerichtetes System wird ohne jegliche manuelle Konfiguration in das (lokale) Netzwerk integriert. Der neue Host verwendet die automatischen Konfigurationsmechanismen, um seine eigene Adresse aus den Informationen abzuleiten, die von den benachbarten Routern zur Verfügung gestellt werden. Dabei nutzt er ein Protokoll, das als ND-Protokoll (Neighbor Discovery) bezeichnet wird. Diese Methode erfordert kein Eingreifen des Administrators und für die Adresszuordnung muss kein zentraler Server verfügbar sein. Dies ist ein weiterer Vorteil gegenüber IPv4, bei dem für die automatische Adresszuordnung ein DHCP-Server erforderlich ist.

Wenn ein Router mit einem Switch verbunden ist, sollte der Router jedoch trotzdem periodische Anzeigen mit Flags senden, die den Hosts eines Netzwerks mitteilen, wie sie miteinander interagieren sollen. Weitere Informationen finden Sie im Artikel RFC 2462, auf der man-Seite radvd.conf(5) und im Artikel RFC 3315.

Mobilität

IPv6 ermöglicht es, einer Netzwerkschnittstelle gleichzeitig mehrere Adressen zuzuordnen. Dadurch können Benutzer problemlos auf mehrere Netzwerke zugreifen, was beispielsweise mit den von Mobilfunkunternehmen angebotenen internationalen Roaming-Diensten vergleichbar ist. Wenn Sie Ihr Mobiltelefon mit ins Ausland nehmen, meldet sich das Telefon automatisch bei dem fremden Dienst an, sobald Sie dessen Bereich betreten, sodass Sie überall unter Ihrer Rufnummer erreichbar sind und Anrufe genauso wie in Ihrem Heimatland tätigen können.

Sichere Kommunikation

Bei IPv4 ist die Netzwerksicherheit eine Add-on-Funktion. IPv6 umfasst IPSec als eine seiner Kernfunktionen und ermöglicht es Systemen, über einen sicheren Tunnel zu kommunizieren, um das Ausspionieren durch Außenstehende über das Internet zu verhindern.

Abwärtskompatibilität

Realistisch gesehen, ist es unmöglich, das gesamte Internet auf einmal von IPv4 auf IPv6 umzustellen. Daher ist es wichtig, dass beide Protokolle nicht nur im Internet, sondern auf einem System koexistieren können. Dies wird durch kompatible Adressen (IPv4-Adressen können problemlos in IPv6-Adressen konvertiert werden) und die Verwendung von Tunnels gewährleistet. Weitere Informationen hierzu finden Sie im Abschnitt 19.2.3, „Koexistenz von IPv4 und IPv6“. Außerdem können Systeme eine Dual-Stack-IP-Technik verwenden, um beide Protokolle gleichzeitig unterstützen zu können. Dies bedeutet, dass sie über zwei Netzwerk-Stacks verfügen, die vollständig unabhängig voneinander sind, sodass zwischen den beiden Protokollversionen keine Konflikte auftreten.

Bedarfsgerechte Dienste über Multicasting

Mit IPv4 müssen einige Dienste, z. B. SMB, ihre Pakete via Broadcast an alle Hosts im lokalen Netzwerk verteilen. Bei IPv6 ist dagegen eine deutlich feinere Vorgehensweise möglich: Die Server können die Hosts per Multicasting adressieren, also mehrere Hosts als Teil einer Gruppe. Dies unterscheidet sich vom Broadcasting, bei dem alle Hosts gleichzeitig adressiert werden, und vom Unicasting, bei dem jeder Host einzeln adressiert werden muss. Welche Hosts als Gruppe adressiert werden, kann je nach Anwendung unterschiedlich sein. Es gibt einige vordefinierte Gruppen, mit der beispielsweise alle Namenserver (die Multicast-Gruppe „all name servers“) oder alle Router (die Multicast-Gruppe „all routers“) angesprochen werden können.

19.2.2 Adresstypen und -struktur #

Wie bereits erwähnt, hat das aktuelle IP-Protokoll zwei wichtige Einschränkungen: Es stehen zunehmend weniger IP-Adressen zur Verfügung und das Konfigurieren des Netzwerks und Verwalten der Routing-Tabellen wird komplexer und aufwändiger. IPv6 löst das erste Problem durch die Erweiterung des Adressraums auf 128 Bit. Das zweite Problem wird durch die Einführung einer hierarchischen Adressstruktur gemildert, die mit weiteren hoch entwickelten Techniken zum Zuordnen von Netzwerkadressen sowie mit dem Multihoming (der Fähigkeit, einem Gerät mehrere Adressen zuzuordnen und so den Zugriff auf mehrere Netzwerke zu ermöglichen) kombiniert wird.

Bei der Arbeit mit IPv6 ist es hilfreich, die drei unterschiedlichen Adresstypen zu kennen:

Unicast: Adressen dieses Typs werden genau einer Netzwerkschnittstelle zugeordnet. Pakete mit derartigen Adressen werden nur einem Ziel zugestellt. Unicast-Adressen werden dementsprechend zum Übertragen von Paketen an einzelne Hosts im lokalen Netzwerk oder im Internet verwendet.
Multicast: Adressen dieses Typs beziehen sich auf eine Gruppe von Netzwerkschnittstellen. Pakete mit derartigen Adressen werden an alle Ziele zugestellt, die dieser Gruppe angehören. Multicast-Adressen werden hauptsächlich von bestimmten Netzwerkdiensten für die Kommunikation mit bestimmten Hostgruppen verwendet, wobei diese gezielt adressiert werden.
Anycast: Adressen dieses Typs beziehen sich auf eine Gruppe von Schnittstellen. Pakete mit einer derartigen Adresse werden gemäß den Prinzipien des zugrunde liegenden Routing-Protokolls dem Mitglied der Gruppe gesendet, das dem Absender am nächsten ist. Anycast-Adressen werden verwendet, damit Hosts Informationen zu Servern schneller abrufen können, die im angegebenen Netzwerkbereich bestimmte Dienste anbieten. Sämtliche Server desselben Typs verfügen über dieselbe Anycast-Adresse. Wann immer ein Host einen Dienst anfordert, erhält er eine Antwort von dem vom Routing-Protokoll ermittelten nächstgelegenen Server. Wenn dieser Server aus irgendeinem Grund nicht erreichbar ist, wählt das Protokoll automatisch den zweitnächsten Server, dann den dritten usw. aus.

Eine IPv6-Adresse besteht aus acht vierstelligen Feldern, wobei jedes 16 Bit repräsentiert, und wird in hexadezimaler Notation geschrieben. Sie werden durch Doppelpunkte (:) getrennt. Alle führenden Null-Byte innerhalb eines bestimmten Felds können ausgelassen werden, alle anderen Nullen jedoch nicht. Eine weitere Konvention ist, dass mehr als vier aufeinander folgenden Null-Byte mit einem doppelten Doppelpunkt zusammengefasst werden können. Jedoch ist pro Adresse nur ein solcher doppelter Doppelpunkt (::) zulässig. Diese Art der Kurznotation wird in Beispiel 19.3, „Beispiel einer IPv6-Adresse“ dargestellt, in dem alle drei Zeilen derselben Adresse entsprechen.

Beispiel 19.3: Beispiel einer IPv6-Adresse #

fe80 : 0000 : 0000 : 0000 : 0000 : 10 : 1000 : 1a4
fe80 :    0 :    0 :    0 :    0 : 10 : 1000 : 1a4
fe80 :                           : 10 : 1000 : 1a4

Jeder Teil einer IPv6-Adresse hat eine festgelegte Funktion. Die ersten Byte bilden das Präfix und geben den Typ der Adresse an. Der mittlere Teil ist der Netzwerkteil der Adresse, der möglicherweise nicht verwendet wird. Das Ende der Adresse bildet der Hostteil. Bei IPv6 wird die Netzmaske definiert, indem die Länge des Präfixes nach einem Schrägstrich am Ende der Adresse angegeben wird. Adressen wie in Beispiel 19.4, „IPv6-Adressen mit Angabe der Präfix-Länge“ enthalten Informationen zum Netzwerk (die ersten 64 Bit) und zum Hostteil (die letzten 64 Bit). Die 64 bedeutet, dass die Netzmaske mit 64 1-Bit-Werten von links gefüllt wird. Wie bei IPv4 wird die IP-Adresse mit den Werten aus der Netzmaske durch UND verknüpft, um zu ermitteln, ob sich der Host im selben oder einem anderen Subnetz befindet.

Beispiel 19.4: IPv6-Adressen mit Angabe der Präfix-Länge #

fe80::10:1000:1a4/64

IPv6 kennt mehrere vordefinierte Präfixtypen. Einige sind unter Unterschiedliche IPv6-Präfixe aufgeführt.

Unterschiedliche IPv6-Präfixe #

00: IPv4-über-IPv6-Kompatibilitätsadressen. Diese werden zur Erhaltung der Kompatibilität mit IPv4 verwendet. Für diesen Adresstyp wird ein Router benötigt, der IPv6-Pakete in IPv4-Pakete konvertieren kann. Mehrere spezielle Adressen, z. B. die für das Loopback-Device, verfügen ebenfalls über dieses Präfix.
2 oder 3 als erste Stelle: Aggregierbare globale Unicast-Adressen. Wie bei IPv4 kann eine Schnittstelle zugewiesen werden, um einen Teil eines bestimmten Subnetzes zu bilden. Aktuell stehen die folgenden Adressräume zur Verfügung: 2001::/16 (Adressraum Produktionsqualität) und 2002::/16 (6to4-Adressraum).
fe80::/10: Link-local-Adressen. Adressen mit diesem Präfix dürfen nicht geroutet werden und können daher nur im gleichen Subnetz erreicht werden.
fec0::/10: Site-local-Adressen. Diese Adressen dürfen zwar geroutet werden, aber nur innerhalb des Organisationsnetzwerks, dem sie angehören. Damit entsprechen diese Adressen den bisherigen privaten Netzen (beispielsweise 10.x.x.x).
ff: Dies sind Multicast-Adressen.

Eine Unicast-Adresse besteht aus drei grundlegenden Komponenten:

Öffentliche Topologie: Der erste Teil, der unter anderem auch eines der oben erwähnten Präfixe enthält, dient dem Routing des Pakets im öffentlichen Internet. Hier sind Informationen zum Provider oder der Institution kodiert, die den Netzwerkzugang bereitstellen.
Site-Topologie: Der zweite Teil enthält Routing-Informationen zu dem Subnetz, in dem das Paket zugestellt werden soll.
Schnittstellen-ID: Der dritte Teil identifiziert eindeutig die Schnittstelle, an die das Paket gerichtet ist. Dies erlaubt, die MAC-Adresse als Adressbestandteil zu verwenden. Da diese weltweit nur einmal vorhanden und zugleich vom Hardwarehersteller fest vorgegeben ist, vereinfacht sich die Konfiguration auf diese Weise sehr. Die ersten 64 Bit werden zu einem so genannten EUI-64-Token zusammengefasst. Dabei werden die letzten 48 Bit der MAC-Adresse entnommen und die restlichen 24 Bit enthalten spezielle Informationen, die etwas über den Typ des Tokens aussagen. Das ermöglicht dann auch, Geräten ohne MAC-Adresse (z. B. PPP-Verbindungen) ein EUI-64-Token zuzuweisen.

Abgeleitet aus diesem Grundaufbau werden bei IPv6 fünf verschiedene Typen von Unicast-Adressen unterschieden:

:: (nicht spezifiziert)

Ein Host verwendet diese Adresse als Quelladresse, wenn seine Netzwerkschnittstelle zum ersten Mal initialisiert wird (wobei die Adresse zu diesm Zeitpunkt noch nicht anderweitig ermittelt werden kann).

::1 (Loopback)

Adresse des Loopback-Device.

IPv4-kompatible Adressen

Die IPv6-Adresse setzt sich aus der IPv4-Adresse und einem Präfix von 96 0-Bits zusammen. Dieser Typ der Kompatibilitätsadresse wird beim Tunneling verwendet (siehe Abschnitt 19.2.3, „Koexistenz von IPv4 und IPv6“). IPv4/IPv6-Hosts können so mit anderen kommunizieren, die sich in einer reinen IPv4-Umgebung befinden.

IPv6-gemappte IPv4-Adressen

Dieser Adresstyp gibt die Adresse in IPv6-Notation an.

Lokale Adressen

Es gibt zwei Typen von Adressen zum rein lokalen Gebrauch:

link-local: Dieser Adresstyp ist ausschließlich für den Gebrauch im lokalen Subnetz bestimmt. Router dürfen Pakete mit einer solchen Ziel- oder Quelladresse nicht an das Internet oder andere Subnetze weiterreichen. Diese Adressen zeichnen sich durch ein spezielles Präfix (fe80::/10) und die Schnittstellen-ID der Netzwerkkarte aus. Der Mittelteil der Adresse besteht aus Null-Bytes. Diese Art Adresse wird von den Autokonfigurationsmethoden verwendet, um Hosts im selben Subnetz anzusprechen.
site-local: Pakete mit diesem Adresstyp dürfen zwischen einzelnen Subnetzen geroutet werden, aber nicht außerhalb einer Organisation ins Internet gelangen. Solche Adressen werden für Intranets eingesetzt und sind ein Äquivalent zu den privaten IPv4-Adressen. Sie bestehen aus einem besonderen Präfix (fec0::/10), der Schnittstellen-ID und einem 16-Bit-Feld mit der Subnetz-ID. Die restlichen Stellen werden wieder mit Null-Bytes gefüllt.

Zusätzlich gibt es in IPv6 eine grundsätzlich neue Funktion: Einer Netzwerkschnittstelle werden in der Regel mehrere IP-Adressen zugewiesen. Das hat den Vorteil, dass mehrere verschiedene Netzwerke zur Verfügung stehen. Eines dieser Netzwerke kann mit der MAC-Adresse und einem bekannten Präfix vollautomatisch konfiguriert werden, sodass nach der Aktivierung von IPv6 alle Hosts im lokalen Netz über Link-local-Adressen erreichbar sind. Durch die MAC-Adresse als Bestandteil der IP-Adresse ist jede dieser Adressen global eindeutig. Einzig die Teile der Site-Topologie und der öffentlichen Topologie können variieren, je nachdem in welchem Netz dieser Host aktuell zu erreichen ist.

Bewegt sich ein Host zwischen mehreren Netzen hin und her, braucht er mindestens zwei Adressen. Die eine, seine Home-Adresse, beinhaltet neben der Schnittstellen-ID die Informationen zu dem Heimatnetz, in dem der Computer normalerweise betrieben wird, und das entsprechende Präfix. Die Home-Adresse ist statisch und wird in der Regel nicht verändert. Alle Pakete, die für diesen Host bestimmt sind, werden ihm sowohl im eigenen als auch in fremden Netzen zugestellt. Möglich wird die Zustellung im Fremdnetz über wesentliche Neuerungen des IPv6-Protokolls, z. B. Stateless Autoconfiguration und Neighbor Discovery. Der mobile Rechner hat neben seiner Home-Adresse eine oder mehrere weitere Adressen, die zu den fremden Netzen gehören, in denen er sich bewegt. Diese Adressen heißen Care-of-Adressen. Im Heimatnetz des mobilen Rechners muss eine Instanz vorhanden sein, die an seine Home-Adresse gerichtete Pakete nachsendet, sollte er sich in einem anderen Netz befinden. Diese Funktion wird in einer IPv6-Umgebung vom Home-Agenten übernommen. Er stellt alle Pakete, die an die Home-Adresse des mobilen Rechners gerichtet sind, über einen Tunnel zu. Pakete, die als Zieladresse die Care-of-Adresse tragen, können ohne Umweg über den Home-Agenten zugestellt werden.

19.2.3 Koexistenz von IPv4 und IPv6 #

Die Migration aller mit dem Internet verbundenen Hosts von IPv4 auf IPv6 wird nicht auf einen Schlag geschehen. Vielmehr werden das alte und das neue Protokoll noch eine ganze Weile nebeneinanderher existieren. Die Koexistenz auf einem Rechner ist dann möglich, wenn beide Protokolle im Dual Stack-Verfahren implementiert sind. Es bleibt aber die Frage, wie IPv6-Rechner mit IPv4-Rechnern kommunizieren können und wie IPv6-Pakete über die momentan noch vorherrschenden IPv4-Netze transportiert werden sollen. Tunneling und die Verwendung von Kompatibilitätsadressen (siehe Abschnitt 19.2.2, „Adresstypen und -struktur“) sind hier die besten Lösungen.

IPv6-Hosts, die im (weltweiten) IPv4-Netzwerk mehr oder weniger isoliert sind, können über Tunnel kommunizieren: IPv6-Pakete werden als IPv4-Pakete gekapselt und so durch ein ein IPv4-Netzwerk übertragen. Ein Tunnel ist definiert als die Verbindung zwischen zwei IPv4-Endpunkten. Hierbei müssen die Pakete die IPv6-Zieladresse (oder das entsprechende Präfix) und die IPv4-Adresse des entfernten Hosts am Tunnelendpunkt enthalten. Einfache Tunnel können von den Administratoren zwischen ihren Netzwerken manuell und nach Absprache konfiguriert werden. Ein solches Tunneling wird statisches Tunneling genannt.

Trotzdem reicht manuelles Tunneling oft nicht aus, um die Menge der zum täglichen vernetzten Arbeiten nötigen Tunnel aufzubauen und zu verwalten. Aus diesem Grund wurden für IPv6 drei verschiedene Verfahren entwickelt, die das dynamische Tunneling erlauben:

6over4: IPv6-Pakete werden automatisch in IPv4-Pakete verpackt und über ein IPv4-Netzwerk versandt, in dem Multicasting aktiviert ist. IPv6 wird vorgespiegelt, das gesamte Netzwerk (Internet) sei ein einziges, riesiges LAN (Local Area Network). So wird der IPv4-Endpunkt des Tunnel automatisch ermittelt. Nachteile dieser Methode sind die schlechte Skalierbarkeit und die Tatsache, dass IP-Multicasting keineswegs im gesamten Internet verfügbar ist. Diese Lösung eignet sich für kleinere Netzwerke, die die Möglichkeit von IP-Multicasting bieten. Die zugrunde liegenden Spezifikationen sind in RFC 2529 enthalten.
6to4: Bei dieser Methode werden automatisch IPv4-Adressen aus IPv6-Adressen generiert. So können isolierte IPv6-Hosts über ein IPv4-Netz miteinander kommunizieren. Allerdings gibt es einige Probleme, die die Kommunikation zwischen den isolierten IPv6-Hosts und dem Internet betreffen. Diese Methode wird in RFC 3056 beschrieben.
IPv6 Tunnel Broker: Dieser Ansatz sieht spezielle Server vor, die für IPv6 automatisch dedizierte Tunnel anlegen. Diese Methode wird in RFC 3053 beschrieben.

19.2.4 IPv6 konfigurieren #

Um IPv6 zu konfigurieren, müssen Sie auf den einzelnen Arbeitsstationen in der Regel keine Änderungen vornehmen. IPv6 ist standardmäßig aktiviert. Um IPv6 auf einem installierten System zu deaktivieren oder zu aktivieren, verwenden Sie das Modul YaST-Netzwerkeinstellungen. Aktivieren oder deaktivieren Sie auf dem Karteireiter Globale Optionen die Option IPv6 aktivieren, falls nötig. Zum vorübergehenden Aktivieren bis zum nächsten Neustart geben Sie modprobe -i ipv6 als root ein. Nach dem Laden des IPv6-Moduls kann es nicht mehr entladen werden.

Aufgrund des Konzepts der automatischen Konfiguration von IPv6 wird der Netzwerkkarte eine Adresse im Link-local-Netzwerk zugewiesen. In der Regel werden Routing-Tabellen nicht auf Arbeitsstationen verwaltet. Bei Netzwerkroutern kann von der Arbeitsstation unter Verwendung des Router-Advertisement-Protokolls abgefragt werden, welches Präfix und welche Gateways implementiert werden sollen. Zum Einrichten eines IPv6-Routers kann das radvd-Programm verwendet werden. Dieses Programm informiert die Arbeitsstationen darüber, welches Präfix und welche Router für die IPv6-Adressen verwendet werden sollen. Alternativ können Sie die Adressen und das Routing auch mit zebra/quagga automatisch konfigurieren.

Weitere Informationen zum Einrichten verschiedneer Tunnel mit den Dateien in /etc/sysconfig/network finden Sie auf der man-Seite zu ifcfg-tunnel (man ifcfg-tunnel).

19.2.5 Weitere Informationen #

Das komplexe IPv6-Konzept wird im obigen Überblick nicht vollständig abgedeckt. Weitere ausführliche Informationen zu dem neueren Protokoll finden Sie in den folgenden Online-Dokumentationen und -Büchern:

http://www.ipv6.org/: Alles rund um IPv6.
http://www.ipv6day.org: Alle Informationen, die Sie benötigen, um Ihr eigenes IPv6-Netzwerk zu starten.
http://www.ipv6-to-standard.org/: Die Liste der IPv6-fähigen Produkte.
http://www.bieringer.de/linux/IPv6/: Hier finden Sie den Beitrag „Linux IPv6 HOWTO“ und viele verwandte Links zum Thema.
RFC 2460: Die grundlegenden IPv6-Spezifikationen.
IPv6 Essentials: Ein Buch, in dem alle wichtigen Aspekte zum Thema enthalten sind, ist IPv6 Essentials von Silvia Hagen (ISBN 0-596-00125-8).

19.3 Namensauflösung #

Mithilfe von DNS kann eine IP-Adresse einem oder sogar mehreren Namen zugeordnet werden und umgekehrt auch ein Name einer IP-Adresse. Unter Linux erfolgt diese Umwandlung üblicherweise durch eine spezielle Software namens bind. Der Computer, der diese Umwandlung dann erledigt, nennt sich Namenserver. Dabei bilden die Namen wieder ein hierarchisches System, in dem die einzelnen Namensbestandteile durch Punkte getrennt sind. Die Namenshierarchie ist aber unabhängig von der oben beschriebenen Hierarchie der IP-Adressen.

Ein Beispiel für einen vollständigen Namen wäre jupiter.example.com, geschrieben im Format Hostname.Domäne. Ein vollständiger Name, der als Fully Qualified Domain Name oder kurz als FQDN bezeichnet wird, besteht aus einem Host- und einem Domänennamen (example.com). Ein Bestandteil des Domänennamens ist die Top Level Domain oder TLD (com).

Aus historischen Gründen ist die Zuteilung der TLDs etwas verwirrend. So werden in den USA traditionell dreibuchstabige TLDs verwendet, woanders aber immer die aus zwei Buchstaben bestehenden ISO-Länderbezeichnungen. Seit 2000 stehen zusätzliche TLDs für spezielle Sachgebiete mit zum Teil mehr als drei Buchstaben zur Verfügung (z. B. .info, .name, .museum).

In der Frühzeit des Internets (vor 1990) gab es die Datei/etc/hosts, in der die Namen aller im Internet vertretenen Rechner gespeichert waren. Dies erwies sich bei der schnell wachsenden Menge der mit dem Internet verbundenen Computer als unpraktikabel. Deshalb wurde eine dezentralisierte Datenbank entworfen, die die Hostnamen verteilt speichern kann. Diese Datenbank, eben jener oben erwähnte Namenserver, hält also nicht die Daten aller Computer im Internet vorrätig, sondern kann Anfragen an ihm nachgeschaltete, andere Namenserver weiterdelegieren.

An der Spitze der Hierarchie befinden sich die root-Namenserver. Die root-Namenserver verwalten die Domänen der obersten Ebene (Top Level Domains) und werden vom Network Information Center (NIC) verwaltet. Der root-Namenserver kennt die jeweils für eine Top Level Domain zuständigen Namenserver. Weitere Informationen zu TLD-NICs finden Sie unter http://www.internic.net.

Der DNS bietet viel mehr Möglichkeiten als die bloße Namensauflösung. Der Namenserver weiß auch, welcher Host für eine ganze Domäne Emails annimmt, der so genannte Mail Exchanger (MX).

Damit auch Ihr Computer einen Namen in eine IP-Adresse auflösen kann, muss ihm mindestens ein Nameserver mit einer IP-Adresse bekannt sein. Ein Namensserver kann einfach mithilfe von YaST angegeben werden. Die Konfiguration des Nameserverzugriffs unter SUSE® Linux Enterprise Server ist in Abschnitt 19.4.1.4, „Konfigurieren des Hostnamens und des DNS“ beschrieben. Eine Beschreibung zum Einrichten Ihres Nameservers finden Sie in Kapitel 31, Domain Name System (DNS).

Eng verwandt mit DNS ist das Protokoll whois. Mit dem gleichnamigen Programm können Sie schnell ermitteln, wer für eine bestimmte Domäne verantwortlich ist.

Anmerkung: MDNS- und .local-Domänennamen

Die Domäne .local der obersten Stufe wird vom Resolver als link-local-Domäne behandelt. DNS-Anforderungen werden als Multicast-DNS-Anforderungen anstelle von normalen DNS-Anforderungen gesendet. Wenn Sie in Ihrer Nameserver-Konfiguration die Domäne .local verwenden, müssen Sie diese Option in /etc/host.conf ausschalten. Weitere Informationen finden Sie auf der man-Seite host.conf.

Soll MDNS während der Installation ausgeschaltet werden, verwenden Sie nomdns=1 als Bootparameter.

Weitere Informationen zum Multicast-DNS finden Sie unter http://www.multicastdns.org.

19.4 Konfigurieren von Netzwerkverbindungen mit YaST #

Unter Linux gibt es viele unterstützte Netzwerktypen. Die meisten verwenden unterschiedliche Gerätenamen und die Konfigurationsdateien sind im Dateisystem an unterschiedlichen Speicherorten verteilt. Einen detaillierten Überblick über die Aspekte der manuellen Netzwerkkonfiguration finden Sie in Abschnitt 19.5, „Manuelle Netzwerkkonfiguration“.

Alle Netzwerkschnittstellen mit aktivierter Verbindung (also mit angeschlossenem Netzwerkkabel) werden automatisch konfiguriert. Zusätzliche Hardware kann jederzeit nach Abschluss der Installation auf dem installierten System konfiguriert werden. In den folgenden Abschnitten wird die Netzwerkkonfiguration für alle von SUSE Linux Enterprise Server unterstützten Netzwerkverbindungen beschrieben.

Tipp: IBM Z: Hotplug-fähige Netzwerkkarten

Auf den IBM Z-Plattformen werden Hotplug-fähige Netzwerkkarten unterstützt, aber nicht deren automatische Netzwerkintegration über DHCP (wie beim PC). Nachdem diese erkannt wurden, müssen Sie die Schnittstelle manuell konfigurieren.

19.4.1 Konfigurieren der Netzwerkkarte mit YaST #

Zur Konfiguration verkabelter oder drahtloser Netzwerkkarten in YaST wählen Sie System › Netzwerkeinstellungen. Nach dem Öffnen des Moduls zeigt YaST das Dialogfeld Netzwerkeinstellungen mit den vier Karteireitern Globale Optionen, Übersicht, Hostname/DNS und Routing an.

Auf dem Karteireiter Globale Optionen können allgemeine Netzwerkoptionen wie die Netzwerkeinrichtungsmethode, IPv6 und allgemeine DHCP-Optionen festgelegt werden. Weitere Informationen finden Sie im Abschnitt 19.4.1.1, „Konfigurieren globaler Netzwerkoptionen“.

Der Karteireiter Übersicht enthält Informationen über installierte Netzwerkschnittstellen und -konfigurationen. Jede korrekt erkannte Netzwerkkarte wird dort mit ihrem Namen aufgelistet. In diesem Dialogfeld können Sie Karten manuell konfigurieren, entfernen oder ihre Konfiguration ändern. Informationen zum manuellen Konfigurieren von Karten, die nicht automatisch erkannt wurden, finden Sie unter Abschnitt 19.4.1.3, „Konfigurieren einer unerkannten Netzwerkkarte“. Informationen zum Ändern der Konfiguration einer bereits konfigurierten Karte finden Sie unter Abschnitt 19.4.1.2, „Ändern der Konfiguration einer Netzwerkkarte“.

Auf dem Karteireiter Hostname/DNS können der Hostname des Computers sowie die zu verwendenden Nameserver festgelegt werden. Weitere Informationen finden Sie im Abschnitt 19.4.1.4, „Konfigurieren des Hostnamens und des DNS“.

Der Karteireiter Routing wird zur Konfiguration des Routings verwendet. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Abschnitt 19.4.1.5, „Konfigurieren des Routings“.

Abbildung 19.3: Konfigurieren der Netzwerkeinstellungen #

19.4.1.1 Konfigurieren globaler Netzwerkoptionen #

Auf dem Karteireiter Globale Optionen des YaST-Moduls Netzwerkeinstellungen können wichtige globale Netzwerkoptionen wie die Verwendung der Optionen NetworkManager, IPv6 und DHCP-Client festgelegt werden. Diese Einstellungen sind für alle Netzwerkschnittstellen anwendbar.

Anmerkung: NetworkManager von der Arbeitsplatzrechnererweiterung bereitgestellt

NetworkManager wird nun von der SUSE Linux Enterprise-Arbeitsplatzrechner-Erweiterung bereitgestellt. Aktivieren Sie zur Installation von NetworkManager das Repository für die Arbeitsplatzrechnererweiterung und wählen Sie die NetworkManager-Pakete aus.

Unter Netzwerkeinrichtungsmethode wählen Sie die Methode aus, mit der Netzwerkverbindungen verwaltet werden sollen. Wenn die Verbindungen für alle Schnittstellen über das Desktop-Applet NetworkManager verwaltet werden sollen, wählen Sie NetworkManager-Dienst aus. NetworkManager eignet sich besonders für den Wechsel zwischen verschiedenen verkabelten und drahtlosen Netzwerken. Wenn Sie keine Desktop-Umgebung ausführen oder wenn Ihr Rechner ein Xen-Server oder ein virtuelles System ist oder Netzwerkdienste wie DHCP oder DNS in Ihrem Netzwerk zur Verfügung stellt, verwenden Sie die Methode Wicked-Dienst. Beim Einsatz von NetworkManager sollte nm-applet verwendet werden, um Netzwerkoptionen zu konfigurieren. Die Karteireiter Übersicht, Hostname/DNS und Routing des Moduls Netzwerkeinstellungen sind dann deaktiviert. Weitere Informationen zu NetworkManager finden Sie in der Dokumentation für SUSE Linux Enterprise Desktop.

Geben Sie unter IPv6-Protokoll-Einstellungen an, ob Sie das IPv6-Protokoll verwenden möchten. IPv6 kann parallel zu IPv4 verwendet werden. IPv6 ist standardmäßig aktiviert. In Netzwerken, die das IPv6-Protokoll nicht verwenden, können die Antwortzeiten jedoch schneller sein, wenn dieses Protokoll deaktiviert ist. Zum Deaktivieren von IPv6 deaktivieren Sie die Option IPv6 aktivieren. Wenn IPv6 deaktiviert ist, lädt der Kernel das IPv6-Modul nicht mehr automatisch. Diese Einstellung wird nach einem Neustart übernommen.

Unter Optionen für DHCP-Client konfigurieren Sie die Optionen für den DHCP-Client. Die Kennung für DHCP-Client muss innerhalb eines Netzwerks für jeden DHCP-Client eindeutig sein. Wenn dieses Feld leer bleibt, wird standardmäßig die Hardware-Adresse der Netzwerkschnittstelle als Kennung übernommen. Falls Sie allerdings mehrere virtuelle Computer mit der gleichen Netzwerkschnittstelle und damit der gleichen Hardware-Adresse ausführen, sollten Sie hier eine eindeutige Kennung in beliebigem Format eingeben.

Unter Zu sendender Hostname wird eine Zeichenkette angegeben, die für das Optionsfeld „Hostname“ verwendet wird, wenn der DHCP-Client Nachrichten an den DHCP-Server sendet. Einige DHCP-Server aktualisieren Nameserver-Zonen gemäß diesem Hostnamen (dynamischer DNS). Bei einigen DHCP-Servern muss das Optionsfeld Zu sendender Hostname in den DHCP-Nachrichten der Clients zudem eine bestimmte Zeichenkette enthalten. Übernehmen Sie die Einstellung AUTO, um den aktuellen Hostnamen zu senden (d. h. der aktuelle in /etc/HOSTNAME festgelegte Hostname). Soll kein Hostname gesendet werden, leeren Sie dieses Feld.

Wenn die Standardroute nicht gemäß den Informationen von DHCP geändert werden soll, deaktivieren Sie Standardroute über DHCP ändern.

19.4.1.2 Ändern der Konfiguration einer Netzwerkkarte #

Wenn Sie die Konfiguration einer Netzwerkkarte ändern möchten, wählen Sie die Karte aus der Liste der erkannten Karten unter Netzwerkeinstellungen › Übersicht in YaST aus, und klicken Sie auf Bearbeiten. Das Dialogfeld Netzwerkkarten-Setup wird angezeigt. Hier können Sie die Kartenkonfiguration auf den Karteireitern Allgemein, Adresse und Hardware anpassen.

19.4.1.2.1 IP-Adressen konfigurieren #

Die IP-Adresse der Netzwerkkarte oder die Art der Festlegung dieser IP-Adresse kann auf dem Karteireiter Adresse im Dialogfeld Einrichten der Netzwerkkarte festgelegt werden. Die Adressen IPv4 und IPv6 werden unterstützt. Für die Netzwerkkarte können die Einstellungen Keine IP-Adresse (nützlich für eingebundene Geräte), Statisch zugewiesene IP-Adresse (IPv4 oder IPv6) oder Dynamische Adresse über DHCP und/oder Zeroconf zugewiesen werden.

Wenn Sie Dynamische Adresse verwenden, wählen Sie, ob Nue DHCP-Version 4 (für IPv4), Nur DHCP-Version 6 (für IPv6) oder DHCP-Version 4 und 6 verwendet werden soll.

Wenn möglich wird die erste Netzwerkkarte mit einer Verbindung, die bei der Installation verfügbar ist, automatisch zur Verwendung der automatischen Adressenkonfiguration mit DHCP konfiguriert.

Anmerkung: IBM Z und DHCP

Auf IBM Z-Plattformen wird die DHCP-basierte Adressenkonfiguration nur mit Netzwerkkarten unterstützt, die über eine MAC-Adresse verfügen. Das ist nur der Fall bei OSA- und OSA Express-Karten.

DHCP sollten Sie auch verwenden, wenn Sie eine DSL-Leitung verwenden, Ihr ISP (Internet Service Provider) Ihnen aber keine statische IP-Adresse zugewiesen hat. Wenn Sie DHCP verwenden möchten, konfigurieren Sie dessen Einstellungen im Dialogfeld Netzwerkeinstellungen des YaST-Konfigurationsmoduls für Netzwerkkarten auf dem Karteireiter Globale Optionen unter Optionen für DHCP-Client. In einer virtuellen Hostumgebung, in der mehrere Hosts über dieselbe Schnittstelle kommunizieren, müssen diese anhand der Kennung für DHCP-Client unterschieden werden.

DHCP eignet sich gut zur Client-Konfiguration, aber zur Server-Konfiguration ist es nicht ideal. Wenn Sie eine statische IP-Adresse festlegen möchten, gehen Sie wie folgt vor:

Wählen Sie im YaST-Konfigurationsmodul für Netzwerkkarten auf dem Karteireiter Übersicht in der Liste der erkannten Karten eine Netzwerkkarte aus, und klicken Sie auf Bearbeiten.
Wählen Sie auf dem Karteireiter Adresse die Option Statisch zugewiesene IP-Adresse aus.
Geben Sie die IP-Adresse ein. Es können beide Adressen, IPv4 und IPv6, verwendet werden. Geben Sie die Netzwerkmaske in Teilnetzmaske ein. Wenn die IPv6-Adresse verwendet wird, benutzen Sie Teilnetzmaske für die Präfixlänge im Format /64.
Optional kann ein voll qualifizierter Hostname für diese Adresse eingegeben werden, der in die Konfigurationsdatei /etc/hosts geschrieben wird.
Klicken Sie auf Weiter.
Klicken Sie auf OK, um die Konfiguration zu aktivieren.

Anmerkung: Schnittstellenaktivierung und Linkerkennung

Bei der Aktivierung einer Netzwerkschnittstelle sucht wicked nach einem Träger und die IP-Konfiguration wird erst dann angewendet, wenn ein Link erkannt wurde. Wenn die Konfiguration unabhängig vom Link-Status angewendet werden soll (etwa wenn Sie einen Dienst testen, der eine bestimmte Adresse überwacht), können Sie die Link-Verbindung überspringen. Hängen Sie hierzu die Variable LINK_REQUIRED=no an die Konfigurationsdatei der Schnittstelle unter /etc/sysconfig/network/ifcfg an.

Darüber hinaus können Sie mit der Variablen LINK_READY_WAIT=5 die Zeitüberschreitung (in Sekunden) für das Erkennen eines Links festlegen.

Weitere Informationen zu den ifcfg-*-Konfigurationsdateien finden Sie unter Abschnitt 19.5.2.5, „/etc/sysconfig/network/ifcfg-*“ und man 5 ifcfg.

Wenn Sie die statische Adresse verwenden, werden die Namenserver und das Standard-Gateway nicht automatisch konfiguriert. Informationen zur Konfiguration von Namenservern finden Sie unter Abschnitt 19.4.1.4, „Konfigurieren des Hostnamens und des DNS“. Informationen zur Konfiguration eines Gateways finden Sie unter Abschnitt 19.4.1.5, „Konfigurieren des Routings“.

19.4.1.2.2 Konfigurieren mehrerer Adressen #

Ein Netzwerkgerät kann mehrere IP-Adressen haben.

Anmerkung: Aliasse stellen eine Kompatibilitätsfunktion dar

Diese sogenannten Aliasse oder Kennungen sind nur mit IPv4 verwendbar. Bei IPv6 werden sie ignoriert. Bei der Verwendung von iproute2-Netzwerkschnittstellen können eine oder mehrere Adressen vorhanden sein.

Gehen Sie folgendermaßen vor, wenn Sie weitere Adressen für Ihre Netzwerkkarte mithilfe von YaST einrichten möchten:

Wählen Sie im YaST-Dialogfeld Netzwerkeinstellungen auf dem Karteireiter Übersicht in der Liste der erkannten Karten eine Netzwerkkarte aus, und klicken Sie auf Bearbeiten.
Klicken Sie auf dem Karteireiter Adresse › Zusätzliche Adressen auf Hinzufügen.
Geben Sie die IPv4-Adresskennung, die IP-Adresse und die Netzmaske ein. Nehmen Sie den Schnittstellennamen nicht in den Aliasnamen auf.
Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

19.4.1.2.3 Ändern des Gerätenamens und der Udev-Regeln #

Der Gerätename der Netzwerkkarte kann während des laufenden Betriebs geändert werden. Es kann auch festgelegt werden, ob udev die Netzwerkkarte über die Hardware-Adresse (MAC) oder die Bus-ID erkennen soll. Die zweite Option ist bei großen Servern vorzuziehen, um den Hotplug-Austausch der Karten zu erleichtern. Mit YaST legen Sie diese Optionen wie folgt fest:

Wählen Sie im YaST-Dialogfeld Netzwerkeinstellungen auf dem Karteireiter Übersicht in der Liste der erkannten Karten eine Netzwerkkarte aus, und klicken Sie auf Bearbeiten.
Öffnen Sie den Karteireiter Allgemein. Der aktuelle Gerätename wird unter Udev-Regeln angezeigt. Klicken Sie auf Ändern.
Wählen Sie aus, ob udev die Karte über die MAC-Adresse oder die Bus-ID erkennen soll. Die aktuelle MAC-Adresse und Bus-ID der Karte werden im Dialogfeld angezeigt.
Aktivieren Sie zum Ändern des Gerätenamens die Option Gerätenamen ändern und bearbeiten Sie den Namen.
Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

19.4.1.2.4 Ändern des Kernel-Treibers für Netzwerkkarten #

Für einige Netzwerkkarten sind eventuell verschiedene Kernel-Treiber verfügbar. Wenn die Karte bereits konfiguriert ist, ermöglicht YaST die Auswahl eines zu verwendenden Kernel-Treibers in einer Liste verfügbarer Treiber. Es ist auch möglich, Optionen für den Kernel-Treiber anzugeben. Mit YaST legen Sie diese Optionen wie folgt fest:

Wählen Sie im YaST-Modul Netzwerkeinstellungen auf dem Karteireiter Übersicht in der Liste der erkannten Karten eine Netzwerkkarte aus, und klicken Sie auf Bearbeiten.
Öffnen Sie den Karteireiter Hardware.
Wählen Sie den zu verwendenden Kernel-Treiber unter Modulname aus. Geben Sie die entsprechenden Optionen für den ausgewählten Treiber unter Optionen im Format = =WERT ein. Wenn mehrere Optionen verwendet werden, sollten sie durch Leerzeichen getrennt sein.
Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

19.4.1.2.5 Aktivieren des Netzwerkgeräts #

Wenn Sie die Methode mit wicked verwenden, können Sie Ihr Gerät so konfigurieren, dass es wahlweise beim Systemstart, beim Anschließen des Kabels, beim Erkennen der Karte, manuell oder nie startet. Wenn Sie den Gerätestart ändern möchten, gehen Sie wie folgt vor:

Wählen Sie in YaST unter System › Netzwerkeinstellungen in der Liste der erkannten Karten eine Netzwerkkarte aus und klicken Sie auf Bearbeiten.
In der Karteireiter Allgemein wählen Sie den gewünschten Eintrag unter Geräte-Aktivierung.
Wählen Sie Beim Systemstart, um das Gerät beim Booten des Systems zu starten. Wenn Bei Kabelanschluss aktiviert ist, wird die Schnittstelle auf physikalische Netzwerkverbindungen überwacht. Wenn Falls hot-plugged aktiviert ist, wird die Schnittstelle festgelegt, wenn sie verfügbar ist. Dies gleicht der Option Bei Systemstart, führt jedoch nicht zu einem Fehler beim Systemstart, wenn die Schnittstelle nicht vorhanden ist. Wählen Sie Manuell, wenn Sie die Schnittstelle manuell mit ifup steuern möchten. Wählen Sie Nie, wenn das Gerät nicht gestartet werden soll. Bei NFSroot verhält sich ähnlich wie Beim Systemstart, allerdings fährt der Befehl systemctl stop network die Schnittstelle bei dieser Einstellung nicht herunter; der network-Dienst wirkt sich auch auf den wicked-Dienst aus, sofern wicked aktiv ist. Diese Einstellung empfiehlt sich bei einem NFS- oder iSCSI-root-Dateisystem.
Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

Tipp: NFS als root-Dateisystem

Auf (festplattenlosen) Systemen, in denen die Stammpartition über das Netzwerk als NFS-Freigabe eingehängt ist, müssen Sie beim Konfigurieren des Netzwerkgeräts, über das die NFS-Freigabe erreichbar ist, besonders vorsichtig vorgehen.

Wenn Sie das System herunterfahren oder neu booten, werden in der standardmäßigen Reihenfolge zunächst die Netzwerkverbindungen deaktiviert und anschließend die Stammpartition ausgehängt. Bei einem NFS-root kann dies zu Problemen führen: Die Stammpartition kann nicht fehlerfrei ausgehängt werden, da die Netzwerkverbindung zur NFS-Freigabe schon nicht mehr aktiviert ist. Damit das System nicht das relevante Netzwerkgerät deaktiviert, öffnen Sie die Registerkarte gemäß Abschnitt 19.4.1.2.5, „Aktivieren des Netzwerkgeräts“ und wählen Sie unter Geräteaktivierung die Option Bei NFSroot.

19.4.1.2.6 Einrichten der Größe der maximalen Transfereinheit #

Sie können eine maximale Transfereinheit (MTU) für die Schnittstelle festlegen. MTU bezieht sich auf die größte zulässige Paketgröße in Byte. Eine größere MTU bringt eine höhere Bandbreiteneffizienz. Große Pakete können jedoch eine langsame Schnittstelle für einige Zeit belegen und die Verzögerung für nachfolgende Pakete vergrößern.

Wählen Sie in YaST unter System › Netzwerkeinstellungen in der Liste der erkannten Karten eine Netzwerkkarte aus und klicken Sie auf Bearbeiten.
Wählen Sie im Karteireiter Allgemein den gewünschten Eintrag aus der Liste Set MTU (MTU festlegen).
Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

19.4.1.2.7 Multifunktionale PCIe-Geräte #

Multifunktionale Geräte, die LAN, iSCSI und FCoE unterstützen, werden unterstützt. Mit dem YaST FCoE-Client (yast2 fcoe-client) werden die privaten Flags in zusätzlichen Spalten angezeigt, um dem Benutzer zu erlauben, das für FCoE vorgesehene Gerät auszuwählen. Mit dem YaST-Netzwerkmodul (yast2 lan) werden „Geräte, die nur als Speicher dienen“, von der Netzwerkkonfiguration ausgeschlossen.

Weitere Informationen zu FCoE erhalten Sie im Section 16.3, “Managing FCoE services with YaST”.

19.4.1.2.8 InfiniBand-Konfiguration für IPoIB (IP-over-InfiniBand) #

Wählen Sie in YaST unter System › Netzwerkeinstellungen das InfiniBand-Gerät aus und klicken Sie auf Bearbeiten.
Wählen Sie auf dem Karteireiter Allgemein einen der IPoIB-Modi (IP-over-InfiniBand) aus: Verbunden (Standard) oder Datagramm.
Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

Weitere Informationen zu InfiniBand finden Sie in der Datei /usr/src/linux/Documentation/infiniband/ipoib.txt.

19.4.1.2.9 Konfigurieren der Firewall #

Sie müssen nicht die genaue Firewall-Konfiguration durchführen, wie im Section 23.4, “firewalld” beschrieben. Sie können die grundlegende Firewall-Konfiguration für Ihr Gerät als Teil der Gerätekonfiguration festlegen. Führen Sie dazu die folgenden Schritte aus:

Öffnen Sie das YaST-Modul System › Netzwerkeinstellungen. Wählen Sie im Karteireiter Übersicht eine Karte aus der Liste erkannter Karten und klicken Sie auf Bearbeiten.
Öffnen Sie den Karteireiter Allgemein des Dialogfelds Netzwerkeinstellungen.
Legen Sie die Firewall-Zone fest, der Ihre Schnittstelle zugewiesen werden soll. Folgende Optionen sind verfügbar:
Firewall deaktiviert
Diese Option ist nur verfügbar, wenn die Firewall deaktiviert ist und nicht ausgeführt wird. Verwenden Sie diese Option nur, wenn Ihr Computer Teil eines größeren Netzwerks ist, das von einer äußeren Firewall geschützt wird.
Automatisches Zuweisen von Zonen
Diese Option ist nur verfügbar, wenn die Firewall aktiviert ist. Die Firewall wird ausgeführt und die Schnittstelle wird automatisch einer Firewall-Zone zugewiesen. Die Zone, die das Stichwort Beliebig enthält, oder die externe Zone wird für solch eine Schnittstelle verwendet.
Interne Zone (ungeschützt)
Die Firewall wird ausgeführt, aber es gibt keine Regeln, die diese Schnittstelle schützen. Verwenden Sie diese Option, wenn Ihr Computer Teil eines größeren Netzwerks ist, das von einer äußeren Firewall geschützt wird. Sie ist auch nützlich für die Schnittstellen, die mit dem internen Netzwerk verbunden sind,wenn der Computer über mehrere Netzwerkschnittstellen verfügt.
Demilitarisierte Zone
Eine demilitarisierte Zone ist eine zusätzliche Verteidigungslinie zwischen einem internen Netzwerk und dem (feindlichen) Internet. Die dieser Zone zugewiesenen Hosts können vom internen Netzwerk und vom Internet erreicht werden, können jedoch nicht auf das interne Netzwerk zugreifen.
Externe Zone
Die Firewall wird an dieser Schnittstelle ausgeführt und schützt sie vollständig vor anderem (möglicherweise feindlichem) Netzwerkverkehr. Dies ist die Standardoption.
Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

19.4.1.3 Konfigurieren einer unerkannten Netzwerkkarte #

Wenn eine Netzwerkkarte nicht ordnungsgemäß erkannt wird, so wird diese Karte nicht in der Liste der erkannten Karten aufgeführt. Wenn Sie sich nicht sicher sind, ob Ihr System über einen Treiber für die Karte verfügt, können Sie sie manuell konfigurieren. Sie können auch spezielle Netzwerkgerätetypen konfigurieren, z. B. Bridge, Bond, TUN oder TAP. So konfigurieren Sie eine nicht erkannte Netzwerkkarte (oder ein spezielles Gerät):

Klicken Sie im Dialogfeld System › Netzwerkeinstellungen › Übersicht in YaST auf Hinzufügen.
Legen Sie den Gerätetyp der Schnittstelle im Dialogfeld Hardware mit Hilfe der verfügbaren Optionen fest und geben Sie einen Konfigurationsnamen ein. Wenn es sich bei der Netzwerkkarte um ein USB-Gerät handelt, aktivieren Sie das entsprechende Kontrollkästchen und schließen Sie das Dialogfeld durch Klicken auf Weiter. Ansonsten können Sie den Kernel Modulname definieren, der für die Karte verwendet wird, sowie gegebenenfalls dessen Optionen.
Unter Ethtool-Optionen können Sie die von ifup für die Schnittstelle verwendeten Ethtool-Optionen einstellen. Weitere Informationen zu den verfügbaren Optionen finden Sie auf der man-Seite ethtool.
Wenn die Optionszeichenkette mit einem - beginnt (z. B. -K SCHNITTSTELLENNAME rx on), wird das zweite Wort der Zeichenkette durch den aktuellen Schnittstellennamen ersetzt. In allen andern Fällen (z. B. autoneg off speed 10) setzt ifup dem Eintrag die Zeichenfolge -s SCHNITTSTELLENNAME voran.
Klicken Sie auf Weiter.
Konfigurieren Sie die benötigten Optionen wie die IP-Adresse, die Geräteaktivierung oder die Firewall-Zone für die Schnittstelle auf den Karteireitern Allgemein, Adresse und Hardware. Weitere Informationen zu den Konfigurationsoptionen finden Sie in Abschnitt 19.4.1.2, „Ändern der Konfiguration einer Netzwerkkarte“.
Wenn Sie für den Gerätetyp der Schnittstelle die Option Drahtlos gewählt haben, konfigurieren Sie im nächsten Dialogfeld die drahtlose Verbindung.
Zum Aktivieren der neuen Netzwerkkonfiguration bestätigen Sie die Einstellungen.

19.4.1.4 Konfigurieren des Hostnamens und des DNS #

Wenn Sie die Netzwerkkonfiguration während der Installation noch nicht geändert haben und die Ethernet-Karte bereits verfügbar war, wurde automatisch ein Hostname für Ihren Rechner erstellt, und DHCP wurde aktiviert. Dasselbe gilt für die Namensservicedaten, die Ihr Host für die Integration in eine Netzwerkumgebung benötigt. Wenn DHCP für eine Konfiguration der Netzwerkadresse verwendet wird, wird die Liste der Domain Name Server automatisch mit den entsprechenden Daten versorgt. Falls eine statische Konfiguration vorgezogen wird, legen Sie diese Werte manuell fest.

Wenn Sie den Namen Ihres Computers und die Namenserver-Suchliste ändern möchten, gehen Sie wie folgt vor:

Wechseln Sie zum Karteireiter Netzwerkeinstellungen › Hostname/DNS im Modul System in YaST.
Geben Sie den Hostnamen ein. Der Hostname ist global und gilt für alle eingerichteten Netzwerkschnittstellen.
Wenn Sie zum Abrufen einer IP-Adresse DHCP verwenden, wird der Hostname Ihres Computers automatisch durch den DHCP-Server festgelegt. Sie sollten dieses Verhalten deaktivieren, wenn Sie Verbindungen zu verschiedenen Netzwerken aufbauen, da Sie verschiedene Hostnamen zuweisen können und das Ändern des Hostnamens beim Ausführen den grafischen Desktop verwirren kann. Zum Deaktivieren von DHCP, damit Sie eine IP-Adresse erhalten, deaktivieren Sie Hostnamen über DHCP ändern.
Legen Sie unter DNS-Konfiguration ändern fest, wie die DNS-Konfiguration (Nameserver, Suchliste, Inhalt der Datei /run/netconfig/resolv.conf) geändert wird.
Wenn die Option Standardrichtlinie verwenden ausgewählt ist, wird die Konfiguration vom Skript netconfig verwaltet, das die statisch definierten Daten (mit YaST oder in den Konfigurationsdateien) mit dynamisch bezogenen Daten (vom DHCP-Client oder NetworkManager) zusammenführt. Diese Standardrichtlinie ist in der Regel ausreichend.
Wenn die Option Nur manuell ausgewählt ist, darf netconfig die Datei /run/netconfig/resolv.conf nicht ändern. Jedoch kann diese Datei manuell bearbeitet werden.
Wenn die Option Benutzerdefinierte Richtlinie ausgewählt ist, muss eine Zeichenkette für die benutzerdefinierte Richtlinienregel angegeben werden, welche die Zusammenführungsrichtlinie definiert. Die Zeichenkette besteht aus einer durch Kommas getrennten Liste mit Schnittstellennamen, die als gültige Quelle für Einstellungen betrachtet werden. Mit Ausnahme vollständiger Schnittstellennamen sind auch grundlegende Platzhalter zulässig, die mit mehreren Schnittstellen übereinstimmen. Beispiel: eth* ppp? richtet sich zuerst an alle eth- und dann an alle ppp0-ppp9-Schnittstellen. Es gibt zwei spezielle Richtlinienwerte, die angeben, wie die statischen Einstellungen angewendet werden, die in der Datei /etc/sysconfig/network/config definiert sind:
STATIC
Die statischen Einstellungen müssen mit den dynamischen Einstellungen zusammengeführt werden.
STATIC_FALLBACK
Die statischen Einstellungen werden nur verwendet, wenn keine dynamische Konfiguration verfügbar ist.
Weitere Informationen finden Sie auf der man-Seite zu netconfig(8) (man 8 netconfig).
Geben Sie die Namenserver ein und füllen Sie die Domänensuchliste aus. Nameserver müssen in der IP-Adresse angegeben werden (z. B. 192.168.1.116), nicht im Hostnamen. Namen, die im Karteireiter Domänensuche angegeben werden, sind Namen zum Auflösen von Hostnamen ohne angegebene Domäne. Wenn mehr als eine Suchdomäne verwendet wird, müssen die Domänen durch Kommas oder Leerzeichen getrennt werden.
Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

Der Hostname kann auch mit YaST über die Kommandozeile bearbeitet werden. Die Änderungen in YaST treten sofort in Kraft (im Gegensatz zur manuellen Bearbeitung der Datei /etc/HOSTNAME). Zum Ändern des Hostnamens führen Sie das folgende Kommando aus:

root # yast dns edit hostname=HOSTNAME

Zum Ändern der Namenserver führen Sie die folgenden Kommandos aus:

root # yast dns edit nameserver1=192.168.1.116
root # yast dns edit nameserver2=192.168.1.117
root # yast dns edit nameserver3=192.168.1.118

19.4.1.5 Konfigurieren des Routings #

Damit Ihre Maschine mit anderen Maschinen und Netzwerken kommuniziert, müssen Routing-Daten festgelegt werden. Dann nimmt der Netzwerkverkehr den korrekten Weg. Wird DHCP verwendet, werden diese Daten automatisch angegeben. Wird eine statische Konfiguration verwendet, müssen Sie die Daten manuell angeben.

Navigieren Sie in YaST zu Netzwerkeinstellungen › Routing.
Geben Sie die IP-Adresse für das Standard-Gateway ein (gegebenenfalls IPv4 und IPv6). Das Standard-Gateway stimmt mit jedem möglichen Ziel überein. Falls jedoch ein Eintrag in der Routingtabelle vorliegt, der mit der angegebenen Adresse übereinstimmt, wird dieser Eintrag anstelle der Standardroute über das Standard-Gateway verwendet.
In der Routing-Tabelle können weitere Einträge vorgenommen werden. Geben Sie die IP-Adresse für das Ziel-Netzwerk, die IP-Adresse des Gateways und die Netzmaske ein. Wählen Sie das Gerät aus, durch das der Datenverkehr zum definierten Netzwerk geroutet wird (das Minuszeichen steht für ein beliebiges Gerät). Verwenden Sie das Minuszeichen -, um diese Werte frei zu lassen. Verwenden Sie default im Feld Ziel, um in der Tabelle ein Standard-Gateway einzugeben.
Anmerkung: Priorisieren einer Route
Wenn mehrere Standardrouten verwendet werden, kann die Metrik-Option verwendet werden, um festzulegen, welche Route eine höhere Priorität hat. Geben Sie zur Angabe der Metrik-Option - Metrik NUMMER unter Optionen ein. Die Route mit der höchsten Metrik wird als Standard verwendet. Wenn das Netzwerkgerät getrennt wird, wird seine Route entfernt und die nächste verwendet.
Wenn das System ein Router ist, aktivieren Sie bei Bedarf die Optionen IPv4-Weiterleitung und IPv6-Weiterleitung in den Netzwerkeinstellungen.
Zum Aktivieren der Konfiguration bestätigen Sie die Einstellungen.

19.4.2 IBM Z: Konfigurieren von Netzwerkgeräten #

SUSE Linux Enterprise Server für IBM Z unterstützt mehrere Typen von Netzwerkschnittstellen. YaST kann zur Konfiguration dieser Schnittstellen verwendet werden.

19.4.2.1 Das qeth-hsi-Gerät #

Wenn dem installierten System eine qeth-hsi-Schnittstelle (Hipersockets) hinzugefügt werden soll, starten Sie in YaST das Modul System › Netzwerkeinstellungen. Wählen Sie eines der Geräte mit der Bezeichnung Hipersocket aus, um es als READ-Geräteadresse zu verwenden, und klicken Sie auf Bearbeiten. Geben Sie die Gerätenummern für den Lese-, den Schreib- und den Steuerkanal ein (Beispiel für Gerätenummernformat: 0.0.0800). Klicken Sie anschließend auf „Weiter“. Im Dialogfeld Konfiguration der Netzwerkadresse geben Sie die IP-Adresse und die Netzmaske für die neue Schnittstelle an. Klicken Sie danach auf Weiter und OK, um die Netzwerkkonfiguration zu beenden.

19.4.2.2 Das qeth-ethernet-Gerät #

Wenn Sie dem installierten System eine qeth-ethernet-Schnittstelle (IBM OSA Express Ethernet Card) hinzufügen möchten, starten Sie in YaST das Modul System › Netzwerkeinstellungen. Wählen Sie eines der Geräte mit der Bezeichnung IBM OSA Express Ethernet Card aus, um es als READ-Geräteadresse zu verwenden, und klicken Sie auf Bearbeiten. Geben Sie eine Gerätenummer für den Lese-, den Schreib- und den Steuerkanal ein (Beispiel für Gerätenummernformat: 0.0.0700). Geben Sie den erforderlichen Portnamen, die Portnummer (falls zutreffend) und einige weitere Optionen, Ihre IP-Adresse sowie eine geeignete Netzmaske ein. Beenden Sie die Netzwerkkonfiguration mit Weiter und OK.

19.4.2.3 Das ctc-Gerät #

Wenn Sie dem installierten System eine ctc-Schnittstelle (IBM Parallel CTC Adapter) hinzufügen möchten, starten Sie in YaST das Modul System › Netzwerkeinstellungen. Wählen Sie eines der Geräte mit der Bezeichnung IBM Parallel CTC Adapter aus, um es als Lesekanal zu verwenden und klicken Sie auf Konfigurieren. Wählen Sie die Geräteeinstellungen für Ihre Geräte aus (gewöhnlich ist das Kompatibilitätsmodus). Geben Sie Ihre IP-Adresse und die IP-Adresse des entfernten Partners ein. Passen Sie gegebenenfalls die MTU-Größe mit Erweitert › Besondere Einstellungen an. Beenden Sie die Netzwerkkonfiguration mit Weiter und OK.

Warnung: Ende der CTC-Unterstützung

Die Nutzung dieser Schnittstelle ist veraltet. Diese Schnittstelle wird in künftigen Versionen von SUSE Linux Enterprise Server nicht mehr unterstützt.

19.4.2.4 Das lcs-Gerät #

Wenn Sie dem installierten System eine lcs-Schnittstelle (IBM OSA-2 Adapter) hinzufügen möchten, starten Sie in YaST das Modul System › Netzwerkeinstellungen. Wählen Sie eines der Geräte mit der Bezeichnung IBM OSA-2 Adapter und klicken Sie auf Konfigurieren. Geben Sie die erforderliche Portnummer, einige weitere Optionen, Ihre IP-Adresse sowie eine geeignete Netzmaske ein. Beenden Sie die Netzwerkkonfiguration mit Weiter und OK.

19.4.2.5 Das IUCV-Gerät #

Wenn Sie dem installierten System eine iucv-Schnittstelle (IUCV) hinzufügen möchten, starten Sie in YaST das Modul System › Netzwerkeinstellungen. Wählen Sie eines der Geräte mit der Bezeichnung IUCV und klicken Sie auf Bearbeiten. YaST fordert Sie auf, den Namen Ihres IUCV-Partners (Peer) einzugeben. Geben Sie den Namen ein (beachten Sie die Groß-/Kleinschreibung) und wählen Sie Weiter. Geben Sie sowohl Ihre IP-Adresse als auch die Entfernte IP-Adresse Ihres Partners ein. Stellen Sie bei Bedarf die MTU-Größe über die Option MTU festlegen im Karteireiter Allgemein ein. Beenden Sie die Netzwerkkonfiguration mit Weiter und OK.

Warnung: Ende der IUCV-Unterstützung

Die Nutzung dieser Schnittstelle ist veraltet. Diese Schnittstelle wird in künftigen Versionen von SUSE Linux Enterprise Server nicht mehr unterstützt.

19.5 Manuelle Netzwerkkonfiguration #

Die manuelle Konfiguration der Netzwerksoftware sollte die letzte Alternative sein. Wir empfehlen, YaST zu benutzen. Die folgenden Hintergrundinformationen zur Netzwerkkonfiguration können Ihnen jedoch auch bei der Arbeit mit YaST behilflich sein.

19.5.1 Die `wicked`-Netzwerkkonfiguration #

Das Werkzeug und die Bibilothek mit der Bezeichnung wicked bilden ein neues Framework für die Netzwerkkonfiguration.

Eine der Herausforderungen der traditionellen Netzwerkschnittstellenverwaltung liegt darin, dass verschiedene Netzwerkverwaltungsschichten in einem einzigen Skript oder maximal zwei Skripten vermischt werden. Diese Skripte interagieren auf nicht eindeutig definierte Weise miteinander. So entstehen unvorhersehbare Probleme, undurchsichtige Einschränkungen und Konventionen und vieles mehr. Verschiedene Schichten mit speziellen Kniffen für unterschiedliche Szenarien machen die Wartungsarbeit nicht gerade leichter. Die verwendeten Adresskonfigurationsprotokolle werden über Daemons wie dhcpcd implementiert, die eher notdürftig mit der restlichen Infrastruktur zusammenarbeiten. Die Schnittstellennamen werden anhand von merkwürdigen Schemata, die eine erhebliche udev-Unterstützung erfordern, dauerhaft identifiziert.

wicked verfolgt einen anderen Ansatz, bei dem das Problem nach mehreren Gesichtspunkten zerlegt wird. Die einzelnen Verfahren dabei sind nicht völlig neuartig, doch eröffnen die Ideen und Konzepte aus anderen Projekten unterm Strich eine bessere Gesamtlösung.

Ein mögliches Verfahren ist das Client/Server-Modell. wicked ist hiermit in der Lage, standardisierte Funktionen für Bereiche wie die Adresskonfiguration zu definieren, die gut in das Framework als Ganzes eingebunden sind. Über eine bestimmte Adresskonfiguration kann der Administrator beispielsweise festlegen, dass eine Schnittstelle mit DHCP oder IPv4 zeroconf konfiguriert werden soll. In diesem Fall holt der Adresskonfigurationsdienst lediglich das Lease vom Server ein und übergibt es an den wicked-Serverprozess, mit dem die Anforderungen Adressen und Routen installiert werden.

Das zweite Verfahren zur Problemzerlegung ist die Erzwingung der Schichten. Für alle Arten von Netzwerkschnittstellen kann ein dbus-Service definiert werden, mit dem die Geräteschicht der Netzwerkschnittstelle konfiguriert wird – ein VLAN, eine Bridge, ein Bonding oder ein paravirtualisiertes Gerät. Häufig verwendete Funktionen, z. B. die Adresskonfiguration, wird über gemeinsame Services implementiert, die sich in einer Schicht oberhalb dieser gerätespezifischen Services befinden, ohne dass sie eigens implementiert werden müssen.

Im wicked-Framework werden diese beiden Aspekte durch eine Vielzahl von dbus-Services zusammengeführt, die den Netzwerkschnittstellen je nach ihrem Typ zugeordnet werden. Im Folgenden finden Sie einen kurzen Überblick über die aktuelle Objekthierarchie in wicked.

Die Netzwerkschnittstelle wird jeweils als untergeordnetes Objekt von /org/opensuse/Network/Interfaces dargestellt. Die Bezeichnung des untergeordneten Objekts ergibt sich aus dem zugehörigen Wert für ifindex. Die Loopback-Schnittstelle (in der Regel ifindex 1) ist beispielsweise /org/opensuse/Network/Interfaces/1, und die erste registrierte Ethernet-Schnittstelle ist /org/opensuse/Network/Interfaces/2.

Jede Netzwerkschnittstelle ist mit einer „Klasse“ verknüpft, mit der die unterstützten dbus-Schnittstellen ausgewählt werden. Standardmäßig gehören alle Netzwerkschnittstellen zur Klasse netif, und wicked ordnet automatisch alle Schnittstellen zu, die mit dieser Klasse kompatibel sind. In der aktuellen Implementierung gilt dies für die folgenden Schnittstellen:

org.opensuse.Network.Interface: Allgemeine Funktionen für Netzwerkschnittstellen, z. B. Herstellen oder Beenden der Verbindung, Zuweisen einer MTU und vieles mehr.
org.opensuse.Network.Addrconf.ipv4.dhcp, org.opensuse.Network.Addrconf.ipv6.dhcp, org.opensuse.Network.Addrconf.ipv4.auto: Adresskonfigurationsservices für DHCP, IPv4 zeroconf usw.

Darüber hinaus können die Netzwerkschnittstellen bestimmte Konfigurationsmechanismen erfordern oder anbieten. Bei einem Ethernet-Gerät benötigen Sie beispielsweise Funktionen zum Steuern der Verbindungsgeschwindigkeit, zum Abgeben der Prüfsummenberechnung usw. Ethernet-Geräte gehören daher zu einer eigenen Klasse (netif-ethernet), die wiederum eine Subklasse von netif ist. Aus diesem Grund umfassen die dbus-Schnittstellen, die mit einer Ethernet-Schnittstelle verknüpft sind, alle oben aufgeführten Services und zusätzlich den Service org.opensuse.Network.Ethernet, der ausschließlich für Objekte der Klasse netif-ethernet verfügbar ist.

Ebenso bestehen Klassen für Schnittstellentypen wie Bridges, VLANs, Bonds oder InfiniBands.

Wie interagieren Sie mit einer Schnittstelle wie VLAN (die im Grunde genommen eine virtuelle Netzwerkschnittstelle über einem Ethernet-Gerät bildet), die erst noch erstellt werden muss? Hierfür werden Factory-Schnittstellen in wicked definiert, beispielsweise org.opensuse.Network.VLAN.Factory. Diese Factory-Schnittstellen bieten nur eine einzige Funktion, mit der Sie eine Schnittstelle mit dem gewünschten Typ erstellen. Die Factory-Schnittstellen sind dem Listenknoten /org/opensuse/Network/Interfaces zugeordnet.

19.5.1.1 `wicked`-Architektur und -Funktionen #

Der wicked-Dienst umfasst mehrere Teile, wie in Abbildung 19.4, „wicked-Architektur“ dargestellt.

Abbildung 19.4: wicked-Architektur #

wicked unterstützt derzeit Folgendes:

Konfigurationsdatei-Back-Ends zum Analysieren von /etc/sysconfig/network-Dateien im SUSE-Format.
Internes Konfigurationsdatei-Back-End zur Darstellung der Netzwerkschnittstellenkonfiguration in XML.
Hoch- und Herunterfahren für „normale“ Netzwerkschnittstellen wie Ethernet oder InfiniBand, außerdem für VLAN-, Bridge-, Bonds-, TUN-, TAP-, Dummy-, MacVLan-, MacVTap-, HSI-, QETH- und IUCV-Geräte sowie für drahtlose Geräte (derzeit auf nur ein WPA-PSK-/EAP-Netzwerk beschränkt).
Integrierter DHCPv4-Client und integrierter DHCPv6-Client.
Der nanny-Daemon (standardmäßig aktiviert) fährt konfigurierte Schnittstellen automatisch hoch, wenn das Gerät verfügbar ist (Schnittstellen-Hotplugging), und richtet die IP-Konfiguration ein, wenn eine Verbindung (Träger) erkannt wird. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Abschnitt 19.5.1.3, „Nanny“.
wicked wurde als eine Gruppe von DBus-Diensten implementiert, die mit systemd integriert sind. Daher sind die üblichen systemctl-Kommandos auch für wicked gültig.

19.5.1.2 Verwendung von `wicked` #

Bei SUSE Linux Enterprise wird wicked standardmäßig ausgeführt. Mit dem folgenden Befehl stellen Sie fest, welche Elemente derzeit aktiviert sind und ob sie ausgeführt werden:

systemctl status network

Wenn wicked aktiviert ist, erhalten Sie die folgende Ausgabe (Beispiel):

wicked.service - wicked managed network interfaces
    Loaded: loaded (/usr/lib/systemd/system/wicked.service; enabled)
    ...

Falls andere Elemente ausgeführt werden (z. B. NetworkManager) und Sie zu wicked wechseln möchten, halten Sie zunächst die ausgeführten Elemente an und aktivieren Sie dann wicked:

systemctl is-active network && \
systemctl stop      network
systemctl enable --force wicked

Beim nächsten Booten werden damit die wicked-Services aktiviert, die Alias-Verknüpfung von network.service und wicked.service wird erstellt, und das Netzwerk wird gestartet.

Starten des Serverprozesses:

systemctl start wickedd

Hiermit werden sowohl wicked (der Hauptserver) und die zugehörigen Supplicants gestartet:

/usr/lib/wicked/bin/wickedd-auto4 --systemd --foreground
/usr/lib/wicked/bin/wickedd-dhcp4 --systemd --foreground
/usr/lib/wicked/bin/wickedd-dhcp6 --systemd --foreground
/usr/sbin/wickedd --systemd --foreground
/usr/sbin/wickedd-nanny --systemd --foreground

Fahren Sie dann das Netzwerk hoch:

systemctl start wicked

Alternativ verwenden Sie das network-Alias:

systemctl start network

Bei diesen Kommandos werden die standardmäßigen oder die systemeigenen Konfigurationsquellen verwendet, die in /etc/wicked/client.xml definiert sind.

Zum Aktivieren der Fehlersuche legen Sie WICKED_DEBUG_ in /etc/sysconfig/network/config fest, beispielsweise:

WICKED_DEBUG="all"

Sollen einige Aspekte ausgelassen werden:

WICKED_DEBUG="all,-dbus,-objectmodel,-xpath,-xml"

Mit dem Clientprogramm rufen Sie die Schnittstellendaten für alle Schnittstellen bzw. für die mit IFNAME angegebenen Schnittstellen ab:

wicked show all
wicked show IFNAME

Als XML-Ausgabe:

wicked show-xml all
wicked show-xml IFNAME

Starten einer bestimmten Schnittstelle:

wicked ifup eth0
wicked ifup wlan0
...

Da keine Konfigurationsquelle angegeben ist, prüft der wicked-Client die Standard-Konfigurationsquellen, die in /etc/wicked/client.xml definiert sind:

firmware: iSCSI Boot Firmware Table (iBFT)
compat: ifcfg-Dateien; aus Kompatibilitätsgründen implementiert

Alle Informationen, die wicked aus diesen Quellen für eine bestimmte Schnittstelle erhält, werden übernommen und angewendet. Die geplante Reihenfolge lautet firmware, dann compat. Diese Reihenfolge wird unter Umständen demnächst geändert.

Weitere Informationen finden Sie auf der man-Seite zu wicked.

19.5.1.3 Nanny #

Der ereignis- und richtliniengestützte Daemon nanny ist für asynchrone oder unverlangte Szenarien zuständig, beispielsweise für das Hotplugging von Geräten. Der nanny-Daemon hilft also dabei, verzögerte oder vorübergehend ausgefallene Dienste zu starten oder neu zu starten. Nanny überwacht Veränderungen an den Geräten und Verknüpfungen und bindet neue Geräte gemäß dem aktuellen Richtliniensatz ein. Nanny fährt aufgrund von angegebenen Einschränkungen zur Zeitüberschreitung mit dem Einrichten fort, auch wenn ifup bereits beendet ist.

Standardmäßig ist der nanny-Daemon im System aktiv. Er wird in der Konfigurationsdatei /etc/wicked/common.xml aktiviert:

<config>
  ...
  <use-nanny>true</use-nanny>
</config>

Durch diese Einstellung wenden ifup und ifreload eine Richtlinie mit der effektiven Konfiguration auf den Daemon an; anschließend führt nanny die Konfiguration von wicked aus und sorgt so für die Hotplug-Unterstützung. Der Daemon wartet im Hintergrund auf Ereignisse oder Änderungen (beispielsweise auf neue Geräte oder auf die Erkennung eines Trägers).

19.5.1.4 Starten von mehreren Schnittstellen #

Bei Bonds und Bridges ist es unter Umständen sinnvoll, die gesamte Gerätetopologie in einer einzigen Datei zu definieren (ifcfg-bondX) und alle Geräte in einem Arbeitsgang hochzufahren. Mit wicked können Sie dann die Schnittstellennamen der obersten Ebene (für den Bridge oder den Bond) angeben und so die gesamte Konfiguration hochfahren:

wicked ifup br0

Dieser Befehl richtet automatisch die Bridge und ihre Abhängigkeiten in der richtigen Reihenfolge ein, ohne dass die Abhängigkeiten (Ports usw.) getrennt aufgeführt werden müssten.

So fahren Sie mehrere Schnittstellen mit einem einzigen Befehl hoch:

wicked ifup bond0 br0 br1 br2

Oder auch alle Schnittstellen:

wicked ifup all

19.5.1.5 Verwenden von Tunneln mit Wicked #

Wenn Sie Tunnels mit Wicked verwenden müssen, wird TUNNEL_DEVICE hierfür verwendet. Die Option erlaubt es, einen optionalen Gerätenamen anzugeben, um den Tunnel an das Gerät zu binden. Die getunnelten Pakete werden nur über dieses Gerät geleitet.

Weitere Informationen erhalten Sie mit dem Kommando man 5 ifcfg-tunnel.

19.5.1.6 Einarbeiten von inkrementellen Änderungen #

Bei wicked müssen Sie eine Schnittstelle zum Neukonfigurieren nicht vollständig herunterfahren (sofern dies nicht durch den Kernel erforderlich ist). Wenn Sie beispielsweise eine weitere IP-Adresse oder Route für eine statisch konfigurierte Netzwerkschnittstelle hinzufügen möchten, tragen Sie die IP-Adresse in die Schnittstellendefinition ein und führen Sie den „ifup“-Vorgang erneut aus. Der Server aktualisiert lediglich die geänderten Einstellungen. Dies gilt für Optionen auf Verbindungsebene (z. B. die MTU oder die MAC-Adresse des Geräts) sowie auf Netzwerkebene, beispielsweise die Adressen, Routen oder gar der Adresskonfigurationsmodus (z. B. bei der Umstellung einer statischen Konfiguration auf DHCP).

Bei virtuellen Schnittstellen, in denen mehrere physische Geräte miteinander verbunden werden (z. B. Bridges oder Bonds), ist die Vorgehensweise naturgemäß komplizierter. Bei Bond-Geräten können bestimmte Parameter nicht geändert werden, wenn das Gerät eingeschaltet ist. Ansonsten würde ein Fehler auftreten.

Als Alternative können Sie stattdessen untergeordnete Geräte des Bonds oder der Bridge hinzufügen oder entfernen oder auch die primäre Schnittstelle eines Bonds festlegen.

19.5.1.7 wicked-Erweiterungen: Adresskonfiguration #

wicked lässt sich mithilfe von Shell-Skripten erweitern. Diese Erweiterungen können in der Datei config.xml definiert werden.

Derzeit werden mehrere Erweiterungsklassen unterstützt:

Verbindungskonfiguration: Skripte zum Einrichten der Verbindungsschicht eines Geräts gemäß der Konfiguration, die vom Client bereitgestellt wurde, sowie zum Entfernen dieser Schicht.
Adresskonfiguration: Skripte zum Verwalten der Konfiguration einer Geräteadresse. Die Adresskonfiguration und DHCP werden in der Regel von wicked selbst verwaltet, können jedoch auch in Form von Erweiterungen implementiert werden.
Firewall-Erweiterung: Mit diesen Skripten werden Firewall-Regeln angewendet.

Erweiterungen umfassen im Normalfall ein Start- und Stopp-Kommando, eine optionale „pid-Datei“ sowie eine Reihe von Umgebungsvariablen, die an das Skript übergeben werden.

In etc/server.xml finden Sie ein Beispiel für eine Firewall-Erweiterung:

<dbus-service interface="org.opensuse.Network.Firewall">
 <action name="firewallUp"   command="/etc/wicked/extensions/firewall up"/>
 <action name="firewallDown" command="/etc/wicked/extensions/firewall down"/>

 <!-- default environment for all calls to this extension script -->
 <putenv name="WICKED_OBJECT_PATH" value="$object-path"/>
 <putenv name="WICKED_INTERFACE_NAME" value="$property:name"/>
 <putenv name="WICKED_INTERFACE_INDEX" value="$property:index"/>
</dbus-service>

Die Erweiterung wird an den Tag <dbus-service> angehängt und definiert auszuführende Kommandos für die Aktionen dieser Schnittstelle. In der Deklaration können außerdem Umgebungsvariablen, die an die Aktion übergeben werden sollen, definiert und initialisiert werden.

19.5.1.8 Wicked-Erweiterungen: Konfigurationsdateien #

Auch die Arbeit mit Konfigurationsdateien kann mithilfe von Skripten erweitert werden. DNS-Aktualisierungen über Leases werden beispielsweise letztlich von dem Skript extensions/resolver verarbeitet, dessen Verhalten in server.xml konfiguriert ist:

<system-updater name="resolver">
 <action name="backup" command="/etc/wicked/extensions/resolver backup"/>
 <action name="restore" command="/etc/wicked/extensions/resolver restore"/>
 <action name="install" command="/etc/wicked/extensions/resolver install"/>
 <action name="remove" command="/etc/wicked/extensions/resolver remove"/>
</system-updater>

Sobald eine Aktualisierung in wicked eingeht, wird das Lease durch die Systemaktualisierungsroutinen analysiert, und die entsprechenden Kommandos (backup, install usw.) im Auflöserskript werden aufgerufen. Hiermit werden wiederum die DNS-Einstellungen über /sbin/netconfig konfiguriert; als Fallback muss die Datei /run/netconfig/resolv.conf manuell geschrieben werden.

19.5.2 Konfigurationsdateien #

Dieser Abschnitt bietet einen Überblick über die Netzwerkkonfigurationsdateien und erklärt ihren Zweck sowie das verwendete Format.

19.5.2.1 `/etc/wicked/common.xml` #

Die Datei /etc/wicked/common.xml enthält allgemeine Definitionen, die von allen Anwendungen verwendet werden sollten. Sie wird von den anderen Konfigurationsdateien in diesem Verzeichnis als Quelle verwendet/eingeschlossen. Obwohl Sie diese Datei zum Aktivieren der Fehlerbehebung für alle wicked-Komponenten verwenden können, empfehlen wir, hierfür die Datei /etc/wicked/local.xml zu verwenden. Nach dem Anwenden von Wartungsaktualisierungen können Ihre Änderungen verloren gehen, da die Datei /etc/wicked/common.xml möglicherweise überschrieben wird. Die Datei /etc/wicked/common.xml enthält /etc/wicked/local.xml in der Standardinstallation, daher müssen Sie in der Regel /etc/wicked/common.xml nicht bearbeiten.

Falls Sie nanny deaktivieren möchten, indem Sie für <use-nanny> den Wert false festlegen, starten Sie den Dienst wickedd.service neu und führen Sie anschließend das folgende Kommando aus, um alle Konfigurationen und Richtlinien anzuwenden:

tux > sudo wicked ifup all

Anmerkung: Konfigurationsdateien

Die Programme wickedd, wicked oder nanny versuchen, die Datei /etc/wicked/common.xml zu lesen, wenn sie über keine eigene Konfigurationsdatei verfügen.

19.5.2.2 `/etc/wicked/server.xml` #

Die Datei /etc/wicked/server.xml wird vom Serverprozess wickedd beim Starten gelesen. Die Datei speichert Erweiterungen zu der Datei /etc/wicked/common.xml. Zusätzlich konfiguriert diese Datei die Handhabung von Resolvern und den Empfang von Informationen von addrconf-Supplicants, z. B. DHCP.

Es wird empfohlen, erforderliche Änderungen an dieser Datei der separaten Datei /etc/wicked/server-local.xml hinzuzufügen. Diese wird von /etc/wicked/server.xml eingeschlossen. Durch Verwenden einer separaten Datei vermeiden Sie das Überschrieben Ihrer Änderungen bei Wartungsaktualisierungen.

19.5.2.3 `/etc/wicked/client.xml` #

Die Datei /etc/wicked/client.xml wird vom Kommando wicked verwendet. Die Datei gibt den Speicherort eines Skripts an, der beim Ermitteln von Geräten, die von ibft verwaltet werden, verwendet wird. Außerdem konfiguriert die Datei die Speicherpositionen der Konfigurationen von Netzwerkschnittstellen.

Es wird empfohlen, erforderliche Änderungen an dieser Datei in der separaten Datei /etc/wicked/client-local.xml hinzuzufügen. Diese wird von /etc/wicked/server.xml eingeschlossen. Durch Verwenden einer separaten Datei vermeiden Sie das Überschrieben Ihrer Änderungen bei Wartungsaktualisierungen.

19.5.2.4 `/etc/wicked/nanny.xml` #

Die Datei /etc/wicked/nanny.xml konfiguriert die Typen der Verbindungsschichten. Es wird empfohlen, spezielle Konfigurationen der separaten Datei /etc/wicked/nanny-local.xml hinzuzufügen, um den Verlust der Änderungen bei Wartungsaktualisierungen zu vermeiden.

19.5.2.5 `/etc/sysconfig/network/ifcfg-*` #

Diese Dateien enthalten die herkömmlichen Konfigurationsdaten für Netzwerkschnittstellen.

Anmerkung: wicked und ifcfg-*-Dateien

wicked liest diese Dateien, wenn Sie das Präfix compat: angeben. Gemäß der Standardkonfiguration von SUSE Linux Enterprise Server in /etc/wicked/client.xml berücksichtigt wicked diese Dateien noch vor den XML-Konfigurationsdateien in /etc/wicked/ifconfig.

Der Schalter --ifconfig wird überwiegend zu Testzwecken verwendet. Wenn dieser Schalter angegeben ist, werden die in /etc/wicked/ifconfig definierten standardmäßigen Konfigurationsquellen nicht angewendet.

Die ifcfg-*-Dateien enthalten Informationen wie den Startmodus und die IP-Adresse. Mögliche Parameter sind auf der man-Seite für den Befehl ifup beschrieben. Wenn eine allgemeine Einstellung nur für eine bestimmte Bedienoberfläche verwendet werden soll, können außerdem alle Variablen aus den Dateien dhcp und wireless in den ifcfg-*-Dateien verwendet werden. Jedoch sind die meisten /etc/sysconfig/network/config-Variablen global und lassen sich in ifcfg-Dateien nicht überschreiben. Beispielsweise sind die Variablen NETCONFIG_* global.

Weitere Informationen zum Konfigurieren der macvlan- und der macvtab-Schnittstelle finden Sie auf den man-Seiten zu ifcfg-macvlan und ifcfg-macvtap. Für eine macvlan-Schnittstelle benötigen Sie beispielsweise eine ifcfg-macvlan0-Datei mit den folgenden Einstellungen:

STARTMODE='auto'
MACVLAN_DEVICE='eth0'
#MACVLAN_MODE='vepa'
#LLADDR=02:03:04:05:06:aa

Informationen zu ifcfg.template finden Sie unter Abschnitt 19.5.2.6, „/etc/sysconfig/network/config, /etc/sysconfig/network/dhcp und /etc/sysconfig/network/wireless“.

IBM Z IBM Z unterstützt USB nicht. Die Namen der Schnittstellendateien und Netzwerkaliasse enthalten IBM Z-spezifische Elemente wie qeth.

19.5.2.6 `/etc/sysconfig/network/config`, `/etc/sysconfig/network/dhcp` und `/etc/sysconfig/network/wireless` #

Die Datei config enthält allgemeine Einstellungen für das Verhalten von ifup, ifdown und ifstatus. dhcp enthält Einstellungen für DHCP und wireless für WLAN-Karten. Die Variablen in allen drei Konfigurationsdateien sind kommentiert. Einige der Variablen von /etc/sysconfig/network/config können auch in ifcfg-*-Dateien verwendet werden, wo sie eine höhere Priorität erhalten. Die Datei /etc/sysconfig/network/ifcfg.template listet Variablen auf, die mit einer Reichweite pro Schnittstelle angegeben werden können. Jedoch sind die meisten /etc/sysconfig/network/config-Variablen global und lassen sich in ifcfg-Dateien nicht überschreiben. Beispielsweise sind die Variablen NETWORKMANAGER oder NETCONFIG_* global.

Anmerkung: Verwenden von DHCPv6

In SUSE Linux Enterprise 11 konnte DHCPv6 selbst auf Netzwerken genutzt werden, deren IPv6-RAs (Router Advertisements) nicht fehlerfrei konfiguriert waren. Ab SUSE Linux Enterprise 12 verlangt DHCPv6, dass mindestens ein Router im Netzwerk RAs aussendet, aus denen hervorgeht, dass das Netzwerk über DHCPv6 verwaltet wird.

In Netzwerken, in denen der Router nicht ordnungsgemäß konfiguriert werden kann, können Sie dieses Verhalten mit einer ifcfg-Option außer Kraft setzen. Geben Sie hierzu DHCLIENT6_MODE='managed' in der ifcfg-Datei an. Alternativ wenden Sie diese Behelfslösung mit einem Bootparameter im Installationssystem an:

ifcfg=eth0=dhcp6,DHCLIENT6_MODE=managed

19.5.2.7 `/etc/sysconfig/network/routes` und `/etc/sysconfig/network/ifroute-*` #

Das statische Routing von TCP/IP-Paketen wird mit den Dateien /etc/sysconfig/network/routes und /etc/sysconfig/network/ifroute-* bestimmt. Alle statischen Routen, die für verschiedene Systemaufgaben benötigt werden, können in /etc/sysconfig/network/routes angegeben werden: Routen zu einem Host, Routen zu einem Host über Gateways und Routen zu einem Netzwerk. Definieren Sie für jede Schnittstelle, die individuelles Routing benötigt, eine zusätzliche Konfigurationsdatei: /etc/sysconfig/network/ifroute-*. Ersetzen Sie das Platzhalterzeichen (*) durch den Namen der Schnittstelle. Die Einträge in der Routing-Konfigurationsdatei sehen wie folgt aus:

# Destination     Gateway           Netmask            Interface  Options

Das Routenziel steht in der ersten Spalte. Diese Spalte kann die IP-Adresse eines Netzwerks oder Hosts bzw. (im Fall von erreichbaren Nameservern) den voll qualifizierten Netzwerk- oder Hostnamen enthalten. Die Netzwerkadresse muss in der CIDR-Notation (Adresse mit entsprechender Routing-Präfixlänge) angegeben werden, z. B. 10.10.0.0/16 für IPv4-Routen oder fc00::/7 für IPv6-Routen. Das Schlüsselwort default gibt an, dass die Route des Standard-Gateways in derselben Adressfamilie wie der Gateway ist. Bei Geräten ohne Gateway verwenden Sie die expliziten Ziele 0.0.0.0/0 oder ::/0.

Die zweite Spalte enthält das Standard-Gateway oder ein Gateway, über das der Zugriff auf einen Host oder ein Netzwerk erfolgt.

Die dritte Spalte wird nicht mehr verwendet; hier wurde bislang die IPv4-Netzmaske des Ziels angegeben. Für IPv6-Routen, für die Standardroute oder bei Verwendung einer Präfixlänge (CIDR-Notation) in der ersten Spalte tragen Sie hier einen Strich (-) ein.

Die vierte Spalte enthält den Namen der Schnittstelle. Wenn Sie in dieser Spalte nur einen Strich (-) statt eines Namens angeben, kann dies zu unerwünschtem Verhalten in /etc/sysconfig/network/routes führen. Weitere Informationen finden Sie auf der man-Seite zu routes.

In einer (optionalen) fünften Spalte können Sie besondere Optionen angeben. Weitere Informationen finden Sie auf der man-Seite zu routes.

Beispiel 19.5: Gebräuchliche Netzwerkschnittstellen und Beispiele für statische Routen #

# --- IPv4 routes in CIDR prefix notation:
# Destination     [Gateway]         -                  Interface
127.0.0.0/8       -                 -                  lo
204.127.235.0/24  -                 -                  eth0
default           204.127.235.41    -                  eth0
207.68.156.51/32  207.68.145.45     -                  eth1
192.168.0.0/16    207.68.156.51     -                  eth1

# --- IPv4 routes in deprecated netmask notation"
# Destination     [Dummy/Gateway]   Netmask            Interface
#
127.0.0.0         0.0.0.0           255.255.255.0      lo
204.127.235.0     0.0.0.0           255.255.255.0      eth0
default           204.127.235.41    0.0.0.0            eth0
207.68.156.51     207.68.145.45     255.255.255.255    eth1
192.168.0.0       207.68.156.51     255.255.0.0        eth1

# --- IPv6 routes are always using CIDR notation:
# Destination     [Gateway]                -           Interface
2001:DB8:100::/64 -                        -           eth0
2001:DB8:100::/32 fe80::216:3eff:fe6d:c042 -           eth0

19.5.2.8 `/var/run/netconfig/resolv.conf` #

In /var/run/netconfig/resolv.conf wird die Domäne angegeben, zu der der Host gehört (Schlüsselwort search). Mit der Option search können Sie bis zu sechs Domänen mit insgesamt 256 Zeichen angeben. Bei der Auflösung eines Namens, der nicht voll qualifiziert ist, wird versucht, einen solchen zu generieren, indem die einzelnen search-Einträge angehängt werden. Mit der Option nameserver können Sie bis zu drei Nameserver angeben (jeweils in einer eigenen Zeile). Kommentare sind mit einer Raute (#) oder einem Semikolon (;) gekennzeichnet. Ein Beispiel finden Sie in Beispiel 19.6, „/var/run/netconfig/resolv.conf“.

Jedoch sollte /etc/resolv.conf nicht manuell bearbeitet werden. Es wird vom Skript netconfig generiert und stellt einen symbolischen Link zu /run/netconfig/resolv.conf dar. Um die statische DNS-Konfiguration ohne YaST zu definieren, bearbeiten Sie die entsprechenden Variablen in der Datei /etc/sysconfig/network/config manuell:

NETCONFIG_DNS_STATIC_SEARCHLIST

Liste der DNS-Domänennamen, die für die Suche nach Hostname verwendet wird

NETCONFIG_DNS_STATIC_SERVERS

Liste der IP-Adressen des Nameservers, die für die Suche nach Hostname verwendet wird

NETCONFIG_DNS_FORWARDER

Name des zu konfigurierenden DNS-Forwarders, beispielsweise bind oder resolver

NETCONFIG_DNS_RESOLVER_OPTIONS

Beliebige Optionen, die in /var/run/netconfig/resolv.conf geschrieben werden, beispielsweise:

debug attempts:1 timeout:10

Weitere Informationen finden Sie auf der man-Seite zu resolv.conf.

NETCONFIG_DNS_RESOLVER_SORTLIST

Liste mit bis zu 10 Einträgen, beispielsweise:

130.155.160.0/255.255.240.0 130.155.0.0

Weitere Informationen finden Sie auf der man-Seite zu resolv.conf.

Zum Deaktivieren der DNS-Konfiguration mit netconfig setzen Sie NETCONFIG_DNS_POLICY=''. Weitere Informationen zu netconfig finden Sie auf der man-Seite zu netconfig(8) (man 8 netconfig).

Beispiel 19.6: /var/run/netconfig/resolv.conf #

# Our domain
search example.com
#
# We use dns.example.com (192.168.1.116) as nameserver
nameserver 192.168.1.116

19.5.2.9 `/sbin/netconfig` #

netconfig ist ein modulares Tool zum Verwalten zusätzlicher Netzwerkkonfigurationseinstellungen. Es führt statisch definierte Einstellungen mit Einstellungen zusammen, die von automatischen Konfigurationsmechanismen wie DHCP oder PPP gemäß einer vordefinierten Richtlinie bereitgestellt wurden. Die erforderlichen Änderungen werden dem System zugewiesen, indem die netconfig-Module aufgerufen werden, die für das Ändern einer Konfigurationsdatei und den Neustart eines Service oder eine ähnliche Aktion verantwortlich sind.

netconfig erkennt drei Hauptaktionen. Die Kommandos netconfig modify und netconfig remove werden von Daemons wie DHCP oder PPP verwendet, um Einstellungen für netconfig hinzuzufügen oder zu entfernen. Nur das Kommando netconfig update steht dem Benutzer zur Verfügung:

modify: Das Kommando netconfig modify ändert die aktuelle Schnittstellen- und Service-spezifischen dynamischen Einstellungen und aktualisiert die Netzwerkkonfiguration. Netconfig liest Einstellungen aus der Standardeingabe oder einer Datei, die mit der Option --lease-file DATEINAME angegeben wurde, und speichert sie intern bis zu einem System-Reboot oder der nächsten Änderungs- oder Löschaktion). Bereits vorhandene Einstellungen für dieselbe Schnittstellen- und Service-Kombination werden überschrieben. Die Schnittstelle wird durch den Parameter -i SCHNITTSTELLENNAME angegeben. Der Service wird durch den Parameter -s SERVICENAME angegeben.
Entfernen: Das Kommando netconfig remove entfernt die dynamischen Einstellungen, die von einer Bearbeitungsaktion für die angegebene Schnittstellen- und Service-Kombination bereitgestellt wurden, und aktualisiert die Netzwerkkonfiguration. Die Schnittstelle wird durch den Parameter -i SCHNITTSTELLENNAME angegeben. Der Service wird durch den Parameter -s SERVICENAME angegeben.
Aktualisieren: Das Kommando netconfig update aktualisiert die Netzwerkkonfiguration mit den aktuellen Einstellungen. Dies ist nützlich, wenn sich die Richtlinie oder die statische Konfiguration geändert hat. Verwenden Sie den Parameter -m MODULTYP, wenn nur ein angegebener Dienst aktualisiert werden soll (dns,nis oder ntp).

Die Einstellungen für die netconfig-Richtlinie und die statische Konfiguration werden entweder manuell oder mithilfe von YaST in der Datei /etc/sysconfig/network/config definiert. Die dynamischen Konfigurationseinstellungen von Tools zur automatischen Konfiguration wie DHCP oder PPP werden von diesen Tools mit den Aktionen netconfig modify und netconfig remove direkt bereitgestellt. Wenn NetworkManager aktiviert ist, verwendet netconfig (im Richtlinienmodus auto) nur NetworkManager-Einstellungen und ignoriert Einstellungen von allen anderen Schnittstellen, die mit der traditionellen ifup-Methode konfiguriert wurden. Wenn NetworkManager keine Einstellung liefert, werden als Fallback statische Einstellungen verwendet. Eine gemischte Verwendung von NetworkManager und der wicked-Methode wird nicht unterstützt.

Weitere Informationen über netconfig finden Sie auf man 8 netconfig.

19.5.2.10 `/etc/hosts` #

In dieser Datei werden, wie in Beispiel 19.7, „/etc/hosts“ gezeigt, IP-Adressen zu Hostnamen zugewiesen. Wenn kein Namenserver implementiert ist, müssen alle Hosts, für die IP-Verbindungen eingerichtet werden sollen, hier aufgeführt sein. Geben Sie für jeden Host in die Datei eine Zeile ein, die aus der IP-Adresse, dem voll qualifizierten Hostnamen und dem Hostnamen besteht. Die IP-Adresse muss am Anfang der Zeile stehen und die Einträge müssen durch Leerzeichen und Tabulatoren getrennt werden. Kommentaren wird immer das #-Zeichen vorangestellt.

Beispiel 19.7: /etc/hosts #

127.0.0.1 localhost
192.168.2.100 jupiter.example.com jupiter
192.168.2.101 venus.example.com venus

19.5.2.11 `/etc/networks` #

Hier werden Netzwerknamen in Netzwerkadressen umgesetzt. Das Format ähnelt dem der hosts-Datei, jedoch stehen hier die Netzwerknamen vor den Adressen. Siehe Beispiel 19.8, „/etc/networks“.

Beispiel 19.8: /etc/networks #

loopback     127.0.0.0
localnet     192.168.0.0

19.5.2.12 `/etc/host.conf` #

Das Auflösen von Namen, d. h. das Übersetzen von Host- bzw. Netzwerknamen über die resolver-Bibliothek, wird durch diese Datei gesteuert. Diese Datei wird nur für Programme verwendet, die mit libc4 oder libc5 gelinkt sind. Weitere Informationen zu aktuellen glibc-Programmen finden Sie in den Einstellungen in /etc/nsswitch.conf. Jeder Parameter muss immer auf einer separaten Zeile eingegeben werden. Kommentaren wird ein #-Zeichen vorangestellt. Tabelle 19.2, „Parameter für /etc/host.conf“ zeigt die verfügbaren Parameter. Ein Beispiel für /etc/host.conf wird in Beispiel 19.9, „/etc/host.conf“ gezeigt.

Tabelle 19.2: Parameter für /etc/host.conf #

order hosts, bind	Legt fest, in welcher Reihenfolge die Dienste zum Auflösen eines Namens angesprochen werden sollen. Mögliche Argumente (getrennt durch Leerzeichen oder Kommas):
	Hosts: Sucht die `/etc/hosts`-Datei
	bind: Greift auf einen Namenserver zu
	nis: Verwendet NIS
multi on/off	Legt fest, ob ein in `/etc/hosts` eingegebener Host mehrere IP-Adressen haben kann.
nospoof on spoofalert on/off	Diese Parameter beeinflussen das spoofing des Namenservers, haben aber keinen Einfluss auf die Netzwerkkonfiguration.
trim Domänenname	Der angegebene Domänenname wird vor dem Auflösen des Hostnamens von diesem abgeschnitten (insofern der Hostname diesen Domänennamen enthält). Diese Option ist nur dann von Nutzen, wenn in der Datei `/etc/hosts` nur Namen aus der lokalen Domäne stehen, diese aber auch mit angehängtem Domänennamen erkannt werden sollen.

Beispiel 19.9: /etc/host.conf #

# We have named running
order hosts bind
# Allow multiple address
multi on

19.5.2.13 `/etc/nsswitch.conf` #

Mit der GNU C Library 2.0 wurde Name Service Switch (NSS) eingeführt. Weitere Informationen hierzu finden Sie auf der man-Seite für nsswitch.conf(5) und im Dokument The GNU C Library Reference Manual.

In der Datei /etc/nsswitch.conf wird festgelegt, in welcher Reihenfolge bestimmte Informationen abgefragt werden. Ein Beispiel für nsswitch.conf ist in Beispiel 19.10, „/etc/nsswitch.conf“ dargestellt. Kommentaren werden #-Zeichen vorangestellt. Der Eintrag unter der hosts-Datenbank bedeutet, dass Anfragen über DNS an /etc/hosts (files) gehen (siehe Kapitel 31, Domain Name System (DNS)).

Beispiel 19.10: /etc/nsswitch.conf #

passwd:     compat
group:      compat

hosts:      files dns
networks:   files dns

services:   db files
protocols:  db files
rpc:        files
ethers:     files
netmasks:   files
netgroup:   files nis
publickey:  files

bootparams: files
automount:  files nis
aliases:    files nis
shadow:     compat

Die über NSS verfügbaren „Datenbanken“ sind in Tabelle 19.3, „Über /etc/nsswitch.conf verfügbare Datenbanken“ aufgelistet. Die Konfigurationsoptionen für NSS-Datenbanken sind in Tabelle 19.4, „Konfigurationsoptionen für NSS-„Datenbanken““ aufgelistet.

Tabelle 19.3: Über /etc/nsswitch.conf verfügbare Datenbanken #

`aliases`	Mail-Aliasse, die von `sendmail` implementiert werden. Siehe `man5 aliases`.
`ethers`	Ethernet-Adressen
`Netzmasken`	Liste von Netzwerken und ihrer Teilnetzmasken. Wird nur benötigt, wenn Sie Subnetting nutzen.
`Gruppe`	Benutzergruppen, die von `getgrent` verwendet werden. Weitere Informationen hierzu finden Sie auch auf der man-Seite für den Befehl `group`.
`hosts`	Hostnamen und IP-Adressen, die von `gethostbyname` und ähnlichen Funktionen verwendet werden.
`netgroup`	Im Netzwerk gültige Host- und Benutzerlisten zum Steuern von Zugriffsberechtigungen. Weitere Informationen hierzu finden Sie auf der man-Seite für `netgroup(5)`.
`networks`	Netzwerknamen und -adressen, die von `getnetent` verwendet werden.
`publickey`	Öffentliche und geheime Schlüssel für Secure_RPC, verwendet durch NFS and NIS+.
`passwd`	Benutzerpasswörter, die von `getpwent` verwendet werden. Weitere Informationen hierzu finden Sie auf der man-Seite `passwd(5)`.
`protocols`	Netzwerkprotokolle, die von `getprotoent` verwendet werden. Weitere Informationen hierzu finden Sie auf der man-Seite für `protocols(5)`.
`rpc`	Remote Procedure Call-Namen und -Adressen, die von `getrpcbyname` und ähnlichen Funktionen verwendet werden.
`services`	Netzwerkdienste, die von `getservent` verwendet werden.
`shadow`	Shadow-Passwörter der Benutzer, die von `getspnam` verwendet werden. Weitere Informationen hierzu finden Sie auf der man-Seite für `shadow(5)`.

Tabelle 19.4: Konfigurationsoptionen für NSS-„Datenbanken“ #

`Dateien`	Direkter Dateizugriff, z. B. `/etc/aliases`
`db`	Zugriff über eine Datenbank
`nis`, `nisplus`	NIS, siehe auch Chapter 3, Using NIS
`dns`	Nur bei `hosts` und `networks` als Erweiterung verwendbar
`compat`	Nur bei `passwd`, `shadow` und `group` als Erweiterung verwendbar

19.5.2.14 `/etc/nscd.conf` #

Mit dieser Datei wird nscd (Name Service Cache Daemon) konfiguriert. Weitere Informationen hierzu finden Sie auf den man-Seiten nscd(8) und nscd.conf(5). Standardmäßig werden die Systemeinträge von passwd, groups und hosts von nscd gecacht. Dies ist für die Leistung von Verzeichnisdiensten wie NIS and LDAP wichtig, denn andernfalls muss für jeden Zugriff auf Namen, Gruppen oder Hosts die Netzwerkverbindung verwendet werden.

Wenn das Caching für passwd aktiviert wird, dauert es in der Regel 15 Sekunden, bis ein neu angelegter lokaler Benutzer dem System bekannt ist. Zum Verkürzen dieser Wartezeit starten Sie nscd wie folgt neu:

tux > sudo systemctl restart nscd

19.5.2.15 `/etc/HOSTNAME` #

/etc/HOSTNAME enthält den vollständigen Hostnamen (FQHN). Der vollständige Hostname besteht aus dem eigentlichen Hostnamen und der Domäne. Die Datei darf nur eine einzige Zeile enthalten (in der der Hostname angegeben ist). Diese Angabe wird beim Booten des Rechners gelesen.

19.5.3 Testen Sie die Konfiguration. #

Bevor Sie Ihre Konfiguration in den Konfigurationsdateien speichern, können Sie sie testen. Zum Einrichten einer Testkonfiguration verwenden Sie den Befehl ip. Zum Testen der Verbindung verwenden Sie den Befehl ping.

Das Kommando ip ändert die Netzwerkkonfiguration direkt, ohne sie in der Konfigurationsdatei zu speichern. Wenn Sie die Konfiguration nicht in die korrekten Konfigurationsdateien eingeben, geht die geänderte Netzwerkkonfiguration nach dem Neustart verloren.

Anmerkung: ifconfig und route sind veraltet

Die Werkzeuge ifconfig und route sind veraltet. Verwenden Sie stattdessen ip. Bei ifconfig sind die Schnittstellennamen beispielsweise auf 9 Zeichen begrenzt.

19.5.3.1 Konfigurieren einer Netzwerkschnittstelle mit `ip` #

ip ist ein Werkzeug zum Anzeigen und Konfigurieren von Netzwerkgeräten, Richtlinien-Routing und Tunneln.

ip ist ein sehr komplexes Werkzeug. Seine allgemeine Syntax ist ip OPTIONS OBJECT COMMAND. Sie können mit folgenden Objekten arbeiten:

Verbindung: Dieses Objekt stellt ein Netzwerkgerät dar.
Adresse: Dieses Objekt stellt die IP-Adresse des Geräts dar.
Nachbar: Dieses Objekt stellt einen ARP- oder NDISC-Cache-Eintrag dar.
route: Dieses Objekt stellt den Routing-Tabelleneintrag dar.
Regel: Dieses Objekt stellt eine Regel in der Routing-Richtlinien-Datenbank dar.
maddress: Dieses Objekt stellt eine Multicast-Adresse dar.
mroute: Dieses Objekt stellt einen Multicast-Routing-Cache-Eintrag dar.
tunnel: Dieses Objekt stellt einen Tunnel über IP dar.

Wird kein Kommando angegeben, wird das Standardkommando verwendet (normalerweise list).

Ändern Sie den Gerätestatus mit dem Befehl:

tux > sudo ip link set DEV_NAME

Wenn Sie beispielsweise das Gerät eth0 deaktivieren möchten, geben Sie Folgendes ein:

tux > sudo ip link set eth0 down

Zur erneuten Aktivierung verwenden Sie

tux > sudo ip link set eth0 up

Tipp: Trennen des NIC-Geräts

Wenn Sie ein Gerät mit

tux > sudo ip link set DEV_NAME down

deaktivieren, wird die Netzwerkschnittstelle auf einer Softwareebene deaktiviert.

Wenn Sie simulieren möchten, dass die Verbindung getrennt wird, so als ob ein Ethernetkabel gezogen oder der Verbindungsschalter ausgeschaltet wird, führen Sie folgendes Kommando aus:

tux > sudo ip link set DEV_NAME carrier off

Beispiel: Mit ip link set DEV_NAME down werden alle Routen mit DEV_NAME verlassen, bei ip link set DEV carrier off ist dies nicht der Fall. Beachten Sie, dass carrier off vom Netzwerkgerätetreiber unterstützt werden muss.

Führen Sie zur erneuten Verbindung mit dem physischen Netzwerk folgendes Kommando aus:

tux > sudo ip link set DEV_NAME carrier on

Nach dem Aktivieren eines Geräts können Sie es konfigurieren. Die IP-Adresse legen Sie fest mit

tux > sudo ip addr add IP_ADDRESS + dev DEV_NAME

Wenn Sie beispielsweise die Adresse der Schnittstelle eth0 auf 192.168.12.154/30 mit standardmäßigem Broadcast (Option brd) setzen möchten, geben Sie Folgendes ein:

tux > sudo ip addr add 192.168.12.154/30 brd + dev eth0

Damit die Verbindung funktioniert, müssen Sie außerdem das Standard-Gateway konfigurieren. Geben Sie zum Festlegen eines Gateways für Ihr System Folgendes ein:

tux > sudo ip route add default via gateway_ip_address

Zum Anzeigen aller Geräte verwenden Sie

tux > sudo ip link ls

Wenn Sie nur die aktiven Schnittstellen abrufen möchten, verwenden Sie

tux > sudo ip link ls up

Zum Drucken von Schnittstellenstatistiken für ein Gerät geben Sie Folgendes ein:

tux > sudo ip -s link ls DEV_NAME

Zum Anzeigen weiterer nützlicher Informationen, insbesondere über virtuelle Netzwerkgeräte, geben Sie Folgendes ein:

tux > sudo ip -d link ls DEV_NAME

Zur Anzeige der Adressen der Netzwerkschicht (IPv4, IPv6) Ihrer Geräte geben Sie Folgendes ein:

tux > sudo ip addr

In der Ausgabe finden Sie Informationen über die MAC-Adressen Ihrer Geräte. Wenn Sie alle Routen anzeigen möchten, wählen Sie

tux > sudo ip route show

Weitere Informationen zur Verwendung von ip erhalten Sie, indem Sie iphelp eingeben oder die man-Seite man 8 ip aufrufen. Die Option help ist zudem für alle ip-Unterkommandos verfügbar, wie:

tux > sudo ip addr help

Suchen Sie die ip-Manualpage in der Datei /usr/share/doc/packages/iproute2/ip-cref.pdf.

19.5.3.2 Testen einer Verbindung mit „ping“ #

Der ping-Befehl ist das Standardwerkzeug zum Testen, ob eine TCP/IP-Verbindung funktioniert. Er verwendet das ICMP-Protokoll, um ein kleines Datenpaket, das ECHO_REQUEST-Datagram, an den Ziel-Host zu senden. Dabei wird eine sofortige Antwort angefordert. Wenn dies funktioniert, zeigt ping eine entsprechende Meldung an. Dies weist darauf hin, dass die Netzwerkverbindung ordnungsgemäß arbeitet.

ping testet nicht nur die Funktion der Verbindung zwischen zwei Computern, es bietet darüber hinaus grundlegende Informationen zur Qualität der Verbindung. In Beispiel 19.11, „Ausgabe des ping-Befehls“ sehen Sie ein Beispiel der ping-Ausgabe. Die vorletzte Zeile enthält Informationen zur Anzahl der übertragenen Pakete, der verlorenen Pakete und der Gesamtlaufzeit von ping.

Als Ziel können Sie einen Hostnamen oder eine IP-Adresse verwenden, z. B. ping example.com oder ping 192.168.3.100. Das Programm sendet Pakete, bis Sie Strg–C drücken.

Wenn Sie nur die Funktion der Verbindung überprüfen möchten, können Sie die Anzahl der Pakete durch die Option -c beschränken. Wenn Sie die Anzahl beispielsweise auf drei Pakete beschränken möchten, geben Sie ping -c 3 example.com ein.

Beispiel 19.11: Ausgabe des ping-Befehls #

ping -c 3 example.com
PING example.com (192.168.3.100) 56(84) bytes of data.
64 bytes from example.com (192.168.3.100): icmp_seq=1 ttl=49 time=188 ms
64 bytes from example.com (192.168.3.100): icmp_seq=2 ttl=49 time=184 ms
64 bytes from example.com (192.168.3.100): icmp_seq=3 ttl=49 time=183 ms
--- example.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2007ms
rtt min/avg/max/mdev = 183.417/185.447/188.259/2.052 ms

Das Standardintervall zwischen zwei Paketen beträgt eine Sekunde. Zum Ändern des Intervalls bietet das ping-Kommando die Option -i. Wenn beispielsweise das Ping-Intervall auf zehn Sekunden erhöht werden soll, geben Sie ping -i 10 example.com ein.

In einem System mit mehreren Netzwerkgeräten ist es manchmal nützlich, wenn der ping-Befehl über eine spezifische Schnittstellenadresse gesendet wird. Verwenden Sie hierfür die Option -I mit dem Namen des ausgewählten Geräts. Beispiel: ping -I wlan1 example.com.

Weitere Optionen und Informationen zur Verwendung von ping erhalten Sie, indem Sie ping-h eingeben oder die man-Seite ping (8) aufrufen.

Tipp: Ping-Ermittlung für IPv6-Adressen

Verwenden Sie für IPv6-Adressen das Kommando ping6. Hinweis: Zur Ping-Ermittlung für Link-Local-Adressen müssen Sie die Schnittstelle mit -I angeben. Das folgende Kommando funktioniert, wenn die Adresse über eth1 erreichbar ist:

ping6 -I eth1 fe80::117:21ff:feda:a425

19.5.4 Unit-Dateien und Startskripte #

Neben den beschriebenen Konfigurationsdateien gibt es noch systemd-Unit-Dateien und verschiedene Skripte, die beim Booten des Computers die Netzwerkdienste laden. Diese werden gestartet, wenn das System auf das Ziel multi-user.target umgestellt wird. Eine Beschreibung für einige Unit-Dateien und Skripte finden Sie unter Einige Unit-Dateien und Startskripte für Netzwerkprogramme. Weitere Informationen zu systemd finden Sie unter Kapitel 15, Der Daemon systemd; weitere Informationen zu den systemd-Zielen finden Sie auf der man-Seite zu systemd.special (man systemd.special).

Einige Unit-Dateien und Startskripte für Netzwerkprogramme #

network.target

network.target ist das systemd-Ziel für das Netzwerk, es ist jedoch abhängig von den Einstellungen, die der Systemadministrator angegeben hat.

Weitere Informationen finden Sie im http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/.

multi-user.target

multi-user.target ist das systemd-Ziel für ein Mehrbenutzersystem mit allen erforderlichen Netzwerkdiensten.

rpcbind

Startet das rpcbind-Dienstprogramm, das RPC-Programmnummern in universelle Adressen konvertiert. Es ist für RPC-Dienste wie NFS-Server erforderlich.

ypserv

Startet den NIS-Server.

ypbind

Startet den NIS-Client.

/etc/init.d/nfsserver

Startet den NFS-Server.

/etc/init.d/postfix

Steuert den postfix-Prozess.

19.6 Grundlegende Routereinrichtung #

Ein Router ist ein Netzwerkgerät, das Daten hin und zurück an mehr als ein Netzwerk zustellt und von diesen empfängt (Netzwerkpakete). Ein Router wird häufig zum Verbinden Ihres lokalen Netzwerks mit dem Remote-Netzwerk (Internet) oder zum Verbinden lokaler Netzwerksegmente verwendet. Mit SUSE Linux Enterprise Server können Sie einen Router mit Funktionen wie Network Address Translation (NAT) oder erweiterten Firewalls erstellen.

Im Folgenden sind grundlegende Schritte beschrieben, mit denen Sie SUSE Linux Enterprise Server in einen Router umfunktionieren können.

Aktivieren Sie die Weiterleitung, beispielsweise in der Datei /etc/sysctl.d/50-router.conf aktivieren
```
net.ipv4.conf.all.forwarding = 1
net.ipv6.conf.all.forwarding = 1
```
Stellen Sie dann ein statisches IPv4- und IPv6-IP-Setup für die Schnittstellen bereit. Durch das Aktivieren der Weiterleitung werden mehrere Mechanismen deaktiviert. Beispielsweise akzeptiert IPv6 keine IPv6-RAs (Router Advertisements) mehr, wodurch ebenfalls die Erstellung einer Standardroute vermieden wird.
In vielen Situationen, beispielsweise wenn Sie über mehr als eine Schnittstelle auf das gleiche Netzwerk zugreifen können oder wenn in der Regel VPN verwendet wird (und sich bereits auf „normalen Multihome-Hosts“ befindet), müssen Sie den Reverse-Path-Filter für IPv4 deaktivieren (diese Funktion ist derzeit für IPv6 nicht vorhanden):
```
net.ipv4.conf.all.rp_filter = 0
```
Stattdessen ist auch das Filtern mit Firewall-Einstellungen möglich.
Um ein IPv6-RA zu akzeptieren (vom Router auf eine externe, Uplink- oder ISP-Schnittstelle) und wieder eine IPv6-Standardroute (oder auch eine speziellere Route) zu erstellen, legen Sie Folgendes fest:
```
net.ipv6.conf.${ifname}.accept_ra = 2
net.ipv6.conf.${ifname}.autoconf = 0
```
(Hinweis: „eth0.42“ muss in einem durch Punkte getrennten sysfs-Pfad als eth0/42 angegeben werden.)

Weitere Beschreibungen zum Routerverhalten und zu Weiterleitungsabhängigkeiten sind unter https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt zu finden.

Um IPv6 auf Ihren internen (DMZ-)Schnittstellen bereitzustellen und den eigenen Router als IPv6-Router bekanntzugeben sowie „autoconf“ der Netzwerke für die Clients auszuführen, installieren und konfigurieren Sie radvd in der Datei /etc/radvd.conf. Beispiel:

interface eth0
{
    IgnoreIfMissing on;         # do not fail if interface missed

    AdvSendAdvert on;           # enable sending RAs
    AdvManagedFlag on;          # IPv6 addresses managed via DHCPv6
    AdvOtherConfigFlag on;      # DNS, NTP... only via DHCPv6

    AdvDefaultLifetime 3600;    # client default route lifetime of 1 hour

    prefix 2001:db8:0:1::/64    # (/64 is default and required for autoconf)
    {
        AdvAutonomous off;         # Disable address autoconf (DHCPv6 only)

        AdvValidLifetime 3600;     # prefix (autoconf addr) is valid 1 h
        AdvPreferredLifetime 1800; # prefix (autoconf addr) is prefered 1/2 h
    }
}

Konfigurieren Sie die Firewall so, dass Datenverkehr aus dem LAN in das WAN mit NAT maskiert („Masquerading“) und eingehender Datenverkehr auf der WAN-Schnittstelle blockiert wird:

tux > sudo firewall-cmd --permanent --zone=external --change-interface=WAN_INTERFACE
tux > sudo firewall-cmd --permanent --zone=external --add-masquerade
tux > sudo firewall-cmd --permanent --zone=internal --change-interface=LAN_INTERFACE
tux > sudo firewall-cmd --reload

19.7 Einrichten von Bonding-Geräten #

Für bestimmte Systeme sind Netzwerkverbindungen erforderlich, die die normalen Anforderungen an die Datensicherheit oder Verfügbarkeit von typischen Ethernet-Geräten übertreffen. In diesen Fällen lassen sich mehrere Ethernet-Geräte zu einem einzigen Bonding-Gerät zusammenschließen.

Die Konfiguration des Bonding-Geräts erfolgt dabei über die Bonding-Moduloptionen. Das Verhalten ergibt sich im wesentlichen aus dem Modus des Bonding-Geräts. Standardmäßig gilt active-backup; wenn das aktive Slave-Gerät ausfällt, wird also ein anderes Slave-Gerät aktiviert. Die folgenden Bonding-Modi sind verfügbar:

0 (balance-rr): Die Pakete werden per Round-Robin von der ersten bis zur letzten verfügbaren Schnittstelle übertragen. Bietet Fehlertoleranz und Lastausgleich.
1 (active-backup): Nur eine Netzwerkschnittstelle ist aktiv. Wenn diese Schnittstelle ausfällt, wird eine andere Schnittstelle aktiv. Dies ist die Standardeinstellung für SUSE Linux Enterprise Server. Bietet Fehlertoleranz.
2 (balance-xor): Der Datenverkehr wird gemäß der folgenden Richtlinie auf alle verfügbaren Schnittstellen aufgeteilt: [(Quell-MAC-Adresse mit XOR mit Ziel-MAC-Adresse XOR Pakettyp-ID) Modulo-Slave-Anzahl] Erfordert Unterstützung durch den Switch. Bietet Fehlertoleranz und Lastausgleich.
3 (broadcast): Der gesamte Datenverkehr wird per Broadcast an alle Schnittstellen übertragen. Erfordert Unterstützung durch den Switch. Bietet Fehlertoleranz.
4 (802.3ad): Aggregiert mehrere Schnittstellen zu einer Gruppe, in der dieselben Geschwindigkeits- und Duplexeinstellungen gelten. Erfordert ethtool-Unterstützung durch die Schnittstellentreiber sowie einen Switch, der die dynamische Link-Aggregation nach IEEE 802.3ad unterstützt und entsprechend konfiguriert ist. Bietet Fehlertoleranz und Lastausgleich.
5 (balance-tlb): Adaptiver Übertragungslastausgleich. Erfordert ethtool-Unterstützung durch die Schnittstellentreiber, jedoch keine Unterstützung durch den Switch. Bietet Fehlertoleranz und Lastausgleich.
6 (balance-alb): Adaptiver Lastausgleich. Erfordert ethtool-Unterstützung durch die Schnittstellentreiber, jedoch keine Unterstützung durch den Switch. Bietet Fehlertoleranz und Lastausgleich.

Eine ausführlichere Beschreibung der Modi finden Sie unter https://www.kernel.org/doc/Documentation/networking/bonding.txt.

Tipp: Bonding und Xen

Der Einsatz von Bonding-Geräten empfiehlt sich nur für Computer, in denen mehrere physische Netzwerkkarten eingebaut sind. Bei den meisten Konstellationen sollten Sie die Bonding-Konfiguration daher lediglich in Dom0 verwenden. Die Bond-Einrichtung in einem VM-Gast-System ist dabei nur dann sinnvoll, wenn dem VM-Gast mehrere Netzwerkkarten zugewiesen sind.

Anmerkung: IBM POWER: Bonding-Modi 5 und 6 (balance-tlb / balance-alb) werden von ibmveth nicht mehr unterstützt

Es besteht ein Konflikt zwischen der tlb/alb-Bonding-Konfiguration und der Power-Firmware. Kurz gesagt, der Bonding-Treiber im tlb/alb-Modus sendet Ethernet-Loopback-Pakete mit den Ursprungs- und Ziel-MAC-Adressen, die als virtuelle Ethernet-MAC-Adressen aufgelistet sind. Diese Pakete werden von der Power-Firmware nicht unterstützt. Daher werden die Bonding-Modi 5 und 6 von ibmveth nicht mehr unterstützt.

Zum Konfigurieren eines Bonding-Geräts gehen Sie wie folgt vor:

Führen Sie YaST › System › Netzwerkeinstellungen aus.
Wählen Sie Hinzufügen und ändern Sie die Einstellung unter Gerätetyp in Bond. Fahren Sie mit Weiter fort.
Geben Sie an, wie dem Bonding-Gerät eine IP-Adresse zugewiesen werden soll. Hierfür stehen drei Methoden zur Auswahl:
- No IP Address (Keine IP-Adresse)
- Dynamic Address (with DHCP or Zeroconf) (Dynamische Adresse (mit DHCP oder Zeroconf))
- Statisch zugewiesene IP-Adresse
Wählen Sie die passende Methode für Ihre Umgebung aus.
Wählen Sie auf dem Karteireiter Bond-Slaves die Ethernet-Geräte aus, die in den Bond aufgenommen werden sollen. Aktivieren Sie hierzu die entsprechenden Kontrollkästchen.
Bearbeiten Sie die Bond-Treiberoptionen und wählen Sie einen Bonding-Modus aus.
Der Parameter miimon=100 muss unter Bond-Treiberoptionen angegeben werden. Ohne diesen Parameter wird die Datenintegrität nicht regelmäßig überprüft.
Klicken Sie auf Weiter, und beenden Sie YaST mit OK. Das Gerät wird erstellt.

19.7.1 Hot-Plugging von Bonding-Slaves #

In bestimmten Netzwerkumgebungen (z. B. High Availability) muss eine Bonding-Slave-Schnittstelle durch eine andere Schnittstelle ersetzt werden. Dieser Fall tritt beispielsweise ein, wenn ein Netzwerkgerät wiederholt ausfällt. Die Lösung ist hier das Hot-Plugging der Bonding-Slaves.

Der Bond wird wie gewohnt konfiguriert (gemäß man 5 ifcfg-bonding), beispielsweise:

ifcfg-bond0
          STARTMODE='auto' # or 'onboot'
          BOOTPROTO='static'
          IPADDR='192.168.0.1/24'
          BONDING_MASTER='yes'
          BONDING_SLAVE_0='eth0'
          BONDING_SLAVE_1='eth1'
          BONDING_MODULE_OPTS='mode=active-backup miimon=100'

Die Slaves werden mit STARTMODE=hotplug und BOOTPROTO=none angegeben:

ifcfg-eth0
          STARTMODE='hotplug'
          BOOTPROTO='none'

ifcfg-eth1
          STARTMODE='hotplug'
          BOOTPROTO='none'

Bei BOOTPROTO=none werden die ethtool-Optionen herangezogen (sofern bereitgestellt), es wird jedoch kein Link zu ifup eth0 eingerichtet. Dies ist darin begründet, dass die Slave-Schnittstelle durch den Bond-Master gesteuert wird.

Bei STARTMODE=hotplug wird die Slave-Schnittstelle dem Bond automatisch zugefügt, wenn diese verfügbar ist.

Die udev-Regeln in /etc/udev/rules.d/70-persistent-net.rules müssen so angepasst werden, dass der Abgleich mit dem Gerät über die Bus-ID (das udev-Schlüsselwort KERNELS entspricht „SysFS BusID“, wie in hwinfo --netcard dargestellt) statt über die MAC-Adresse erfolgt. So ist es möglich, defekte Hardware auszutauschen (eine Netzwerkkarte in demselben Steckplatz, jedoch mit einer anderen MAC), und es treten keine Verwechselungen auf, wenn der Bond die MAC-Adresse aller Slaves ändert.

Beispiel:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
KERNELS=="0000:00:19.0", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth0"

Beim Booten wartet der systemd-Service network.service nicht darauf, dass die Hot-Plug-Slaves einsatzbereit sind, sondern es wird die Bereitschaft des gesamten Bonds abgewartet, wofür mindestens ein verfügbarer Slave erforderlich ist. Wenn eine Slave-Schnittstelle aus dem System entfernt wird (durch Aufheben der Bindung an den NIC-Treiber, durch rmmod des NIC-Treibers oder durch normales PCI-Hot-Plug-Entfernen), so entfernt der Kernel die betreffende Schnittstelle automatisch aus dem Bond. Wird eine neue Karte in das System eingebaut (Austausch der Hardware im Steckplatz), benennt udev diese Karte anhand der Regel für busgestützte permanente Namen in den Namen des Slaves um und ruft ifup für die Karte auf. Mit dem ifup-Aufruf tritt die Karte automatisch in den Bond ein.

19.8 Einrichten von Team-Geräten für Netzwerk-Teaming #

Der Begriff „Link-Aggregation“ ist der allgemeine Begriff zum Beschreiben der Kombination (oder Aggregation) einer Netzwerkverbindung zum Bereitstellen einer logischen Ebene. Manchmal stoßen Sie auf Begriffe wie „Channel-Teaming“, „Ethernet-Bonding“, „Port Truncating“ usw. Dies sind Synonyme des Begriffs und bezeichnen dasselbe Konzept.

Dieses Konzept ist allgemein bekannt als „Bonding“ und wurde ursprünglich in den Linux-Kernel integriert (Informationen zur ursprünglichen Implementierung finden Sie in Abschnitt 19.7, „Einrichten von Bonding-Geräten“). Der Begriff Netzwerk-Teaming wird zum Bezeichnen der neuen Implementierung dieses Konzepts verwendet.

Der Hauptunterschied zwischen Bonding und Netzwerk-Teaming ist der, dass das Teaming eine Reihe an kleinen Kernel-Modulen bereitstellt, die für die Bereitstellung einer Schnittstelle für die teamd-Instanzen verantwortlich sind. Alles andere wird im Userspace verarbeitet. Dies unterscheidet sich von der ursprünglichen Bondings-Implementierung, die alle ihre Funktionen ausschließlich im Kernel enthält. Einen Vergleich finden Sie unter Tabelle 19.5, „Funktionsvergleich zwischen Bonding und Team“.

Tabelle 19.5: Funktionsvergleich zwischen Bonding und Team #

Funktion	Bonding	Team
Broadcast, Round-Robin-TX-Richtlinie	Ja	Ja
Active-Backup-TX-Richtlinie	Ja	Ja
LACP-Unterstützung (802.3ad)	Ja	Ja
Hashbasierte TX-Richtlinie	Ja	Ja
Benutzer kann Hashfunktion festlegen	Nein	Ja
TX-Lastenausgleichsunterstützung	Ja	Ja
TX-Lastenausgleichsunterstützung für LACP	Nein	Ja
Ethtool-Link-Überwachung	Ja	Ja
ARP-Link-Überwachung	Ja	Ja
NS/NA-Link-Überwachung (IPv6)	Nein	Ja
RCU-Sperre in TX-/RX-Pfaden	Nein	Ja
Portpriorität und Stickiness	Nein	Ja
Separate Einrichtung der Link-Überwachung nach Port	Nein	Ja
Einrichtung der Link-Überwachung für mehrere Ports	begrenzt	Ja
VLAN-Unterstützung	Ja	Ja
Stapeln mehrerer Geräte	Ja	Ja
Quelle: http://libteam.org/files/teamdev.pp.pdf

Beide Implementierungen, Bonding und Netzwerk-Teaming, können parallel verwendet werden. Netzwerk-Teaming ist eine Alternative zur bestehenden Bondings-Implementierung. Es ersetzt das Bonding nicht.

Netzwerk-Teaming kann für verschiedene Anwendungsfälle verwendet werden. Die beiden wichtigsten Anwendungsfälle werden später erläutert und umfassen:

Lastausgleich zwischen Netzwerkgeräten.
Failover von einem Netzwerkgerät zu einem anderen, falls eines der Geräte einen Fehler aufweist.

Zurzeit ist kein YaST-Modul vorhanden, dass das Erstellen eines Teaming-Geräts unterstützt. Sie müssen Netzwerk-Teaming manuell konfigurieren. Das allgemeine Verfahren ist unten dargestellt und kann auf alle Netzwerk-Teaming-Konfigurationen angewendet werden:

Vorgehen 19.1: Allgemeines Verfahren #

Stellen Sie sicher, dass alle erforderlichen Pakete installiert sind. Installieren Sie die Pakete libteam-tools, libteamdctl0, und python-libteam.
Erstellen Sie eine Konfigurationsdatei unter /etc/sysconfig/network/. In der Regel ist dies ifcfg-team0. Benötigen Sie mehr als ein Netzwerk-Teaming-Gerät, teilen Sie ihnen aufsteigende Nummern zu.
Diese Konfigurationsdatei enthält mehrere Variablen, die auf den man-Seiten erläutert werden (siehe man ifcfg und man ifcfg-team). Eine Beispielkonfiguration finden Sie im System in der Datei /etc/sysconfig/network/ifcfg.template.
Entfernen Sie die Konfigurationsdatei der Schnittstellen, die für das Teaming-Gerät verwendet werden (in der Regel ifcfg-eth0 und ifcfg-eth1).
Es wird empfohlen, eine Sicherung zu erstellen und beide Dateien zu löschen. Wicked legt die Konfigurationsdateien mit den erforderlichen Parametern für Teaming neu an.
Optional können Sie überprüfen, ob alle Angeben in der Konfigurationsdatei von Wicked enthalten sind:
```
tux > sudo wicked show-config
```
Starten Sie das Netzwerk-Teaming-Gerät team0:
```
tux > sudo wicked ifup all team0
```
Falls Sie zusätzliche Informationen zur Fehlersuche benötigen, verwenden Sie die Option --debug all nach dem Subkommando all.
Überprüfen Sie den Status des Netzwerk-Teaming-Geräts. Führen Sie hierzu die folgenden Kommandos aus:
- Status der teamd-Instanz von Wicked abrufen:
```
tux > sudo wicked ifstatus --verbose team0
```
- Status der gesamten Instanz abrufen:
```
tux > sudo teamdctl team0 state
```
- systemd-Status der teamd-Instanz abrufen:
```
tux > sudo systemctl status teamd@team0
```
Jedes Kommando zeigt eine etwas andere Ansicht abhängig von Ihren Anforderungen an.
Falls Sie nachträglich Änderungen in der Datei ifcfg-team0 vornehmen müssen, laden Sie die Konfiguration der Datei mit folgendem Kommando neu:
```
tux > sudo wicked ifreload team0
```

Verwenden Sie nicht systemctl zum Starten oder Stoppen des Teaming-Geräts! Verwenden Sie stattdessen das Kommando wicked, wie oben gezeigt.

So entfernen Sie das Teaming-Gerät vollständig:

Vorgehen 19.2: Entfernen eines Teamgeräts #

Halten Sie das Netzwerk-Teaming-Gerät team0 an:
```
tux > sudo wicked ifdown team0
```
Benennen Sie die Datei /etc/sysconfig/network/ifcfg-team0 in /etc/sysconfig/network/.ifcfg-team0 um. Wenn ein Punkt vor dem Dateinamen steht, ist er für Wicked „unsichtbar“. Falls Sie die Konfiguration tatsächlich nicht mehr benötigen, können Sie die Datei auch entfernen.
Laden Sie die Konfiguration neu:
```
tux > sudo wicked ifreload all
```

19.8.1 Anwendungsfall: Lastausgleich bei Netzwerk-Teaming #

Der Lastausgleich erhöht die Bandbreite. Verwenden Sie die folgende Konfigurationsdatei zum Erstellen eines Netzwerk-Teaming-Geräts mit Funktionen für den Lastenausgleich. Fahren Sie mit Prozedur 19.1, „Allgemeines Verfahren“ fort, um das Gerät einzurichten. Überprüfen Sie die Ausgabe mit teamdctl.

Beispiel 19.12: Konfiguration für Lastausgleich bei Netzwerk-Teaming #

STARTMODE=auto 1
BOOTPROTO=static 2
IPADDRESS="192.168.1.1/24" 2
IPADDR6="fd00:deca:fbad:50::1/64" 2

TEAM_RUNNER="loadbalance" 3
TEAM_LB_TX_HASH="ipv4,ipv6,eth,vlan"
TEAM_LB_TX_BALANCER_NAME="basic"
TEAM_LB_TX_BALANCER_INTERVAL="100"

TEAM_PORT_DEVICE_0="eth0" 4
TEAM_PORT_DEVICE_1="eth1" 4

TEAM_LW_NAME="ethtool" 5
TEAM_LW_ETHTOOL_DELAY_UP="10" 6
TEAM_LW_ETHTOOL_DELAY_DOWN="10" 6

1	Steuert das Starten des Teaming-Geräts. Der Wert `auto` bedeutet, dass die Schnittstelle eingerichtet wird, wenn der Netzwerkdienst verfügbar ist und bei jedem Reboot automatisch gestartet wird. Falls Sie das Gerät selbst steuern müssen (und das automatische Starten vermeiden möchten) legen Sie `manual` für `STARTMODE` fest.
2	Legt eine statische IP-Adresse fest (hier `192.168.1.1` für IPv4 und `fd00:deca:fbad:50::1` für IPv6). Wenn das Netzwerk-Teaming-Gerät eine dynamische IP-Adresse verwenden soll, legen Sie `BOOTPROTO="dhcp"` fest und entfernen (oder kommentieren) Sie die Zeile mit `IPADDRESS` und `IPADDR6`.
3	Stellt `TEAM_RUNNER` auf `loadbalance` ein und aktiviert damit den Lastausgleichsmodus.
4	Gibt ein oder mehrere Geräte an, die aggregiert werden sollen, um das Netzwerk-Teaming-Gerät zu bilden.
5	Definiert eine Verbindungsüberwachung, die den Status der untergeordneten Geräte überwacht. Mit dem Standardwert `ethtool` wird nur überprüft, ob das Gerät aktiv und erreichbar ist. Hierdurch erfolgt die Überprüfung recht schnell. Jedoch wird nicht überprüft, ob das Gerät wirklich Pakete senden und empfangen kann. Wenn Sie wirklich sicher sein müssen, dass die Verbindung einwandfrei funktioniert, verwenden Sie die Option `arp_ping`. Damit werden Ping-Signale an einen beliebigen Host gesendet (in der Variablen `TEAM_LW_ARP_PING_TARGET_HOST` konfiguriert). Das Netzwerk-Teaming-Gerät gilt nur dann als funktionsfähig, wenn Antworten empfangen werden.
6	Definiert die Verzögerung in Millisekunden zwischen dem Verbindungsaufbau (oder -abbau) und der Benachrichtigung des Runner.

19.8.2 Anwendungsfall: Failover bei Netzwerk-Teaming #

Failover wird verwendet, um eine hohe Verfügbarkeit kritischer Netzwerk-Teaming-Geräte sicherzustellen, indem ein paralleles Sicherungsnetzwerkgerät verwendet wird. Das Sicherungsnetzwerkgerät ist ständig aktiv und übernimmt die Funktionen, wenn das Hauptgerät ausfällt.

Verwenden Sie die folgende Konfigurationsdatei zum Erstellen eines Netzwerk-Teaming-Geräts mit Failover-Funktionen. Fahren Sie mit Prozedur 19.1, „Allgemeines Verfahren“ fort, um das Gerät einzurichten. Überprüfen Sie die Ausgabe mit teamdctl.

Beispiel 19.13: Konfiguration für DHCP-Netzwerk-Teaming-Gerät #

STARTMODE=auto 1
BOOTPROTO=static 2
IPADDR="192.168.1.2/24" 2
IPADDR6="fd00:deca:fbad:50::2/64" 2

TEAM_RUNNER=activebackup 3
TEAM_PORT_DEVICE_0="eth0" 4
TEAM_PORT_DEVICE_1="eth1" 4

TEAM_LW_NAME=ethtool 5
TEAM_LW_ETHTOOL_DELAY_UP="10" 6
TEAM_LW_ETHTOOL_DELAY_DOWN="10" 6

1	Steuert das Starten des Teaming-Geräts. Wert `auto` bedeutet, dass die Schnittstelle eingerichtet wird, wenn der Netzwerkdienst verfügbar ist, und bei jedem Reboot automatisch gestartet wird. Falls Sie das Gerät selbst steuern müssen (und das automatische Starten vermeiden möchten) legen Sie `manual` für `STARTMODE` fest.
2	Legt eine statische IP-Adresse fest (hier `192.168.1.2` für IPv4 und `fd00:deca:fbad:50::2` für IPv6). Wenn das Netzwerk-Teaming-Gerät eine dynamische IP-Adresse verwenden soll, legen Sie `BOOTPROTO="dhcp"` fest und entfernen (oder kommentieren) Sie die Zeile mit `IPADDRESS` und `IPADDR6`.
3	Stellt `TEAM_RUNNER` auf `activebackup` ein und aktiviert damit den Failover-Modus.
4	Gibt ein oder mehrere Geräte an, die aggregiert werden sollen, um das Netzwerk-Teaming-Gerät zu bilden.
5	Definiert eine Verbindungsüberwachung, die den Status der untergeordneten Geräte überwacht. Mit dem Standardwert `ethtool` wird nur überprüft, ob das Gerät aktiv und erreichbar ist. Hierdurch erfolgt die Überprüfung recht schnell. Jedoch wird nicht überprüft, ob das Gerät wirklich Pakete senden und empfangen kann. Wenn Sie wirklich sicher sein müssen, dass die Verbindung einwandfrei funktioniert, verwenden Sie die Option `arp_ping`. Damit werden Ping-Signale an einen beliebigen Host gesendet (in der Variablen `TEAM_LW_ARP_PING_TARGET_HOST` konfiguriert). Nur, wenn die Antworten empfangen werden, wird das Netzwerk-Teaming-Gerät als aktiv betrachtet.
6	Definiert die Verzögerung in Millisekunden zwischen dem Verbindungsaufbau (oder -abbau) und der Benachrichtigung des Runner.

19.8.3 Anwendungsfall: VLAN zusätzlich zu Teamgerät #

VLAN ist eine Abkürzung für Virtual Local Area Network (virtuelles lokales Netzwerk). Es ermöglicht die Ausführung mehrerer logischer (virtueller) Ethernets über ein einzelnes physisches Ethernet. Es teilt das Netzwerk in verschiedene Broadcast-Domänen auf, sodass Pakete nur zwischen den Ports, die für dasselbe VLAN bestimmt sind, umgeschaltet werden müssen.

Im nachfolgenden Anwendungsfall werden zwei statische VLANs zusätzlich zu einem Teamgerät angelegt:

vlan0, an die IP-Adresse 192.168.10.1 gebunden
vlan1, an die IP-Adresse 192.168.20.1 gebunden

Führen Sie dazu die folgenden Schritte aus:

Aktivieren Sie die VLAN-Tags am Switch. Soll der Lastausgleich für das Teaming-Gerät vorgenommen werden, muss der Switch das LACP (Link Aggregation Control Protocol) (802.3ad) unterstützen. Weitere Informationen finden Sie im Hardware-Handbuch.
Legen Sie fest, ob ein Lastausgleich oder ein Failover für das Teamgerät verwendet werden soll. Richten Sie das Teamgerät gemäß den Anweisungen unter Abschnitt 19.8.1, „Anwendungsfall: Lastausgleich bei Netzwerk-Teaming“ oder Abschnitt 19.8.2, „Anwendungsfall: Failover bei Netzwerk-Teaming“ ein.

Erstellen Sie unter /etc/sysconfig/network die Datei ifcfg-vlan0 mit folgendem Inhalt:

STARTMODE="auto"
BOOTPROTO="static" 1
IPADDR='192.168.10.1/24' 2
ETHERDEVICE="team0" 3
VLAN_ID="0" 4
VLAN='yes'

1	Definiert eine feste IP-Adresse, angegeben in `IPADDR`.
2	Definiert die IP-Adresse, hier mit der Netzmaske.
3	Enthält die eigentliche Schnittstelle für die VLAN-Schnittstelle, hier das Teamgerät (`team0`).
4	Gibt eine eindeutige ID für das VLAN an. Vorzugsweise entsprechen der Dateiname und die `VLAN_ID` dem Namen `ifcfg-vlanVLAN_ID`. In diesem Fall ist `VLAN_ID` gleich `0`, sodass der Dateiname `ifcfg-vlan0` entsteht.

Kopieren Sie die Datei /etc/sysconfig/network/ifcfg-vlan0 in /etc/sysconfig/network/ifcfg-vlan1 und ändern Sie die folgenden Werte:
- IPADDR von 192.168.10.1/24 zu 192.168.20.1/24.
- VLAN_ID von 0 zu 1.
Starten Sie die beiden VLANs:
```
root # wicked ifup vlan0 vlan1
```

Prüfen Sie die Ausgabe von ifconfig:

root # ifconfig -a
[...]
vlan0     Link encap:Ethernet  HWaddr 08:00:27:DC:43:98
          inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fedc:4398/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:816 (816.0 b)

vlan1     Link encap:Ethernet  HWaddr 08:00:27:DC:43:98
          inet addr:192.168.20.1 Bcast:192.168.20.255 Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fedc:4398/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:816 (816.0 b)

19.9 Softwaredefiniertes Networking mit Open vSwitch #

Softwaredefiniertes Networking (SDN) bedeutet eine Trennung des Systems, das steuert, wohin der Datenverkehrs gesendet wird (die Steuerebene), vom zugrunde liegenden System, das den Datenverkehr zum ausgewählten Ziel weiterleitet (die Datenebene, auch Weiterleitungsebene genannt). Dies bedeutet, dass die Funktionen, die zuvor von einem einzelnen, in der Regel nicht flexiblen, Switch erbracht wurden, jetzt zwischen einem Switch (Datenebene) und seinem Controller (Steuerebene) aufgeteilt werden können. In diesem Modell ist der Controller programmierbar und funktioniert sehr flexibel und passt sich schnell an sich ändernde Netzwerkbedingungen an.

Open vSwitch ist eine Software, die einen verteilten Switch mit mehreren Ebenen implementiert, der mit dem OpenFlow-Protokoll kompatibel ist. OpenFlow erlaubt es einer Controller-Anwendung, die Konfiguration eines Switch zu bearbeiten. OpenFlow baut als Ebene auf dem TCP-Protokoll auf und wird in einer Reihe von Hardware und Software implementiert. Ein einzelner Controller kann daher mehrere, sehr unterschiedliche Switches unterstützen.

19.9.1 Vorteile von Open vSwitch #

Softwaredefiniertes Networking mit Open vSwitch bietet einige Vorteile, vor allem wenn es gemeinsam mit virtuellen Computern verwendet wird:

Networking-Zustände können einfach identifiziert werden.
Netzwerke und ihre Live-Zustände können von einem Host auf einen anderen übertragen werden.
Netzwerkdynamiken sind nachverfolgbar und externe Software kann dafür konfiguriert werden, auf diese zu antworten.
Sie können Tags in Netzwerkpaketen anwenden und so einstellen, dass sie identifizieren, von welchem bzw. an welchen Computer sie gesendet werden, und andere Netzwerkkontexte verwalten. Zuweisungsregeln für Tags können konfiguriert und migriert werden.
Open vSwitch implementiert das GRE-Protokoll (Generic Routing Encapsulation). Dies erlaubt es Ihnen beispielsweise, private Netzwerke virtueller Computer miteinander zu verbinden.
Open vSwitch kann eigenständig verwendet werden, ist jedoch für die Integration mit Networking-Hardware konzipiert und kann Hardware-Switches steuern.

19.9.2 Installieren von Open vSwitch #

Installieren Sie Open vSwitch und ergänzende Pakete:
```
root # zypper install openvswitch openvswitch-switch
```
Wenn Sie Open vSwitch zusammen mit dem KVM-Hypervisor verwenden möchten, installieren Sie zusätzlich tunctl . Wenn Sie Open vSwitch zusammen mit dem Xen-Hypervisor verwenden möchten, installieren Sie zusätzlich openvswitch-kmp-xen .
Aktivieren Sie den Open vSwitch-Dienst:
```
root # systemctl enable openvswitch
```
Starten Sie entweder den Computer neu oder verwenden Sie systemctl, um den Open vSwitch-Dienst sofort zu starten:
```
root # systemctl start openvswitch
```
Um zu überprüfen, ob Open vSwitch richtig aktiviert wurde, verwenden Sie das Kommando:
```
root # systemctl status openvswitch
```

19.9.3 Überblick über Open vSwitch-Daemons und -Dienstprogramme #

Open vSwitch besteht aus mehreren Komponenten. Hierzu gehören ein Kernel-Modul und verschiedenste Userspace-Komponenten. Das Kernel-Modul wird zur Beschleunigung des Datenpfads verwendet, ist für eine Minimalinstallation von Open vSwitch jedoch nicht erforderlich.

19.9.3.1 Daemons #

Die zentralen ausführbaren Dateien von Open vSwitch sind die zugehörigen zwei Daemons. Wenn Sie den openvswitch-Dienst starten, starten Sie die Daemons indirekt.

Der Haupt-Daemon (ovs-vswitchd) von Open vSwitch stellt die Implementierung eines Switch bereit. Der Datenbank-Daemon (ovsdb-server) von Open vSwitch dient der Datenbank, in der die Konfiguration und der Zustand von Open vSwitch gespeichert werden.

19.9.3.2 Dienstprogramme #

Open vSwitch wird außerdem mit mehreren Dienstprogrammen bereitgestellt, die die Arbeit damit vereinfachen. Die folgende Liste ist nicht vollständig, es werden nur die wichtigsten Kommandos beschrieben.

ovsdb-tool

Open vSwitch-Datenbanken erstellen, upgraden, komprimieren und abfragen. Transaktionen auf Open vSwitch-Datenbanken durchführen.

ovs-appctl

Einen aktiven ovs-vswitchd- oder ovsdb-server-Daemon konfigurieren.

ovs-dpctl, ovs-dpctl-top

Datenpfade erstellen, bearbeiten, visualisieren und löschen. Die Verwendung dieses Werkzeugs kann zu einem Konflikt mit ovs-vswitchd führen, wenn dieser auch Datenpfade verwaltet. Daher wird es oft nur zu Diagnostikzwecken verwendet.

ovs-dpctl-top erstellt eine Visualisierung ähnlich wie top- für Datenpfade.

ovs-ofctl

Alle Switches verwalten, die dem OpenFlow-Protokoll unterliegen. ovs-ofctl ist nicht auf die Interaktion mit Open vSwitch beschränkt.

ovs-vsctl

Bietet eine Schnittstelle auf höchster Ebene für die Konfigurationsdatenbank. Sie kann zum Abfragen und Bearbeiten der Datenbank verwendet werden. Konkret zeigt sie den Zustand von ovs-vswitchd und kann zur Konfiguration verwendet werden.

19.9.4 Erstellen einer Bridge mit Open vSwitch #

In der folgenden Beispielkonfiguration wird der Wicked-Netzwerkdienst standardmäßig auf SUSE Linux Enterprise Server verwendet. Weitere Informationen zu Wicked finden Sie unter Abschnitt 19.5, „Manuelle Netzwerkkonfiguration“.

Wenn Sie Open vSwitch installiert und gestartet haben, gehen Sie wie folgt vor:

Um eine Bridge zur Verwendung durch Ihren virtuellen Computer zu konfigurieren, erstellen Sie eine Datei mit folgendem Inhalt:

STARTMODE='auto'1
BOOTPROTO='dhcp'2
OVS_BRIDGE='yes'3
OVS_BRIDGE_PORT_DEVICE_1='eth0'4

1	Richten Sie die Bridge automatisch ein, wenn der Netzwerkdienst gestartet wird.
2	Das zu verwendende Protokoll für die Konfiguration der IP-Adresse.
3	Kennzeichnen Sie die Konfiguration als Open vSwitch-Bridge.
4	Wählen Sie aus, welche(s) Gerät(e) zur Bridge hinzugefügt werden soll(en). Um mehr Geräte hinzuzufügen, fügen Sie zusätzliche Zeilen für jedes der Geräte in der Datei hinzu: OVS_BRIDGE_PORT_DEVICE_SUFFIX='DEVICE' Das SUFFIX kann eine beliebige alphanummerische Zeichenfolge darstellen. Stellen Sie jedoch sicher, dass das SUFFIX für jedes Gerät eindeutig ist, um das Überschreiben einer vorherigen Definition zu vermeiden.

Speichern Sie die Datei im Verzeichnis /etc/sysconfig/network mit dem Namen ifcfg-br0. Anstelle von br0 können Sie jeden beliebigen Namen verwenden. Jedoch muss der Dateiname mit ifcfg- beginnen.

Informationen zu weiteren Optionen finden Sie auf den man-Seiten von ifcfg (man 5 ifcfg) und ifcfg-ovs-bridge (man 5 ifcfg-ovs-bridge).

Starten Sie nun die Bridge:
```
root # wicked ifup br0
```
Wenn Wicked fertig ist, sollte es den Namen der Bridge und daneben den Zustand up ausgeben.

19.9.5 Verwenden von Open vSwitch direkt mit KVM #

Nach dem Erstellen der Bridge (wie in Abschnitt 19.9.4, „Erstellen einer Bridge mit Open vSwitch“ beschrieben) können Sie Open vSwitch zum Verwalten des Netzwerkzugriffs auf virtuelle Computer verwenden, die mit KVM/QEMU erstellt wurden.

Um die Möglichkeiten von Wicked am besten nutzen zu können, führen Sie weitere Änderungen an der zuvor konfigurierten Bridge durch. Öffnen Sie die zuvor erstellte Datei /etc/sysconfig/network/ifcfg-br0 und fügen Sie eine Zeile für ein weiteres Port-Gerät hinzu:
```
OVS_BRIDGE_PORT_DEVICE_2='tap0'
```
Legen Sie zusätzlich für BOOTPROTO den Wert none fest. Die Datei sollte nun wie folgt aussehen:
```
STARTMODE='auto'
BOOTPROTO='none'
OVS_BRIDGE='yes'
OVS_BRIDGE_PORT_DEVICE_1='eth0'
OVS_BRIDGE_PORT_DEVICE_2='tap0'
```
Das neue Port-Gerät tap0 wird im nächsten Schritt konfiguriert.
Fügen Sie nun eine Konfigurationsdatei für das Gerät tap0 hinzu:
```
STARTMODE='auto'
BOOTPROTO='none'
TUNNEL='tap'
```
Speichern Sie die Datei im Verzeichnis /etc/sysconfig/network mit dem Namen ifcfg-tap0.
Tipp: Anderen Benutzern den Zugriff auf das Tap-Gerät erlauben
Um dieses Tap-Gerät über einen virtuellen Computer verwenden zu können, der als Benutzer ohne root-Berechtigungen gestartet wurde, fügen Sie Folgendes hinzu:
```
TUNNEL_SET_OWNER=USER_NAME
```
Um den Zugriff für eine ganze Gruppe zu erlauben, fügen Sie Folgendes hinzu:
```
TUNNEL_SET_GROUP=GROUP_NAME
```
Öffnen Sie schließlich die Konfiguration für das Gerät, das als das erste OVS_BRIDGE_PORT_DEVICE-Gerät definiert ist. Wenn Sie den Namen nicht geändert haben, sollte dies eth0 sein. Öffnen Sie daher /etc/sysconfig/network/ifcfg-eth0 und stellen Sie sicher, dass die folgenden Optionen festgelegt sind:
```
STARTMODE='auto'
BOOTPROTO='none'
```
Wenn die Datei noch nicht vorhanden ist, erstellen Sie sie.
Starten Sie die Bridge-Schnittstelle mithilfe von Wicked neu:
```
root # wicked ifreload br0
```
Dies löst auch das erneute Laden der neu definierten Bridge-Port-Geräte aus.
Verwenden Sie zum Starten eines virtuellen Computers beispielsweise:
```
root # qemu-kvm \
-drive file=/PATH/TO/DISK-IMAGE1 \
-m 512 -net nic,vlan=0,macaddr=00:11:22:EE:EE:EE \
-net tap,ifname=tap0,script=no,downscript=no2
```
1
Pfad zum QEMU-Laufwerksabbild, das Sie starten möchten.
2
Verwenden Sie das zuvor erstellte Tap-Gerät (tap0).
Weitere Informationen zur Verwendung von KVM/QEMU finden Sie im Part V, “Managing virtual machines with QEMU”.

19.9.6 Verwenden von Open vSwitch mit `libvirt` #

Nach Erstellen der Bridge, wie zuvor in Abschnitt 19.9.4, „Erstellen einer Bridge mit Open vSwitch“ beschrieben, können Sie die Bridge zu einem vorhandenen virtuellen Computer hinzufügen, der mit libvirt verwaltet wird. Da libvirt Open vSwitch-Bridges bereits teilweise unterstützt, können Sie die in Abschnitt 19.9.4, „Erstellen einer Bridge mit Open vSwitch“ erstellte Bridge ohne weitere Änderungen an der Networking-Konfiguration verwenden.

Öffnen Sie die Domänen-XML-Datei für den gewünschten virtuellen Computer:
```
root # virsh edit VM_NAME
```
Ersetzen Sie VM-NAME durch den Namen des gewünschten virtuellen Computers. Hiermit wird Ihr Standardtexteditor geöffnet.
Suchen Sie nach einem Abschnitt, der mit <interface type="..."> beginnt und mit </interface> endet, um den Networking-Abschnitt des Dokuments zu finden.
Ersetzen Sie den vorhandenen Abschnitt durch einen Networking-Abschnitt, der etwa so aussieht:
```
<interface type='bridge'>
  <source bridge='br0'/>
  <virtualport type='openvswitch'/>
</interface>
```
Wichtig: Kompatibilität von virsh iface-* und Virtual Machine Manager mit Open vSwitch
Zurzeit wird die Open vSwitch-Kompatibilität von libvirt nicht über die virsh iface-*-Werkzeuge und Virtual Machine Manager verfügbar gemacht. Wenn Sie eines dieser Werkzeuge verwenden, kann die Konfiguration beschädigt werden.
Sie können die virtuellen Computer nun wie üblich starten oder neu starten.

Weitere Informationen zur Verwendung von libvirt finden Sie im Part II, “Managing virtual machines with libvirt”.

19.9.7 Weitere Informationen #

https://docs.openvswitch.org/en/latest/#documentation: Dokumentationsabschnitt der Open vSwitch-Projekt-Website
https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf: Whitepaper der Open Networking Foundation zum softwaredefinierten Networking und zum OpenFlow-Protokoll

1	Pfad zum QEMU-Laufwerksabbild, das Sie starten möchten.
2	Verwenden Sie das zuvor erstellte Tap-Gerät (`tap0`).

19 Grundlegendes zu Netzwerken #

19.1 IP-Adressen und Routing #

19.1.1 IP-Adressen #

19.1.2 Netzmasken und Routing #

19.2 IPv6 – das Internet der nächsten Generation #

19.2.1 Vorteile #

19.2.2 Adresstypen und -struktur #

19.2.3 Koexistenz von IPv4 und IPv6 #

19.2.4 IPv6 konfigurieren #

19.2.5 Weitere Informationen #

19.3 Namensauflösung #

19.4 Konfigurieren von Netzwerkverbindungen mit YaST #

19.4.1 Konfigurieren der Netzwerkkarte mit YaST #

19.4.1.1 Konfigurieren globaler Netzwerkoptionen #

19.4.1.2 Ändern der Konfiguration einer Netzwerkkarte #

19.4.1.2.1 IP-Adressen konfigurieren #

19.4.1.2.2 Konfigurieren mehrerer Adressen #

19.4.1.2.3 Ändern des Gerätenamens und der Udev-Regeln #

19.4.1.2.4 Ändern des Kernel-Treibers für Netzwerkkarten #

19.4.1.2.5 Aktivieren des Netzwerkgeräts #

19.4.1.2.6 Einrichten der Größe der maximalen Transfereinheit #

19.4.1.2.7 Multifunktionale PCIe-Geräte #

19.4.1.2.8 InfiniBand-Konfiguration für IPoIB (IP-over-InfiniBand) #

19.4.1.2.9 Konfigurieren der Firewall #

19.4.1.3 Konfigurieren einer unerkannten Netzwerkkarte #

19.4.1.4 Konfigurieren des Hostnamens und des DNS #

19.4.1.5 Konfigurieren des Routings #

19.4.2 IBM Z: Konfigurieren von Netzwerkgeräten #

19.4.2.1 Das qeth-hsi-Gerät #

19.4.2.2 Das qeth-ethernet-Gerät #

19.4.2.3 Das ctc-Gerät #

19.4.2.4 Das lcs-Gerät #

19.4.2.5 Das IUCV-Gerät #

19.5 Manuelle Netzwerkkonfiguration #

19.5.1 Die wicked-Netzwerkkonfiguration #

19.5.1.1 wicked-Architektur und -Funktionen #

19.5.1.2 Verwendung von wicked #

19.5.1.3 Nanny #

19.5.1.4 Starten von mehreren Schnittstellen #

19.5.1.5 Verwenden von Tunneln mit Wicked #

19.5.1.6 Einarbeiten von inkrementellen Änderungen #

19.5.1.7 wicked-Erweiterungen: Adresskonfiguration #

19.5.1.8 Wicked-Erweiterungen: Konfigurationsdateien #

19.5.2 Konfigurationsdateien #

19.5.2.1 /etc/wicked/common.xml #

19.5.2.2 /etc/wicked/server.xml #

19.5.2.3 /etc/wicked/client.xml #

19.5.2.4 /etc/wicked/nanny.xml #

19.5.2.5 /etc/sysconfig/network/ifcfg-* #

19.5.2.6 /etc/sysconfig/network/config, /etc/sysconfig/network/dhcp und /etc/sysconfig/network/wireless #

19.5.2.7 /etc/sysconfig/network/routes und /etc/sysconfig/network/ifroute-* #

19.5.2.8 /var/run/netconfig/resolv.conf #

19.5.2.9 /sbin/netconfig #

19.5.2.10 /etc/hosts #

19.5.2.11 /etc/networks #

19.5.2.12 /etc/host.conf #

19.5.2.13 /etc/nsswitch.conf #

19.5.2.14 /etc/nscd.conf #

19.5.2.15 /etc/HOSTNAME #

19.5.3 Testen Sie die Konfiguration. #

19.5.3.1 Konfigurieren einer Netzwerkschnittstelle mit ip #

19.5.3.2 Testen einer Verbindung mit „ping“ #

19.5.4 Unit-Dateien und Startskripte #

19.6 Grundlegende Routereinrichtung #

19.7 Einrichten von Bonding-Geräten #

19.7.1 Hot-Plugging von Bonding-Slaves #

19.8 Einrichten von Team-Geräten für Netzwerk-Teaming #

19.8.1 Anwendungsfall: Lastausgleich bei Netzwerk-Teaming #

19.8.2 Anwendungsfall: Failover bei Netzwerk-Teaming #

19.8.3 Anwendungsfall: VLAN zusätzlich zu Teamgerät #

19.9 Softwaredefiniertes Networking mit Open vSwitch #

19.9.1 Vorteile von Open vSwitch #

19.9.2 Installieren von Open vSwitch #

19.9.3 Überblick über Open vSwitch-Daemons und -Dienstprogramme #

19.9.3.1 Daemons #

19.9.3.2 Dienstprogramme #

19.9.4 Erstellen einer Bridge mit Open vSwitch #

19.9.5 Verwenden von Open vSwitch direkt mit KVM #

19.9.6 Verwenden von Open vSwitch mit libvirt #

19.9.7 Weitere Informationen #

19.5.1 Die `wicked`-Netzwerkkonfiguration #

19.5.1.1 `wicked`-Architektur und -Funktionen #

19.5.1.2 Verwendung von `wicked` #

19.5.2.1 `/etc/wicked/common.xml` #

19.5.2.2 `/etc/wicked/server.xml` #

19.5.2.3 `/etc/wicked/client.xml` #

19.5.2.4 `/etc/wicked/nanny.xml` #

19.5.2.5 `/etc/sysconfig/network/ifcfg-*` #

19.5.2.6 `/etc/sysconfig/network/config`, `/etc/sysconfig/network/dhcp` und `/etc/sysconfig/network/wireless` #

19.5.2.7 `/etc/sysconfig/network/routes` und `/etc/sysconfig/network/ifroute-*` #

19.5.2.8 `/var/run/netconfig/resolv.conf` #

19.5.2.9 `/sbin/netconfig` #

19.5.2.10 `/etc/hosts` #

19.5.2.11 `/etc/networks` #

19.5.2.12 `/etc/host.conf` #

19.5.2.13 `/etc/nsswitch.conf` #

19.5.2.14 `/etc/nscd.conf` #

19.5.2.15 `/etc/HOSTNAME` #

19.5.3.1 Konfigurieren einer Netzwerkschnittstelle mit `ip` #

19.9.6 Verwenden von Open vSwitch mit `libvirt` #