Letting linux be the router, allowing dynamic routes, suggestion

[Marcelo Pacheco]

No, this would in fact operate as a routing mode instead of bridging.
TAP would be used as a means to push routing to where it belongs, the
linux/bsd/... kernel.
Consider the challenge of having completely dynamic routing between vpn
peers. In one minute I might have 10000 routes towards one specific peer,
and hour latter I might have NONE. And I need to diferentiate each peer at
the kernel routing layer.
And no, it can't be a pure bridge, it has to be L3 routing.
TAP is just to use the ethernet layer to multiplex/demultiplex each layer.
Consider how ethernet works.
How would linux/bsd routing works if we had 10 routers on the same subnet,
obviously each with a separate IP on that same subnet.
Now instead of having that physical ethernet wire, that wire is now 10 vpn
peers connected via the internet.
Consider that in that scenario each router have other ethernet interfaces,
but its ROUTING between the common ethernet interface and the remote ones.
Its not a BRIDGE between multiple ethernets.

On Tue, May 12, 2015 at 5:42 AM, Guus Sliepen <guus at tinc-vpn.org> wrote:

> On Tue, May 12, 2015 at 01:13:58AM -0300, Marcelo Pacheco wrote:
>
> [...]
> > Instead of creating a heap of tun devices, there's a more logical
> solution.
> > Create a TAP device, and emulate ARP on the VPN software.
> > The many peers would form a virtual ethernet device, where each tunnel
> has
> > a separate virtual MAC address.
>
> You mean like using tinc in switch mode?
>
>
> http://tinc-vpn.org/documentation/Main-configuration-variables.html#index-Mode
>
> --
> Met vriendelijke groet / with kind regards,
>      Guus Sliepen <guus at tinc-vpn.org>
>
> _______________________________________________
> tinc-devel mailing list
> tinc-devel at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20150512/bdefeb21/attachment.html>