Administration #501
open
Added by tux over 4 years ago.
Updated about 4 years ago.
Description
Ich habe mal kurz über eine Struktur der Adressen im Präfix fda9:26e:5805:bab1/64 nachgedacht. Was haltet ihr davon?
Die Adressen sind etwas komplexer, dafür ist es leichter, Adressen ohne Konflikte zu generieren.
Nutzung von "modulo-F"-Namenskodierung:
i.e. g->a, h->b, ...
o/t können durch 0/7 ersetzt werden
web -> aeb
gw01 -> af01 ...
gekennzeichnet als modF
Präfix: fda9:26e:5805:bab1/64
fda9:26e:5805:bab1:53::1/64 DNS (bereits fest vergeben)
-> Verweis auf fda9:26e:5805:bab1:aaaa:53::1/64
Nächstes Hextet: "Host"-Kennung
aaaa unabhängige Adressen (z.B. DNS)
ausnahme: 53::1 ist schon vergeben
53::1 -> Master-DNS
53::af01 -> Slave-DNS auf gw01
modF für Management-Hosts (web, gw, ....)
nächstes Hextet: Funktion (modF)
0 generische Host-Adressen
::1/80 der Host selbst, z.B. eth-Device
d0c0/96 docker-Netz 0 (doc0)
d0c0/96 docker-Netz 1 (doc1)
7cb Tunnel (tun)
nächstes Hextet: Typ
47=gre
letztes Hextet: Ziel-Host
z.B. Gre-Tunnel zwischen web zu gw01
web gre tunnel fda9:26e:5805:bab1:aeb:7cb:47:af01
gw1 gre tunnel fda9:26e:5805:bab1:af01:7cb:47:aeb
Beispiele:
web.md.freifunk.net fda9:26e:5805:bab1:aeb::1/80
web Docker0-Netz fda9:26e:5805:bab1:aeb:d0c0/96
web Docker1-Netz fda9:26e:5805:bab1:aeb:d0c1/96
gw01.md.freifunk.net fda9:26e:5805:bab1:af01::1/80
GRE gw01->web fda9:26e:5805:bab1:af01:7cb:47:aeb/80
GRE gw01->gw02 fda9:26e:5805:bab1:af01:7cb:47:af02/80
gw02.md.freifunk.net fda9:26e:5805:bab1:af02::1/80
GRE gw02->gw01 fda9:26e:5805:bab1:af02:7cb:47:af01/80
Anycast-DNS fda9:26e:5805:bab1:aaaa:53::1/64
Slave-DNS auf gw02 fda9:26e:5805:bab1:aaaa:53::af02/64
Alternative: fda9:26e:5805:bab1:af02::53/80
Hinweis: Die Erzeugung von /96-Adressen für Docker-Netze kommt aus verschiedenen Howtos im Netz.
Nachtrag: Mir fällt gerade auf, dass die GRE-Tunnel ein eigenes Netz haben sollten. D.h. das Präfix ändert sich. Die Grundlegende Struktur der Adressen würde ich aber behalten, weil man daran ablesen kann, von wo nach wo der Tunnel geht.
Update: Ist das so? Wurde offenbar nur beim Tunnel zum web so gemacht.
- Description updated (diff)
Für die Vergabe der Slave-DNS-Adressen gibt es mehrere Varianten.
Die DNS-Resolver müssen sich untereinander adressieren können.
Für die Clients gilt die anycast-Adresse.
- Description updated (diff)
- Description updated (diff)
- Description updated (diff)
- Description updated (diff)
tux wrote:
Für die Vergabe der Slave-DNS-Adressen gibt es mehrere Varianten.
Die DNS-Resolver müssen sich untereinander adressieren können.
Für die Clients gilt die anycast-Adresse.
Die Clients nutzen den node an dem sie angeschlossen sind als resolver. Dieser nutzt die anycast-adressen unter denen die im backend laufenden DNS-server erreichbar sind.
tux wrote:
Nachtrag: Mir fällt gerade auf, dass die GRE-Tunnel ein eigenes Netz haben sollten. D.h. das Präfix ändert sich. Die Grundlegende Struktur der Adressen würde ich aber behalten, weil man daran ablesen kann, von wo nach wo der Tunnel geht.
Update: Ist das so? Wurde offenbar nur beim Tunnel zum web so gemacht.
ich würde vorschlagen ll-adressen aufd en gre interfaces zu wählen und nichts sonst. Das reduziert die Komplexität etwas.
klausdieter wrote:
tux wrote:
Nachtrag: Mir fällt gerade auf, dass die GRE-Tunnel ein eigenes Netz haben sollten. D.h. das Präfix ändert sich. Die Grundlegende Struktur der Adressen würde ich aber behalten, weil man daran ablesen kann, von wo nach wo der Tunnel geht.
Update: Ist das so? Wurde offenbar nur beim Tunnel zum web so gemacht.
ich würde vorschlagen ll-adressen aufd en gre interfaces zu wählen und nichts sonst. Das reduziert die Komplexität etwas.
Gern auch das. Dann gilt der Strukturvorschlag für link-local-Adressen (letztendlich ändert sich nur das Präfix).
klausdieter wrote:
tux wrote:
Für die Vergabe der Slave-DNS-Adressen gibt es mehrere Varianten.
Die DNS-Resolver müssen sich untereinander adressieren können.
Für die Clients gilt die anycast-Adresse.
Die Clients nutzen den node an dem sie angeschlossen sind als resolver. Dieser nutzt die anycast-adressen unter denen die im backend laufenden DNS-server erreichbar sind.
Gut, dann gilt die anycast-Adresse für den Node :)
Wichtig ist, dass die einzelnen DNS auch einzeln adressierbar sind, selbst wenn die Strutkur für die Knoten transparent ist.
Netzstruktur:
* Infrastrukturnetz als
fda9:26e:5805:
* bab0::/64
* bab1::/64 - Nodes
* bab2::/64 - node-client-Bereich
* ba01::/64 -> gw01
* ba01:d0c0::/80 - dockernetz auf gw1
* ba02::/64 -> gw02
* ba02:d0c0::/80 - dockernetz auf gw2
* baaa/64 - globale Services
Also available in: Atom
PDF