Opnsense IPv6 Problem

kroerig

New Member
Dec 8, 2024
8
0
1
Hallo zusammen,

ich kämpfe seit ein paar Monaten mit einem Problem und finde keinen Fehler.

Ich hatte bisher alles unter dem freien ESXi laufen. Da die Hardware aber zu klein für weitere Aufgaben war, habe ich mir so kleinen Barebone auf Intel Alder Lake-N 12th Gen N100 Basis mit 4 NICs geholt und darauf Proxmox installiert.
Abgesehen davon, dass mir Proxmox immer mal wieder mit einem Kernelpanic aussteigt (warum sehe ich leider nicht), kämpfe ich aber mit folgenden:

Nach dem Start ist erstmal alles normal und ich komme über IPv4 und IPv6 ins Internet. Aber irgendwann (keine feste Zeit, können 15 Minuten aber auch 24h sein), funktioniert kein IPv6 mehr. Also die Endgeräte haben weiter IPv6 Adressen, aber es geht keine Daten mehr durch. Dann muss ich die OPNSense VM neustarten und dann geht es wieder eine Zeit lang. Unter VMware ESXi hatte ich dieses Verhalten nicht.


Die OPNsense VM hat drei E1000-Interfaces:
em0 -> LAN
em1 -> WAN (PPPoE)
em2 -> DMZ

LAN und DMZ liegen in Proxmox auf der vmbr0 mit "VLAN aware" aktiviert.
LAN landet im untagged VLAN, DMZ in VLAN 100 (tagged).
Auf der vmbr0 im untagged VLAN liegt auch die Proxmox IPv4-Adresse.
vmbr0 ist an die erste NIC gebunden.

WAN landet in vmbr1 (kein VLAN) und ist auf die zweite NIC gebunden (kleine IP). An dem Port hängt direkt mein DSL Modem.

Hat jemand eine Idee, was hier die Ursache sein könnte, oder kennt das Verhalten vielleicht?

Zu Anfang hatte ich VirtIO Interfaces genommen. Dachte es liegt vielleicht daran und habe auf E1000 umgestellt.

Danke & Gruß
Klaus
 
Hallo Klaus, deine Phänomene kenne ich gar nicht und OPNsense läuft bei mir und bei bekannten überall mit VirtIO ohne Probleme.
Welche Netzwerkkarten hat denn dein Barebone?
IPv6 kann ich nicht testen, da mein Provider das nicht kann, aber bei bekannten läuft das auch seit Jahren ohne Probleme.

Wenn du Kernel Panics hast, dann sammle mal die Logs und eventuell hängen die beiden Probleme zusammen.
 
Das sind 4x Intel Corporation Ethernet Controller I226-V (rev 04)

Wie komme ich denn an die Logs?
 
Hilfreich wäre /var/log/syslog und die Uhrzeit wann es passiert ist.
 
Wenn dein PVE kein syslog schreibt, hast du irgend ein größeres Problem. Jedes Linux schreibt ein syslog.
 
Also, Logeinträge vom letzten Crash habe ich gefunden:

Code:
Dec 03 16:28:48 pve kernel: BUG: unable to handle page fault for address: ffff8e5c91378718
Dec 03 16:28:48 pve kernel: #PF: supervisor read access in kernel mode
Dec 03 16:28:48 pve kernel: #PF: error_code(0x0000) - not-present page
Dec 03 16:28:48 pve kernel: PGD 5ede01067 P4D 5ede01067 PUD 0
Dec 03 16:28:48 pve kernel: Oops: 0000 [#1] PREEMPT SMP NOPTI
Dec 03 16:28:48 pve kernel: CPU: 2 PID: 923 Comm: pve-firewall Tainted: P           O       6.8.12-4-pve #1
Dec 03 16:28:48 pve kernel: Hardware name: Default string Default string/Default string, BIOS 5.27 03/07/2024
Dec 03 16:28:48 pve kernel: RIP: 0010:kmem_cache_alloc+0xce/0x370
Dec 03 16:28:48 pve kernel: Code: 83 78 10 00 48 8b 38 0f 84 48 02 00 00 48 85 ff 0f 84 3f 02 00 00 41 8b 44 24 28 49 8b 9c 24 b8 00 00 00 49 8b 34 24 48 01 f8 <48> 33 18 48 89 c1 48 89 f8 48 0f c9 48 31 cb 48>
Dec 03 16:28:48 pve kernel: RSP: 0018:ffffa566437b3960 EFLAGS: 00010286
Dec 03 16:28:48 pve kernel: RAX: ffff8e5c91378718 RBX: 25e8e4fb12cc16bc RCX: 0000000000000000
Dec 03 16:28:48 pve kernel: RDX: 0000014a0519e002 RSI: 000000000003cfe0 RDI: ffff8e5c91378708
Dec 03 16:28:48 pve kernel: RBP: ffffa566437b39a8 R08: 0000000000000000 R09: 0000000000000000
Dec 03 16:28:48 pve kernel: R10: ffff8e54871c4a80 R11: 0000000000000000 R12: ffff8e54801e0b00
Dec 03 16:28:48 pve kernel: R13: 0000000000000cc0 R14: 0000000000000028 R15: ffffffff9fae681f
Dec 03 16:28:48 pve kernel: FS:  00007474fe1e0b80(0000) GS:ffff8e5bdfb00000(0000) knlGS:0000000000000000
Dec 03 16:28:48 pve kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 03 16:28:48 pve kernel: CR2: ffff8e5c91378718 CR3: 000000010160c004 CR4: 0000000000f72ef0
Dec 03 16:28:48 pve kernel: PKRU: 55555554

Aber die hat nichts mit dem IPv6 Verlust zutun.
 
was für einen Ram hast du in den Barebone gepackt?
Is das so ein China Barebone mit SO-DIMM Slot für DDr5 ?
 
ok, also auch mit dem corsair ram? ich frage deshalb, da es bei diesen Geräten Probleme mit den Crucial Rams bestimmter Serien gibt, durfte ich selbst auch feststellen.
 
Debian 12 nicht mehr per Default.
Schreiben tut er das trotzdem, nur dann per journalctl -u syslog abrufbar. Dann hast du den PVE nicht von der ISO sonder on Top auf ein Debian installiert?
 
nein. Frisch von der ISO bzw. Stick.

Code:
# dmidecode 3.4
Getting SMBIOS data from sysfs.
SMBIOS 3.5.0 present.

Handle 0x0027, DMI type 16, 23 bytes
Physical Memory Array
        Location: System Board Or Motherboard
        Use: System Memory
        Error Correction Type: None
        Maximum Capacity: 64 GB
        Error Information Handle: Not Provided
        Number Of Devices: 2

Handle 0x0028, DMI type 17, 92 bytes
Memory Device
        Array Handle: 0x0027
        Error Information Handle: Not Provided
        Total Width: 64 bits
        Data Width: 64 bits
        Size: 32 GB
        Form Factor: SODIMM
        Set: None
        Locator: Controller0-ChannelA-DIMM0
        Bank Locator: BANK 0
        Type: DDR5
        Type Detail: Synchronous
        Speed: 4800 MT/s
        Manufacturer: Corsair
        Serial Number: 00000000
        Asset Tag: 9876543210
        Part Number: CMSX32GX5M1A4800C40
        Rank: 2
        Configured Memory Speed: 4800 MT/s
        Minimum Voltage: 1.1 V
        Maximum Voltage: 1.1 V
        Configured Voltage: 1.1 V
        Memory Technology: DRAM
        Memory Operating Mode Capability: Volatile memory
        Firmware Version: Not Specified
        Module Manufacturer ID: Bank 3, Hex 0x9E
        Module Product ID: Unknown
        Memory Subsystem Controller Manufacturer ID: Unknown
        Memory Subsystem Controller Product ID: Unknown
        Non-Volatile Size: None
        Volatile Size: 32 GB
        Cache Size: None
        Logical Size: None

Ich hab die Logeinträge ja auch gefunden.

Die Crashs könnten aber auch davon gekommen sein, dass ich Docker in einem LXC laufen hatte und dem irgendwann die Inodes ausgingen. Jetzt läuft Docker in einer VM. Das beobachte ich jetzt mal.

Aber die eigentliche Frage war ja: Warum funktioniert mein IPv6 plötzlich nicht mehr. Das Problem hatte ich unter ESXi nicht und ich habe die Konfig der OPNSense ja 1:1 übernommen.
 
Die Crashs könnten aber auch davon gekommen sein, dass ich Docker in einem LXC laufen hatte und dem irgendwann die Inodes ausgingen. Jetzt läuft Docker in einer VM. Das beobachte ich jetzt mal.
Klingt plausibel.
Aber die eigentliche Frage war ja: Warum funktioniert mein IPv6 plötzlich nicht mehr. Das Problem hatte ich unter ESXi nicht und ich habe die Konfig der OPNSense ja 1:1 übernommen.
Eventuell OPNsense Updates gemacht, ich hatte so halb gelesen, dass ein paar Sachen bei IPv6 angepasst wurden, bin da aber nicht wirklich im Thema.
 
So, nach dem Umzug von Docker vom LCX in eine VM crashed jetzt nicht mehr das ganze System, sondern nur noch die VM.

Daher habe ich gerade mal Memtest laufen lassen, dass mir bei 24GB Speicherfehler gemeldet hat. Leider verweist mich das große A nur an den Cosair Support für Hilfe.

Hat jemand Erfahrung, ob der "Corsair VENGEANCE SODIMM DDR5 RAM 32GB" generell Probleme macht? Dann würde ich ggf. einen anderen kaufen.

Nachtrag: Hier lese ich gerade, dass der Hersteller Probleme mit diesem RAM nennt. Man soll Crucial, Samsung, Hynix usw. verwenden. Bei Crucial aber keine 23xx-Zyklen-RAMs.
 
Last edited:
Hat jemand Erfahrung, ob der "Corsair VENGEANCE SODIMM DDR5 RAM 32GB" generell Probleme macht? Dann würde ich ggf. einen anderen kaufen.

Nachtrag: Hier lese ich gerade, dass der Hersteller Probleme mit diesem RAM nennt. Man soll Crucial, Samsung, Hynix usw. verwenden. Bei Crucial aber keine 23xx-Zyklen-RAMs.

Ich hab einen "CWWK X86-P5", ebenfalls mit N100, hier und anfangs mit dem "Corsair Vengeance SO-DIMM 16GB, DDR5-4800, CL40-40-40-77, on-die ECC" (CMSX16GX5M1A4800C40) getestet, welcher fortwährend zu Fehlern im Memtest geführt hat. Mal nach kurzer Zeit; teils aber auch erst nach zig Stunden/Durchläufen.

Hab jetzt den "Crucial SO-DIMM 16GB, DDR5-4800, CL40-39-39, on-die ECC" (CT16G48C40S5) drin, welcher über 36 Stunden Memtest-stabil war und nun seit Anfang des Jahres 24/7 problemlos läuft.

YMMV...

BTW: Der N100 unterstützt In-band ECC. Könnte man sich ebenfalls überlegen zusätzlich (zu Memtest-stabilem RAM) zu aktivieren; vorausgesetzt das Bios/UEFI gibt es her...
 
Wenn dein PVE kein syslog schreibt, hast du irgend ein größeres Problem. Jedes Linux schreibt ein syslog.
Debian Bookworm nicht mehr, solange man nicht explizit das durch Installation des rsyslogd ändert. Da wird nur noch der journald genommen:
Das deckt sich mit den Zustand meiner auf Bookworm basierenden PVE und PBS-Installationen.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!