Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
F
ffbs-gluon
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
ffbs
ffbs-gluon
Commits
e4ef4217
Commit
e4ef4217
authored
7 years ago
by
Martin Weinelt
Committed by
Andreas Ziegler
7 years ago
Browse files
Options
Downloads
Patches
Plain Diff
docs: faq: clarify how to calculate proper mesh-vpn mtu value
parent
0d1d5791
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
docs/user/faq.rst
+81
-0
81 additions, 0 deletions
docs/user/faq.rst
docs/user/site.rst
+4
-1
4 additions, 1 deletion
docs/user/site.rst
with
85 additions
and
1 deletion
docs/user/faq.rst
+
81
−
0
View file @
e4ef4217
...
...
@@ -15,3 +15,84 @@ interface. This DNS server must be announced in router advertisements (using
on *batman-adv*. If your mesh does not have global IPv6 connectivity, you can setup
your *radvd* not to announce a default route by setting the *default lifetime* to 0;
in this case, the *radvd* is only used to announce the DNS server.
What is a good MTU on the mesh-vpn
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Setting the MTU on the transport interface requires careful consideration, as
setting it too low will cause excessive fragmentation and setting it too high
may leave peers with a broken tunnel due to packet loss.
Consider these key values:
- Payload: Allow for the transport of IPv6 packets, by adhering to the minimum MTU
of 1280 Byte specified in RFC 2460
- and configure `MSS clamping`_ accordingly,
- and announce your link MTU via Router Advertisments and DHCP
.. MSS clamping: http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.mtu-mss.html
- Encapsulation: Account for the overhead created by the configured mesh protocol
encapsulating the payload, which is
- up to 32 Byte (14 Byte Ethernet + 18 Byte batadv) for batman-adv compat v15 (v2014.0 and later)
- up to 28 Byte (14 Byte Ethernet + 14 Byte batadv) for batman-adv compat v14 (v2011.3.0 until and including v2013.4.0)
- PMTU: What MTU does the path between your gateway and each of its peers support?
For reference, the complete MTU stack looks like this:
.. image:: https://cloud.hamburg.freifunk.net/thumbnail/de738ee3ac/1024/MTU%20within%20a%20batman-adv%20network%20v5.png
Minimum MTU
-----------
Calculcate the minimum transport MTU by adding the encapsulation overhead to the
minimum payload MTU required. This is the lowest recommended value, since going
lower would cause unnecessary fragmentation for clients which respect the announced
link MTU.
Example: Our network currently uses batman-adv v15, it therefore requires up
to 32 Bytes of encapsulation overhead on top of the minimal link MTU required for
transporting IPv6.::
\ 1312 1294 1280 0
\---------+-----------------+-------------+----------------------------------+
\TAP | batadv v15 | Ethernet | Payload |
\-------+-----------------+-------------+----------------------------------+
\ ^
|
MTU_LOW = 1280 Byte + 14 Byte + 18 Byte = 1312 Byte
Maximum MTU
-----------
Calculating the maximum transport MTU is interesting, because it increases the
throughput, by allowing larger payloads to be transported, but also more difficult
as you have to take into account the tunneling overhead and each peers PMTU, which
varies between providers.
The underlying reasons are mostly PPPoE, Tunneling and IPv6 transition technologies
like DS-Lite.
Example: The peer with the smallest MTU on your network is behind DS-Lite and can
transport IPv4 packets up to 1436 Bytes in size. Your tunnel uses IPv4 (20 Byte),
UDP (8 Byte), Fastd (24 byte) and you require TAP (14 Byte) for Layer 2 (Ethernet)
Tunneling.::
1436 1416 1408 1384 1370 \
+-------------------+--------+-----------------------+-------------+------\
| IP | UDP | Fastd | TAP | bat\
+-------------------+--------+-----------------------+-------------+--------\
^ \
|
MTU_HIGH = 1436 Byte - 20 Byte - 8 Byte - 24 Byte - 14 Byte = 1370 Byte
Conclusion
----------
Determining the maximum MTU can be a tedious process, especially since the PMTU
of peers could change at any time. The general recommendation for maximized
compatibility is therefore the minimum MTU of 1312 Byte, which works well with
all combinations of IPv4, IPv6, batman-adv compat v14 and v15.
This diff is collapsed.
Click to expand it.
docs/user/site.rst
+
4
−
1
View file @
e4ef4217
...
...
@@ -195,7 +195,10 @@ mesh_vpn
Remote server setup for the mesh VPN.
The `enabled` option can be set to true to enable the VPN by default. `mtu`
defines the MTU of the VPN interface.
defines the MTU of the VPN interface, determining a proper MTU value is described
in the FAQ entry `"What is a good MTU on the mesh-vpn?"`_.
.. _"What is a good MTU on the mesh-vpn?": faq.rst
The `fastd` section configures settings specific to the *fastd* VPN
implementation.
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment