Proxmox vmbr0 bridge is not "switching". Why? - proxmox

Question

I am trying to figure out why the "default" Proxmox network configuration is not behaving as I expect.
I have:
a Proxmox server (10.0.40.10)
the network bridge (vmbr0) created by Proxmox by default
a VM (10.0.40.20) connected to vmbr0 (let's call it VM1)
a VM (10.0.40.25) connected to vmbr0 (let's call it VM2)
a gateway (10.0.40.254) configured on vmbr0
When I performed an HTTP transfer (GET) on VM2 from VM1, the speed I observed indicated that traffic was exiting the Proxmox host, going to the gateway, and returning back to the Proxmox host.
Both VM1 and VM2 are connected to vmbr0, so my expectation was that vmbr0 would "switch" between the two VMs, based on the MAC/ARP, and that the traffic would remain entirely local (and be one or two orders of magnitude faster).
When I run a ping from VM2 to VM1, I observe this:
[root#vm2 ~]# ping -c 5 10.0.40.20
PING 10.0.40.20 (10.0.40.20) 56(84) bytes of data.
64 bytes from 10.0.40.20: icmp_seq=1 ttl=64 time=0.485 ms
From 10.0.40.254 icmp_seq=1 Redirect Host(New nexthop: 10.0.40.20)
64 bytes from 10.0.40.20: icmp_seq=2 ttl=64 time=0.609 ms
From 10.0.40.254 icmp_seq=2 Redirect Host(New nexthop: 10.0.40.20)
64 bytes from 10.0.40.20: icmp_seq=3 ttl=64 time=0.598 ms
--- 10.0.40.20 ping statistics ---
3 packets transmitted, 3 received, +2 errors, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.485/0.564/0.609/0.056 ms
Running a traceroute shows:
[root#vm2 ~]# traceroute -I 10.0.40.20
traceroute to 10.0.40.20 (10.0.40.20), 30 hops max, 60 byte packets
1 gateway (10.0.40.254) 0.328 ms 0.308 ms 0.393 ms
2 10.0.40.20 (10.0.40.20) 0.472 ms 0.481 ms 0.533 ms
The vmbr0 configuration looks like this:
Network definition for VM1:
Network definition for VM2:
This seems like such a fundamental use-case it seems like I must be missing something.
Does anyone know if my expectations are correct, or is this correct behavior for vmbr0? Does something look misconfigured? Do I need something like Proxy ARP or an on-box virtual router to solve such a simple use-case?

Answer 1

Solved: The IP addresses of some of the Virtual Machines were configured as /32 rather than /24, eg. 10.0.40.25/32 instead of 10.0.40.25/24, and therefore did not consider themselves in the same subnet as their peers, and traffic was sent out on the default route.