https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243554
Bug ID: 243554
Summary: multicast packets not seen on PHY bridge member
Product: Base System
Version: 12.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: james.blac...@gmail.com
Summary: if_bridge(4) purports in the man page[1] to forward multicast traffic
to all members of the bridge. However, this does not appear to be the case.
Extended summary: a bridge with members tap0, tap1, ... comprising bhyve
virtual machines, as well as igb1 (the host's primary interface) forwards
multicast traffic (mDNS specifically) among the taps, and OUT the PHY interface
(igb1), however, the PHY interface does not receive inbound multicast traffic
(on the FreeBSD side). Unicast traffic operates fine.
Details:
I use FreeBSD 12.1 as a VM host and ran into a problem with multicast packets
over a bridge not being seen by programs [on the host] listening on the
bridge's physical interface constituent (igb1), which I discovered when running
avahi-daemon.
Briefly, my setup is as follows:
FreeBSD 11.2 host, bare metal, eth PHY igb1
bridge0 with members igb1, tap0, tap1
VM linux guest virtio-net to tap0 to bridge on FreeBSD
VM freebsd guest virtio-net to tap1 to bridge on FreeBSD
Mac, ethernet to same switch as FreeBSD
mDNS query/response operates properly between the Mac and any of the
others (both physical and virtual), and all work in the converse
direction with the Mac. The guests, all of which are constituents of
the bridge, are able to communicate via mDNS with one another. However,
the guests are _unable_ to communicate with the host via mDNS.
tcpdump shows the query packets appearing on igb1, but truss on avahi-daemon
shows they are not received.
This means multicast packets are forwarded OUT all members of the
bridge, but not IN (at least, to physical interfaces -- they do
go both directions on the taps)
If I add an IP address to the bridge, avahi-daemon on the host binds to
the bridge interface directly and then receives incoming packets,
responding with the IP of the bridge. All then operates correctly,
except that the host now has two IPs on the same subnet of course.
Given that if_bridge(4) is described as a virtual switch [1] and
Given that unicast packets originating on one of the bridge's
taps are received by host programs bound to igb1, it seems to me that
anything bound to igb1 should also be receiving the multicast packets.
Is the discrepancy between handling of unicast and multicast packets
* an error specifically related to multicast and bridging, or
* an accident that unicast connections work? [unlikely]
* (or none of the above)
Kind regards and thanks in advance.
[1] A bridge works like a switch, forwarding traffic from one interface to
another. Multicast and broadcast packets are always forwarded to all
interfaces that are part of the bridge. For unicast traffic, the bridge
learns which MAC addresses are associated with which interfaces and will
forward the traffic selectively.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
