Dies ist eine alte Version des Dokuments!

Aus einer E-Mail:

[..] 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.