[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