--- format: markdown categories: Netz-Infrastruktur, Backbone, Supernodes title: Interfaces ... # Interfaces ## MAC-Adressen Die Mac-Adressen für das Mesh-Interface `bat0` steht im Spreadsheet unter "Mesh MAC". Diese wird dem Dummy-Interface `meshdummy` zugewiesen, batman-adv übernimmt die Adresse. Server MAC --------- ------ map 02:ce:ef:ca:fe:1a node01-1 02:ce:ef:ca:fe:2a node01-2 02:ce:ef:ca:fe:2b node02-1 02:ce:ef:ca:fe:3a node02-2 02:ce:ef:ca:fe:3b ## eth0 (IP: Public) Die Adressen stehen im Spreadsheet und kommen aus dem IP-Bereich des Hosters, bei dem die Supernode steht. Dies ist das einzige Interface ohne Tunnel und ist in der `main`-Routingtabelle die Default Route. Das Interface wird als `pointopoint` betrieben, so dass jede Kommunikation zum Default Gateway geschickt wird. ToDo: Forwarding für eth0 ausschalten? Hier darf ja kein geroutetes Paket raus gehen. ## tap00 und tap01 Diese Interfaces werden von den [fastd](fastd)-Instanzen zur Verfügung gestellt (Layer-2-VPN zu den Clients) und werden beim Start von fastd dem Batman hinzugefügt. ## bb-node* und bb-map Gretap-Tunnel zu den anderen Supernodes und dem Map-Server. Diese Interfaces werden beim Aktivierung dem Batman hinzugefügt. ## bat0 (IP: Mesh) Dieses Interface wird durch batman-adv bereitgestellt. Die Tunnel zu den Clients (`tap00` und `tap01`), zu den anderen Servern (`bb-node*`) sind an Batman angeschlossen. Durch das Dummy-Interface `meshdummy` wird sichergestellt, dass batman-adv unabhängig von den fastd-tunneln startet sowie die korrekte MAC-Adresse übernimmt. Unser Mesh hat für IPv4 das /16 `10.233/16` und für IPv6 das /64 `2a03:2260:50:5::/64`. Die Mesh-IPs der Supernodes und Client-Ranges (IPv4) sind nach folgendem Schema aufgebaut: Supernode IPv4 IPv6 DHCPv4-Range ---------- ------------------- -------------------------- -------------------------- node01-1 10.233.**8**.1/16 2a03:2260:50:5::**8**/64 10.233.9.1-10.233.15.254 node01-2 10.233.**16**.1/16 2a03:2260:50:5::**16**/64 10.233.17.1-10.233.23.254 node02-1 10.233.**24**.1/16 2a03:2260:50:5::**24**/64 10.233.25.1-10.233.31.254 node02-2 10.233.**32**.1/16 2a03:2260:50:5::**32**/64 10.233.33.1-10.233.39.254 Eingehender Traffic vom Mesh wird anhand des Quell-Subnetzes per Routing Policy auf die Routing Table `42` gelenkt, die die über BGP gelernten Routen des FFRL-Netzes enthält: ``` ip rule add from 10.233.0.0/16 pref 10 table 42 ip -6 rule add from 2a03:2260:50:5::/64 pref 10 table 42 ``` Siehe [what the hell is bat0 for](http://www.open-mesh.org/projects/batman-adv/wiki/Quick-start-guide). ## ffrg-* (IP: Peering) Gre-Tunnel zu den Backbone-Routern. In jeder Colocation hat nur einer der zwei dort stehenden Supernodes ein Peering nach außen. Router Standort IPv4 -------- -------- ------------- ffrg2-5 OVH 5.39.121.115 ffrg11 MyLoc 85.14.244.128 Standort Supernode Peering `ffrg-ffrg11` v4 v6 `ffrg-ffrg2-5` v4 v6 ----------- ---------- ------------------ ---------------- --------------------- ----------------- --------------------- OVH node01-1 **ja** 10.0.6.6/30 2a03:2260:50:5b::2/64 10.0.6.2/30 2a03:2260:50:5a::2/64 OVH node01-2 nein - - - - Webtropia node02-1 **ja** 10.0.6.14/30 2a03:2260:50:5d::2/64 10.0.6.10/30 2a03:2260:50:5c::2/64 Webtropia node02-2 nein - - - - Die IP-Adressen für die Peering-Interfaces sind im Spreadsheet unter "GRE" eingetragen. Die Supernodes untereinander tauschen ihre Routen per BGP aus, so daß die anderen beiden Supernodes über die bestehenden Supernodes ins Backbone geroutet werden. # Routing BIRD schreibt in die Routing-Tabelle `42`. Über die mit `ip rule` gesetzte Routing-Policy für das Mesh-Subnetz wird sichergestellt, dass aus dem Mesh eingehende Pakete über die per BGP bezogenen Routen geroutet werden und nicht über die `main`-Routingtabelle, die `eth0` als Gateway nutzen würde. ## AS-Nummer Jede Community hat im IBGP eine eigene ASN die im Spreadsheet dokumentiert ist, wir sind `AS65403`.