171 lines
6.6 KiB
ReStructuredText
171 lines
6.6 KiB
ReStructuredText
gluon-mesh-batman-adv
|
|
=====================
|
|
|
|
.. image:: gluon-mesh-batman-adv-logo.svg
|
|
:width: 300 px
|
|
|
|
B.A.T.M.A.N. Advanced (often referenced as batman-adv) is an implementation of
|
|
the B.A.T.M.A.N. routing protocol in form of a linux kernel module operating on layer 2.
|
|
|
|
Layer 2 means that all client devices will operate in the same, virtual broadcast
|
|
domain and will see each other "as if they were connected to one giant switch".
|
|
|
|
This comes with a set of advantages (like quick and economical client device roaming,
|
|
layer 3 protocol agnosticism, broadcast/multicast). But also impediments, especially
|
|
layer 2 multicast overhead - which Gluon tries to mitigate to achieve a certain degree
|
|
of scalability. See :doc:`gluon-ebtables-filter-multicast` and
|
|
:ref:`batman-adv-multicast-architecture` for details.
|
|
|
|
B.A.T.M.A.N. Advanced project homepage:
|
|
|
|
* https://www.open-mesh.org/projects/batman-adv/wiki/Wiki
|
|
|
|
B.A.T.M.A.N. Routing Algorithms
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Two routing algorithms are selectable via
|
|
:ref:`site.conf mesh section <user-site-mesh>`: BATMAN_IV and BATMAN_V.
|
|
|
|
BATMAN_IV - stable
|
|
""""""""""""""""""
|
|
|
|
This is the recommended algorithm to use with `gluon-mesh-batman-adv-15`.
|
|
|
|
BATMAN_V - experimental
|
|
"""""""""""""""""""""""
|
|
|
|
This is the experimental B.A.T.M.A.N. routing algorithm. It is packet format /
|
|
compatibility stable but is still in development.
|
|
|
|
For more details, see:
|
|
|
|
* https://www.open-mesh.org/projects/batman-adv/wiki/BATMAN_V
|
|
|
|
.. _batman-adv-multicast-architecture:
|
|
|
|
Multicast Architecture
|
|
----------------------
|
|
|
|
.. image:: gluon-mesh-batman-adv-multicast.svg
|
|
:width: 300 px
|
|
|
|
While generally broadcast capability is a nice feature of a layer 2
|
|
mesh protocol, it quickly reaches its limit.
|
|
|
|
For meshes with about **50 nodes / 100 clients, or more** it is therefore highly
|
|
recommended to add the :doc:`gluon-ebtables-filter-multicast`
|
|
package. Also, with the *mesh-batman-adv-15* feature,
|
|
:doc:`gluon-ebtables-limit-arp` is selected by default.
|
|
|
|
Furthermore, by default IGMP and MLD messages are filtered. See
|
|
:ref:`site.conf mesh section <user-site-mesh>` and
|
|
:ref:`igmp-mld-domain-segmentation` for details.
|
|
|
|
To achieve some level of scalability for multicast, multicast group
|
|
awareness is implemented and utilized in the following ways:
|
|
|
|
Node-Local Multicast Handling
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
.. image:: gluon-mesh-batman-adv-multicast-architecture-to-clients.svg
|
|
|
|
A Gluon node sends IGMP/MLD Queries with the following parameters on its
|
|
local segment:
|
|
|
|
* Interval: 20 seconds
|
|
* Robustness: 9
|
|
* Query Response Interval: 5 seconds
|
|
|
|
This way, through the returning IGMP/MLD reports, the node learns which
|
|
multicast groups its clients are interested in.
|
|
|
|
This is then used to deliver multicast packets to its own Wifi clients
|
|
via individual Wifi unicast transmissions instead of a broadcast transmission.
|
|
|
|
The advantages of this are:
|
|
|
|
* Usually higher bitrates: Mostly lower airtime usage
|
|
* Acknowledged, retried transmissions (ARQ): Higher reliability
|
|
* If no local client is interested: Avoiding the transmission, no airtime usage
|
|
|
|
Notably multicast for IPv6 Neighbor Discovery usually has only a single
|
|
multicast listener in the case of address resolution and usually no
|
|
multicast listener for duplicate address detection. Which are the ideal
|
|
cases for multicast snooping / multicast to unicast.
|
|
|
|
The unicast delivery is achieved through utilizing the multicast-to-unicast
|
|
feature in OpenWrt/netifd. Which in turn utilizes the multicast-to-unicast
|
|
conversion and hairpin features of the Linux bridge, plus the hostapd client
|
|
isolation feature, to hand over full delivery control to the bridge.
|
|
|
|
Mesh-wide Multicast Handling
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
.. image:: gluon-mesh-batman-adv-multicast-architecture-to-mesh.svg
|
|
|
|
To be able to avoid transmissions not only on the "last mile", the AP interface
|
|
to the local clients, but also from the "last mile" into the mesh in the future
|
|
multicast listener state is propagated through the mesh:
|
|
|
|
batman-adv (compat 15) taps into the Linux bridge and inherits the multicast
|
|
groups into its translation table. Which then takes care of efficiently
|
|
distributing this knowledge to other nodes.
|
|
|
|
While by that the receiver side is ready to go, the sender part in batman-adv
|
|
is disabled for now in Gluon. It will be enabled in a future release.
|
|
|
|
.. _igmp-mld-domain-segmentation:
|
|
|
|
IGMP/MLD Domain Segmentation
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
.. image:: gluon-mesh-batman-adv-multicast-architecture-segmentation.svg
|
|
|
|
Internet Group Membership Protocol and Multicast Listener Discovery Protocol
|
|
are the standardized network protocols to query, report and learn multicast
|
|
group memberships on the local link for IPv4 (IGMP) and IPv6 (MLD).
|
|
|
|
By default Gluon filters IGMP and MLD queries and reports towards the mesh
|
|
and runs an IGMP/MLD querier on each node for its own local clients.
|
|
Furthermore Gluon tags the mesh side bridge port (bat0) as a multicast
|
|
router port.
|
|
|
|
That way, even though the Linux client bridge in Gluon is unable to learn
|
|
about multicast memberships behind other nodes, the multicast router port
|
|
flag will force it to unconditionally hand over all multicast packets to
|
|
batman-adv. Which even with IGMP/MLD filtered, will have full multicast
|
|
membership knowledge through its own propagation through the batman-adv
|
|
translation table.
|
|
|
|
Advantages are:
|
|
|
|
* Reduced overhead through reactive batman-adv multicast TT vs.
|
|
periodic IGMP/MLD messages in the mesh
|
|
* Increased IGMP/MLD snooping robustness via local, per node
|
|
IGMP/MLD queriers
|
|
* DDoS vector mitigation
|
|
|
|
**Note:** For nodes running an operating system other than Gluon, but a bridge
|
|
interface on top of the batman-adv interface, you will need to set the
|
|
multicast router flag there manually:
|
|
|
|
``debian$ echo 2 > /sys/class/net/bat0/brport/multicast_router``
|
|
|
|
"2" for this parameter means to always assume a multicast router behind
|
|
this bridge port and to therefore forward all multicast packets to this
|
|
port. Versus the default of "1" which means to learn about multicast
|
|
routers via IGMP/MLD Queries, PIM and MRD messages; or "0" to always
|
|
assume that there is no multicast router behind this port, meaning
|
|
to only forward multicast to this port if an according multicast
|
|
listener on this link was detected.
|
|
|
|
Further limitations: IGMP/MLD snooping switches (e.g. "enterprise switches")
|
|
behind the client network of a node (LAN ports) are unsupported. It is
|
|
advised to disable IGMP/MLD snooping on those enterprise switches for now
|
|
or to at least manually mark the port to the Gluon router as a
|
|
"multicast router port".
|
|
|
|
Alternatively, the filtering of IGMP/MLD reports can be disabled via
|
|
the site.conf (which is not recommended in large meshes though).
|
|
See :ref:`site.conf mesh section <user-site-mesh>` for details.
|