tinc devel - May 2015 - Letting linux be the router, allowing dynamic routes, suggestion

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>

On Tue, May 12, 2015 at 04:27:10PM -0300, Marcelo Pacheco wrote:
> 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.
Although the manual says that switch mode is primarily useful for
bridging Ethernet segments, it doesn't say you cannot use it for other
things, including what you want.

In switch mode, tinc routes solely based on the Ethernet header.
Whatever you want to do with that is up to you. If you want to add or
remove 10000 routes to a specific node, then just add those routes with
the gateway address set to that node. If you want to run OSPF or any
other routing protocol on top of tinc, that is possible as well.
> 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.
That is already exactly what happens in switch mode; tinc creates a tap
interface and forms a virtual switch. It doesn't have to emulate ARP at
all, the kernel will generate ARP packets as usual. Each node's tap
interface has its own MAC address.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20150512/125bfc41/attachment.sig>

I see what you want me to do. But it does incur an extra MAC layer header
to each VPN packet, more fragmentation.
And broadcasts leak to all peers.
It sure saves you from doing any improvements, but there are side effects
that are undesirable to many customers.
This is specially a problem if I want two VPN connections between two sites
using redundant connections, we get an instant L2 loop.
With my proposal this doesn`t happen since the traffic between peers is
still L3.

On Tue, May 12, 2015 at 4:45 PM, Guus Sliepen <guus at tinc-vpn.org>
wrote:
> On Tue, May 12, 2015 at 04:27:10PM -0300, Marcelo Pacheco wrote:
>
> > 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.
>
> Although the manual says that switch mode is primarily useful for
> bridging Ethernet segments, it doesn't say you cannot use it for other
> things, including what you want.
>
> In switch mode, tinc routes solely based on the Ethernet header.
> Whatever you want to do with that is up to you. If you want to add or
> remove 10000 routes to a specific node, then just add those routes with
> the gateway address set to that node. If you want to run OSPF or any
> other routing protocol on top of tinc, that is possible as well.
>
> > 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.
>
> That is already exactly what happens in switch mode; tinc creates a tap
> interface and forms a virtual switch. It doesn't have to emulate ARP at
> all, the kernel will generate ARP packets as usual. Each node's tap
> interface has its own MAC address.
>
> --
> 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/10a0059e/attachment-0001.html>