dswd
/
vpncloud
mirror of https://github.com/dswd/vpncloud.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Updated Frequently Asked Questions (markdown)

dswd 2016-08-25 09:17:57 +02:00
parent 08a5d7195c
commit 8353117901
1 changed files with 26 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
Frequently-Asked-Questions.md

@ -1,3 +1,28 @@
This is a collection of answers given to common questions.
##### Why does my VpnCloud setup perform so poorly?
Most likely this is because of a slightly too high (or missing) MTU setting on the interface. Please try the recommended way of 1400. With proper MTU settings, VpnCloud should perform almost as good as the native network.
##### What happens when I increase the MTU above 1400?
Setting the MTU higher than the physical medium causes IP to fragment each inner packet into several outer packets and reassemble them at the receiving side. This has the advantage that VpnCloud has to process less packets and therefore uses less CPU (most of it will be memcpy) and has less context switches. It will also save some bytes on the wire as less bytes are used for VpnCloud headers and UDP headers and only a small additional IP fragmentation header is added. I think in total that is the 2% you are seeing.
The downside is that if one of the outer packets gets lost on the wire the whole inner packet is lost. If your MTU is is 40 times higher than normal, 40 outer packets will be sent for one inner packet. So your packet loss rate will be about 40 times higher than normal (e.g. 4.1% instead of 0.1%). It will also influence your delay distribution negatively.
If the delay distribution and the loss ratio matters to you, this is a bad idea. If your line is pretty good and you just care about throughput, I think it makes sense to increase the MTU.
([Full thread in #2](../../issues/2))
##### Does VpnCloud support IP multicast?
VpnCloud has no special support for multicast and I did not test any multicast scenarios. So this is all theoretical:
1) If you use a TAP device, IP multicast should be mapped to ethernet broadcast and just work (although being a little bit inefficient)
2) If you use a TUN device with the default router mode IP multicast packets should be dropped as no node claims the IP multicast region.
3) If you use a TUN device with the learning switch mode, the multicast packets should be broadcast and multicast should just work (although being a little bit inefficient)
Other VPN software either does not implement multicast (like VpnCloud currently) or cheats by broadcasting it. Proper multicast support is somewhat complicated as several control protocols for IPv4 and IPv6 have to implemented. ([Full thread in #12](../../issues/12))
##### What does this "non-native forwarding mode" mean?
There are two device types TUN and TAP and the only difference between them is that TUN transports IP packets and TAP transports Ethernet frames.
All the rest is about how VpnCloud decides where packets/frames should be sent to. In routed mode each node claims one or more address regions by prefix and all the nodes match against those prefixes. In switch mode, nodes learn addresses by looking at the source addresses and broadcast for unknown addresses. Routed mode is native to TUN devices and switched mode is native to TAP devices but there is no reason not to use switched mode for TUN devices. ([Full thread in #12](../../issues/12))