Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Letzte Überarbeitung Beide Seiten der Revision
hamnet:examplebackbonenet [05.10.2009 14:07 Uhr]
dd9qp
hamnet:examplebackbonenet [21.10.2009 08:30 Uhr]
dd9qp
Zeile 1: Zeile 1:
 +Aus einer E-Mail:
  
 +<​code>​
 +[..] wenn der BackBone eine Bridge ist kann man das /24 im Stück verwenden.
 +
 +Ich meine jedoch, dass man im Backbone an mehr als nur einer Stelle
 +Übergabepunkte in ein anderes AS hat und dass man manchmal auch
 +zwischen einzelnen Standorten routen statt bridgen will (vielleicht auch
 +nur, weil es technisch bedingt nicht anders geht).
 +
 +Das würde ich zumindest beim Netzplan für das BackBone Netz mit
 +berücksichtigen.
 +
 +Ich würde das Netz unterteilen. Habe mal ein Blatt Papier in die
 +Hand genommen und ein bisschen umhergeschoben / bits geshiftet:
 +
 +1. Ein /30 hat sich aus eigener Erfahrung stets für zu klein
 +   ​erwiesen,​ weil man da nicht noch kurz was reinhängen kann um einen
 +   ​Ping-Test zu machen.
 +2. Im Backbone-Netz haben wir sicher Teile, die gebridged sind und wir haben
 +   an Übergabepunkten nach innen und nach aussen Transfernetze hängen (da die
 +   ​Nachbarn aussen auch Transfernetze haben, reduziert sich der Bedarf
 +   auf etwa die Hälfte).
 +3  Aktive Komponenten im AS mit iBGP werden max. 10 sein (da sie vermascht
 +   sein müssen, funktioniert das bei mehr als 10 nicht mehr zuverlässig).
 +4. Da keine Services im Backbone-Bereich betrieben werden sollen, stehen
 +   hier aktive Routing-Komponenten,​ APs, Switche. Innerhalb einer Bridge
 +   ​werden wir sicher nicht mehr als 62 dieser Komponenten antreffen;
 +   ​vermutlich auch weniger als 30.
 +
 +Mit diesen Überlegungen im Hintergrund komme ich auf zwei
 +mögliche Empfehlungen,​ das BB-Netz zu unterteilen. [Achtung: wir können
 +nur Tipps geben und für und wider abwägen. Viele Wege führen nach Rom!].
 +
 +A)          Aufteilung eines /24er Backbone-Netzes
 +0---------------+---------------+-----------------------------256
 + ​bridge-Bereiche,​ ggf. routing ​ |           ​transfer
 +----------------+---------------+--------------------------------
 +    /26         ​| ​ /27  |  /27  | 8 Transfernetze,​ /28.         |
 +  64 Adressen ​  |32 Adr.|32 Adr.| zu je 16 Adressen, 14 Nutzbar |
 +  oder spliten ​ 64      92     ​128 ​  ​liessen sich bei Bedarf ​  256
 +  und verteilen |       |auch in|      auf /29 (je 8 Adressen)
 +  auf mehrere ​  ​| ​      ​|/​28|/​28| ​  ​verkleinern (-> 16 T.Netze)
 +  Standorte ​    ​| ​      ​|splitbar ​  /29 ist m.E. ausreichend
 +
 +Das ist m.E. eine gute Ausgangsposition,​ die sich den verändernden
 +Gegebenheiten durch weiteres Kleinteilen gut anpassen lassen kann.
 +
 +B)
 +
 +Natürlich kann man den Gaul auch noch schöner aufziehen, damit
 +Transfernetze und Bridgebereich beieinanderliegen und ich es z.B.
 +auf 8 gleich grosse Netze aufteilen will.
 +
 +8 Standorte -> 32 Adressen verfuegbar. ​
 +
 +1x /28 [= 16 Adressen, 14 nutzbar] bridge area am Standort
 +dahinter
 +1x /29 [= 8 Adressen, 6 nutzbar] Transfernetz 1
 +dahinter
 +1x /29 [= 8 Adressen, 6 nutzbar] Transfernetz 2
 +
 +oder
 +
 +1x /29 [= 8 Adressen, 6 nutzbar] bridge area am Standort
 +dahinter
 +1x /29 [= 8 Adressen, 6 nutzbar] Transfernetz 1
 +dahinter
 +1x /29 [= 8 Adressen, 6 nutzbar] Transfernetz 2
 +dahinter
 +1x /29 [= 8 Adressen, 6 nutzbar] Transfernetz 3
 +dahinter
 +1x /29 [= 8 Adressen, 6 nutzbar] Transfernetz 4
 +
 +
 +Nachteil von B)
 +
 +Das Schema wird in dem Moment unübersichtlich,​ wenn die Transfernetze an
 +einem Standort nicht mehr genügen und man das Schema durchbricht,​ um sich
 +die fehlenden dann aus einem anderen Netz auszuleihen.... ;)
 +
 +
 +Vorteil von B)
 +
 +Wenn man mehrere bridging-Bereiche an mehreren Standorten hat, die je über
 +Router erreichbar sind, dann braucht man nicht jedes Transfernetz
 +zusätzlich als Route announcen, da Transfernetz und Bridgingnetz
 +sich als eine Netzroute zusammenfassen.
 +Wenn man, wie im Beispiel A, Routen für jedes Transfernetz (also
 +die Übergabepunkte) setzen muss und es vergisst sie zu announcen,
 +dann fällt das vielleicht erst nicht weiter auf - doch wenn man z.B.
 +die Hosts auf dem Weg, den ein traceroute aufgezeichnet hat, pingen möchte,
 +und sie nicht antworten (weil man mangels Route nicht hin kommt), wird das
 +wohl eine der möglichen Fehlerquellen sein.
 +</​code>​