hamnet:examplebackbonenet

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung
Nächste Überarbeitung		 Vorherige Überarbeitung
Letzte ÜberarbeitungBeide Seiten, nächste Überarbeitung
dokumentation:examplebackbonenet [05.10.2009 14:07 Uhr] – dd9qphamnet: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>