technik:babel-backbone

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
technik:babel-backbone [10.10.2024 - 19:22] nrbtechnik:babel-backbone [12.10.2024 - 12:09] (aktuell) nrb
Zeile 3: Zeile 3:
 Der Babel-Backbone wird aktuell verwendet, um zwischen unseren Proxmox-Hosts in den beiden Clustern pvehetzner und pvez10a ein L3-Netzwerk aufzubauen. Der Babel-Backbone wird aktuell verwendet, um zwischen unseren Proxmox-Hosts in den beiden Clustern pvehetzner und pvez10a ein L3-Netzwerk aufzubauen.
  
-Dieses L3 wird bspw. als underlay fuer verwendet das clusteruebergreifende VXLAN auf unseren [[technik:proxmox|Proxmox-Hosts]] verwendet.+Dieses L3 wird bspw. als underlay fuer das clusteruebergreifende VXLAN auf unseren [[technik:proxmox|Proxmox-Hosts]] verwendet. 
 + 
 +===== Adressen ===== 
 + 
 +jeder host seine IPv4 und IPv6 Adresse auf dem Loopbackinterface ''bb-loop'' 
 + 
 +auf den Interfaces auf denen babel gesprochen wird (beispielsweise ''connections'') gibt es nur link-local IPv6. IPv4 wird per v6-nexthop geroutet.  
 + 
 +''100.101.191.0/24'' 
 + 
 +''fd21:b4dc:4bff:ffff::/64''
  
 ===== Deployment ===== ===== Deployment =====
Zeile 9: Zeile 19:
 per ansible role ''backbone_babel'' im [[https://gitlab.freifunk-stuttgart.de/infrastruktur/ansible|infrastruktur-Ansible]]. per ansible role ''backbone_babel'' im [[https://gitlab.freifunk-stuttgart.de/infrastruktur/ansible|infrastruktur-Ansible]].
  
-===== Wireguard =====+===== Verbindungen ===== 
 +Verbindungen zwischen zwei Hosts ueber die Routingprotokoll gesprochen wird koennen wie folgt aufgebaut werden 
 + 
 +  * wireguard 
 +  * direktes lokales Linux-Interface via ''bb_babel_peer_interfaces'' in host_vars
  
 Wireguard hat ein internes Routing. Wireguard hat ein internes Routing.
  
-wir moechten ein eigenes routingprotokoll verwende, daher hat ein Wireguard-tunnel immer genau zwei Endpunkte.+wir moechten ein eigenes routingprotokoll verwenden, daher hat ein Wireguard-tunnel immer genau zwei Endpunkte. 
 + 
 +===== Babel ===== 
 + 
 +als Routingprotokoll wird Babel verwendet 
 + 
 +als Daemon kommt babeld zum einsatz https://www.irif.fr/~jch/software/babel/babeld.html 
 + 
 +bird hat auch eine sehr gute babel-Implementierung, aber die in Debian bookworm enthaltene Version unterstuetzt bspw die RTT-basierten Metriken nicht, daher babeld 
 + 
 +===== Konzepte ===== 
 + 
 +  * ''line'': eine IPv4/v6-Adresse sowie eine zusammenhaengende Range Ports auf denen Wireguard-Punkt-zu-Punkt Tunnel aufgebaut werden koennen 
 +    * jede line gehoert zu genau einem Host 
 +    * beschreibt eine Verbindungsmoeglichkeit, beispielsweise via IPv6 und via IPv4  
 +  * ''connections'' verbinden zwei ''lines'' miteinander 
 +    * connection sorgt dafuer dass ein Wireguard-Tunnel zwischen zwei '''lines''' aufgebaut wird 
 +    * wird eine connection zwischen zwei lines angelegt, werden fuer beide Lines Port-Nummern aus der Range der jeweiligen Line ausgewaehlt  
 +    * jeder Connection entspricht genau ein Wireguard-Tunnel und damit ein Linux-Interface. Das interface wird nach der gegenueberliegenden line benannt
  
  
Zeile 19: Zeile 51:
  
 [[https://gitlab.freifunk-stuttgart.de/infrastruktur/ansible/-/blob/master/group_vars/backbone_babel.yml?ref_type=heads|group_vars]] enthalten Definitionen, die fuer alle hosts interessant sind, beispielsweise die IPs und Ports der Wireguard-endpunkte [[https://gitlab.freifunk-stuttgart.de/infrastruktur/ansible/-/blob/master/group_vars/backbone_babel.yml?ref_type=heads|group_vars]] enthalten Definitionen, die fuer alle hosts interessant sind, beispielsweise die IPs und Ports der Wireguard-endpunkte
 +
 +===== aktuelle Struktur =====
 +
 +zeigt die Wireguard Links
 +
 +https://pad.n7r.de/diagram/#/2/diagram/view/WecoqhYVOlgphdqXdbKb5-xSaKQYcw--iK8cO74xkF0/
 +
  
  • technik/babel-backbone.1728588145.txt.gz
  • Zuletzt geändert: vor 5 Monaten
  • von nrb