Gelegentlicher Paketverlust zwischen Bridge-Schnittstellen

Gelegentlicher Paketverlust zwischen Bridge-Schnittstellen

Ich habe zwei Virtualisierungsserver, die auf libvirt und KVM basieren. Und manchmal sehe ich, dass Pakete auf einer bestimmten virtuellen Maschine verloren gehen. Nach einem Neustart des Virtualisierungshosts ist dieses Problem gelöst, aber es hilft nur für eine Weile.

Ich habe in iptraph-ng Filter erstellt und sehe, dass Pakete zwischen Bridge-Schnittstellen verloren gehen.

Sie können es hier sehen::

Fri Mar  3 00:21:43 2023; ICMP; ens3f0; 84 bytes; from 10.10.10.68 to 10.10.11.23;      echo req
Fri Mar  3 00:21:43 2023; ICMP; bond1; 84 bytes; from 10.10.10.68 to 10.10.11.23;       echo req
Fri Mar  3 00:21:43 2023; ICMP; bond1.121; 84 bytes; from 10.10.10.68 to 10.10.11.23;   echo req
Fri Mar  3 00:21:43 2023; ICMP; ens3f0; 84 bytes; from 10.10.10.68 to 10.10.11.23;      echo req
Fri Mar  3 00:21:43 2023; ICMP; bond1; 84 bytes; from 10.10.10.68 to 10.10.11.23;       echo req
Fri Mar  3 00:21:43 2023; ICMP; bond1.121; 84 bytes; from 10.10.10.68 to 10.10.11.23;   echo req

Wenn kein Paketverlust vorliegt:

Fri Mar  3 00:21:43 2023; ICMP; ens3f0; 84 bytes; from 10.10.10.68 to 10.10.11.23;      echo req
Fri Mar  3 00:21:43 2023; ICMP; bond1; 84 bytes; from 10.10.10.68 to 10.10.11.23;       echo req
Fri Mar  3 00:21:43 2023; ICMP; bond1.121; 84 bytes; from 10.10.10.68 to 10.10.11.23;   echo req
Fri Mar  3 00:21:43 2023; ICMP; vnet18; 84 bytes; from 10.10.10.68 to 10.10.11.23;      echo req
Fri Mar  3 00:21:43 2023; ICMP; vnet18; 84 bytes; from 10.10.11.23 to 10.10.10.68;      echo rply
Fri Mar  3 00:21:43 2023; ICMP; bond1.121; 84 bytes; from 10.10.11.23 to 10.10.10.68;   echo rply
Fri Mar  3 00:21:43 2023; ICMP; bond1; 84 bytes; from 10.10.11.23 to 10.10.10.68;       echo rply
Fri Mar  3 00:21:43 2023; ICMP; ens3f0; 84 bytes; from 10.10.11.23 to 10.10.10.68;      echo rply

Einstellungen der virtuellen Schnittstelle:

virsh dumpxml vm-rep |xmllint -xpath ///interface -
<interface type="bridge">
      <mac address="52:54:00:2b:35:b4"/>
      <source bridge="br121"/>
      <target dev="vnet18"/>
      <model type="virtio"/>
      <alias name="net0"/>
      <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>

Wenn Pakete verloren gehen, sehe ich keine RX/TX-Fehler oder Ausfälle auf der Bridge-Schnittstelle, der verbundenen VLAN-Schnittstelle oder der TAP-Schnittstelle (ifconfig br121 and etc.). Ich sehe keine Erhöhung der Zähler mit virsh domifstat vm-rep vnet18. Ich bin von Linuxbridge zu OpenvSwitch gewechselt, aber das hat nicht geholfen, und wenn ich ausführe ovs-ofctl dump-ports ovsbr121, sehe ich keine Fehler oder Ausfälle. Ich habe die Debug-Ebene in OpenvSwitch aktiviert und sehe auch keine Fehler oder Ausfälle in den Bridge-Schnittstellen.

Diese virtuelle Maschine ist ein Repository auf nginx und hat ein Blockgerät rbd auf Serh und keine Speicher-/Prozessor-/Blockgerätelast. Der Virtualisierungshost ist auch nicht geladen, topich sehe keine hohen Werte in wa, hi, si, stoder im Lastdurchschnittswert. Der Leerlauf liegt fast immer bei 96. Es gibt nur 17 virtuelle Maschinen auf dem Host.

In den Protokollen der Virtualisierungshosts und der VM konnte ich keinen Grund für dieses Verhalten erkennen. Ich verstehe nicht, wie ich die Ursache für den Paketverlust herausfinden kann. Es sieht nach einem kurzfristigen Einfrieren der VM aus.

Umfeld:

  • Rocky Linux 8.5 auf Virtualisierungshost und VM.
  • libvirtd (libvirt) 6.0.0
  • QEMU-Emulator Version 4.2.0 (qemu-kvm-4.2.0-60.module+el8.5.0+772+743bb337.2)
  • Kernel 4.18.0-348.23.1.el8_5.x86_64
  • virt-install 2.2.1

Die VM wurde mit virt-install erstellt:

virt-install \
      --machine q35 \
      --name vm-rep \
      --memory=16384 \
      --vcpus=8 \
      --os-variant rocky8.5 \
      --disk size=20,bus=virtio \
      --network bridge=br121,model=virtio \
      --graphics=vnc \
      --boot hd,cdrom \
      --noautoconsole \
      --autostart \
      --channel unix,mode=bind,path=/var/lib/libvirt/qemu/vm-rep.agent,target_type=virtio,name=org.qemu.guest_agent.0 \
      --location /var/lib/libvirt/isos/Rocky-8.5-x86_64-minimal.iso \
      --initrd-inject=ks.cfg \
      --extra-args "inst.ks=file:/ks.cfg console=ttyS0,115200n8"

Manchmal treten solche Paketverluste auch bei anderen VMs auf, bei dieser jedoch am häufigsten. Ein Neustart der VM hilft nicht, nur ein Neustart des Virtualisierungshosts.

Gibt es eine Möglichkeit, verlorene Pakete zu verfolgen/zu sichern oder zumindest irgendwie zu sehen, was mit ihnen passiert?

Antwort1

In meinem Fall war es ein Multihoming-Problem im EVPN/VXLAN-Fabric und in der FDB-Tabelle in der Bridge auf dem KVM. Was passiert ist: VMs haben ARP-Anfragen oder anderen Broadcast-/Multicast-Verkehr gesendet. Ein solcher Frame würde den erreichen bridge -> bond -> one of the physical interfaces -> ip fabric.Split Horizon/Designierter Spediteurwürde dann im EVPN/VXLAN-Fabric falsch funktionieren und dieser Frame würde über eine andere physische Schnittstelle des KVM-Servers zum selben Bond und dann zur Bridge zurückgehen, wodurch sich das Verhältnis der Schnittstelle zur Mac-Adresse der VM in der FDB-Tabelle zur Bond-Schnittstelle ändert. Als Workaround wechselten wir zu macvtap, das die FDB-Tabelle ausschließt, aber nachdem wir das Multihoming-Problem gelöst hatten, gingen wir wieder zu Bridges zurück.

Bildbeschreibung hier eingeben

verwandte Informationen