Packet loss on VMs, but not with Proxmox directly

[vctgomes]

I just installed Proxmox on my Intel NUC with N100. I was noticing a terrible performance on accessing some VMs remotely by HTTP protocol, however everything looks great accessing Promox (Proxmox has 0% of packet loss).

So I tested the ping and packet loss from my VM IPs and to my surprise, some VMs was having 20, 40% of packet loss (only one VM running Ubuntu Server looks to have a great performance with only 1% so so). Even doing the packet loss over ping directly from Promox Shell to VM result on packet loss.

I tried to turn off IPv6 and remove some firewall, but I'm newer on Proxmox and I don't well if it's really disable or the reason packet loss is happening.

As interface, I'm using Linux bridge, connected to an EdgeRouter X router.

 

[Lukas Wagner]

Hello,

could you provide us with your /etc/network/interfaces, the respective VM configurations (qm config <vmid>? Also, what is the load situation on the host? cat /proc/pressure/cpu and cat /proc/loadavg. Anything suspicious in journalctl or dmesg?

 

[vctgomes]

Hello,

could you provide us with your /etc/network/interfaces, the respective VM configurations (qm config <vmid>? Also, what is the load situation on the host? cat /proc/pressure/cpu and cat /proc/loadavg. Anything suspicious in journalctl or dmesg?

Thank
This was what I got on /etc/network/interfaces

auto lo
iface lo inet loopback

iface enp3s0 inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.2.156/24
gateway 192.168.2.1
bridge-ports enp3s0
bridge-stp off
bridge-fd 0
mtu 1400

iface wlp1s0 inet manual

root@minipc:~# cat /proc/pressure/cpu
some avg10=1.62 avg60=1.60 avg300=1.04 total=31328329
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

root@minipc:~# cat /proc/loadavg
0.51 0.34 0.14 1/352 27616

Using the dmesq I got a lot of things, but something caught my attention

[ 11.239488] vmbr0: port 2(tap100i0) entered blocking state
[ 11.239496] vmbr0: port 2(tap100i0) entered disabled state
[ 11.239574] vmbr0: port 2(tap100i0) entered blocking state
[ 11.239577] vmbr0: port 2(tap100i0) entered forwarding state
[ 28.368995] vmbr0: received packet on enp3s0 with own address as source address (addr:e0:51:d8XXX, vlan:0)
[ 28.370541] vmbr0: received packet on enp3s0 with own address as source address (addr:e0:51:d8:XXX, vlan:0)
[ 29.394239] vmbr0: received packet on enp3s0 with own address as source address (addr:e0:51:d8XXX, vlan:0)
[ 29.395936] vmbr0: received packet on enp3s0 with own address as source address (addr:e0:51:d8:XXX, vlan:0)
[ 30.418223] vmbr0: received packet on enp3s0 with own address as source address (addr:e0:51:d8XXX, vlan:0)
[ 30.419954] vmbr0: received packet on enp3s0 with own address as source address (addr:e0:51:d8:XXX, vlan:0)
[ 137.983260] device tap101i0 entered promiscuous mode
[ 138.020413] vmbr0: port 3(fwpr101p0) entered blocking state
[ 138.020421] vmbr0: port 3(fwpr101p0) entered disabled state
[ 138.020469] device fwpr101p0 entered promiscuous mode
[ 138.020505] vmbr0: port 3(fwpr101p0) entered blocking state
[ 138.020508] vmbr0: port 3(fwpr101p0) entered forwarding state
[ 138.027796] fwbr101i0: port 1(fwln101i0) entered blocking state

 

[Lukas Wagner]

 [ 28.368995] vmbr0: received packet on enp3s0 with own address as source address (addr:e0:51:d8XXX, vlan:0)

That's quite interesting. Could you make sure that you have no IP address conflicts between VMs/Hosts and also that all MAC addresses of the physical and virtual network interfaces are unique? I've found a similar issue on our forum, there the issue was that a VM had the same MAC address as the host.

[1] https://forum.proxmox.com/threads/v...o1-with-own-address-as-source-address.126475/

 

[GusSara]

Hello,

I'm having similar problem here, running Proxmox 8 on an HP Prodesk mini).

 

[dosmage]

I've found this rather newer and mention of Proxmox 8 thread on the subject. I'm not certain if my issue is exactly the same. I've been running a a pair of Proxmox workstations, they aren't in a pve cluster, for about 2 years. Just last week I physically upgraded one of the computers and installed Proxmox 8 on it. Now both systems are experiencing this strange "received packet on %interface with own address of source address (addr:%mac, vlan:%vlan)".

There are no artifacts of duplicated IPs or MAC addresses. The reported problematic MAC addresses are each systems' own physical adapters' MAC. There is exactly 1 5 port switch and each host has 1 ethernet cable to it, so it can't be a physical switching loop. Plus a physical switching loop wouldn't feel right for this issue because with mine it seems like an ever increasing rush of demsg entries until the network destabilizes and I have to run the hosts off. I wish I could help explain this but I'm currently flummoxed.

 

[dosmage]

I figured I'd come in and give an update to my problem. I'm uncertain why this hasn't bee a problem previously; however my router and AP extenders are using some form of spanning tree protocol that is incompatible with STP provided by Proxmox (Linux) and even my unmanaged switch. To solve my problem I needed to disable STP on my Proxmox bridges in /etc/network/interface and; I replaced my unmanaged switch with a managed switch and as a workaround I disabled STP and enabled BPDU forwarding. I hope this helps but the router you've mentioned isn't the same as mine and you didn't mention additional extenders/points.

 

[shahram]

Hi everyone, i have the same problem with one of my VMs (debian12)
i have very unstable pings and IDK what should i do!

root@vmDocker:/# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=10.2 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=9.45 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=9.86 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=9.34 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=9.97 ms

64 bytes from 1.1.1.1: icmp_seq=6 ttl=58 time=9.76 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=9.68 ms
^C
--- 1.1.1.1 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6008ms
rtt min/avg/max/mdev = 9.335/9.747/10.184/0.271 ms
root@vmDocker:/# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

^C
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9190ms

root@vmDocker:/# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7153ms

root@vmDocker:/# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=3009 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=1985 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=59 time=961 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=59 time=9.70 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=59 time=9.78 ms
^C
--- 8.8.8.8 ping statistics ---
8 packets transmitted, 5 received, 37.5% packet loss, time 7104ms
rtt min/avg/max/mdev = 9.701/1194.849/3008.820/1164.316 ms, pipe 3
root@vmDocker:/#

root@vmDocker:/# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens18
iface ens18 inet dhcp
# This is an autoconfigured IPv6 interface
iface ens18 inet6 auto
root@vmDocker:/# ll /etc/network/interfaces.d/
total 0

root@pve:~# cat /proc/pressure/cpu
some avg10=0.00 avg60=0.00 avg300=0.29 total=18380940
full avg10=0.00 avg60=0.00 avg300=0.00 total=0
root@pve:~# cat /proc/loadavg
0.00 0.23 0.29 1/303 19483

Best Regards, Shahram