I've been successfully running a pretty simple two-tier network setup for awhile: a Mikrotik CHR and a Sophos Home UTM. These are connected together with a OVS bridge, the Mikrotik connects to my network (with several VLANs configured on the Mikrotik) via an OVS bridge that connects to a trunk port on my switch, and my internet connection is connected to an OVS bridge and connects to an interface on the Sophos.
I'm currently still successfully running this on 7.4, and have done for years.
However, every flavour of Proxmox 8 I've tried has given the following behaviour:
From my local segment, ping anything like the gateway IP of the VLAN or anything routed via the Mikrotik.
Put *any* kind of TCP load through the connection.
ICMP ping now indicates >300ms and in many cases more than 1500ms
This takes a minute to settle down after I stop the TCP traffic.
To continue running successfully, I currently still have one node in my cluster on 7.4, but I'd love to solve this for 8.
I've tried fresh installs, I've tried new hardware, I've tried disabling everything under the trunked interface via ethtool, I've tried disabling power management on the kernel--nothing fixes this. And it continues to work great on 7.4.
No incriminating messages in any logs I can find.
I'm very stumped at this point and would love another set of eyes or thoughts here, because this doesn't make for a workable environment:
(network running with very little traffic)
64 bytes from 192.168.10.1: icmp_seq=5498 ttl=64 time=0.571 ms
64 bytes from 192.168.10.1: icmp_seq=5499 ttl=64 time=0.844 ms
64 bytes from 192.168.10.1: icmp_seq=5500 ttl=64 time=0.586 ms
64 bytes from 192.168.10.1: icmp_seq=5501 ttl=64 time=0.727 ms
64 bytes from 192.168.10.1: icmp_seq=5502 ttl=64 time=0.827 ms
64 bytes from 192.168.10.1: icmp_seq=5503 ttl=64 time=0.863 ms
64 bytes from 192.168.10.1: icmp_seq=5504 ttl=64 time=0.770 ms
64 bytes from 192.168.10.1: icmp_seq=5505 ttl=64 time=0.221 ms
(started a basic dnf update session from a machine on the network)
64 bytes from 192.168.10.1: icmp_seq=5506 ttl=64 time=512 ms
64 bytes from 192.168.10.1: icmp_seq=5507 ttl=64 time=512 ms
64 bytes from 192.168.10.1: icmp_seq=5508 ttl=64 time=508 ms
64 bytes from 192.168.10.1: icmp_seq=5509 ttl=64 time=580 ms
64 bytes from 192.168.10.1: icmp_seq=5510 ttl=64 time=738 ms
64 bytes from 192.168.10.1: icmp_seq=5511 ttl=64 time=1068 ms
64 bytes from 192.168.10.1: icmp_seq=5512 ttl=64 time=1318 ms
64 bytes from 192.168.10.1: icmp_seq=5513 ttl=64 time=1717 ms
64 bytes from 192.168.10.1: icmp_seq=5514 ttl=64 time=1996 ms
64 bytes from 192.168.10.1: icmp_seq=5515 ttl=64 time=2245 ms
64 bytes from 192.168.10.1: icmp_seq=5516 ttl=64 time=2490 ms
Current hardware:
02:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I226-V [8086:125c] (rev 04)
03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I226-V [8086:125c] (rev 04)
04:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I226-V [8086:125c] (rev 04)
05:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I226-V [8086:125c] (rev 04)
But I'll say that I've used everything from i225-v and even various realtek USB NICs on different boxes -- I get the same behaviour on PVE8 but not 7. Same image used in both cases.
I'm currently still successfully running this on 7.4, and have done for years.
However, every flavour of Proxmox 8 I've tried has given the following behaviour:
From my local segment, ping anything like the gateway IP of the VLAN or anything routed via the Mikrotik.
Put *any* kind of TCP load through the connection.
ICMP ping now indicates >300ms and in many cases more than 1500ms
This takes a minute to settle down after I stop the TCP traffic.
To continue running successfully, I currently still have one node in my cluster on 7.4, but I'd love to solve this for 8.
I've tried fresh installs, I've tried new hardware, I've tried disabling everything under the trunked interface via ethtool, I've tried disabling power management on the kernel--nothing fixes this. And it continues to work great on 7.4.
No incriminating messages in any logs I can find.
I'm very stumped at this point and would love another set of eyes or thoughts here, because this doesn't make for a workable environment:
(network running with very little traffic)
64 bytes from 192.168.10.1: icmp_seq=5498 ttl=64 time=0.571 ms
64 bytes from 192.168.10.1: icmp_seq=5499 ttl=64 time=0.844 ms
64 bytes from 192.168.10.1: icmp_seq=5500 ttl=64 time=0.586 ms
64 bytes from 192.168.10.1: icmp_seq=5501 ttl=64 time=0.727 ms
64 bytes from 192.168.10.1: icmp_seq=5502 ttl=64 time=0.827 ms
64 bytes from 192.168.10.1: icmp_seq=5503 ttl=64 time=0.863 ms
64 bytes from 192.168.10.1: icmp_seq=5504 ttl=64 time=0.770 ms
64 bytes from 192.168.10.1: icmp_seq=5505 ttl=64 time=0.221 ms
(started a basic dnf update session from a machine on the network)
64 bytes from 192.168.10.1: icmp_seq=5506 ttl=64 time=512 ms
64 bytes from 192.168.10.1: icmp_seq=5507 ttl=64 time=512 ms
64 bytes from 192.168.10.1: icmp_seq=5508 ttl=64 time=508 ms
64 bytes from 192.168.10.1: icmp_seq=5509 ttl=64 time=580 ms
64 bytes from 192.168.10.1: icmp_seq=5510 ttl=64 time=738 ms
64 bytes from 192.168.10.1: icmp_seq=5511 ttl=64 time=1068 ms
64 bytes from 192.168.10.1: icmp_seq=5512 ttl=64 time=1318 ms
64 bytes from 192.168.10.1: icmp_seq=5513 ttl=64 time=1717 ms
64 bytes from 192.168.10.1: icmp_seq=5514 ttl=64 time=1996 ms
64 bytes from 192.168.10.1: icmp_seq=5515 ttl=64 time=2245 ms
64 bytes from 192.168.10.1: icmp_seq=5516 ttl=64 time=2490 ms
Current hardware:
02:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I226-V [8086:125c] (rev 04)
03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I226-V [8086:125c] (rev 04)
04:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I226-V [8086:125c] (rev 04)
05:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I226-V [8086:125c] (rev 04)
But I'll say that I've used everything from i225-v and even various realtek USB NICs on different boxes -- I get the same behaviour on PVE8 but not 7. Same image used in both cases.