Letting linux be the router, allowing dynamic routes, suggestion

Marcelo Pacheco marcelo at m2j.com.br
Thu May 14 06:25:19 CEST 2015


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>


More information about the tinc-devel mailing list