l2tp statt fastd zwischen den Supernodes - best practice?

Ich wollte ein wenig mit alternativer Tunnel-Technik rumspielen und stehe vor folgender Frage:

Historisch haben ja die Supernodes fastd zu den Nodes - für den Quertraffic zwischen den Supernodes haben diese auch ein eigenen fastd-Prozess (schon alleine um die dortige CPU-Last besser auf die CPU-Kerne zu verteilen, wenn man einfach mehrere fastd-Instanzen startet, oder eben auch wegen ander/keiner Crypto…).
Diese beiden fastd-Interfaces „stecken“ im batman-adv (hier: v14-compat) bat0, der sich um die Bridge-Loop-Avoidance kümmert.
Dieses bat0 wiederum steckt (als einziges) Interface in der lokalen Host-Bridge br-all, welche dann wiederum selbst kein STP aktiviert hat - weil sie’s ja mit nur einem Interface gesteckt auch nicht braucht…

Jetzt evaluiere ich gerade L2TP als Ersatz für die fastd-Server-Instanz - was mache ich am besten mit diesem Pseudowire…?

  • mit in bat0 stecken? (# batctl -m bat0 if add l2tp0)
    oder
  • STP auf der Bridge aktivieren und parallel zu bat0 in die br-all

?

Zusätzlich: würde ich zwischen den Supernodes ein volles N-zu-N Mesh damit aufziehen, bei der jede Supernode zu jeder anderen eine Verbindung über L2TP hat und die dann in den br-all sammeln?
oder nur maximal „einen Ring“ bauen, bei dem jede Supernode nur zwei Tunnel hat - einen „rechts“ und einen „links“?

Do-s and Don’t-s ? Erfahrungen?

Grüsse
Shiva

Für’s Setup v2 (neue und mehr VMs, funktionale Trennung, Konfiguration via puppet) hab’ ich für die Verbindung zwischen den GWs auf L2TP-Tunnel gesetzt (siehe Grafik). Die L2TP-Tunnel sind per batctl if einfach zugeschaltet, wie es vorher das Backbone-fastd-Interface war. Aber weder inner- noch intra-DC sehe ich die Notwendigkeit der Verschlüsselung des unverschlüsselten WLAN-Verkehrs, schon daher weg mit fastd an der Stelle:

root@gw01:~# batctl-ffgt if
gw01-gw02: active
gw01-gw03: active
gw01-gw04: active
ffgt-mesh-vpn: active

Geplant und derzeit umgesetzt ist ein FullMesh (siehe Grafik), was aber mit mehr Gateways irgendwann (also eigentlich ab dem 5. ;)) nicht mehr zwingend praktikabel ist. Evtl. wird es auf 2 designierte GWs pro „RZ“ rauslaufen, die den Traffic in- und außerhalb des jeweiligen Bereichs transportieren und im jeweiligen RZ/beim jeweiligen Hoster werden weitere GWs nur parallel an jene beiden angebunden. Selbst zw. verschiedenen Hetzner-RZen sind die Laufzeiten i. d. R. unter 1 ms — ich glaube nicht, daß sich da ein FullMesh wirklich lohnt. Zumal Inter-GW-Verkehr eigentlich gering sein sollte?

Randbedingungen: batman_adv v14. GWs machen bei uns nur Mesh, IPvX-Defaultroute kommt per OSPF von einem von zwei lokalen Routern (je 1 priorisiert über OPSF-Kosten). Damit ist die fastd-Ebene unabhängiger skalierbar. Inwiefern das noch toll ist, wenn nicht mehr die CPU das Bottleneck ist sondern die GBit-Ports (nach Wechsel von fastd zu L2TP auch zwischen Knoten und Gateway), wird sich zeigen.
Außerdem fangen wir den bisherigen Hoster-Zoo ein, aktuell sieht’s danach aus, daß wir in Gütersloh weiter Hardware stehen haben werden und ein, zwei Hosts bei Hetzner anmieten für Redundanz und Lastspitzen. (Die i7-Kisten aus der Serverbörse machen eine nette Figur und sind mit ~40 EUR/Monat für Kiste, 20 TB und /64er v6- und 5 v4-Adressen für uns erstmal ausreichend.) Außerhalb Güterslohs gehen wir, aus Latenz- und Redundanzgründen, über den FFRL ins v4-Internet. fastd-Ausbalancierung erfolgt durch minütlichen Check der Größe des Meshes, der aktiven (batman-) Gateways und der fastd-Verbindungen, jedes GW nimmt nicht mehr als (KnotenImMesh + 50)/AnzahlBatmanGateways fastd-Verbindungen an. Bei Überschreiten des dynamischen Wertes lehnt das Gateways neue fastd-Verbindungen ab, fastd auf dem Knoten sollte dann ein anderes Gateways ansprechen, was auch zu tun scheint :wink:
Ungelöst (und partiell ungeklärt) ist derzeit noch die ungleiche Verteilung von Clients auf (IPv4-) Gateways; trotz zentralem DHCPd kommt es vor, daß trotz fastd-Verbindung z. B. zu gw03 gw01 als DHCP-Gateway auserkoren wird. Geschieht dies RZ-übergreifend, geht der Datenverkehr pro Paket ggf. mehrfach zwischen Gütersloh und Frankfurt hin und her :frowning: Aber das Problem hatten wir auch schon vor L2TP und zentralem DHCP …

Bislang finde ich L2TP super; wir fahren aber noch keinen Kernel, mit dem die MAC-Adressen änderbar sind. Sofern sich das als Problem herausstellt, werden wir darüber nachdenken :wink: Wichtig für uns war, daß die Sessions per „name“ benamst werden können, l2tpXX ist doch etwas unhandlich. Evtl. werden die GRE-Tunnel mit der Zeit, wo möglich, bei uns durch L2TP ersetzt, um das Setup zu vereinfachen.

HTH,
-kai

Hallo,

bei uns haben sich für die Verbindung der Gateways, des Backbones und der Superknoten GRE-Tunnel etabliert. Das ist ziemlich simpel und ich kann es nur weiter empfehlen. Überall da, wo Batman drüber laufen soll, nimmt man dann Gretap und reine Routingtunnel reines GRE.

Fastd machen wir nur noch zu den Plastikroutern durch die DSL- und Kabelanschlüsse.

Grüße
Matthias

GRE funktioniert im Fall von Düsseldorf z.b. fast gar nicht da der Hoster die Rate für GRE Pakete limitiert.
Wir haben in diesem Fall viel bessere Erfahrungen mit L2TPv3 gemacht.

Hier ein Beispiel wie wir die Tunnel aufgesetzt haben:

iface bb-map inet manual
  pre-up ip l2tp add tunnel tunnel_id 10203 peer_tunnel_id 10302 encap ip local 89.163.154.93 remote 5.45.103.49 ; exit 0
  pre-up ip l2tp add session tunnel_id 10203 session_id 10203 peer_session_id 10302 name $IFACE ; exit 0
  post-up ip link set address 06:BE:EF:25:00:02 dev $IFACE
  post-up ip link set dev $IFACE mtu 1400
  post-up ip link set up dev $IFACE
  # Batman configuration
  post-up batctl if add $IFACE
  post-up echo "enabled" > /sys/devices/virtual/net/$IFACE/batman_adv/no_rebroadcast
  pre-down batctl if del $IFACE
  post-down ip l2tp del tunnel tunnel_id 10203 peer_tunnel_id 10302 encap ip local 89.163.154.93 remote 5.45.103.49

In diesem Beispiel verwenden wir L2TP over IP (Also nicht UDP), soweit ich es sehen kann hat es den selben Overhead wie GRE.

Wie man sieht schalten wir auch das Rebroadcasting ab, denn beide Gateways sowie der Map Server sind voll vermascht und Rebroadcasting sinnlos in diesem Fall.

Gestartet werden diese Interfaces durch ein Systemd-Script bei Bootzeit, dadurch können wir bestimmen in welcher Reihenfolge wir Interfaces & Dienste starten.

2 Likes

Welcher ist das? Eventuell haben noch andere das Problem, ohne es zu merken.

Und dake für die Beispielkonfiguration. Wie ich sehe, hat der Tunnel jetzt keine eigene IP, wie macht ihr dann geroutete Verbindungen (IP / Layer3), z.B. zum Backbone?

Grüße
Matthias

In dem Fall ist es FFRL Hardware.

Oh hab den letzten Part irgendwie überlesen.

Das ist lediglich die Verbindung zwischen den Gateways, der Uplink zum Backbone is via Tun-Device auf beiden Gateways realisiert.

Auch die muss ja irgendwo stehen. Im Zweifel kann man das meist per Traceroute auf die IP ermitteln.

Soweit ich weiß Myloc in Düsseldorf.

[quote=„CyrusFox, post:4, topic:9121“]
GRE funktioniert im Fall von Düsseldorf z.b. fast gar nicht da der Hoster die Rate für GRE Pakete limitiert.[/quote]

Oh, interessant. Den IPs nach steht der Host bei Netcup und die Gegenstelle bei myLoc. Ja, GRE ist einfach zu erkennen, L2TP via IP allerdings eigentlich vergleichbar. Daher ziehe ich i. d. R. UDP vor, weil man dann auch flexibler ausweichen könnte, das Verhalten von UDP aber IP recht ähnlich ist. Aber wahrscheinlich wäre ein Anbieterwechsel in dem Falle sinnvoller, als das Katz-und-Maus-Spiel mitzumachen. Wirkt sich IP/UDP auf die Nutzlast, i. e. MTU, durch den Tunnel aus?

ot: viele der hoster haben eine udp paket drossel … um p2p ab/kleinzuhalten … aber wird haben ja kein 2. klassen internet :slight_smile:

Wir haben sogar ein Gateway was bei denen steht und am Rheinland Backbone hängt - über GRE versteht sich :cry:.

Danke für die Info!

Gibt es eine Policy von denen, die das erklärt oder Messdaten? Wir würden gerne irgendwas objektives haben um eine Entscheidung über den Fortbestand der Server by MyLoc zu treffen.

Muss ich da was Zaubern damit das funktioniert? Bei uns geht es nicht.

Du musst batman mit dem Patch kompilieren

Ja da ist es ja vorbei … Welcher Patch? Wo finde ich den, und wie baue ich mit dem Patch?

wget http://map.freifunk-moehne.de/stuff/1001-batman-adv-introduce-no_rebroadcast-option.patch
im batman dir einfach patch < 1001-batman-adv-introduce-no_rebroadcast-option.patch
make
make install

1 Like