[wlanfhain] IPv4-Infrastruktur / Adressallokation
Andreas Kotes
count-wlanfhain
Di Jul 6 17:17:40 CEST 2004
Hallo!
leider etwas verspaetet, aber hoffentlich noch rechtzeitig zum naechsten
Termin, hier mein Senf zur bisherigen Planung, und ein (IMHO) besserer
Vorschlag.
ich gehe davon aus das man mal n blick auf
http://encyclopedia.thefreedictionary.com/Routing%20Metric geworfen hat, da sind
routing an sich und einige der verwendeten begriffe/abkuerzungen etwas
ausfuehrlicher dargelegt.
Ich hab eure bisherige Herangehensweise wie folgt verstanden:
- statisches routing
- 10.x.x.x/8 als basisnetz
- transfernetz 10.y.y.y/30 auf den einzelnen strecken zwischen
nodes/corepoints
- corepoints kriegen jeder ein 10.z.z.z/16
- nodes kriegen jede ein 10.u.u.u/24
... soweit, so gut. wuerde funktionieren, und zwar eine ganze weile.
danach wirds dann uebel, und zwar aus folgenden gruenden:
- statisches routing
schoen und gut, aber je mehr kleine allokationen man hat, desto mehr
einzelne routen braucht man, desto laenger werden die routingtabellen,
desto laenger werden die paketlaufzeiten durch diese
mit dynamischem routing wird das ganze auch nur sehr bedingt besser,
allerdings sollte man (so oder so) die routen optimieren (s.u.)
dynamisches routing (RIP, OSPF, IS-IS - ich empfehle fuer euch IS-IS oder
OSPF, RIP ist von OSPF ueberholt) will man allerdings (auf dauer)
sowieso haben
- 10.x.x.x/8 als basisnetz
wuerde funktionieren, allerdings gibt es bereits extrem viele
existierende installation mit diesem netz, was zum einen fuer aerger
sorgt, zum anderen die massetraegheit der admins dieser netze
steigert. ergebnis: netze, die dieses basisnetz bereits benutzen,
werden nicht so bald angebunden, weil der aufwand zu gross ist.
- transfernetz 10.y.y.y/30 auf den einzelnen strecken zwischen
nodes/corepoints
sorgt fuer extreme fragmentierung des netzes, ausserdem graebt man
sich dadurch hintenrum den adressraum ab, besonders wenn man
ploetzlich mehr als einen uplink pro node hat - oder die corepoints
enger miteinander vermascht werden, indem mehr links zwischen ihnen
aufgebaut werden
- corepoints kriegen jeder ein 10.z.z.z/16
die allokation ist viel zu gross. kein einziger corepoint wird von
anfang an 255/256 nodes dran haben, und wenn dann mal einer soviele
hat und mehr braucht, gehn die probleme los - dann muss man den
adressraum von sonstwo herrouten, was die routingtabellen laenger und
das routing komplexer -> die paketlaufzeiten laenger macht. mag ja
'egal' sein, summiert sich aber auf dauer auf
- nodes kriegen jede ein 10.u.u.u/24
dito. die meisten nodes werden nicht (anfangs) nicht mehr als 14 hosts
haben, wuerden also mit einem /28 voellig auskommen
aehnlich lief die verteilung im internet seit 10-20 jahren schon, und
erst in den letzten 5-8 jahren ist aufgefallen, das man derart bald an
selbstgeschaffene grenzen stoesst, und diese auch nicht wieder
einreissen kann. folglich braucht es einen vorschlag der:
- skalierbar ist
es muss fuer berlin reichen, und sollte auch fuer groesser reichen
koennen
- oekonomisch ist
.. sprich: adressverschwendung vermeidet
- geringen administrationsaufwand vermeidet
.. sprich: bei aenderungen muss moeglichst wenig angefasst werden
- zukunftssicher ist
.. sprich: alle obigen punkte plus beruecksichtigung (und nach
moeglichkeit nutzung) kommender technologien
mein konkreter vorschlag lautet also:
- routing dynamisch via IS-IS oder OSPF
hat den vorteil das bei neu dazukommenden strecken/links nach draussen diese
automatisch beruecksichtigt werden und der traffic sinnvoll verteilt wird
wenn z.B. aus:
n0-n1-n2-\
>-n3
n4-n5-n6-/
n0-n1-n2-\
| >-n3
n4-n5-n6-/
wird, wird der traffic zwischen n1<->n5 _automatisch_ nicht mehr via
n1<->n2<->n3<->n6<->n5 sondern via n1<->n0<->n4<->n5 geroutet.
- z.B. 104.x.x.x/8 als basisnetz
10.x.x.x/8 ist ein privates netz, 104.x.x.x/8 kommt aus dem netzraum
96.x.x.x/3, und ist ein von der IANA reserviertes netz (siehe auch
http://www.iana.org/assignments/ipv4-address-space). es wird
vermutlich von irgendwem sonstwo benutzt, pakete die von/an diese
adressen gehen werden allerdings faktisch von (quasi) allen routern im
internet sofort verworfen, genau wie solche aus 10.x.x.x, 192.168.x.x
und 172.16.x.x .. macht es zu einem guten kandidaten fuer die eigene
nutzung, wenn auch nicht 100% koscher.
absolut cool waere natuerlich PI-(Provider Independant)-Adresspace
beim RIPE zu beantragen, allerdings waere das sowohl buerokratisch
aufwendig, als auch vielleicht teuer und schwer in der angestrebten
groesse durchzukriegen. vorteil hierbei waere allerdings das man
spaeter einfach(er) ein AS (Autonomes System) werden kann, so man dies
will.
warum eine adresse mitten aus dem space? weil man, wenn der space zu
eng wird, einfach weiter aufmacht. sprich, man macht aus dem
104.x.x.x/8 ein 104.x.x.x/7 und hat doppel soviele adresse. oder ein
102.x.x.x/6 und hat viermal soviele - und das alles ohne die
vorhandenen systeme welche 104.x.x.x/8 (oder adressen aus diesem raum)
benutzen anfassen zu muessen. sofern diese sinnvolle defaultrouten zu
ihren upstreams haben sollte alles schoen werden.
... die erklaerung unten wird vielleicht noch etwas
aufschlussreicher...
- transfernetze NICHT aus dem eigenen adressraum nehmen
sprich: KEINE adressen aus 96.x.x.x/3. zum einen ist es unnoetig, zum
anderen fragmentiert man sich so den adressraum nicht.
zur erklaerung was transfernetze sind und wozu man sie braucht, an
einem beliebigen beispiel mit beliebigen netzen (ich hab der
einfachheit halber /24 genommen, die kennt jeder und in denen kann man
gut rechnen):
node1, eth0: 1.2.3.4/24
node2, eth0: 1.2.3.5/24
wenn man diese beiden rechner zusammenhaengen wuerde, macht man mit
nem /30 folgendes:
node1, eth0: 1.2.3.4/24
node1, eth1: 6.7.8.9/30
node2, eth1: 6.7.8.10/30
node2, eth0: 1.2.3.5/24
route auf node1 nach 1.2.3.5/24 geht auf 6.7.8.10,
route auf node2 nach 1.2.3.4/24 geht auf 6.7.8.9
.. soweit, so gut. das netz 6.7.8.8/30 wird _ausschliesslich_
gebraucht um die pakete vom einen netz zum anderen geroutet zu
kriegen, aus keinem anderen grund. sprich: es muesste nichtmal nach
aussen sichtbar sein, und man koennte es ueber
bridging/ttl-spielereien auch im traceroute/mtr verstecken, so man das
will. das netz 6.7.8.8/30 muss weder irgendwo anders bekannt noch
irgendwo anders als lokal geroutet sein, es ist also in
IPv6-terminologie ein 'link local' netzwerk.
nur zur loesung fuer unsere problematik: einfach fuer derartige
transfernetze IPs aus einem der raeume 10.x.x.x, 192.168.x.x, oder
172.16.x.x nehmen, dieses nicht nach aussen announcen, und gluecklich
sein. die paketen kommen durch, der adressraum wird nicht
verhackstueckt, es ist (lokal) sauber zu administrieren, global wirds
nur minimal unuebersichtlicher (man muss sich halt extra IP-adressen
fuer die endpunkte der einzelnen strecken notieren).
es geht sogar noch anders wenn man IPv6 im netz (mit)benutzt, da kann
man dann einfach hingehn und ueber die (sowieso existierende)
link-local adresse der interfaces gehen und hat die adressen sozusagen
schon vorbestimmt - allerdings kommt dann die kapselung IPv4->IPv6 und
die entkapselung IPv6->IPv4 dazu, was wieder fuer overhead/latency
sorgt. ersteres is also in den meisten faellen vorzuziehen, es sei
denn man leitet ueber eine groessere strecke via nativem IPv6 weiter.
- corepoints kriegen jeder ein 104.x.x.x/22, mit abstand dazwischen
beispiel:
cp1: 104.0. 0.x/22 - 104.0. 0.x - 1024 adressen
cp2: 104.0.32.x/22 - 104.0.34.x - 1024 adressen
cp3: 104.0.64.x/22 - 104.0.67.x - 1024 adressen
cpM: 104.0.96.x/22 - 104.0.99.x - 1024 adressen
... wenn jetzt der adressraum von z.B. cp2 und cp3 nicht mehr
ausreicht, macht man weiter auf:
cp1: 104.0. 0.x/22 - 104.0. 0.x - 1024 adressen
cp2: 104.0.32.x/21 - 104.0.39.x - 2048 adressen
cp3: 104.0.64.x/21 - 104.0.71.x - 2048 adressen
cpM: 104.0.96.x/22 - 104.0.99.x - 1024 adressen
... reicht immernochnicht? ok, noch weiter aufmachen:
cp1: 104.0. 0.x/22 - 104.0. 0.x - 1024 adressen
cp2: 104.0.32.x/20 - 104.0.47.x - 4096 adressen
cp3: 104.0.64.x/20 - 104.0.79.x - 4096 adressen
cpM: 104.0.96.x/22 - 104.0.99.x - 1024 adressen
... cp2 braucht noch mehr?? ok:
cp1: 104.0. 0.x/22 - 104.0. 0.x - 1024 adressen
cp2: 104.0.32.x/19 - 104.0.63.x - 8192 adressen
cp3: 104.0.64.x/20 - 104.0.79.x - 4096 adressen
cpM: 104.0.96.x/22 - 104.0.99.x - 1024 adressen
.. fuer cp2 ist jetzt das ende der fahnenstange erreicht, allerdings
konnte es dreimal problemlos verdoppelt werden! soweit, so gut. nehmen
wir mal an, es kommt noch ein cpN dazu, und wir sind uns sicher das
cp3 und cpM in absehbarer zeit nicht wachen werden:
cp1: 104.0. 0.x/22 - 104.0. 0.x - 1024 adressen
cp2: 104.0.32.x/19 - 104.0.63.x - 8192 adressen
cp3: 104.0.64.x/20 - 104.0.79.x - 4096 adressen
cpN: 104.0.80.x/22 - 104.0.83.x - 1024 adressen oder
cpN: 104.0.84.x/22 - 104.0.87.x - 1024 adressen oder
cpN: 104.0.88.x/22 - 104.0.91.x - 1024 adressen oder
cpN: 104.0.92.x/22 - 104.0.95.x - 1024 adressen oder
cpN: 104.0.80.x/22 - 104.0.87.x - 2048 adressen oder
cpN: 104.0.88.x/22 - 104.0.95.x - 2048 adressen oder
cpN: 104.0.80.x/22 - 104.0.95.x - 4096 adressen
cpM: 104.0.96.x/22 - 104.0.99.x - 1024 adressen
... es ist wie bei IKEA - entdecke die moeglichkeiten. wenn die
allokationen statisch erfolgt waeren muessten in allein beispielen in
den benachbarten netzen aenderungen gemacht werden - oder der
adressraum waer ploetzlich zu eng.
hoffe, das war verstaendlich.
- nodes kriegen jede ein 104.x.x.x/28
... analog zur allokation bei den corepoints.
- routing erfolgt immer mit moeglichst grossen netzmasken
sprich: man macht eine grosszuegige aufteilung nach
logischen/geographischen gesichtspunkten, z.B. ost-berlin 104.x.x.0/9
und west-berlin 104.x.x.128/9, je naeher man dem entsprechenden
corepoint kommt, desto konkreter wird man. so vermeidet man
konstellationen wie:
n2 -\ /- n4
| >- n0 - n1 <
n3 -/ \- n5
routen n0 | routen n1 | routen n2 | routen n3 | routen n4 | routen n5
n0 lokal | n0 direkt | n0 direkt | n0 direkt | n0 via n1 | n0 via n1
n1 direkt | n1 lokal | n1 via n0 | n1 via n0 | n1 direkt | n1 direkt
n2 direkt | n2 via n0 | n2 lokal | n2 direkt | n2 via n1 | n2 via n1
n3 direkt | n3 via n0 | n3 direkt | n3 lokal | n3 via n1 | n3 via n1
n4 via n1 | n4 direkt | n4 via n0 | n4 via n0 | n4 lokal | n4 via n1
n5 via n1 | n5 direkt | n5 via n0 | n5 via n0 | n5 via n1 | n5 lokal
und hat stattdessen z.B.:
n1 -\ /- n9
| >- n0 - n8 <
n2 -/ \- n10
routen n0 | routen n1 | routen n2 | routen n8 | routen n9 | routen n10
n0 lokal | n0 direkt | n0 direkt | n0 direkt | <n8 -> n8 | <n8 -> n8
n1 direkt | n1 lokal | n1 direkt | <n8 -> n0 | n8 direkt | n8 direkt
n2 direkt | n2 direkt | n2 lokal | n8 lokal | n9 lokal | n9 -> n8
n8 direkt | n8 via n0 | n8 via n0 | n9 direkt | n10 -> n8 | n10 lokal
>n8 -> n8 | >n8 -> n0 | >n8 -> n0 | n10 direkt| |
.. eine zeile weniger, weniger komplexitaet -> schneller. ist bei einem
groesseren graphen mit mehr hosts noch drastischer.
soviel erstmal dazu, ich hoffe, das war auch fuer laien/semiprofis
verstaendlich, wenn nicht, bitte solange nachhaken, bis es klar(er) ist. ich
werde auch zusehen das ich am mittwoch ab 20h auf der base anwesend bin, so das
ich nach bedarf zu eurem treffen hinzugezogen werden kann (mein generelles
interesse an der thematik geht nicht so weit als das ich die ganze zeit
dabeisitzen wollen wuerde, meine expertise steht euch allerdings nahezu
uneingeschraenkt zur verfuegung, und wenn ich mitbekomme das etwas weniger
optimal als (mir bekannt) moeglich in angriff genommen werden soll, werd ich
auch einspruch erheben - man darf mich natuerlich auch ignorieren, darf mir dann
aber spaeter ein 'ich habs euch ja vorher gesagt' nicht uebel nehmen ;))
fuer die routen nach draussen wuerde ich uebrigends empfehlen das man auf jeden
fall metriken auf diesen setzt, d.h. man kann in der routingtabelle mit
eintragen wie hoch die 'kosten' fuer die nutzung einer strecke sind, damit immer
die 'billigste' genommen wird. da bei flatrates, dsl, etc keine kosten entstehen,
sollte man die bandbreite darueber nach draussen announcen, z.B:
- metric 32 - analog-modem
- metric 30 - isdn-anschluss
- metric 25 - adsl 768/128
- metric 24 - adsl 768/256
- metric 20 - adsl 1024/256
- metric 19 - adsl 1024/512
- metric 16 - adsl 1500/384
- metric 15 - adsl 1500/768
- metric 12 - sdsl 1024/1024
- metric 10 - adsl 2048/1024
- metric 8 - sdsl 2048/2048
- metric 7 - sdsl 4096/4096
- metric 6 - 10 mbit ethernet
- metric 5 - 22mbit wlan
- metric 4 - 54mbit wlan
- metric 3 - 100 mbit ethernet
- metric 2 - 1 gbit ethernet
- metric 1 - noch fetter
- metric 0 - so fett, dasses egal ist (sollte nicht vorkommen, ist allerdings
default wenn mans nicht angibt!!! VORSICHT!!)
.. nurn vorschlag den ich mir ad-hoc aus dem aermel geschuettelt habe, um die
idee zu illustrieren - ihr sollte euch da nochmals gedanken drueber machen :)
macht sich auf jeden fall schick wenn das routing automatisch so laeuft das der
beste durchsatz erzeugt wird ;) ... die routing daemons rechnen auf jeden fall
die moeglichen wege durch und nehmen dann den (in der summe) billigsten.
so, soviel erstmal dazu.
Viele Gruesse,
Count
--
Andreas Kotes - ICQ: 3741366 - The views expressed herein are (only) mine!
Follow the path of the unsafe, independent thinker. Expose your ideas to the
danger of controversy. Speak your mind and fear less the label of "crackpot"
than the stigma of conformity. (Thomas J. Watson) ### OpenPGP key 0x8F94C228
Mehr Informationen über die Mailingliste Berlin