vxlan als fastd/tunneldigger Ersatz

[Simon Kurka]

Unterschiedliche UDP Ports sind eigentlich nicht notwendig, da man über
die VXLAN ID trennen kann.

Bzgl. MTU:

#ip link add vxlan0 type vxlan id 42 dstport 4789
#ip a

vxlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000

#ip link set mtu 1628 dev vxlan0
#ip a

vxlan0: <BROADCAST,MULTICAST> mtu 1628 qdisc noop state DOWN group
default qlen 1000

1628 war jetzt aus der Luft gegriffen. Welcher Wert ist da genau sinnvoll?

Viele Grüße,
Simon

On 02.10.2017 19:43, Tim Niemeyer wrote:
> 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
>>>
>>>