Letting linux be the router, allowing dynamic routes, suggestion

[Guus Sliepen]

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>