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

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>

On Tue, May 12, 2015 at 05:21:49PM -0300, Marcelo Pacheco wrote:
> I see what you want me to do. But it does incur an extra MAC layer header
> to each VPN packet,
This is a quite small overhead.
> more fragmentation.
This doesn't imply more fragmentation. Tinc already does path MTU
discovery, calculating the optimum packet size for tunneled packets, and
uses various techniques to enforce this on VPN traffic without causing
fragmentation.
> And broadcasts leak to all peers.
If you don't want broadcast packets at all, you can set Broadcast = no,
and add static entries to the kernel's ARP table.

If you are worried about broadcast ARP packets leaking to peers, then
having all peers in the same VPN is maybe not what you should do in the
first place.
> 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.
There is nothing special about L3 compared to L2 that magically prevents
routing loops. Unless you configure things wrong, I don't see how having
redundant L2 connections automatically implies getting an instant L2
loop.

I'm sorry, but I think your proposal of doing some weird IP address to
MAC address mapping does not make sense. If you need even more control
over routing between nodes than tinc already provides, then implementing
better support for VLANs, or perhaps even support for MPLS, would be the
way to go.

-- 
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/7fc0ff2b/attachment.sig>

Dropping broadcasts doesn't magically fix the problem. Any unicast packet
to an unlearned (and offline) MAC address behaves exactly the same as a
broadcast.
Trying to be pure doesn't always work in the real world.

On Tue, May 12, 2015 at 6:05 PM, Guus Sliepen <guus at tinc-vpn.org>
wrote:
> On Tue, May 12, 2015 at 05:21:49PM -0300, Marcelo Pacheco wrote:
>
> > I see what you want me to do. But it does incur an extra MAC layer
header
> > to each VPN packet,
>
> This is a quite small overhead.
>
> > more fragmentation.
>
> This doesn't imply more fragmentation. Tinc already does path MTU
> discovery, calculating the optimum packet size for tunneled packets, and
> uses various techniques to enforce this on VPN traffic without causing
> fragmentation.
>
> > And broadcasts leak to all peers.
>
> If you don't want broadcast packets at all, you can set Broadcast = no,
> and add static entries to the kernel's ARP table.
>
> If you are worried about broadcast ARP packets leaking to peers, then
> having all peers in the same VPN is maybe not what you should do in the
> first place.
>
> > 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.
>
> There is nothing special about L3 compared to L2 that magically prevents
> routing loops. Unless you configure things wrong, I don't see how
having
> redundant L2 connections automatically implies getting an instant L2
> loop.
>
> I'm sorry, but I think your proposal of doing some weird IP address to
> MAC address mapping does not make sense. If you need even more control
> over routing between nodes than tinc already provides, then implementing
> better support for VLANs, or perhaps even support for MPLS, would be the
> way to go.
>
> --
> 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/20150514/9b3f2b7e/attachment-0001.html>