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
dokumentation:examplebackbonenet [21.10.2009 08:30 Uhr] – dd9qphamnet:examplebackbonenet [01.12.2020 21:34 Uhr] (aktuell) – Remove page via multiORPHANS 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>