vxlan als fastd/tunneldigger Ersatz

Simon Kurka simon.kurka at ffnw.de
Mo Okt 2 19:28:49 CEST 2017


Hi auch,

ich habe mir dabei ein paar Gedanken gemacht ja. Erprobungsfähig ist
bisher nichts.

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 ;-))

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?

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
>
>



Mehr Informationen über die Mailingliste franken-dev