<div dir="ltr">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.<div>Trying to be pure doesn't always work in the real world.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 12, 2015 at 6:05 PM, Guus Sliepen <span dir="ltr"><<a href="mailto:guus@tinc-vpn.org" target="_blank">guus@tinc-vpn.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, May 12, 2015 at 05:21:49PM -0300, Marcelo Pacheco wrote:<br>
<br>
> I see what you want me to do. But it does incur an extra MAC layer header<br>
> to each VPN packet,<br>
<br>
</span>This is a quite small overhead.<br>
<br>
> more fragmentation.<br>
<br>
This doesn't imply more fragmentation. Tinc already does path MTU<br>
discovery, calculating the optimum packet size for tunneled packets, and<br>
uses various techniques to enforce this on VPN traffic without causing<br>
<span class="">fragmentation.<br>
<br>
> And broadcasts leak to all peers.<br>
<br>
</span>If you don't want broadcast packets at all, you can set Broadcast = no,<br>
and add static entries to the kernel's ARP table.<br>
<br>
If you are worried about broadcast ARP packets leaking to peers, then<br>
having all peers in the same VPN is maybe not what you should do in the<br>
first place.<br>
<span class=""><br>
> It sure saves you from doing any improvements, but there are side effects<br>
> that are undesirable to many customers.<br>
> This is specially a problem if I want two VPN connections between two sites<br>
> using redundant connections, we get an instant L2 loop.<br>
> With my proposal this doesn`t happen since the traffic between peers is<br>
> still L3.<br>
<br>
</span>There is nothing special about L3 compared to L2 that magically prevents<br>
routing loops. Unless you configure things wrong, I don't see how having<br>
redundant L2 connections automatically implies getting an instant L2<br>
loop.<br>
<br>
I'm sorry, but I think your proposal of doing some weird IP address to<br>
MAC address mapping does not make sense. If you need even more control<br>
over routing between nodes than tinc already provides, then implementing<br>
better support for VLANs, or perhaps even support for MPLS, would be the<br>
way to go.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Met vriendelijke groet / with kind regards,<br>
     Guus Sliepen <<a href="mailto:guus@tinc-vpn.org">guus@tinc-vpn.org</a>><br>
</div></div><br>_______________________________________________<br>
tinc-devel mailing list<br>
<a href="mailto:tinc-devel@tinc-vpn.org">tinc-devel@tinc-vpn.org</a><br>
<a href="http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc-devel" target="_blank">http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc-devel</a><br></blockquote></div><br></div>