[SOLVED] Virtualisierter Cluster: Kein Multicast auf vmbr0

Ingo S

Renowned Member
Oct 16, 2016
346
41
68
41
Hallo miteinander

Ich habe in einem Proxmox Cluster einen virtuellen Cluster angelegt, um ein Testsystem zu haben, mit dem ich ein paar Dinge ausprobieren kann.
Dazu habe ich einfach 3 virtuelle Maschinen angelegt, und darauf PVE 5.3 installiert. Das Netzwerk dieser Maschinen läuft auf vmbr0 der Host Maschinen, alle VMs befinden sich auf dem gleichen Host, so das kein Switch den Datenverkehr "sehen" muss.

Leider funktioniert Multicast nicht, so das Corosync immer wieder glaubt, die Nodes seien nicht erreichbar. Ich habe bereits folgendes versucht:
Code:
root@vm-1:~# ip link show vmbr0 | grep MULTICAST
7: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
Die Bridge ist also scheinbar Multicast fähig.
Außerdem habe ich einen Querier hinzugefügt:
Code:
auto vmbr0
iface vmbr0 inet static
        [...]
        post-up ( echo 1 > /sys/devices/virtual/net/vmbr0/bridge/multicast_querier )
Und IGMP snooping ist aktiv:
Code:
root@vm-1:/# cat /sys/devices/virtual/net/vmbr0/bridge/multicast_snooping
1

Wenn ich mit omping Multicast teste, funktioniert auch alles zunächst super, aber nach der auto leave time von 5min bricht das dann zusammen.
Wenn ich Multicast richtig verstanden habe, deutet das darauf hin, das der Querier nicht richtig funktioniert, so das die Bridge vergisst, welche MAC Adressen (aufm Switch wären das quasi die Switchports) zu der Multicast Gruppe gehören.

Meine Frage ist jetzt: Wie kriege ich raus ob der Querier funktioniert, und wenn er eben nicht funktioniert, warum das so ist?
Irgend jemand eine Idee?

PS: Eine Sache habe ich noch vergessen zu erwähnen:

Der virtuelle Cluster nutzt 2 Netze auf vmbr0

Vom Host aus gesehen:
1.) net0: Das normale Access Netz, das ist einfach direkt auf vmbr0
2.) net1: Das Netz für Corosync. liegt mit vlan tag 200 auf vmbr0
Alle virtuellen Hosts sind so konfiguriert:
Code:
agent: 1
bootdisk: scsi0
cores: 4
ide2: CD-Images:iso/proxmox-ve_5.3-1.iso,media=cdrom,size=657186K
memory: 8192
name: PMX-FW-Test1
net0: virtio=2A:04:05:97:FC:10,bridge=vmbr0
net1: virtio=26:7B:7C:33:14:1B,bridge=vmbr0,tag=200
numa: 0
ostype: l26
parent: Pre_Cluster
scsi0: HDD_Storage-VM:vm-910-disk-0,discard=on,size=32G
scsihw: virtio-scsi-pci
smbios1: uuid=f065d79c-5157-48c8-b991-0a0b751a2278
sockets: 1
vmgenid: 0f6d3cbc-83ff-4020-9683-228d9c91af93

Von den virtuellen Cluster Nodes aus gesehen:
Code:
auto ens19
iface ens19 inet static
        address  192.168.200.1
        netmask  255.255.255.0
#Corosync Testcluster

auto vmbr0
iface vmbr0 inet static
        address  192.168.1.26
        netmask  255.255.255.0
        gateway  192.168.1.254
        bridge-ports ens18
        bridge-stp off
        bridge-fd 0

Bei meiner Recherche bin ich auf den Artikel gestoßen:
http://troglobit.com/howto/multicast/
Demnach gibt es einen Bug im IGMP snooping Code des Kernels, allerdings wird da der Kernel 3.13 genannt. Gibts da Erfahrungen? Gibts den Bug noch immer?
 
Wenn ich mit omping Multicast teste, funktioniert auch alles zunächst super, aber nach der auto leave time von 5min bricht das dann zusammen.
Wenn ich Multicast richtig verstanden habe, deutet das darauf hin, das der Querier nicht richtig funktioniert, so das die Bridge vergisst, welche MAC Adressen (aufm Switch wären das quasi die Switchports) zu der Multicast Gruppe gehören.

Ja, das sieht danach aus. Ich habe jede Menge solcher Testcluster laufen und da noch nie ein Problem gehabt. Allerdings verwende ich keinen Querier, sondern mache einfach ein eigenes virtuelles Netwerk für den Testcluster (also z.B. vmbr1 ohne physikalischen Port), da gibt's keine Notwendigkeit für Querier. Natürlich muss es mit genauso laufen, ich habe das mal probiert, und beim Aktivieren geht die Verbindung kurzzeitig verloren, ist aber nach ~ 20 sek. wieder da.

Wenn's nur darum geht, einen Testcluster zu haben, würde ich ein virtuelles Netzwerk ohne Querier nehmen. Sollte aber genau der Querier das Thema sein, müsste man das igmp Protokoll analysieren, z.B. mit

Code:
tcpdump -e -n -i ens19 | grep igmp

Da sehe ich dann etwa
Code:
14:36:28.431704 f6:42:bf:be:cf:e6 > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 46: 0.0.0.0 > 224.0.0.1: igmp query v2
14:36:29.012726 3e:56:11:8c:53:02 > 01:00:5e:40:0d:e7, ethertype IPv4 (0x0800), length 46: 10.149.47.2 > 239.192.13.231: igmp v2 report 239.192.13.231
 
Ach, danke für den Tipp. Ich hatte gar nicht daran gedacht, das ich auch eine Bridge ohne echten Netzwerk Port erstellen kann. Da das Corosync Netz ja sowieso keine Verbindung nach draußen braucht, werde ich das mal testen.

Den IGMP Traffic werde ich auch mal analysieren. Ich bin jetzt neugierig, was die Ursache für diesen merkwürdigen Quatsch ist.
 
Sobald ich eine Bridge ohne Hardwareanbindung nutze, läuft der Cluster einwandfrei. Leider hatte ich noch keine Zeit, der Ursache auf den Grund zu gehen. Ich hab aber das Gefühl, dass da ein Bug sein Unwesen treibt.
VMs die ich im virtuellen Cluster erstellt habe, bekommen nämlich auch keinen Zugriff auf das Netzwerk. Sehr mysteriös irgendwie...
 
VMs die ich im virtuellen Cluster erstellt habe, bekommen nämlich auch keinen Zugriff auf das Netzwerk. Sehr mysteriös irgendwie...

Da müsste man die VM Konfiguration mal überprüfen ....
 

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!