From: Roland Volkmann <roland.volkmann@t-online.de>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: [B.A.T.M.A.N.] No rebroadcast on mesh links
Date: Fri, 25 Mar 2016 22:35:43 +0100 [thread overview]
Message-ID: <56F5AF2F.6060904@t-online.de> (raw)
Hi,
when having Nodes with wired Mesh-Links, or on point-to-point
connections, rebroadcasts on the same interface are unnecessary, because
all Nodes receive the broadcast packets at the same time.
On non-gateway nodes (Freifunk-Routers) running firmware "Gluon", there
is a patch from Linus Lüssing adding the feature/option
"mesh_no_rebroadcast" to batman-adv, which is enabled by default on
mesh_vpn interface. Because of the good experience reducing traffic also
on other wired mesh links (Mesh-on-LAN / Mesh-on-WAN), this option will
also be enabled there by default with the upcoming Gluon v2016.2.
Gatways are not running Gluon, but typically Debian Linux, and there the
option "mesh_no_rebroadcast" does not exist on batban-adv.
Are there some (other) features already implemented in batman-adv to
prevent rebroadcast of unnecessary mesh packets?
If not, what is the chance to have the functionality implemented by the
mentioned patch as part of the original code base?
Background:
At Freifunk-Stuttgart we have multiple distributed gateways connected by
layer2-tinc, which is logically the same situation as using LAN-Cables
and physical Switch. Avoiding rebroadcast will reduce traffic between
the gateways.
Additional info:
On 12.03.2015 Ticket #207 was opened by Ruben Kelevra relating the same
issue, but immediately closed due to formal error.
Best regards,
Roland.
next reply other threads:[~2016-03-25 21:35 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-25 21:35 Roland Volkmann [this message]
2016-03-25 22:46 ` [B.A.T.M.A.N.] No rebroadcast on mesh links Sven Eckelmann
2016-03-25 23:19 ` Roland Volkmann
2016-03-27 2:38 ` Marek Lindner
2016-03-28 13:43 ` Roland Volkmann
2016-03-28 14:43 ` Marek Lindner
2016-03-28 19:11 ` Linus Lüssing
2016-03-28 21:19 ` Roland Volkmann
2016-03-28 23:52 ` Linus Lüssing
2016-03-29 8:37 ` Adrian Reyer
2016-03-29 9:50 ` Sven Eckelmann
2016-03-29 17:59 ` Adrian Reyer
2016-03-29 18:55 ` Sven Eckelmann
2016-03-29 23:37 ` Roland Volkmann
2016-03-30 2:15 ` Marek Lindner
2016-03-30 8:00 ` Sven Eckelmann
2016-03-30 9:09 ` Roland Volkmann
2016-03-30 12:23 ` Sven Eckelmann
2016-03-30 11:58 ` Simon Wunderlich
2016-03-30 13:58 ` Adrian Reyer
2016-03-30 16:08 ` Sven Eckelmann
2016-03-30 19:55 ` Adrian Reyer
2016-03-31 12:11 ` Simon Wunderlich
2016-03-31 12:21 ` Simon Wunderlich
2016-03-31 15:54 ` Antonio Quartulli
2016-03-31 16:25 ` Linus Lüssing
2016-03-31 15:35 ` Linus Lüssing
2016-03-31 15:49 ` Antonio Quartulli
2016-03-31 16:53 ` Linus Lüssing
2016-03-31 16:01 ` Antonio Quartulli
2016-03-31 17:17 ` Linus Lüssing
2016-04-13 12:17 ` Simon Wunderlich
2016-04-13 12:22 ` Sven Eckelmann
2016-03-29 0:02 ` Linus Lüssing
2016-03-29 6:38 ` Roland Volkmann
2016-03-30 8:08 ` Simon Wunderlich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56F5AF2F.6060904@t-online.de \
--to=roland.volkmann@t-online.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox