hans at fugal.net
Tue Jul 5 15:36:43 MDT 2005
On Tue, 5 Jul 2005 at 15:25 -0600, Andrew McNabb wrote:
> Some of you may be sick of this thread, but I have found it extremely
> insightful. Thanks to everyone who has participated.
It was indeed a blast.
> As far as tun vs. tap is concerned, I've been a little biased towards
> tun because my only application of OpenVPN so far has been in an
> environment where tun is really the only way to go.
> We have three separate subnets which are connected together by an
> OpenVPN network. The main thing that impressed me with OpenVPN is that
> it can route everything properly even if the various routers have
> dynamic VPN IP addresses. The only thing I have to specify in the
> configuration is that client A is a router for subnet A, client B for
> subnet B, and so on. The IP address assigned to client A is irrelevent.
> I thought that that was very cool.
Yes, it is cool. One (who?? me??) might say that openvpn is emulating a
router now too... but I won't go there. ;-) Part of OpenVPN's beauty is
its simplicity, and part of that simplicity is doing a lot of this stuff
internally. I have found that James has excellent sense in how to strike
this balance, although I take issue with the community's anti-DHCP
> Thanks to everyone's input, when I set up my wireless network, I'll
> probably use tap for it. However, I still have a question about
> efficiency. I can see, from the various points that have been made,
> that tap is probably easier to configure for a many-clients network.
> However, Hans also said that it tap can be faster than tun. I have a
> hard time seeing that, since tun would avoid ARP packets and other such
> chatty packets which are commonly found on a subnet. Why would tap be
> faster than tun? Are there other factors?
tap would undoubtedly generate more traffic. If bandwidth is an issue,
that traffic may be a performance hit. If bandwidth is fine, it may not
be a real-world issue. I only related the gist of a poor memory of some
anecdotal account of tap being "fast." I can't off-hand think of any
reason tap would be faster, although it might have been in a windows
client setup where the translation from tap to tun which Windows has to
do ended up slowing things down.
Clearly more empirical evidence is needed (or more research to find such
which may already exist), and clearly tun is theoretically faster.
I probably needed to be more careful, too - tap is definitely less
efficient than tun because you are passing along all layer 2 traffic
like ARP, not filtering it. But in the magical world of networking,
interesting things can happen, like efficiency != speed.
.O. Hans Fugal | De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://plug.org/pipermail/plug/attachments/20050705/446ddaa0/attachment.bin
More information about the PLUG