Netzwerkschnittstelle des Proxmox-Hosts nicht erreichbar

Natriumchlorid

Lt. Junior Grade
Registriert
Sep. 2013
Beiträge
369
Ich benötige eure Hilfe, da ich alleine nicht drauf komme, was hier los ist. :D

Seit heute morgen habe ich das Phänomen entdeckt, dass die Netzwerkschnittstelle meines Proxmox-Hosts sporadisch ausfällt.
Gemerkt habe ich dies, da mein WLAN nicht mehr funktioniert hatte. Ich hab einen Blick auf den Host geworfen, um festzustellen, dass ich absolut keine Verbindung (ping/https/ssh) hinbekomme.
Ich hab die Kiste neu gestartet, dennoch kam keine Verbindung zustande. Die Ausgabe auf der Konsole teilte mir ein Netzwerk-Problem mit:
Code:
 r8169 0000:2d:00.0 enp45s0: rtl_txcfg_empty_cond == 0 (loop: 666, delay: 100).
Dies erscheint auch direkt nach dem Neustart des Hosts:
Code:
[   50.336167] ------------[ cut here ]------------
[   50.336175] NETDEV WATCHDOG: enp45s0 (r8169): transmit queue 0 timed out
[   50.336186] WARNING: CPU: 7 PID: 0 at net/sched/sch_generic.c:448 dev_watchdog+0x264/0x270
[   50.336186] Modules linked in: nft_limit nft_compat nft_counter cfg80211 8021q garp mrp nf_tables nf_log_ipv6 ip6t_REJECT nf_reject_ipv6 xt_hl ip6t_rt nf_log_ipv4 nf_log_common ipt_REJECT nf_reject_ipv4 xt_LOG xt_limit xt_addrtype xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 veth ebtable_filter ebtables ip_set ip6table_raw iptable_raw ip6table_filter ip6_tables iptable_filter bpfilter softdog nfnetlink_log nfnetlink snd_hda_codec_hdmi edac_mce_amd snd_hda_codec_realtek kvm_amd snd_hda_codec_generic ledtrig_audio kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel snd_hda_intel crypto_simd snd_intel_dspcfg cryptd snd_hda_codec glue_helper snd_hda_core snd_hwdep joydev snd_pcm pcspkr wmi_bmof snd_timer k10temp snd soundcore ccp mac_hid zfs(PO) zunicode(PO) zzstd(O) zlua(O) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) vhost_net vhost tap ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp nfsd libiscsi scsi_transport_iscsi auth_rpcgss
[   50.336213]  nfs_acl lockd grace sunrpc ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c hid_generic usbhid hid i2c_piix4 r8169 xhci_pci realtek ahci xhci_hcd libahci wmi gpio_amdpt gpio_generic
[   50.336222] CPU: 7 PID: 0 Comm: swapper/7 Tainted: P           O      5.4.119-1-pve #1
[   50.336223] Hardware name: Micro-Star International Co., Ltd. MS-7C56/B550-A PRO (MS-7C56), BIOS A.30 08/31/2020
[   50.336224] RIP: 0010:dev_watchdog+0x264/0x270
[   50.336225] Code: 48 85 c0 75 e6 eb a0 4c 89 ef c6 05 60 b8 ef 00 01 e8 20 b8 fa ff 89 d9 4c 89 ee 48 c7 c7 70 5d c3 9f 48 89 c2 e8 95 55 15 00 <0f> 0b eb 82 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
[   50.336226] RSP: 0018:ffffbbef003a4e58 EFLAGS: 00010282
[   50.336227] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[   50.336227] RDX: ffff9cd63e9e7740 RSI: 00000000000000f6 RDI: 0000000000000300
[   50.336227] RBP: ffffbbef003a4e88 R08: 0000000000000522 R09: 0000000000000004
[   50.336228] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001
[   50.336228] R13: ffff9cd63ae7e000 R14: ffff9cd63ae7e480 R15: ffff9cd62bb55a80
[   50.336229] FS:  0000000000000000(0000) GS:ffff9cd63e9c0000(0000) knlGS:0000000000000000
[   50.336230] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   50.336230] CR2: 00007fa883f961c0 CR3: 0000000799a10000 CR4: 0000000000340ee0
[   50.336231] Call Trace:
[   50.336232]  <IRQ>
[   50.336234]  ? pfifo_fast_enqueue+0x160/0x160
[   50.336236]  call_timer_fn+0x32/0x130
[   50.336237]  run_timer_softirq+0x1a5/0x430
[   50.336238]  ? ktime_get+0x3c/0xa0
[   50.336240]  ? lapic_next_event+0x20/0x30
[   50.336242]  ? clockevents_program_event+0x93/0xf0
[   50.336243]  __do_softirq+0xdc/0x2d4
[   50.336246]  irq_exit+0xa9/0xb0
[   50.336246]  smp_apic_timer_interrupt+0x79/0x130
[   50.336247]  apic_timer_interrupt+0xf/0x20
[   50.336248]  </IRQ>
[   50.336249] RIP: 0010:poll_idle+0x98/0xbd
[   50.336250] Code: 44 89 f0 41 5c 41 5d 41 5e 5d c3 4c 89 ef 48 89 de e8 1c a1 d8 ff 49 89 c5 b8 c9 00 00 00 65 48 8b 14 25 c0 6b 01 00 48 8b 12 <83> e2 08 75 aa f3 90 83 e8 01 75 e8 65 8b 3d 15 cc d4 60 e8 40 03
[   50.336250] RSP: 0018:ffffbbef0016fe18 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13
[   50.336251] RAX: 0000000000000096 RBX: ffff9cd62d74d800 RCX: 000000000000001f
[   50.336251] RDX: 0000000080204000 RSI: ffff9cd62d74d800 RDI: ffffffff9ff669a0
[   50.336252] RBP: ffffbbef0016fe38 R08: 0000000000000002 R09: 000000000002a680
[   50.336252] R10: 000000343c685274 R11: ffff9cd63e9e9aa0 R12: 0000000bb844e460
[   50.336252] R13: 00000000000007d0 R14: 0000000000000000 R15: ffffffff9ff669a0
[   50.336254]  ? poll_idle+0x84/0xbd
[   50.336256]  cpuidle_enter_state+0x75/0x450
[   50.336257]  cpuidle_enter+0x2e/0x40
[   50.336259]  call_cpuidle+0x23/0x40
[   50.336259]  do_idle+0x22c/0x270
[   50.336260]  cpu_startup_entry+0x1d/0x20
[   50.336261]  start_secondary+0x166/0x1c0
[   50.336263]  secondary_startup_64+0xa4/0xb0
[   50.336264] ---[ end trace d1f5951d4dcc536f ]---
[   50.426806] r8169 0000:2d:00.0 enp45s0: rtl_txcfg_empty_cond == 0 (loop: 666, delay: 100).
[   55.286764] r8169 0000:2a:00.0 enp42s0: rtl_txcfg_empty_cond == 0 (loop: 666, delay: 100).
[   60.406683] r8169 0000:2d:00.0 enp45s0: rtl_txcfg_empty_cond == 0 (loop: 666, delay: 100).

Mein derzeitiger Workaround ist meinen Switch neu zu starten. Der Host wird wieder erreichbar und mein Netzwerk funktioniert wieder. Allerdings taucht das Problem nach ca. 30 Minuten erneut auf.

Den Switch habe ich ausgetauscht, dennoch bleibt das Problem erhalten. Meine Vermutung ist daher, dass der Proxmox-Host dahinter steckt.
Ein paar Informationen zum Netzwerk-Interface:
Code:
root@pve01:~# ethtool -i enp45s0
driver: r8169
version:
firmware-version: rtl8168h-2_0.0.2 02/26/15
expansion-rom-version:
bus-info: 0000:2d:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

Mein Host ist top aktuell: Virtual Environment 6.4-8 und Kernel-Version: 5.4.119-1-pve

Hat jemand einen Plan was hier schief läuft?
 
Bitte sehr.
Code:
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

iface enp45s0 inet manual

iface enp42s0 inet manual

iface enp43s0 inet manual

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

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

auto vmbr2
iface vmbr2 inet manual
        bridge-ports enp43s0
        bridge-stp off
        bridge-fd 0
#External Interface
 
hm. Sieht eigentlich alles super aus. Fast die minimale Config.

Hast du noch andere Netzwerkkarten da?
 
kartoffelpü schrieb:
Nö, kein Plan was schief läuft. Aber ähnliche Sachen in Verbindung mit dem r8169 kann man zumindest ergoogeln:
https://askubuntu.com/questions/909213/ethernet-fails-to-initialize
https://forums.centos.org/viewtopic.php?t=46242
Das hab ich natürlich auch gemacht. Aber die Beiträge haben wir nicht weiter geholfen. Ich sitze auch schon seit heute morgen an dem Problem. :D
madmax2010 schrieb:
hm. Sieht eigentlich alles super aus. Fast die minimale Config.

Hast du noch andere Netzwerkkarten da?
Es ist neben dem Onboard-NIC noch eine Karte mit 2 NICs drin, welche jedoch aktiv verwendet wird. Einen Ersatz habe ich nicht da.
 
Ja, meine Container und VMs sind entweder untagged im internen Netz unterwegs oder tagged in einem isolierten Netzwerk.
 
Natriumchlorid schrieb:
Das hab ich natürlich auch gemacht. Aber die Beiträge haben wir nicht weiter geholfen. Ich sitze auch schon seit heute morgen an dem Problem.
Aber im ersten Link gibt es zumindest Workarounds.
Da du ja nicht allein mit solchen Problemen bist, könnte es halt "einfach" ein Hardware/Firmware/Modul-Bug sein.
Wäre mal interessant, ob das Problem auch bei einem beliebigen Live-Linux auftritt...
 
enp45s0 an vmbr0 ist dein reines Management VLAN? kannst du dort VLAN Aware entfernen und dir ein vlan inkl vmbr einrichten?
Ich hatte so ein Problem schon einmal, da hatte die NIC Probleme mit VLAN Aware. War mehr als seltsam, es kam nach einer Weile immer wieder zu Verbindungsabbrüchen.
 
was steht so in den proxmox logs? // halt mal pveproxy im auge:
journalctl -u pveproxy

Ist der Server alleine oder im Cluster?
in letzterem Fall gern auch mal ins Corosync log schauen.
 
kartoffelpü schrieb:
könnte es halt "einfach" ein Hardware/Firmware/Modul-Bug sein.
Ja, das vermute ich leider auch. Ich habe Beiträge gesehen, die das Problem wohl in neueren Kernel-Versionen gefixt haben (5.10 oder 5.11), aber das ist mit Proxmox keine Option, soweit ich weiß.
kartoffelpü schrieb:
Wäre mal interessant, ob das Problem auch bei einem beliebigen Live-Linux auftritt...
Das stimmt, ich werde das mal im Laufe des Tages testen.
dalini schrieb:
enp45s0 an vmbr0 ist dein reines Management VLAN? kannst du dort VLAN Aware entfernen und dir ein vlan inkl vmbr einrichten?
Die VLAN-Awareness für die vmbr0 habe ich raus genommen und die Kiste nochmal neu gestartet. Der Fehler trat diesmal erst eine Minute nach dem Reboot auf, was die Sache nur minimal verbessert. Interessant ist es allemal. Ich werde das im Auge behalten, ob das nach dem Reboot so konsistent bleibt, oder ob dies jetzt einfach nur Zufall gewesen ist.
madmax2010 schrieb:
Ist der Server alleine oder im Cluster?
Der Server ist alleine.
madmax2010 schrieb:
journalctl -u pveproxy
Leider erst nach dem Reboot gesehen, aber trotz des Auftretens sehe ich leider keinerlei nützliche Information.
Code:
-- Logs begin at Tue 2021-06-22 16:12:35 CEST, end at Tue 2021-06-22 16:21:05 CEST. --
Jun 22 16:12:42 pve01 systemd[1]: Starting PVE API Proxy Server...
Jun 22 16:12:43 pve01 pveproxy[1548]: starting server
Jun 22 16:12:43 pve01 pveproxy[1548]: starting 3 worker(s)
Jun 22 16:12:43 pve01 pveproxy[1548]: worker 1549 started
Jun 22 16:12:43 pve01 pveproxy[1548]: worker 1550 started
Jun 22 16:12:43 pve01 pveproxy[1548]: worker 1551 started
Jun 22 16:12:43 pve01 systemd[1]: Started PVE API Proxy Server.
 
Ich glaub ich hab das Problem gefunden.

Jedes Mal, wenn der Host nicht mehr auf Anfragen reagiert hatte, war auch das komplette Netzwerk down. Kein Gerät konnte mit dem anderen kommunizieren. Das hat den Verdacht geweckt, dass jemand im Netzwerk Unfug treibt.

Sobald also mein Netzwerk nicht mehr funktioniert hatte, hab ich ein Gerät nach dem anderen entfernt, um zu sehen, was passiert. Und siehe da, als mein Android Smart TV nicht mehr am Netzwerk hing, so löste sich der Knoten. Mein Netzwerk hat ohne Probleme funktioniert.

Keine Ahnung ob das eine Racheaktion seinerseits sein soll, dass er nicht mehr mit seinem heimischen DNS-Server kommunizieren darf. Aber es ist sehr interessant zu beobachten, wie nur ein Fernseher mein komplettes Netzwerk außer Kraft gesetzt hat.

Es ist auch perfekt reproduzierbar:
  • Fernseher hängt am Netz
  • Reboot des Servers
  • Nach einer Minute hängt alles
  • Fernseher wird vom Netz getrennt
  • Netzwerk funktioniert wieder

Ein Serverreboot ohne angeschlossenen Fernseher führt nicht zum Netzwerkausfall.

Den Server trifft also keine Schuld. :D
Danke an alle, die mir geholfen haben.
 
  • Gefällt mir
Reaktionen: Testa2014
Hallo @Natriumchlorid
ich habe GENAU das gleiche Verhalten meines Sony Fernsehers. Wenn er aus ist, komm ich wunderbar auf Proxmox, wenn er an ist, ist es aus ...
Wie hast du das behoben? Ich kann ja nicht immer den Fernseher ausschalten um auf Proxmox zugreifen zu können ....
 
Hallo @Homer-S
Behoben habe ich es leider nicht. Ich habe mich dazu entschlossen den Fernseher über WLAN anzubinden, da ich keinen grossen Durchsatz bei dem Gerät benötige. Seitdem traten die Fehler nicht mehr auf.
 
  • Gefällt mir
Reaktionen: Homer-S
Zurück
Oben