[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200420094351.0fadab71@hermes.lan>
Date: Mon, 20 Apr 2020 09:43:51 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: roucaries.bastien@...il.com
Cc: netdev@...r.kernel.org, sergei.shtylyov@...entembedded.com,
Bastien Roucariès <rouca@...ian.org>
Subject: Re: [PATCH 1/6] Better documentation of mcast_to_unicast option
On Mon, 13 Apr 2020 01:50:33 +0200
roucaries.bastien@...il.com wrote:
> +.BR mcast_to_unicast
> +works on top of the multicast snooping feature of
> +the bridge. Which means unicast copies are only delivered to hosts which
> +are interested in it and signalized this via IGMP/MLD reports
> +previously.
> +
> +This feature is intended for interface types which have a more reliable
> +and/or efficient way to deliver unicast packets than broadcast ones
> +(e.g. WiFi).
> +
> +However, it should only be enabled on interfaces where no IGMPv2/MLDv1
> +report suppression takes place. IGMP/MLD report suppression issue is usually
> +overcome by the network daemon (supplicant) enabling AP isolation and
> +by that separating all STAs.
> +
> +Delivery of STA-to-STA IP mulitcast is made possible again by
> +enabling and utilizing the bridge hairpin mode, which considers the
> +incoming port as a potential outgoing port, too (see
> +.B hairpin
> +option).
It probably doesn't make difference but seems like inconsistent usage
of Bold and BoldRoman macros
.B mcast_to_unicast
works on top of the multicast snooping feature of
.BR hairpin "option)."
Powered by blists - more mailing lists