Netzwerkproblem mit Proxmox PVE 9.06

C

CarstenKl

Member
Apr 11, 2022
15
1
8
Hallo zusammen,
ich habe im Homeoffice Proxmox laufen. Darauf läuft unter anderem eine pfsense, die auch die Einwahl ins Internet macht. Hierfür werden zwei Netzwerinterfaces direkt reingereicht (WAN + LAN und Co) und das LAN per Bridge angebunden.

Das hat mit Proxmox 8.x Jahrelang einwandfrei funktioniert.

Nach dem Update auf 9.05 vor ein paar Tagen kommt es immer wieder (immer nach einigen Std) dazu, dass weder Proxmox noch die pfsense netzwerktechnisch erreichbar ist (ping, ssh,web) usw.

Wie man hier auch durch checkmk sieht, ist das gerade gegen 13:25 Uhr wieder passiert.
Bildschirmfoto 2025-08-27 um 14.23.48.png

Ich muss sagen, dass ich auch aus dem Syslog hier leider nicht schlau werde, was die Ursache sein könnte.
Aug 27 13:00:34 pve24 systemd[1]: Started check-mk-agent@238-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:00:36 pve24 systemd[1]: check-mk-agent@238-1125-999.service: Deactivated successfully.
Aug 27 13:00:36 pve24 systemd[1]: check-mk-agent@238-1125-999.service: Consumed 1.334s CPU time, 48.4M memory peak.
Aug 27 13:01:34 pve24 systemd[1]: Started check-mk-agent@239-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:01:36 pve24 systemd[1]: check-mk-agent@239-1125-999.service: Deactivated successfully.
Aug 27 13:01:36 pve24 systemd[1]: check-mk-agent@239-1125-999.service: Consumed 1.286s CPU time, 48M memory peak.
Aug 27 13:02:34 pve24 systemd[1]: Started check-mk-agent@240-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:02:36 pve24 systemd[1]: check-mk-agent@240-1125-999.service: Deactivated successfully.
Aug 27 13:02:36 pve24 systemd[1]: check-mk-agent@240-1125-999.service: Consumed 1.280s CPU time, 48.2M memory peak.
Aug 27 13:03:34 pve24 systemd[1]: Started check-mk-agent@241-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:03:36 pve24 systemd[1]: check-mk-agent@241-1125-999.service: Deactivated successfully.
Aug 27 13:03:36 pve24 systemd[1]: check-mk-agent@241-1125-999.service: Consumed 1.284s CPU time, 48.2M memory peak.
Aug 27 13:03:44 pve24 pvedaemon[102540]: <root@pam> successful auth for user 'root@pam'
Aug 27 13:04:34 pve24 systemd[1]: Started check-mk-agent@242-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:04:36 pve24 systemd[1]: check-mk-agent@242-1125-999.service: Deactivated successfully.
Aug 27 13:04:36 pve24 systemd[1]: check-mk-agent@242-1125-999.service: Consumed 1.271s CPU time, 48.2M memory peak.
Aug 27 13:05:34 pve24 systemd[1]: Started check-mk-agent@243-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:05:36 pve24 systemd[1]: check-mk-agent@243-1125-999.service: Deactivated successfully.
Aug 27 13:05:36 pve24 systemd[1]: check-mk-agent@243-1125-999.service: Consumed 1.252s CPU time, 48.3M memory peak.
Aug 27 13:06:34 pve24 systemd[1]: Started check-mk-agent@244-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:06:36 pve24 systemd[1]: check-mk-agent@244-1125-999.service: Deactivated successfully.
Aug 27 13:06:36 pve24 systemd[1]: check-mk-agent@244-1125-999.service: Consumed 1.271s CPU time, 48.3M memory peak.
Aug 27 13:07:34 pve24 systemd[1]: Started check-mk-agent@245-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:07:36 pve24 systemd[1]: check-mk-agent@245-1125-999.service: Deactivated successfully.
Aug 27 13:07:36 pve24 systemd[1]: check-mk-agent@245-1125-999.service: Consumed 1.353s CPU time, 48.3M memory peak.
Aug 27 13:08:34 pve24 systemd[1]: Started check-mk-agent@246-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:08:36 pve24 systemd[1]: check-mk-agent@246-1125-999.service: Deactivated successfully.
Aug 27 13:08:36 pve24 systemd[1]: check-mk-agent@246-1125-999.service: Consumed 1.265s CPU time, 48.2M memory peak.
Aug 27 13:09:34 pve24 systemd[1]: Started check-mk-agent@247-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:09:36 pve24 systemd[1]: check-mk-agent@247-1125-999.service: Deactivated successfully.
Aug 27 13:09:36 pve24 systemd[1]: check-mk-agent@247-1125-999.service: Consumed 1.279s CPU time, 48.2M memory peak.
Aug 27 13:10:34 pve24 systemd[1]: Started check-mk-agent@248-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:10:36 pve24 systemd[1]: check-mk-agent@248-1125-999.service: Deactivated successfully.
Aug 27 13:10:36 pve24 systemd[1]: check-mk-agent@248-1125-999.service: Consumed 1.313s CPU time, 48.5M memory peak.
Aug 27 13:11:34 pve24 systemd[1]: Started check-mk-agent@249-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:11:36 pve24 systemd[1]: check-mk-agent@249-1125-999.service: Deactivated successfully.
Aug 27 13:11:36 pve24 systemd[1]: check-mk-agent@249-1125-999.service: Consumed 1.303s CPU time, 48.2M memory peak.
Aug 27 13:12:34 pve24 systemd[1]: Started check-mk-agent@250-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:12:36 pve24 systemd[1]: check-mk-agent@250-1125-999.service: Deactivated successfully.
Aug 27 13:12:36 pve24 systemd[1]: check-mk-agent@250-1125-999.service: Consumed 1.415s CPU time, 48.2M memory peak.
Aug 27 13:13:34 pve24 systemd[1]: Started check-mk-agent@251-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:13:36 pve24 systemd[1]: check-mk-agent@251-1125-999.service: Deactivated successfully.
Aug 27 13:13:36 pve24 systemd[1]: check-mk-agent@251-1125-999.service: Consumed 1.271s CPU time, 48.3M memory peak.
Aug 27 13:14:34 pve24 systemd[1]: Started check-mk-agent@252-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:14:36 pve24 systemd[1]: check-mk-agent@252-1125-999.service: Deactivated successfully.
Aug 27 13:14:36 pve24 systemd[1]: check-mk-agent@252-1125-999.service: Consumed 1.289s CPU time, 48.2M memory peak.
Aug 27 13:15:34 pve24 systemd[1]: Started check-mk-agent@253-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:15:36 pve24 systemd[1]: check-mk-agent@253-1125-999.service: Deactivated successfully.
Aug 27 13:15:36 pve24 systemd[1]: check-mk-agent@253-1125-999.service: Consumed 1.270s CPU time, 48.1M memory peak.
Aug 27 13:16:34 pve24 systemd[1]: Started check-mk-agent@254-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:16:36 pve24 systemd[1]: check-mk-agent@254-1125-999.service: Deactivated successfully.
Aug 27 13:16:36 pve24 systemd[1]: check-mk-agent@254-1125-999.service: Consumed 1.331s CPU time, 48.5M memory peak.
Aug 27 13:17:01 pve24 CRON[146475]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
Aug 27 13:17:01 pve24 CRON[146477]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Aug 27 13:17:01 pve24 CRON[146475]: pam_unix(cron:session): session closed for user root
Aug 27 13:17:34 pve24 systemd[1]: Started check-mk-agent@255-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:17:36 pve24 systemd[1]: check-mk-agent@255-1125-999.service: Deactivated successfully.
Aug 27 13:17:36 pve24 systemd[1]: check-mk-agent@255-1125-999.service: Consumed 1.255s CPU time, 48.6M memory peak.
Aug 27 13:18:34 pve24 systemd[1]: Started check-mk-agent@256-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:18:36 pve24 systemd[1]: check-mk-agent@256-1125-999.service: Deactivated successfully.
Aug 27 13:18:36 pve24 systemd[1]: check-mk-agent@256-1125-999.service: Consumed 1.264s CPU time, 48.3M memory peak.
Aug 27 13:19:34 pve24 systemd[1]: Started check-mk-agent@257-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:19:36 pve24 systemd[1]: check-mk-agent@257-1125-999.service: Deactivated successfully.
Aug 27 13:19:36 pve24 systemd[1]: check-mk-agent@257-1125-999.service: Consumed 1.282s CPU time, 48.1M memory peak.
Aug 27 13:20:34 pve24 systemd[1]: Started check-mk-agent@258-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:20:36 pve24 systemd[1]: check-mk-agent@258-1125-999.service: Deactivated successfully.
Aug 27 13:20:36 pve24 systemd[1]: check-mk-agent@258-1125-999.service: Consumed 1.294s CPU time, 48.3M memory peak.
Aug 27 13:21:34 pve24 systemd[1]: Started check-mk-agent@259-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:21:36 pve24 systemd[1]: check-mk-agent@259-1125-999.service: Deactivated successfully.
Aug 27 13:21:36 pve24 systemd[1]: check-mk-agent@259-1125-999.service: Consumed 1.335s CPU time, 48.5M memory peak.
Aug 27 13:21:54 pve24 pvedaemon[102995]: <root@pam> successful auth for user 'root@pam'
Aug 27 13:22:34 pve24 systemd[1]: Started check-mk-agent@260-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:22:36 pve24 systemd[1]: check-mk-agent@260-1125-999.service: Deactivated successfully.
Aug 27 13:22:36 pve24 systemd[1]: check-mk-agent@260-1125-999.service: Consumed 1.306s CPU time, 48.3M memory peak.
Aug 27 13:23:34 pve24 systemd[1]: Started check-mk-agent@261-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:23:36 pve24 systemd[1]: check-mk-agent@261-1125-999.service: Deactivated successfully.
Aug 27 13:23:36 pve24 systemd[1]: check-mk-agent@261-1125-999.service: Consumed 1.277s CPU time, 48.1M memory peak.
Aug 27 13:24:34 pve24 systemd[1]: Started check-mk-agent@262-1125-999.service - Checkmk agent (PID 1125/UID 999).
Aug 27 13:24:36 pve24 systemd[1]: check-mk-agent@262-1125-999.service: Deactivated successfully.
Aug 27 13:24:36 pve24 systemd[1]: check-mk-agent@262-1125-999.service: Consumed 1.278s CPU time, 48.1M memory peak.
Aug 27 13:26:54 pve24 pvedaemon[102995]: <root@pam> successful auth for user 'root@pam'
Aug 27 13:34:34 pve24 kernel: CIFS: VFS: \\10.0.100.91 has not responded in 180 seconds. Reconnecting...
Aug 27 13:37:54 pve24 pvedaemon[102540]: <root@pam> successful auth for user 'root@pam'
Aug 27 13:41:23 pve24 pveproxy[110955]: worker exit
Aug 27 13:41:23 pve24 pveproxy[1399]: worker 110955 finished
Aug 27 13:41:23 pve24 pveproxy[1399]: starting 1 worker(s)
Aug 27 13:41:23 pve24 pveproxy[1399]: worker 155005 started
Aug 27 13:42:15 pve24 pveproxy[117025]: worker exit
Aug 27 13:42:15 pve24 pveproxy[1399]: worker 117025 finished
Aug 27 13:42:15 pve24 pveproxy[1399]: starting 1 worker(s)
Aug 27 13:42:15 pve24 pveproxy[1399]: worker 155228 started
Aug 27 13:42:54 pve24 pvedaemon[92659]: <root@pam> successful auth for user 'root@pam'
Aug 27 13:53:54 pve24 pvedaemon[102995]: <root@pam> successful auth for user 'root@pam'
Click to expand...


proxmox-boot-tool status
Re-executing '/usr/sbin/proxmox-boot-tool' in new private mount namespace..
System currently booted with uefi
9353-9D68 is configured with: uefi (versions: 6.14.8-2-pve, 6.8.12-13-pve)
Click to expand...




inxi -CN
CPU:
Info: quad core model: Intel N100 bits: 64 type: MCP cache: L2: 2 MiB
Speed (MHz): avg: 2619 min/max: 700/3400 cores: 1: 2619 2: 2619 3: 2619 4: 2619
Network:
Device-1: Intel Ethernet I226-V driver: vfio-pci
Device-2: Intel Ethernet I226-V driver: vfio-pci
Device-3: Intel Ethernet I226-V driver: igc
Device-4: Intel Ethernet I226-V driver: igc
Click to expand...


Hier auch noch die Hardwareconfig der pfsense (2.8)
Bildschirmfoto 2025-08-27 um 14.26.59.png
Gestern habe ich noch ein Update auf 9.06 gemacht, allerdings hat dies leider nichts an dem Problem verändert.

Vielleicht hat ja jemand eine Idee oder das gleiche Problem. Vielen Dank!
 
Last edited:
Ich hatte bei meiner Recherche gerade noch hier den Hinweis gefunden offload-tso und offload-gso zu deaktivieren. Das habe ich testweise jetzt mal für alle interfacees auf dem Proxmox-Server getan.


O

Post in thread 'Proxmox 6.8.12-9-pve kernel has introduced a problem with e1000e Driver and network connection lost after some hours'

Proxmox 9.0.5 Debian Trixie (6.14.8-2) intel i219-LM the same problems with the network card freezing. And in Windows there were never such problems at all, only on Linux something happens. In general, the problem was solved with minimal edits to the file interfaces:

iface eno1 inet manual
offload-tso off
offload-gso off

I really didn't want to disable all the functionality of the network card due to problems in the Linux kernels and found this minimal set of changes that works
 
Bei Netzwerkverbindung alle paar Stunden weg denke ich sofort an das e1000 Problem. :D
CarstenKl said:
Das hat mit Proxmox 8.x Jahrelang einwandfrei funktioniert.
Click to expand...
Weißt Du zufällig noch welches der letzte von Dir genutze Kernel mit 8.x war und Frage zwei wäre dann was in Deiner Proxmox Kiste für eine NIC steckt? Falls es eine Intel NIC sein sollte könnte es durchaus an dem e1000 Problem liegen, welches je nach genutzer Kernel-Version immer mal wieder auftrifft. Bis Kernel-Version 6.8.12-8 war es mal eine Zeit lang weg und seit Kernel Version 6.8.12-9 tritt es wieder auf.

Siehe dazu die div. Diskussionen hier im Forum. Z.B.: https://forum.proxmox.com/threads/e1000-driver-hang.58284/

BTW: Mit meiner Intel I219-LM (Rev.-Version wird leider nicht angezeigt) in meiner Fujitsu Kiste gibt es das Problem nicht. *** Dreimal auf Holz klopf. *** :D

VG JIm
 
Last edited:
Mhmm den Kernel bei der 8.x kann ich leider nicht mehr sagen, tut mir leid.
Netzwerkkarte ist 4 x 2.5GbE I226-V.
 
OK zu der I226-V kann ich leider gar nichts sagen, sprich ob es damit ggf. auch das e1000 Problem gibt oder halt nicht. Hast Du hier im Forum auch schon mal einfach nach I226-V gesucht, ob und wenn ja welche Probleme dazu ggf. bekannt sind.

PS: Sorry ich hatte die vorhandene Angabe zu der I226-V in Deinem ersten Posting übersehen. :)

VG Jim
 
Muss eigentlich offload tso und gso auch für die Bridge gesetzt werden oder nur für die einzelnen interfaces?
Aktuell sieht meine Netzwerkconfig so aus.

auto lo
iface lo inet loopback

iface enp3s0 inet manual
offload-tso off
offload-gso off

iface enp1s0 inet manual
offload-tso off
offload-gso off

iface enp2s0 inet manual
offload-tso off
offload-gso off

iface enp4s0 inet manual
offload-tso off
offload-gso off

auto vmbr0
iface vmbr0 inet static
address 10.0.100.24/24
gateway 10.0.100.1
bridge-ports enp3s0
bridge-stp off
bridge-fd 0


auto vmbr1
iface vmbr1 inet manual
bridge-ports enp4s0
bridge-stp off
bridge-fd 0


source /etc/network/interfaces.d/*
Click to expand...

@jim_os Leider nein, zu exakt der Karte habe ich leider nichts gefunden.
 
Ich hatte Probleme mt einem NU14 und dem 226.
R

Thread 'NUC14 i226 LAN Performance fix'

Information:
I use a NUC14Pro with i226 as my homeserver.
The network performance was not very stable.
As usual the ASPM was the problem with stable 6.8.12-11.
I solved it by adding
crontab -e
@reboot echo 0 > /sys/bus/pci/devices/0000:57:00.0/link/l1_aspm
Check the PCIe ID
In Bios all other aspm can still be active and save same power
  • Like
Evtl hilft das bei dir auch.
 
Hallo, frage warum hat vmbr1 eine Netzwerkinterface enp4s0?
Code: 
auto vmbr1
iface vmbr1 inet manual
       bridge-ports enp4s0
       bridge-stp off
       bridge-fd 0
Was soll/ wird dadurch erreicht?
Wird auf das vmbr1 an eine LXC oder VM gebunden?
Wie sieht dann das Netzwerksegment aus?
 
news said:
Hallo, frage warum hat vmbr1 eine Netzwerkinterface enp4s0?
Code: 
auto vmbr1
iface vmbr1 inet manual
       bridge-ports enp4s0
       bridge-stp off
       bridge-fd 0
Was soll/ wird dadurch erreicht?
Wird auf das vmbr1 an eine LXC oder VM gebunden?
Wie sieht dann das Netzwerksegment aus?
Click to expand...
Ich weiß nicht wo du das mit der vmbr1 gefunden hast, aber wenn da ein eigenes Netz für bestimmte VMs dran hängt, muss der Host doch gar nichts über ein Netzwerksegment wissen.
 
rage said:
Ich hatte Probleme mt einem NU14 und dem 226.
R

Thread 'NUC14 i226 LAN Performance fix'

Information:
I use a NUC14Pro with i226 as my homeserver.
The network performance was not very stable.
As usual the ASPM was the problem with stable 6.8.12-11.
I solved it by adding
crontab -e
@reboot echo 0 > /sys/bus/pci/devices/0000:57:00.0/link/l1_aspm
Check the PCIe ID
In Bios all other aspm can still be active and save same power
  • Like
Evtl hilft das bei dir auch.
Click to expand...
Super, danke für den Hinweis, wenn sich das Problem wiederholt, werde ich es testen. Seit gestern läuft es jetzt erstmal.
 
news said:
Hallo, frage warum hat vmbr1 eine Netzwerkinterface enp4s0?
Code: 
auto vmbr1
iface vmbr1 inet manual
       bridge-ports enp4s0
       bridge-stp off
       bridge-fd 0
Was soll/ wird dadurch erreicht?
Wird auf das vmbr1 an eine LXC oder VM gebunden?
Wie sieht dann das Netzwerksegment aus?
Click to expand...
Es kann gut sein, dass hier ein Fehler liegt, allerdings funktioniert es erstmal so, wie gewünscht.

Auf dem Interface enp4s0 sind verschiedene VLANs, welche ich verschiedenen VMs zur Verfügung stelle. Der Host selber braucht (aus meiner Sicht) keine IP aus diesem Netz, da er da nicht drüber kommunizieren soll. Für ihn reicht das vmbr0, welches mein Lan ist.

Das vmbr1 enthält verschiedene VLANs, welche ich dann auf der pfsense entsprechend auflöse (im Grunde verschiedene WLANs). Sieht man hier auch.
Bildschirmfoto 2025-08-28 um 14.28.51.png

Wobei das igc0 das WAN ist (direkt reingereicht), igc1 das LAN (ebenfalls direkt reingereicht), der Rest (siehe Screenshot) kommt über vmbr1.

Aber vielleicht nochmal die, ist offload-tso off und offload-gso off auch auf der Bridge vmbr0 und vmbr1 notwendig?
An der Stelle schonmal ganz lieben Dank für eure Hilfe soweit!! :)
 
Leider trat noch immer das Problem auf, ich habe jetzt noch den Tipp von Rage befolgt und aspm für die Interfaces deaktivieren wollen.

Das hat leider nicht geklappt, hier kam immer ein Permission denied,
@reboot echo 0 > "/sys/bus/pci/devices/0000:01:00.0/link/1_aspm"

also habe ich es komplett deaktiviert.

/etc/default/grub
# Zeile ergänzt
pcie_aspm=off


sudo update-grub
reboot
Click to expand...

Seit gestern ist es dann nicht mehr aufgetreten, mal abwarten.
 
Du musst schauen ob das device dein NIC ist oder was anderes.
 
Last edited:
hehe, ja das ist schon klar ;)
Ist aber auch. egal jetzt, habe es komplett deaktiviert.

root@pve24:~# lspci
...
01:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
02:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
03:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
04:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
...


root@pve24:~# ls -lh /sys/bus/pci/devices/0000:01:00.0/link/
total 0
 
CarstenKl said:
Das hat leider nicht geklappt, hier kam immer ein Permission denied,
Click to expand...
Bevor ich am proxmox was fummel, schalte ich sowas lieber komplett im BIOS.

Vorschlag: im BIOS ASPM komplett deaktivieren, mal 2-3 Tage so laufen lassen und beobachten. Wenn das klappt, L0-only setzen und länger testen.

Neuere firmware flashen wird auch hier sicher nicht schaden: https://www.intel.com/content/www/u...t-utility-preboot-images-and-efi-drivers.html
Vielleicht findet sich in den release notes sogar was zu neueren kernels.
 
Wenn Du die Interfaces in die pfSense durchgereicht hast, wundert es mich nicht. OpnSense, was auch FreeBSD als Basis hernimmt, hat aktuell massive Probleme mit Intel-Netzwerkadaptern, wenn ASPM aktiv ist (gilt für bare metal). Wann immer solche Probleme auftreten, ist im OpnSense-Forum der Tipp, erstmal ASPM abzuschalten - obwohl auf den China-Boxen das BIOS das meist nicht zulässt. Ich hatte das Problem sowohl mit I226-V (igc) als auch mit ES82559 (ix).

Eventuell hilft, virtio Netwerkadapter für alles zu nehmen, weil der Linux-Support oft besser ist.
 
  • Like
Reactions: Johannes S
mr44er said:
Bevor ich am proxmox was fummel, schalte ich sowas lieber komplett im BIOS.

Vorschlag: im BIOS ASPM komplett deaktivieren, mal 2-3 Tage so laufen lassen und beobachten. Wenn das klappt, L0-only setzen und länger testen.

Neuere firmware flashen wird auch hier sicher nicht schaden: https://www.intel.com/content/www/u...t-utility-preboot-images-and-efi-drivers.html
Vielleicht findet sich in den release notes sogar was zu neueren kernels.
Click to expand...
Bin ich bei dir und hätte ich auch gemacht, wie aber @meyergru schon vermutet hat, gibt es die Möglichkeit bei dem China-Teil leider nicht. Also blieb mir leider nur noch der Weg. :(

Die Firmware scheint mir nicht für meinen Adapter geeignet zu sein, aber ich schau mal nach dem passenden, danke!
 
meyergru said:
Wenn Du die Interfaces in die pfSense durchgereicht hast, wundert es mich nicht. OpnSense, was auch FreeBSD als Basis hernimmt, hat aktuell massive Probleme mit Intel-Netzwerkadaptern, wenn ASPM aktiv ist (gilt für bare metal). Wann immer solche Probleme auftreten, ist im OpnSense-Forum der Tipp, erstmal ASPM abzuschalten - obwohl auf den China-Boxen das BIOS das meist nicht zulässt. Ich hatte das Problem sowohl mit I226-V (igc) als auch mit ES82559 (ix).

Eventuell hilft, virtio Netwerkadapter für alles zu nehmen, weil der Linux-Support oft besser ist.
Click to expand...
Ah, das würde es erklären, warum aktuell gerade Ruhe ist, danke! Ja, ich habe zwei Interfaces direkt reingereicht.

Ich hatte gestern auch überlegt das umzustellen von pass trough auf virtio-bridges, allerdings war ich mir unklar, ob das dann noch so einfach mit dem WAN-Interface klappt (Telekom Glasfaser), die PPPOE-Einwahl macht die Pfsense. Kann das funktionieren für das WAN interface?
 
You must log in or register to reply here.
Top Bottom