Difference between revisions of "Mesh/Firmware/MTU issues"
Jump to navigation
Jump to search
(Created page with "MTU across the network has to be set correctly. MTUs we can control: *Mesh node wifi interfaces. *Mesh node ethernet interfaces. *Tunnels from mesh to vpn. *Tunnels from vpn...") |
m (Juul moved page Mesh/MTU issues to Mesh/Firmware/MTU issues) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 19: | Line 19: | ||
[http://www.open-mesh.org/projects/batman-adv/wiki/Troubleshooting some info on batman-adv MTU issues] (search for MTU on the page]. | [http://www.open-mesh.org/projects/batman-adv/wiki/Troubleshooting some info on batman-adv MTU issues] (search for MTU on the page]. | ||
[http://en.wikipedia.org/wiki/Path_MTU_discovery Wikipedia Path MTU discovery] | |||
Latest revision as of 12:49, 25 July 2013
MTU across the network has to be set correctly.
MTUs we can control:
- Mesh node wifi interfaces.
- Mesh node ethernet interfaces.
- Tunnels from mesh to vpn.
- Tunnels from vpn to exit node.
MTUs we cannot control:
- People's internet connections (ADLS / cable).
- People's existing routers' ethernet connections.
- Wifi of connecting nodes.
Issues
Both the L2TP tunnels, OpenVPN tunnels and batman-adv interfaces add overhead to packets. The MTUs should be calibrated to deal with this. At the VPNs, the L2TP tunnel interfaces' MTUs will be limited by the MTU of the internet connection so if we add them all to the same batman-adv interface, then the batman-adv interface MTU is probably (we should check) going to be limited by the smallest MTU out of all the L2TP interfaces. How can we avoid this? Have per-MTU batman-adv interfaces? Then how do they talk to each-other?
some info on batman-adv MTU issues (search for MTU on the page].