Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
| Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung | |||
| hamnet:examplebackbonenet [15.08.2015 14:07 Uhr] – ↷ Seite von dokumentation:examplebackbonenet nach hamnet:examplebackbonenet verschoben dd9qp | hamnet:examplebackbonenet [01.12.2020 20:34 Uhr] (aktuell) – Remove page via multiORPHANS dd9qp | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| - | 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 | ||
| - | | ||
| - | | ||
| - | 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 | ||
| - | | ||
| - | 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, | ||
| - | | ||
| - | | ||
| - | |||
| - | Mit diesen Überlegungen im Hintergrund komme ich auf zwei | ||
| - | mögliche Empfehlungen, | ||
| - | nur Tipps geben und für und wider abwägen. Viele Wege führen nach Rom!]. | ||
| - | |||
| - | A) Aufteilung eines /24er Backbone-Netzes | ||
| - | 0---------------+---------------+-----------------------------256 | ||
| - | | ||
| - | ----------------+---------------+-------------------------------- | ||
| - | /26 | ||
| - | 64 Adressen | ||
| - | oder spliten | ||
| - | und verteilen | |auch in| auf /29 (je 8 Adressen) | ||
| - | auf mehrere | ||
| - | Standorte | ||
| - | |||
| - | Das ist m.E. eine gute Ausgangsposition, | ||
| - | 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, | ||
| - | einem Standort nicht mehr genügen und man das Schema durchbricht, | ||
| - | 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. | ||
| - | </ | ||