Paketverlust bei Verwendung beider NICs auf einer Dual Port PCIe Netzwerkkarte

[Reason2040]

Ich habe bei meinem Proxmox Server eine Dual Port PCIe Netzwerkkarte installiert und habe ein reproduzierbares Problem mit Paketverlust, sobald beide NICs in Verwendung sind.
Als das Problem aufgetreten ist und ich es nicht lösen konnte, bin ich von einem HW Defekt ausgegangen und habe eine zweite Dual Port Netzwerkkarte organisiert, jedoch tritt bei dieser separaten Karte genau das gleiche Phänomen auf.

Vorhandene NICs:

1x 2.5 GbE direkt vom Mainboard
1x 1 GbE USB 3.0 Netzwerkadapter
2x 1 GbE Broadcom BCM5720 (Dual Port PCIe Netzwerkkarte)
2x 1 GbE Intel Corporation 82575EB (Dual Port PCIe Netzwerkkarte)

Ich habe total 4 vmbr Interfaces von denen ich das Problem mit vmbr1 und vmbr2 nachstellen kann.
Wenn die beiden vmbr an unterschiedliche HW separater Controller assoziiert sind, so wie im Beispiel unten, funktioniert alles einwandfrei.
Sobald ich jedoch beide Bridges am gleichen Controller hängen, an unterschiedlichen Interfaces, habe ich auf einem der beiden Bridges Paketverluste.
Der Paketverlust tritt jeweils auf der vmbr auf, die als 2. konfiguriert wurde, als würde Proxmox nicht klarkommen, wenn mehrere Bridges auf einer PCIe Schnittstelle laufen.

Beispiel:

vmbr1 auf enp4s0f0
vmbr2 auf ens8f1
Resultat: OK

vmbr1 auf enp4s0f1
vmbr2 auf ens8f0
Resultat: OK

vmbr1 auf ens8f0
vmbr2 auf enp4s0f0
Resultat: OK

vmbr1 auf ens8f1
vmbr2 auf enp4s0f1
Resultat: OK

vmbr1 auf enp4s0f0
vmbr2 auf enp4s0f1
Resultat: Paketverlust auf der vmbr, die als 2. konfiguriert wurde.

vmbr1 auf enp4s0f1
vmbr2 auf enp4s0f0
Resultat: Paketverlust auf der vmbr, die als 2. konfiguriert wurde.

vmbr1 auf ens8f0
vmbr2 auf ens8f1
Resultat: Paketverlust auf der vmbr, die als 2. konfiguriert wurde.

vmbr1 auf ens8f1
vmbr2 auf ens8f0
Resultat: Paketverlust auf der vmbr, die als 2. konfiguriert wurde.

root@Proxmox:~# cat /etc/network/interfaces
# 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 enp3s0 inet manual

iface enp4s0f0 inet manual

iface enp4s0f1 inet manual

iface enx9cebe8153735 inet manual

iface ens8f0 inet manual

iface ens8f1 inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.1.55/24
gateway 192.168.1.1
bridge-ports enp3s0
bridge-stp off
bridge-fd 0
#LAN

auto vmbr1
iface vmbr1 inet manual
bridge-ports enp4s0f0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 172,255,999
#Trunk

auto vmbr2
iface vmbr2 inet manual
bridge-ports ens8f1
bridge-stp off
bridge-fd 0
#WAN

auto vmbr3
iface vmbr3 inet manual
bridge-ports enx9cebe8153735
bridge-stp off
bridge-fd 0
#USB

source /etc/network/interfaces.d/*

root@Proxmox:~# lspci -nn | grep Ethernet
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 05)
04:00.0 Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe [14e4:165f]
04:00.1 Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe [14e4:165f]
05:00.0 Ethernet controller [0200]: Intel Corporation 82575EB Gigabit Network Connection [8086:10a7] (rev 02)
05:00.1 Ethernet controller [0200]: Intel Corporation 82575EB Gigabit Network Connection [8086:10a7] (rev 02)

root@Proxmox:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
link/ether d8:43:ae:18:28:01 brd ff:ff:ff:ff:ff:ff
3: enp4s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr1 state UP group default qlen 1000
link/ether 00:0a:f7:90:07:ec brd ff:ff:ff:ff:ff:ff
4: enp4s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:0a:f7:90:07:ed brd ff:ff:ff:ff:ff:ff
5: ens8f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:25:90:35:ef:d2 brd ff:ff:ff:ff:ff:ff
altname enp5s0f0
inet6 fe80::225:90ff:fe35:efd2/64 scope link
valid_lft forever preferred_lft forever
6: ens8f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr2 state UP group default qlen 1000
link/ether 00:25:90:35:ef:d3 brd ff:ff:ff:ff:ff:ff
altname enp5s0f1
7: enx9cebe8153735: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master vmbr3 state DOWN group default qlen 1000
link/ether 9c:eb:e8:15:37:35 brd ff:ff:ff:ff:ff:ff
8: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether d8:43:ae:18:28:01 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.55/24 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::da43:aeff:fe18:2801/64 scope link
valid_lft forever preferred_lft forever
9: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:0a:f7:90:07:ec brd ff:ff:ff:ff:ff:ff
inet6 fe80::20a:f7ff:fe90:7ec/64 scope link
valid_lft forever preferred_lft forever
10: vmbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:25:90:35:ef:d3 brd ff:ff:ff:ff:ff:ff
inet6 fe80::225:90ff:fe35:efd3/64 scope link
valid_lft forever preferred_lft forever
11: vmbr3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 9c:eb:e8:15:37:35 brd ff:ff:ff:ff:ff:ff
inet6 fe80::9eeb:e8ff:fe15:3735/64 scope link
valid_lft forever preferred_lft forever

 

[Falk R.]

Hi,
eigentlich darf das nicht vorkommen und ich habe soetwas auch noch nicht gesehen.
Was ich mir vorstellen könnte, wenn das PCIe3 Karten sind und auf einem PCIe2 Steckplatz stecken, kann das schon mal zu Problemen kommen.
Gib mal mehr Infos zum Rechner.
Manchmal hilft auch ein BIOS Update.

 

[Reason2040]

Hi,
eigentlich darf das nicht vorkommen und ich habe soetwas auch noch nicht gesehen.
Was ich mir vorstellen könnte, wenn das PCIe3 Karten sind und auf einem PCIe2 Steckplatz stecken, kann das schon mal zu Problemen kommen.
Gib mal mehr Infos zum Rechner.
Manchmal hilft auch ein BIOS Update.

Hallo Falk,
Danke für die Rückmeldung. Es handelt sich konkret um eine Supermicro AOC-SG-I2 2-Port Gigabit Ethernet PCIe und eine Broadcom NetXtreme® BCM5720 Dual-Port 1 Gigabit PCIe Karte. BIOS habe ich bereits aktualisiert.

Mainboard: MSI PRO B760-P DDR4 II
CPU: Intel® Core™ i5-13600T
RAM: Corsair DDR4 Vengeance LPX 64GB

Ansonsten keine andere Hardware und oder Steckkarten installiert.

 

[Falk R.]

Bei der aktuellen Hardware sollte das nicht vorkommen. Ich vermute mal das bestimmt irgend ein Offloading der NIC schuld ist, aber da bin ich thematisch raus.

 

[Reason2040]

Danke für den Hinweis. Hab mal versucht bei beiden Netzwerk Adaptern sämtliche Offloading Features einzuschalten und zu testen und dann sämtliche Offloading Features zu deaktivieren und erneut zu testen. Hat leider beides das Problem nicht gelöst.

root@Proxmox:~# ethtool -k enp4s0f0
Features for enp4s0f0:
rx-checksumming: off
tx-checksumming: off
tx-checksum-ipv4: off
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: off
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: off
tx-scatter-gather: off
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
tx-tcp-segmentation: off
tx-tcp-ecn-segmentation: off
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: off
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on [fixed]
tx-vlan-offload: on [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
tx-gso-list: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
rx-udp-gro-forwarding: off
hsr-tag-ins-offload: off [fixed]
hsr-tag-rm-offload: off [fixed]
hsr-fwd-offload: off [fixed]
hsr-dup-offload: off [fixed]

 

[Falk R.]

Dann habe ich auch keine Idee dazu, eventuell hat ja jemand anderes eine Idee dazu.

 

[khe]

Aktiviere mal spaßeshalber bei enp4s0f0 und enp4s0f1 bzw. ens8f0 und ens8f1 Autostart in den Netzwerkeinstelliungen.

 

[Reason2040]

Wie es scheint, war es ein Problem mit der vmbr1 und vmbr2, welches ich mir aber nicht erklären kann.

Habe beide Bridges gelöscht und neue Interfaces mit anderen Namen erstellt, die genau gleich wie vorhin an die physischen Schnittstellen gebunden sind. Nun funktioniert es auf wundersame Weise wie es sollte.

Ich werde es mal so laufen lassen und beobachten, ob es auch die nächsten Tage stabil läuft.

# 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 enp3s0 inet manual
#Mainboard 2.5 GbE

iface enp4s0f0 inet manual
#Broadcom Port 1

iface enp4s0f1 inet manual
#Broadcom Port 2

iface enx9cebe8153735 inet manual
#USB Network Adapter

iface ens8f0 inet manual
#Supermicro Port 1

iface ens8f1 inet manual
#Supermicro Port 2

auto vmbr0
iface vmbr0 inet static
address 192.168.1.55/24
gateway 192.168.1.1
bridge-ports enp3s0
bridge-stp off
bridge-fd 0
#LAN

auto trunk1
iface trunk1 inet manual
bridge-ports ens8f0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 172,255,999
#Trunk

auto wan1
iface wan1 inet manual
bridge-ports ens8f1
bridge-stp off
bridge-fd 0
#WAN

source /etc/network/interfaces.d/*

 

[Reason2040]

Zu früh gefreut... Hat zwar funktioniert, jedoch wurde bei einem Interface nur ein Link Speed von 10Mbit/s bzw. nach ein- und ausstecken 100Mbit/s anstelle 1Gbit/s ausgehandelt. Somit scheint weiterhin irgendein komisches Problem vorhanden zu sein.

 

[Falk R.]

Zu früh gefreut... Hat zwar funktioniert, jedoch wurde bei einem Interface nur ein Link Speed von 10Mbit/s bzw. nach ein- und ausstecken 100Mbit/s anstelle 1Gbit/s ausgehandelt. Somit scheint weiterhin irgendein komisches Problem vorhanden zu sein.

Wenn du soetwas hast, solltest du zuerst das Kabel checken/tauschen und im schlimmsten Fall ist ein Port defekt.

 

[Reason2040]

Danke für die Rückmeldung. Hab ich auch bereits versucht. Der Port funktioniert weinwandfrei, wenn der Port einzeln verwendet wird. Das Problem tritt wirklich nur auf, wenn von einer PCIe Steckkarte beide NIC in Verwendung sind.

 

[Falk R.]

Was für einen Switch nutzt du und wie sieht denn die Konfiguration aus?

 

[Reason2040]

Ist ein Cisco Small Business Switch (CBS250-8PP-D). Hab dort auch bereits mit Port Aushandlung herumgespielt, STP deaktiviert, EEE deaktiviert usw.
Port GE1 ist mit angepassten Einstellungen, Port GE8 ist mit Default Einstellungen damit ich umstecken und testen kann. Bei beiden das gleiche Verhalten.

interface GigabitEthernet1
flowcontrol auto
negotiation preferred master
switchport mode trunk
switchport access vlan none
switchport trunk native vlan none
switchport trunk allowed vlan 172,255,999
!
interface GigabitEthernet4
switchport trunk allowed vlan 172,255,999
!
interface GigabitEthernet5
switchport access vlan 999
!
interface GigabitEthernet6
switchport access vlan 172
!
interface GigabitEthernet7
switchport access vlan 255
!
interface GigabitEthernet8
switchport mode trunk
switchport access vlan none
switchport trunk native vlan none
switchport trunk allowed vlan 172,255,999

Das Verhalten mach für mich nicht wirklich Sinn... Auch, da es komplett unterschiedliche Netzwerkadapter sind. Einer mit Broadcom Controller und der andere mit einem Intel Controller wobei das Verhalten bei beiden, was den Paketverlust angeht, identisch ist, sobald von einer Karte beide NICs verwendet wird.

 

[Falk R.]

Was mich wundert, hat aber nix mit dem Problem zu tun. Du hast bei einem switchport mode trunk ein switchport access definiert, auch wenn none.
Eigentlich sollte das nicht gehen.
Hast du Spanning Tree oder Loop Protection an?

 

[Reason2040]

Ja bei den SB Switchen ist die Syntax etwas komisch. Sonst wäre es ja "no switchport access vlan".
Spanning Tree und Loop Protection hatte ich auch testhalber ausgeschaltet ohne Unterschied.