https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296106
Arthur Kroisel <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #10 from Arthur Kroisel <[email protected]> ---
Same bug here, confirmed on stock 15.1-RELEASE GENERIC with no hardware or
hypervisor involved — minimal two-jail repro below (epairs only), so ESXi/vmx
can be ruled out entirely.
--- repro.sh ---
#!/bin/sh
kldload -n carp
ifconfig epair0 create
ifconfig epair1 create
ifconfig bridge0 create addm epair0a addm epair1a up
ifconfig epair0a up
ifconfig epair1a up
jail -c name=a path=/ persist vnet allow.raw_sockets=1
jail -c name=b path=/ persist vnet allow.raw_sockets=1
ifconfig epair0b vnet a
ifconfig epair1b vnet b
jexec a ifconfig epair0b up
jexec a ifconfig vlan3 create vlan 3 vlandev epair0b
jexec a ifconfig vlan3 inet 172.16.2.1/24 up
jexec b ifconfig epair1b up
jexec b ifconfig bridge0 create addm epair1b up
jexec b ifconfig vlan3 create vlan 3 vlandev bridge0
jexec b ifconfig vlan3 inet 172.16.2.2/24 up
jexec b ifconfig vlan3 vhid 13 pass testpass alias 172.16.2.13/32
sleep 5
jexec a ping -c 2 172.16.2.2 # interface address: works
jexec a ping -c 3 172.16.2.13 # CARP VIP: ARP resolves, then 100% loss
--- end ---
Code-level cause, complementing comment #9, from reading sys/net/if_bridge.c
(releng/15.1): in bridge_input(), unicast local delivery is decided by
GRAB_OUR_PACKETS(bifp) — the frame is "ours" if the dst MAC matches
IF_LLADDR(bifp) or CARP_CHECK_WE_ARE_DST(bifp), and only then are tagged
frames handed to (*vlan_input_p)(bifp, m). CARP_CHECK_WE_ARE_DST(bifp)
expands to carp_forus(bifp, ...), which consults only bifp->if_carp — the
CARP addresses of the bridge interface itself. A VHID on the vlan(4) child
hangs off the vlan interface's if_carp, which is never consulted (vlan demux
happens only after the frame is already accepted as local). So the vlan
child's virtual MAC fails the "destined for us" test and the frame is
flooded instead of delivered.
That matches all observed controls: a VIP untagged on the bridge itself works
(bifp->if_carp), the vlan interface's own address works (shares the bridge
MAC), a VIP on vlan-over-epair works (no bridge in the path).
Impact is wider than one setup: any HA gateway with VLANs on a bridge loses
CARP on every VLAN while looking healthy (election, ARP, firewall logs all
fine). Also reproduced on OPNsense 26.7 with the VLAN-on-bridge backport —
narrowed down in https://forum.opnsense.org/index.php?topic=50260 with the
full control-matrix jail scripts.
Happy to test patches — the jail repro takes seconds to run.
--
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.