Nach Update geht Trunk/Linkaggregation nicht mehr

Feb 2, 2024
11
0
6
Moin zusammen,

ich verzweifle gerade - nach dem problemlos durchgelaufenen Update habe ich nur noch Kontakt zur Fritze und zum Netzwerkswitch. Sobald ich einen von zweien Ports trenne, klappt es auch mit den Nachbarn.

Der kleine HP G8 Microserver hat bis dato super funktioniert - auch, wenn es mit den drei - vier VMs knapp bemessen ist - für mich privat reicht es (noch).
/etc/networking/interfaces:
Code:
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual
#network 192.168.2.0 This is an autoconfigured IPv6 interface

auto eno2
iface eno2 inet manual

auto bond0
iface bond0 inet manual
        bond-slaves eno1 eno2
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
        address 192.168.2.11/24
        gateway 192.168.2.254
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0

source /etc/network/interfaces.d/*

Ausgaben ip:
Code:
root@oms-11:/home/eharren# ip r
default via 192.168.2.254 dev vmbr0 proto kernel onlink
192.168.2.0/24 dev vmbr0 proto kernel scope link src 192.168.2.11
root@oms-11:/home/eharren# ip addr
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: eno1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq master bond0 state DOWN group default qlen 1000
    link/ether 3c:a8:2a:9f:88:10 brd ff:ff:ff:ff:ff:ff
    altname enp3s0f0
    altname enx3ca82a9f8810
3: eno2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether 3c:a8:2a:9f:88:10 brd ff:ff:ff:ff:ff:ff permaddr 3c:a8:2a:9f:88:11
    altname enp3s0f1
    altname enx3ca82a9f8811
12: tap104i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether aa:15:51:18:89:c2 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::a815:51ff:fe18:89c2/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
13: veth100i0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether fe:03:b9:de:5b:ef brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::fc03:b9ff:fede:5bef/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
22: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether 3c:a8:2a:9f:88:10 brd ff:ff:ff:ff:ff:ff
23: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 3c:a8:2a:9f:88:10 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.11/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::3ea8:2aff:fe9f:8810/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

Was habe ich gemacht:
modprobe 8021q
reinstall Kernel

Hat jemand einen Hinweis für mich, wo ich suchen muss?

VG
 
Last edited:
Hey,

das NO-CARRIER bedeutet, dass kein physischer link bei eno1 erkannt wird. Meistens ist das Kabel nicht ordentlich eingesteckt, oder defekt. Hast du das schon überprüft?
 
Moin,

ja, das No Carrier kommt durch das Ziehen - wenn ich den Port wieder verbinde, erhalte ich keinen Kontakt zur Außenwelt - außer zum Swicht und zur FB.

VG
 
Moin,

ja, das No Carrier kommt durch das Ziehen - wenn ich den Port wieder verbinde, erhalte ich keinen Kontakt zur Außenwelt - außer zum Swicht und zur FB.

VG
Das macht keinen Sinn in meinen Augen, was Du da schreibst.
Vorher hast Du schon die "Fakten" aufgezeigt, nun nur noch pros a.
Code:
ip addr show
ip route show
ethtool [eno1,eno2]
Anm. : Und der Switch muss natürlich auch dies unterstützen und konfiguriert worden sein:
Code:
iface bond0 inet manual
        bond-slaves eno1 eno2
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer3+4
 
Last edited:
  • Like
Reactions: ThoSo
- wenn ich den Port wieder verbinde, erhalte ich keinen Kontakt zur Außenwelt - außer zum Swicht und zur FB.
Was ist mit der Außenwelt gemeint?
Kein ping auf google?
Kein zugriff von einem Client auf PVE?

Schon mal einen älteren Kernel gebootet und gegengetestet?
Auf dem Switch mal geschaut ob da etwas geblocked wird? Reset?
 
Last edited:
Ich hab's mit einem alten Kernel probiert und es lief wieder. Switch war ruhig und lieferte keine Erkenntnisse, die Konfiguration lief seit einigen Jahren sauber durch - inkl. Stresstests.
Als ich dann wieder den 7.0-Kernel startete, fing das Drama mit beiden Kabeln wieder an, aber der Netgear GS724TPP blieb weiterhin ruhig - was mich zur Annahme verleitet, da stimmt was nicht mit dem Kernel in Zusammenhang mit Bonding.
Außenwelt: kein ping google.com, kein ping 1.1.1.1, kein ping auf interne Hardware
ping auf PVE von Clients bzw. lokalen VMs nicht möglich.

Aktuell läuft der 7.0-Kernel mit Bonding im active-Backup-Modus, so kann ich wenigstens weiter werkeln.
 
Hi,
ggf. hilft dir ein
Code:
tcpdump
mit der
Code:
-XX
Option. Wenn verfügbar auf beiden Seiten Switch/PVE und dann im Vergleich alter und neuer Kernel, um Unterschiede in den (nicht) versendeten Paketen festzustellen und der Brotkrumenspur zu folgen.

Terminieren beide PVE-Ports auf dem selben Switch? Oder ist da noch VLT/Stacking etc. Im Einsatz?

BG, Lucas
 
Ähnlich/Identisch?:
 
Check mal bitte ob dein Switch überhaupt LACP Layer3+4 unterstützt. Ich habe das schon mehrfach gesehen, dass nach Updates die Spezifikationen etwas genauer genommen werden und so halbgare Konfigurationen funktionieren dann plötzlich nicht mehr.

Check die Einstellungen auf dem Switch und sonst mal Layer 2+3 oder Layer2 testen.