☰

RTNETLINK-Fehler „Datei existiert“ beim Versuch, eine Veth-Schnittstelle zu erstellen, die zuvor ein Dummy war

tag-icon • tag-icon linux networking interface
RTNETLINK-Fehler „Datei existiert“ beim Versuch, eine Veth-Schnittstelle zu erstellen, die zuvor ein Dummy war

Linux Mint 20.2

Ich habe diesen Befehl verwendet, um eine Dummy-Ethernet-Schnittstelle namens veth0 zu erstellen:

sudo ip link add veth0 type dummy

Als ich fertig war, habe ich es mit folgendem entfernt:

sudo ip link delete veth0 type dummy

Die Schnittstelle wurde definitiv entfernt. Nach einem Neustart habe ich dann versucht, eine virtuelle Ethernet-Schnittstelle zu erstellen mit:

sudo ip link add veth0 type veth

Aber wenn ich das mache, erhalte ich die Fehlermeldung „Datei existiert“.

Es erlaubt mir, mit dem ersten Befehl erneut eine Dummy-Schnittstelle zu erstellen. Wo könnte der Schnittstellenname referenziert werden, um zu verhindern, dass er als virtueller Ethernet-Typ wiederverwendet wird?

Meine Recherche hat viele ähnliche Beiträge hervorgebracht, aber sie alle verweisen im Allgemeinen auf ein Problem mit physischen Schnittstellen, die den Befehl ifup nicht verwenden können. Die Lösung besteht darin, die Adressen auf der Schnittstelle zu löschen und sicherzustellen, dass in /etc/network/interfaces nicht mehr als ein Gateway aufgeführt ist. Keine der Lösungen trifft hier zu. Ich habe nichts darüber gefunden, dass virtuelle Schnittstellennamen nicht für verschiedene Schnittstellentypen wiederverwendbar sind, nachdem der vorherige Typ entfernt wurde.

Mir ist klar, dass ich einfach einen anderen Schnittstellennamen verwenden könnte, aber ich möchte dieses Konfigurationsproblem beheben und herausfinden, wodurch es verursacht wurde.

Antwort1

Dieses Problem ist reproduzierbar, liegt aber daran, dass ein Name gewählt wird, der mit der Standardauswahl des Kernels in Konflikt steht.

Wenn kein Name für die Peer-Schnittstelle angegeben wird, wird die niedrigstmögliche Ganzzahl angehängt, um vethden Peer-Namen zu bilden.Erste. Dies geschieht zuerst, bevor die Hauptschnittstelle selbst erstellt wird. Dies kann man sehen, wenn man einen Namen angibt, der nicht kollidieren kann:

# ip link add name myveth type veth
# ip link show type veth
17: veth0@myveth: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 2a:93:f8:8e:bc:b6 brd ff:ff:ff:ff:ff:ff
18: myveth@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 8a:c3:1d:82:93:a6 brd ff:ff:ff:ff:ff:ff

der Peer-Name wird auf die übliche Weise gewählt: Erstellen Sie eine Schnittstelle mit dem Typ und der nächsten verfügbaren Ganzzahl, die daran angehängt wird: veth+ 0: veth0. Der niedrigere Index (hier 17 statt 18) bedeutet, dass er zuerst erstellt wird.

Wenn man nun genau denselben Namen angibt, den der Kernel automatisch zuerst erstellt, kommt es zu einem Konflikt, die angegebene Schnittstelle wird nicht erstellt und die Peer-Schnittstelle wird daher gelöscht. Keine Spur außer einem RTNETLINK answers: File exists. Dies ist deutlich zu sehen, wenn man es in einer separaten Shell ausführt ip link monitor:

Schale 1:

$ ip link monitor

Schale 2:

# ip link add name veth0 type veth
RTNETLINK answers: File exists

nochmal Schale 1:

23: veth0@NONE: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether 72:2d:b8:9f:90:6c brd ff:ff:ff:ff:ff:ff
Deleted 23: veth0@NONE: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether 72:2d:b8:9f:90:6c brd ff:ff:ff:ff:ff:ff

Hier @NONEbedeutet, dass noch kein Peer-Link-Index zugeordnet ist... noch nicht. Eine vethSchnittstelle hat einen Peer-Link-Index: die andere Seite des virtuellen Ethernet-Kabels. Sie hätte den Peer-Link-Index auf die nächste Schnittstelle auflösen sollen, die gerade mit Index 24 erstellt wurde, aber diese Schnittstelle konnte dann nicht mit dem Namen erstellt werden, veth0weil sie bereits existierte (selbst wenn das an ihrer eigenen Erstellung lag). Dies löst den Abbruch des gesamten Vorgangs und das Löschen des flüchtigen Datenelements veth0sowie die als zurückgesendete Fehlermeldung aus File exists, andernfalls bleibt keine Spur des Problems zurück.

Fazit: Um Konflikte zu vermeiden,

  • Geben Sie keinen Namen an und überlassen Sie die Auswahl dem Kernel:

    ip link add type veth

    bekommen:

    24: veth0@veth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN group default 
    link/ether 2a:93:f8:8e:bc:b6 brd ff:ff:ff:ff:ff:ff
25: veth1@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN group default 
    link/ether 86:70:54:05:0f:75 brd ff:ff:ff:ff:ff:ff

  • Geben Sie einen Namen an, der nicht dem Standardbenennungsschema entspricht.

    ip link add name myveth type veth

  • oder geben Sie beide Namen an, auch wenn sie nicht der Standardreihenfolge entsprechen, in der sie vom Kernel in seinem Standardbenennungsschema erstellt werden (Peer als veth0und Main als veth1):

    ip link add name veth0 type veth peer name veth1

  • Vergessen Sie nicht, vethdass Schnittstellen außerhalb von Netzwerk-Namespace-Umgebungen meistens (aber nicht immer) nutzlos sind. Die Peer-Schnittstelle kann bei Bedarf direkt an anderer Stelle hinzugefügt werden:

    ip netns add othernamespace
ip link add name veth0 type veth peer netns othernamespace

    veth0wo der Peer auch ohne Konflikte erstellt wird .

    # ip link show type veth
27: veth0@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 2a:93:f8:8e:bc:b6 brd ff:ff:ff:ff:ff:ff link-netns othernamespace
# ip -n othernamespace link show type veth
2: veth0@if27: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether fa:cb:bf:23:fc:a6 brd ff:ff:ff:ff:ff:ff link-netnsid 0

verwandte Informationen