[wlanfhain] Warum IPs geographisch verteilen (zu Konkret: IP-Adressvergabe an PLZ orientiert)
Jens Nachtigall
nachtigall
Fr Okt 15 18:50:58 CEST 2004
> | IMHO _müssen_ wir die IPs geographisch vergeben, wenn wir uns für
> | die Zukunft die Möglichkeit offen halten wollen, evt. BGP (also ein
> | routing zw. den Autonomen System bzw. kiezen) zu benutzen. Ohne
> | vernümpftige, _geographische_ Vergabe der IPs geht kein
> | vernümpftiges BGP.
>
> Das ist genau der punkt, den ich nicht verstehe. Um bgp zu sprechen
> brauche ich doch blos Autonome Systeme und, die irgendwie miteinander
> verbunden sind oder an deren grenzen ein Router steht.
> Wo diese Systeme sind ist doch ziemlich bgp doch ziemlich egal.
Um etwas besser erklären zu können, warum wir die IPs geographisch
verteilen sollten, habe ich mal die Szenarien grafisch aufbereitet. Das
ist eine grobe Vereinfachung:
Szenario heute:
Wir haben eine olsr-Wolke mit einer ESSID olsr.freifunk.net. Die IPs
sind geographisch verteilt, was aber egal ist, da sowieso alles auf
einer Ebene (»flat« bzw. hierachielos) abläuft:
http://www.informatik.hu-berlin.de/~nachtiga/heute.png
Das ist das Optimum, weil weiterhin Roaming möglich ist.
Szenario Zukunft:
Sollten wir evtl. sehr viele Rechner mit olsr im Netz haben (1000, 5000,
15000, ...), dann vermute ich, dass das nicht mehr sonderlich gut
funktioniert (OLSR-»Broadcasts« fluten über ganze Netz, sehr lange
Routingtabellen, Berechnung der Routingtabellen). Dann mag es Sinn
machen, die eine OLSR-Wolke zu unterteilen (in etwa entlang der roten
Linien). Border Gateways (die braunen Punkte) verbinden diese Autonomen
Systeme (fhain-olrsr-, xberg-olsr-, mitte-olsr- und
pberg-olsr.freifunk.net). Auf diesen Border Gateways läuft BGP, das
mittels Metriken die Routen zu den anderen Border Gateways (und
zugehörigen Autonomen Systemen) bestimmt. U.a. kann so ein
BorderGateway den anderen BorderGateways mitteilen, welcher IP-Bereich
über ihn erreichbar ist (ein einziges 104.x/16 statt tausender
104.x.x.x/32). Die Border Gateways könnten das HDL, RapunCell o.ä.
sein. Mittels HNA4-Messages teilt das Border Gateway seinem eigenen
Autonomen System mit welche anderen externen Netze es sieht (3 bis 4
IPs a la 104.x./16 statt tausender 104.x.x.x/32).
http://www.informatik.hu-berlin.de/~nachtiga/evtl-zukunft.png
Beispiel:
Extern-BGP: KreuzbergBorderGateway (KreuzbBG) und MitteBorderGateway
(MitteBG) sind über einen Link, auf dem BGP läuft verbunden.
KreuzbergBorderGateway teilt auf diesem Link MitteBG mit, dass sein
Autonomes System 104.192.0.0/10 ist (das ist genau eine »IP-Adresse«,
bei nicht geographischer Vergabe wären es tausende). MitteBG teilt
wiederum mit, dass er 104.0.0.0/9 (PBerg+mitte), 104.128.0.0/10 (fhain)
sieht.
Intern-OLSR: Intern kann KreuzbgBG nun mittels HNA4-Nachricht seiner
olsr-wolke (sein auton. system) mitteile, dass über ihn die externen
Netze 104.0.0.0/9 (PBerg+mitte), 104.128.0.0/10 (fhain) errechbar sind.
Das ist eine sehr kleine HNA4-nachrict. Sind die IPs nicht geogr.
vergeben, dann wäre die HNA4-nachricht riesig, da sie alle /32 Host-IPs
beinhalten müsste. Ohne geogr. IP-vergabe gäbe es also keine/kaum
verringerung an OLSR-routing-nachrichten, und auch keine kürzeren
Routingtabellen -- die Unterteilung in autonome systeme würde also
keinerlei Einsparungen bringen.
Fazit: Wir verschenken uns nichts, wenn wir heute IPs geographisch
vergeben. Dadurch halten wir uns für die unbekannte Zukunft (bessere
Hardware?, bessere Wlan-standards?) weitere Möglichkeiten offen.
Ich hoffe, dass war ok erklärt und dass die Idee grob herüberkam. Wenn
nicht, dann hakt nochmal nach.
jens
Mehr Informationen über die Mailingliste Berlin