Environment:

• VyOS running as a VM on Proxmox VE (virtio-net NICs)
• Upgraded via add system image latest: from 1.5-rolling-202405140019 to 2026.09.01-0034-rolling
• Config preserved across upgrade (kept config files + SSH host keys)

Setup:
interfaces {

bridge br0 {
    address "10.2.0.1/16"
    member {
        interface eth0.300 { }
        interface eth1.300 { }
    }
}
ethernet eth0 { hw-id "..." vif 300 { } }
ethernet eth1 { hw-id "..." vif 300 { } }

}
eth0.300 and eth1.300 are 802.1q sub-interfaces on two separate virtio-net NICs, both bridged together as br0, which holds the gateway address for a /16 subnet used by several Proxmox VMs.

Symptom:
After the upgrade, hosts on the 10.2.0.0/16 segment can no longer reach the gateway (10.2.0.1) at all — ARP requests for the gateway address go unanswered from the hosts' point of view, causing full network segment outage.

Diagnostic steps taken:

1. Confirmed both bridge member ports in STP forwarding state (bridge link show).
2. Confirmed net.ipv4.conf.{br0,eth1.300}.arp_ignore = 0 (default).
3. Confirmed bridge fdb show br br0 correctly maps the requesting hosts' MAC addresses to the physical port they actually arrive on.
4. Ran simultaneous tcpdump -i <iface> 'arp[6:2] == 2' -v on br0, eth0.300, and eth1.300 while triggering ARP requests from hosts on the segment.
   • Result: the ARP reply (10.2.0.1 is-at <bridge MAC>) is visible only on br0 (i.e. generated by the kernel's own IP stack, since the address belongs to the bridge). It is never seen leaving via either physical/virtual member interface (eth0.300 nor eth1.300), even though FDB correctly points to the right port.

Workaround confirmed:
Removing the bridge entirely and assigning the address directly to one member interface restores normal ARP reply transmission and full connectivity:
delete interfaces bridge br0
set interfaces ethernet eth1 vif 300 address '10.2.0.1/16'
This strongly points to a regression in bridge egress handling for locally-originated traffic (frames generated by the host's own IP stack destined out through a bridge device), not a general interface/driver failure — pass-through / MAC-learning behavior (FDB population from received frames) still works correctly.

Expected behavior: ARP replies (and presumably other locally-originated traffic) generated for a bridge's own address should be transmitted out the correct member interface per the bridge's FDB, as in 1.5-rolling-202405140019.

Actual behavior: such traffic is generated but silently dropped before reaching any physical/virtual bridge member port.