Suggestion: use Open-Mesh/BATMAN to help with layer 2/3 routing?

Michael Adams madams at ezrac.com
Fri Apr 29 15:25:02 CEST 2011


Thanks for replying. Interesting stuff on your response to #1. As for 
#2, since I'm using tinc as Ethernet interfaces, I've had to use Quagga 
to maintain an OSPFv3 routing setup. It works nicely: my thoughts on 
BATMAN were leaning towards the idea that tinc could implement it so you 
could dump use of external routing, and create a self-maintaining 
network. I'd be glad to test out having my network not rely on a central 
point.

On 2:59 PM, Guus Sliepen wrote:
> On Thu, Apr 28, 2011 at 12:07:01AM -0400, Michael Adams wrote:
>
>> http://www.open-mesh.org/
>>
>> Idea #1: is BATMAN worth considering using as part of the layer 2 routing in
>> Tinc?
> I do not know if it would improve anything. Also, a VPN is an overlay network,
> so it works on top of an already existing network, where you can more or less
> assume all nodes can already talk to each other (barring NAT and firewalls of
> course). Tinc's internal routing protocol, which is similar to OSPF, is used
> only as a fallback for when packets cannot be sent directly to the destination.
> This is not something other routing protocols take into account AFAIK (mostly
> because they are not designed for overlay networks).
>
> An idea I have is to expose the connections to various other nodes as VLANs on
> the tap interface, or creating multiple tap interfaces, so you can run any
> routing daemon on top of them, without having to hack an existing routing
> protocol into tinc.
>
>> Idea #2: would it be possible to embed BATMAN as an option to avoid having
>> to use Quagga for routing v6 subnets?
> Why do you need to use Quagga for routing v6 subnets in the first place? And if
> you already run a routing daemon on top of tinc, I do not see why you cannot
> use BATMAN on it as well without having to embed it?
>




More information about the tinc-devel mailing list