Realtek-Netzwerkkarte kann nicht über IP kommunizieren

[Natriumchlorid]

Guten Abend,

im Rahmen eines kleines Upgrades habe ich meinem Homeserver heute eine neue Netzwerkkarte verpasst. Es handelt sich um eine einfache Delock 89358 Gigabit Ethernet 2 Port-Netzwerkkarte, mit einem Realtek Chipsatz.
Sie wird im BIOS und in Proxmox erkannt.

Das Problem: Es findet keine Verbindung über IP statt.

Ich hab die Karte eingebaut und meiner VM (opnsense) zugewiesen, aber es ging nichts. Kein Gerät kann mit der VM über die Schnittstelle sprechen. Über ARP finden sich die Geräte, aber IP ist nicht möglich. Kein Ping kommt an, nichts.
Anschließend habe ich in Proxmox direkt der Bridge, in der die beiden Ports der Netzwerkkarte drin sind, eine IP zugewiesen und habe dasselbe wieder probiert. Auch hier kann kein Netzwerkgerät mit den Schnittstellen sprechen. Die MAC-Adressen der Teilnehmer im Netzwerk sind jedoch sichtbar.

Was mich irritiert ist die Tatsache, dass meine bestehende Netzwerkkarte und mein Netzwerkport auf dem Mainboard ebenfalls Realtek-Chipsätze haben und problemlos funktionieren. Sie unterscheiden sich nur in der Revision.

Ein lspci -nnk | grep -i net -A4 gibt folgendes aus:

2a:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
        Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:0123]
        Kernel driver in use: r8169
        Kernel modules: r8169
2e:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
        Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:0123]
        Kernel driver in use: r8169
        Kernel modules: r8169
30:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
        Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:0123]
        Kernel driver in use: r8169
        Kernel modules: r8169
31:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
        Subsystem: Micro-Star International Co., Ltd. [MSI] RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [1462:7c56]
        Kernel driver in use: r8169
        Kernel modules: r8169

Die Schnittstellen mit rev 15 funktionieren problemlos. Die beiden Schnittstellen mit rev 06 stellen die beiden Schnittstellen der neuen Netzwerkkarte dar und können über IP einfach nicht kommunizieren.

Wie lässt sich das Problem beheben? Im Proxmox-Forum wird zur Neuinstallation geraten, die würde ich gerne vermeiden.
Das Pakete fehlen, kann ich mir kaum vorstellen, da die anderen Ports funktionieren. Übersehe ich hier etwas?

 

[Redundanz]

also wenn layer 2 konnektiviät gegeben ist, wie ich dich verstanden habe, dann probier doch einfach mal aus dich mit einem laptop per kabel direkt oder über einen switch an die karte zu schließen und richte manuell ein statisches netz bei dem adapter im server (nicht via vm bitte) und im laptop ein und schau ob du die karte anpingen kannst. ICMP ist ja bereits layer 3.
ein test unter den einfachsten bedingungen sozusagen.

klingt nämlich eher so als gäbe es ein problem mit der ip-konfiguration bzw. der einbindung des adapters in deine vm.

das würde dann auch alle zweifel ausräumen, dass es an der hardware selbst liegt, da du spezifisch auf den revisionsunterschied hingewiesen hast.

 

[LieberNetterFlo]

moment, du hast sie in einem Rechner, auf dem Proxmox läuft, dort hast du eine VM in der OPNsense läuft, und dieser VM hast du die Netzwerkkarten zugewiesen? Passthrough oder "ganz normal"?

Wiedem auch sei: findet die OPNsense die Karte/Schnittstelle? Falls ja, dann musst du sie ja in OPNsense konfigurieren damit du sie dort nutzen kannst. Hast du das gemacht? (ich kenn das von pfSense, nur weil ne Schnittstelle da ist funktioniert sie nicht einfach, die muss konfiguriert werden)

 

[Natriumchlorid]

dann probier doch einfach mal aus dich mit einem laptop per kabel direkt oder über einen switch an die karte zu schließen

Das habe ich auch probiert.
Ich hab ein Notebook mit Windows und Linux getestet. Beide Ports bekamen eine IP-Adresse im selben Netzwerk (statisch, versteht sich) und können sich nicht anpingen.

Ich habe dabei auf dem Proxmox-Server direkt der Schnittstelle eine IP-Adresse vergeben.

klingt nämlich eher so als gäbe es ein problem mit der ip-konfiguration bzw. der einbindung des adapters in deine vm.

Dachte ich zuerst auch, aber die Konnektivität auf Layer 3 (IP) funktioniert unter keinen Umständen. Layer 2 (ARP) ist jedoch möglich. Das klingt meiner Meinung nach stark nach Problemen mit dem Treiber.

moment, du hast sie in einem Rechner, auf dem Proxmox läuft, dort hast du eine VM in der OPNsense läuft, und dieser VM hast du die Netzwerkkarten zugewiesen? Passthrough oder "ganz normal"?

Genau. Ein Proxmox-Host. Dieser hat eine VM in der OPNsense läuft. Der VM werden die Netzwerkports normal zugewiesen, nicht über Passthrough. Ich musste das damals aus einem bestimmten Grund machen, kann dir leider nicht mehr sagen warum.

Wiedem auch sei: findet die OPNsense die Karte/Schnittstelle? Falls ja, dann musst du sie ja in OPNsense konfigurieren damit du sie dort nutzen kannst. Hast du das gemacht?

OPNsense hat die Schnittstelle gefunden und konnte sie auch "normal verwenden".
Die VM hat bereits vor dem Einbau der Karte funktioniert. Ich hatte bereits 2 Netzwerkports (Mainboard, Netzwerkkarte).

Nur mit der Zuweisung eines Ports der neuen Netzwerkkarte hat die VM ihren Dienst eingestellt. Ich hab den alten Port mit dem neuen in der VM-Konfiguration ersetzt.
In der VM konnte ich Geräte per ARP identifizieren, über IP hatte ich einfach keine Chance. Gleiches Spiel mit dem Proxmox-Host. ARP im Netzwerk funktioniert, sobald IP ins Spiel kommt, geht da nichts.

 

[andy_m4]

Ich weiß nicht, ob es hier in dem Fall ein Problem ist. Aber Realtek ist generell jetzt keine Firma von der man Ethernethardware haben möchte und sind unter den Open-Source-Entwicklern regelmäßig Quelle von Ärger.
Sowohl die Hardware als auch die Software gehört eher zur Kategorie unterirdisch. Das ist halt wirklich ein Billigstanbieter. Wenns unter Windows halbwegs stabil läuft wirds verkauft. Unter alternativen Systemen sieht es oft schlechter aus. Das muss nicht ausnahmslos bei jedem Realtek-Netzwerkchip so sein, aber es kommt halt häufig genug vor. Den schlechten Ruf den es in der Szene hat, hat man sich über Jahre aufgebaut und somit redlich verdient.

 

[Sommersocke]

Hallo!
Abgesehen vom bisherigen: Wie hast du denn die Netzwerkkarte auf dem Host konfiguriert? Läuft die in einem eigenen (Sub-)Netz? Passende Route(n) gesetzt? Du schreibst was von Netzwerkbrücke: Auch da: Wie hast du die konfiguriert? Falls alles über systemd-networkd läuft, ist die Konfiguration ja recht übersichtlich.

 

[Natriumchlorid]

Meine alte Netzwerkkarte mit nur einem NIC wurde ausgebaut und die neue eingebaut.
Sie wurde erkannt, die Ports mussten jedoch erst manuell mithilfe von ip link set enp46s0 up und ip link set enp48s0 up aktiviert werden.
Anschließend habe ich beide Ports in die Bridge vmbr2 aufgenommen und den alten Port der alten Netzwerkkarte entfernt.

Somit haben wir in der Erzählung folgenden Stand:

Bridge-Name	IP-Adresse	Name der Ports	Beschreibung
vmbr0	10.10.10.1/24	enp49s0	NIC des Mainboards
vmbr1	-	-	-
vmbr2	-	enp46s0 enp48s0	NICs der PCIe-Karte

Der Firewall-VM (OPNsense) habe ich also normal ein internen Port (vmbr0) und einen externen Port (vmbr2) zugewiesen. So hat es auch vor dem Wechsel funktioniert.

Zwischen dem Proxmox-Host und meiner FritzBox existiert ein separates Netzwerk mit der IP 172.20.21.0/24.
In der VM habe ich dem externen Port statisch eine IP im Netzwerk vergeben (im Prinzip wie vorher eben auch), sodass er die FritzBox erreichen kann.

Ab hier begann die Dienstverweigerung. Die Ports am NIC blinken, FritzBox sieht auch die MAC meiner VM, meine VM sieht die MAC der FritzBox, aber IP will da drüber nicht laufen.
Innerhalb der VM habe ich versucht die FritzBox anzupingen, es kam nichts an.

Gut, ich dachte es liegt eventuell an der VM, vielleicht schmeckt OPNsense das nicht wenn man Ports nach Lust und Laune neu zuordnet. Kann ja sein.

Also begann ich der Bridge vmbr2 eine statische IP in dem Netzwerk 172.20.21.0/24 zu vergeben, in der Hoffnung, dass nun eine Verbindung stattfinden kann.

Auch hier selbes Spiel wie vorher:
FritzBox sieht die MAC des Ports von Proxmox, aber über IP können die beiden nicht kommunizieren.
Damit er wirklich über die richtige Schnittstelle geht, hab ich ping -I vmbr2 172.20.21.1 laufen lassen. Trotzdem kam nichts an.

Statt einer FritzBox habe ich natürlich die Verbindung zwischen Proxmox-Host und Notebook probiert. Beide Parteien haben eine statische IP-Adresse erhalten. Auch hier, kein Ping kommt an.

Ab hier habe ich meine alte Netzwerkkarte wieder eingebaut, PCIe-Slots sind ja genug vorhanden. Wenn es mit der alten Karte funktioniert hat, muss es nach dem Einbau genauso wieder funktionieren.

Alles wieder konfiguriert und nun habe ich folgenden Stand:

Bridge-Name	IP-Adresse	Name der Ports	Beschreibung
vmbr0	10.10.10.1/24	enp49s0	NIC des Mainboards
vmbr1	-	enp46s0 enp48s0	NICs der neuen PCIe-Karte
vmbr2	-	enp42s0	NIC der alten PCIe-Karte

Ich habe meiner VM den einen Netzwerkport von vmbr2 zugewiesen und ich hatte prompt wieder Internet. Kommunikation zwischen FritzBox und Proxmox-Host läuft problemlos.

Abschließend habe ich einen Container erstellt, dort einen Netzwerkport von vmbr1 zugewiesen, was nun die neue Netzwerkkarte darstellt.
Hier selbes Spiel, Verbindung zwischen Container und Notebook, kein IP möglich.
Dann habe ich der vmbr1 in Proxmox direkt eine IP zugewiesen und die Verbindung zwischen Proxmox-Host und Notebook getestet. Ebenfalls keine Verbindung über IP möglich.
Ich hab auch nur einzeln Ports in der Bridge drin gehabt, um zu sehen ob das einen Unterschied macht, aber vergebens.

Der Auszug aus /etc/network/interfaces:

auto lo
iface lo inet loopback

iface enp42s0 inet manual

iface enp49s0 inet manual

iface enp46s0 inet manual

iface enp48s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.10.10.1/24
        gateway 10.10.10.254
        bridge-ports enp49s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
#Management Interface

auto vmbr1
iface vmbr1 inet manual
        bridge-ports enp46s0 enp48s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
#Internal Interface

auto vmbr2
iface vmbr2 inet manual
        bridge-ports enp42s0
        bridge-stp off
        bridge-fd 0
#External Interface

Um also auf deine Frage zurück zukommen, die Ports sind eigentlich nicht konfiguriert. Die Bridges werden VMs/CTs zugewiesen und bekommen dort ihre IP-Adresse. Für den Fall der Fehlerbehebung habe ich testweise immer der Bridge eine statische IP-Adresse verpasst, damit ich die Verbindung testen kann.

Was mir gerade noch einfällt ist, dass auch IPv6 nicht funktioniert hat.