vxlan als fastd/tunneldigger Ersatz

Tim Niemeyer tim at tn-x.org
Mo Okt 2 19:43:38 CEST 2017


Hi Simon

Am Montag, den 02.10.2017, 19:28 +0200 schrieb Simon Kurka:
> Hi auch,
> 
> ich habe mir dabei ein paar Gedanken gemacht ja. Erprobungsfähig ist
> bisher nichts.
Ich habe mich bisher noch _gar_ nicht mit dem Thema befasst. :(

> Mit L2TP lassen sich sicherlich ähnliche Vorteile erzielen, da der
> Kernel den Datenaustausch managed. Wesentlicher Nachteil an Tunneldigger
> ist afaik fehlendes Dual-Stack und die Instabilität?!
> 
> Nicht spruchreife Implementierungen stelle ich wirklich ungerne zur
> Diskussion, ich habe vor wenigen Tagen erst den gesamten C Code komplett
> weg geworfen (ist mein erstes C Projekt ;-))
Man kann es ja als RFC sehen.. ^^
Im Zweifel findet sich schon jemand der refactored oder rewriten kann,
wenn es überhaupt schon mal im Ansatz funktioniert hat.. :)

> Wir können gerne mal Ideen zu dem Thema austauschen. Hier sind meine:
> 
> Batman-adv tauscht Daten via L2-Broadcast an 00:00:00:00:00:00 aus. Das
> Autolearning von VXLAN ist dafür nicht ausreichend. Der
> Verbindungsaufbau kann (muss?) daher wie bei Tunneldigger im Userspace
> statt finden.
> 
> 1. Der Router stellt eine Verbindungsanfrage an einen Server. Diese
> Anfrage kann per UDP erfolgen um gleichzeitig klassisches UDP Hole
> Punching zu betreiben.
> 
> 2. Der Server fügt einen neuen L2 Broadcast Eintrag auf die Quell-IP &
> Port Kombination in die Forwarding DB ein und bestätigt die
> Verbindungsanfrage
> 
> 3. Der Router konfiguriert sein VXLAN Interface Richtung Server.
> 
> 4. Austausch von Keep-Alive Paketen über den Tunnel. Bei ausbleibenden
> Keep-Alives werden alle Daten aus der Verbindung aufgelöst und ggf.
> aktiv ein Disconnect von jeder Seite gesendet. Der Verbindungsprozess
> kann dann erneut gestartet werden.
> 
> Ich vermute das Vorgehen ist (fast) identisch zu Tunneldigger, basierend
> auf einem anderen Protokoll. Was performanter ist würde ich Live-Tests
> überlassen.
> 
> Habt ihr Anregungen? Habe ich etwas übersehen?
Gestern war gefühlt noch eine kleine Unsicherheit mit der MTU da. Wenn
das heute immer noch so ist, dann sollten wir das mal vorher testen
bevor wir Verbindungsaufbau / Handshaking / Keep-Alive / etc entwickeln.

Ansonsten wäre bei der Implementierung wichtig, dass man jeweils den UDP
Port wählen kann, da wir gern mehrere "Hood-Instanzen" auf ein Gateway
werfen.

Tim

> 
> Viele Grüße,
> Simon
> 
> On 02.10.2017 16:40, Tim Niemeyer wrote:
> > Hi zusammen
> >
> > Christian und ich haben uns gestern mit Simon (ich hoffe ich hab den
> > richtigen im CC erwischt) über vxlan unterhalten.
> >
> > Simon ist dabei vxlan als möglichen Ersatz für das vpn zu erproben. Er
> > hat dazu bereits eine (fast fertige?) Implementierung.
> >
> > Der Vorteil wäre, dass wir keine Verschlüsselung brauchen und alles im
> > Kernel passieren kann. Vermutlich (das ist bisher nicht sicher
> > bestätigt) kann man die MTU auf dem vxlan Interface für Batman auf 15xx
> > stellen, damit batman nicht fragmentieren muss. vxlan wird dann intern
> > zwar fragmentieren, aber mit fastd und Tunneldigger im Vergleich
> > passiert die Fragmentierung im batman und die Pakete müssen dann zweimal
> > ins VPN geschickt werden.
> >
> > Als weiterer Vorteil (zumindest im Vergleich zu fastd, bei Tunneldigger
> > weiß ich es nicht) gibt es die Möglichkeit (sofern die Hardware es
> > supported), dass Hardware-Beschleunigung verwendet werden kann. Ich
> > rechne allerdings nicht damit, dass die Plaste-Kisten das können.
> >
> > Tim
> >
> >
> 

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20171002/9963c008/attachment.sig>


Mehr Informationen über die Mailingliste franken-dev