Normal? vmbr wechseln in "blocking state"

[whiterabbit]

Hi. Ich habe gestern ein Upgrade von V4.4 auf V5.2 gemacht. dmesg liefert bei mir "ständig" Meldungen dieser Art:

[63520.001385] vmbr2: port 2(tap100i0) entered blocking state
[63520.001388] vmbr2: port 2(tap100i0) entered disabled state
[63520.001516] vmbr2: port 2(tap100i0) entered blocking state
[63520.001518] vmbr2: port 2(tap100i0) entered forwarding state

Nur so aus Interesse -- war das auch vorher schon so? Ist das der Normalzustand (zB wenn die vmbr länger nicht genutzt werden)? Sobald man zugreift, wird ja wieder in den "forwarding state" gewechselt. Es funktioniert also alles; dennoch wüsste ich gerne, ob das so seine Richtigkeit hat...
Schöne Grüße.

 

[whiterabbit]

Leider zu früh gefreut. Gerade habe ich einen Serverneustart gemacht. Einige VMs bekommen keine IP mehr.
Hier die Ausgabe von pveversion. Ich setze hier ein bond.0 und divese vmbr ein.
Außerdem hatte ich bereits die grub-Optionen "pci=nomsi,noaer" eingefügt.
Am Bond hängt eine Intel i350 4-fach Netzwerkkarte.

auto bond0
iface bond0 inet manual
        slaves eth1 eth2 eth3 eth4
        bond_miimon 100
        bond_mode 802.3ad
        bond_xmit_hash_policy layer2
#4-fach-bond0 / LAG1

auto vmbr0
iface vmbr0 inet static
        address  XXX
        netmask  255.255.255.0
        gateway  XXX
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        bridge_maxage 0
        bridge_ageing 0
        bridge_maxwait 0

und

pveversion -v
proxmox-ve: 5.2-2 (running kernel: 4.15.18-5-pve)
pve-manager: 5.2-9 (running version: 5.2-9/4b30e8f9)
pve-kernel-4.15: 5.2-8
pve-kernel-4.15.18-5-pve: 4.15.18-24
pve-kernel-4.4.134-1-pve: 4.4.134-112
pve-kernel-4.4.128-1-pve: 4.4.128-111
pve-kernel-4.4.117-2-pve: 4.4.117-110
pve-kernel-4.4.117-1-pve: 4.4.117-109
pve-kernel-4.4.114-1-pve: 4.4.114-108
pve-kernel-4.4.98-6-pve: 4.4.98-107
pve-kernel-4.4.98-5-pve: 4.4.98-105
pve-kernel-4.4.98-4-pve: 4.4.98-104
pve-kernel-4.4.98-3-pve: 4.4.98-103
pve-kernel-4.4.98-2-pve: 4.4.98-101
pve-kernel-4.4.95-1-pve: 4.4.95-99
pve-kernel-4.4.83-1-pve: 4.4.83-96
pve-kernel-4.4.76-1-pve: 4.4.76-94
pve-kernel-4.4.67-1-pve: 4.4.67-92
pve-kernel-4.4.62-1-pve: 4.4.62-88
pve-kernel-4.4.59-1-pve: 4.4.59-87
corosync: 2.4.2-pve5
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.0-8
libpve-apiclient-perl: 2.0-5
libpve-common-perl: 5.0-40
libpve-guest-common-perl: 2.0-18
libpve-http-server-perl: 2.0-11
libpve-storage-perl: 5.0-29
libqb0: 1.0.1-1
lvm2: 2.02.168-pve6
lxc-pve: 3.0.2+pve1-2
lxcfs: 3.0.2-2
novnc-pve: 1.0.0-2
proxmox-widget-toolkit: 1.0-20
pve-cluster: 5.0-30
pve-container: 2.0-27
pve-docs: 5.2-8
pve-firewall: 3.0-14
pve-firmware: 2.0-5
pve-ha-manager: 2.0-5
pve-i18n: 1.0-6
pve-libspice-server1: 0.12.8-3
pve-qemu-kvm: 2.11.2-1
pve-xtermjs: 1.0-5
qemu-server: 5.0-36
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.11-pve1~bpo1

 

[whiterabbit]

Noch ein Nachtrag ... ich komme hier leider nicht weiter. Unsere Hardware:
Mainboard Gigabyte Technology Co., Ltd. GA-990FXA-UD5/GA-990FXA-UD5, BIOS F12 10/03/2013
Intel i350 Karte mit ganz aktuellem Treiber: igb version: 5.3.5.20 (aus der Not heraus selbst kompiliert)

Die VMs erhalten leider zum Teil weiterhin keine IP. dmesg meldet bei manchen VMs:

[ 2703.574452] vmbr200: port 2(tap100i0) entered blocking state
[ 2703.575340] vmbr200: port 2(tap100i0) entered disabled state
[ 2703.576322] vmbr200: port 2(tap100i0) entered blocking state
[ 2703.577195] vmbr200: port 2(tap100i0) entered forwarding state

... trotzdem kommt in der VM nix an.
Hat einer eine Idee?
Es tritt wie gesagt erst seit dem Upgrade von 4.4 auf 5.2-1 auf. Vorher lief alles problemlos.

 

[dcsapak]

[ 2703.577195] vmbr200: port 2(tap100i0) entered forwarding state

kannst du die ganze /etc/network/interfaces posten? ich vermissen die vmbr200 nämlich in dem output

 

[whiterabbit]

Hi. Ok -- hier kommt die komplette Datei.
Das Problem scheint damit zusammenzuhängen, dass das bond0 nicht mehr im LACP-Modus arbeitet? Ganz sicher bin ich aber nicht.
Ich wundere mich, dass einige Subnetze problemlos laufen während ich in anderen Subnetzen keine IP mehr bekomme.
Auf einem anderen Server (IBM x3650, der allerdings ebenfalls eine Intel i350 Karte besitzt) ist das kein Problem. Auch dort ist Version 5.2 installiert. Auf diesem Server (wie gesagt mit Gigabyte Mainboard) tritt das erst seit dem Upgrade auf.

Ich habe schon einige Einstellungen ausprobiert; darunter:
* alten Kernel booten (4.4)
* Option nomsi,noaer
* Option acpi=off (dmesg-Meldung legte das nahe)
* PVE-Kernel Upgrade auf pve2 4.15.18-7-pve
* Intel i350: nageneue Treiber Version 5.3.5.20
Hat alles nichts gebracht. Der Fehler steckt tiefer

08:14/0 pve2 ~ # 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 part of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT 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 eth0 inet manual

iface eth1 inet manual

iface eth2 inet manual

iface eth3 inet manual

iface eth4 inet manual

auto bond0
iface bond0 inet manual
        slaves eth1 eth2 eth3 eth4
        bond_miimon 100
        bond_mode 802.3ad
        bond_xmit_hash_policy layer2
#4-fach-bond0 / LAG1

auto vmbr0
iface vmbr0 inet static
        address 192.168.10.100
        netmask 255.255.255.0
        gateway 192.168.10.1
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        bridge_maxage 0
        bridge_ageing 0
        bridge_maxwait 0
#Default Bridge (an FritzBox/Rot)

auto vmbr1
iface vmbr1 inet manual
        bridge_ports bond0
        bridge_stp off
        bridge_fd 0
        bridge_maxage 0
        bridge_ageing 0
        bridge_maxwait 0
#4-fach Bond (Intel-Karte)

auto vmbr2
iface vmbr2 inet manual
        bridge_ports bond0.2
        bridge_stp off
        bridge_fd 0
        bridge_maxage 0
        bridge_ageing 0
        bridge_maxwait 0
#Switch-Management

auto vmbr10
iface vmbr10 inet manual
        bridge_ports bond0.10
        bridge_stp off
        bridge_fd 0
        bridge_maxage 0
        bridge_ageing 0
        bridge_maxwait 0
#Internet

auto vmbr11
iface vmbr11 inet manual
        bridge_ports bond0.11
        bridge_stp off
        bridge_fd 0
        bridge_maxage 0
        bridge_ageing 0
        bridge_maxwait 0
#Servernetz

auto vmbr12
iface vmbr12 inet manual
        bridge_ports bond0.12
        bridge_stp off
        bridge_fd 0
        bridge_maxage 0
        bridge_ageing 0
        bridge_maxwait 0
#WLAN

auto vmbr13
iface vmbr13 inet manual
        bridge_ports bond0.13
        bridge_stp off
        bridge_fd 0
        bridge_maxage 0
        bridge_ageing 0
        bridge_maxwait 0
#DMZ

auto vmbr50
iface vmbr50 inet manual
        bridge_ports bond0.50
        bridge_stp off
        bridge_fd 0
        bridge_maxage 0
        bridge_ageing 0
        bridge_maxwait 0
#Netz1

auto vmbr51
iface vmbr51 inet manual
        bridge_ports bond0.51
        bridge_stp off
        bridge_fd 0
#Netz2

auto vmbr52
iface vmbr52 inet manual
        bridge_ports bond0.52
        bridge_stp off
        bridge_fd 0
#Netz3

auto vmbr53
iface vmbr53 inet manual
        bridge_ports bond0.53
        bridge_stp off
        bridge_fd 0
#Netz4

auto vmbr60
iface vmbr60 inet manual
        bridge_ports bond0.60
        bridge_stp off
        bridge_fd 0
        bridge_maxage 0
        bridge_ageing 0
        bridge_maxwait 0
#Netz5

auto vmbr100
iface vmbr100 inet manual
        bridge_ports bond0.100
        bridge_stp off
        bridge_fd 0
        bridge_maxage 0
        bridge_ageing 0
        bridge_maxwait 0
#Netz 6

auto vmbr200
iface vmbr200 inet manual
        bridge_ports bond0.200
        bridge_stp off
        bridge_fd 0
        bridge_maxage 0
        bridge_ageing 0
        bridge_maxwait 0
#Netz 7

auto vmbr999
iface vmbr999 inet manual
        bridge_ports none
        bridge_stp off
        bridge_fd 0
        bridge_maxage 0
        bridge_ageing 0
        bridge_maxwait 0
#virt. Switch fuer IPFire an BLAU

 

[whiterabbit]

Das Problem ist gelöst -- es lag am Switch! Ein Neustart des Layer3-Switches hat's gebracht. Wobei mich wundert, dass der bei der Vergabe der IP auf den VMs überhaupt beteiligt ist?? Ich dachte, dass das "rein virtuell" abgewickelt wird -- also ohne den Proxmox-Server zu verlassen?!?