hamnet:examplebackbonenet

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Nächste Überarbeitung		 Vorherige Überarbeitung
Letzte ÜberarbeitungBeide Seiten, nächste Überarbeitung
dokumentation:examplebackbonenet [03.10.2009 10:52 Uhr] – angelegt dl9sauhamnet:examplebackbonenet [15.08.2015 16:07 Uhr] – ↷ Seite von dokumentation:examplebackbonenet nach hamnet:examplebackbonenet verschoben 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>