Regionales Testbed Bayern
- RTB Netztechnik

ALIs

kommt noch

Stufenplan für die Konfiguration der Netztechnik

Stufenplan für die Konfiguration der Netztechnik
Inhalt dieser Seite

Einleitung
Randbedingungen
Phase 0
Phase 1
Phase 2
Phase 3
Phase 4

Einleitung

Der Stufenplan stellt das Ergebnis verschiedener Überlegungen hinsichtlich der vorzunehmenden Konfiguration im Rahmen des RTB-Bayern dar, die am 19.1.95 bei einem RTB-Treffen im LRZ besprochen wurden. Teilnehmer des Treffens waren:

LRZ: Bonk, Läpple (teilweise), Kaiser, Schuhknecht
TU-München/Informatik: Bartel, Gnatz
RRZE: Clemens, Holleczek (teilweise)
Uni-Erlangen/Informatik: Eckert.

Es handelt sich dabei um einen 5-Phasen-Plan, der eine sichere Einbindung des RTB's in den Produktionsbetrieb gewährleisten soll und dabei die Möglichkeit bietet, gewünschte Ergänzungen gegenüber dem Konfigurationsplan des DFN-NOC einzubinden, um die Anforderungen der Anwender im RTB-Bayern umzusetzen.

Diese Ergänzungen betreffen:

IPX-Routing
Multicast-Support
Direkte WS-WS-Kopplung mit ATM zwischen München und Erlangen
X.25 über IP

Ziel des Stufenplans ist es, RTB-Anwendern auf Basis einer minimalen Konfiguration möglichst frühzeitig die Nutzung der 34-Mbps-Strecke zu ermöglichen und dann sukzessive die Konfiguration aufzubauen und zu testen, um schließlich die Strecke betrieblich zu nutzen, einschließlich der oben aufgezählten Ergänzungen. Diese Vorgehensweise erscheint unumgänglich, um Probleme sukzessive angehen und lösen zu können.

Randbedingungen

Da die Verwendung von dynamischem Routing zwar als wünschenswert jedoch kritisch erachtet wurde, ist ein wesentlicher Punkt des Phasen-Konzepts die stufenweise Einführung von dynamischem Routing, um Probleme eindeutig eingrenzen zu können. Es konnten für jede Phase allseits akzeptierte Kriterien spezifiert werden, die vor Eintritt in die nächste Phase erfüllt sein müssen. Der zeitliche Rahmen der einzelnen Phasen wurde grob geschätzt.

Da z. Zt. noch nicht eindeutig geklärt ist, wann die ATM-Switches für das RTB verfügbar sind, wurde festgelegt, daß die Switches bei Eintreffen transparent in das dann bestehende Szenario eingebunden werden. In jedem Fall müssen die Switches vor Beginn der Phase 4 (Betrieb) eingetroffen und die notwendige/mögliche Konfiguration von PVC's evaluiert sein.

Generell wurde eine Unterscheidung RTB-Verkehr und regulärer Betrieb vorgenommen. Wichtigstes Kriterium hierbei: Sowie regulärer Betrieb über die RTB-Strecke geführt wird, sind Tests oder den Verkehr möglicherweise beeinflussende Konfigurationsänderungen nur noch in einem Wartungsfenster möglich. Der reguläre Betrieb zwischen München und Erlangen soll außerdem über einen vom RTB-Verkehr getrennten PVC geführt werden. Insbesondere dienen einzurichtende Backups vornehmlich dem regulären Betrieb (evtl. zusätzlich einzelnen 'dünnbandigen' RTB-Anwendungen), da die WiN-Anschlüsse ansonsten überlastet wären, da ein 2-stufiger-Backup (Stufe-1: Backup für E3-Strecke und Switches, Stufe-2: Backup für RTB-Router) eingrichtet wird, kann der RTB-Verkehr ggf. über den 'Stufe-1-Backup' geführt werden. Vergl. Abb. 3. Die RTB-Teilnehmer werden informiert, daß Ausfälle möglich sind.

Ein weiterer Grund für das gewählte schrittweise, vorsichtige Vorgehen sind die unausweichlichen Fehler, die auftreten werden und evtl. durch kurzfristige Ersatzlösungen oder durch Ändern der Konfiguration umgangen werden müssen.
Ein Beispiel ist der PVC-Bug der Cisco-Router, der während der Abnahmetests entdeckt wurde. Aufgrund dieses Bugs kann im Cisco-Router aus Performancegründen zur Zeit nur ein PVC konfiguriert werden. Deshalb ist ein Routen des regulären Betriebs über die RTB-Strecke in jedem Fall erst nach Behebung dieses Bugs möglich.

Die Anbindung der Strecke Erlangen-Nürnberg wurde bei diesem Stufenplan nicht einbezogen, da auf dieser Strecke relativ schnell auch Produktionsbetrieb gefahren werden muß. Die Inbetriebnahme dieser Strecke wird nach einem ähnlichen Stufenplan wie dem hier vorliegenden erfolgen und neben dem Produktionsbetrieb auch die RTB-Anforderungen hinreichend berücksichtigen.

Phase 0

Diese Phase dient nur einer kurzen Validierung der Funktionalität der Komponenten und der E3-Strecke zwischen München und Erlangen.

Dauer: im Bereich von Tagen
Ziel: Validierung der Funktionalität.
Konfiguration: Suns direkt an den FDDI-Ringen der RTB-Router. Statische Routen.
Tests: Durchsatz und Delay, Querlogin
Nutzung der Strecke: Nur durch die Sun's.
Ende der Phase: Durchsatz und Delay OK, Querlogin über einen Tag problemlos.

Figure 1: RTB-Konfiguration in der Phase 0

Phase 1

Diese Phase dient dem Sammeln von Erfahrung und der Evaluation der Möglichkeiten, die die eingesetzte ATM-Technologie bietet. Es soll daher möglichst viel Verkehr über die Strecke geführt und dedizierte PVC's für die Anwendergruppen verwendet werden. Wünschenswert wäre das Einbinden der Switches bereits in dieser Phase. Der PVC-Bug der Router sollte vor Verlassen dieser Phase behoben sein.

Dauer: 2-3 Wochen
Ziel: Möglichst viel Verkehr, sichere Einschätzung möglicher Probleme auf ATM-Ebene, stabiler Betrieb mit statischen Routen über ATM.
Konfiguration: Am FDDI der RTB-Router sind die zu verwendenden lokalen Router angeschlossen. Hinter den lokalen Routern hängen die Suns aus Phase 0. Die lokalen Router filtern dabei den Verkehr durch statische Routen.
Neben den Routen für die Suns werden Host-Routen für RTB-Teilnehmer auf Anfrage in den lokalen Routern eingetragen. über diese Möglichkeit werden die RTB-Teilnehmer informiert.

Evtl. werden die Newsserver der Informatik in München und Erlangen über die RTB-Strecke gekoppelt.

Das Eintragen von statischen Host-Routen wird in gegenseitiger Absprache zwischen München und Erlangen durchgeführt.
Nutzung der Strecke: Durch einzelne RTB-Teilnehmer.
Ende: Betrieb wird als stabil erachtet.

Figure 2: RTB-Konfiguration in der Phase 1; (Vergrößerung: Bild anklicken)

Phase 2

In dieser Phase soll die Backup-Verbindung zwischen den RTB-Routern und den X.25-Switches eingerichtet werden. Daneben sollen Möglichkeiten des IPX-Routing getestet werden. Der Test von direkten WS-WS-Kopplungen über ATM setzt das Vorhandensein der RTB-ATM-Switches voraus.

Dauer: 1-2 Monate
Ziel: Einrichtung des separaten Backups für die RTB-Strecke. Stabiler Betrieb mit dynamischem Routing auf den RTB-Routern.
ergänzende Tests: WS-WS-Kopplung, IPX-Routing
Konfiguration: Auf den RTB-Routern (und nur da) wird dynamisches Routing eingerichtet. Die lokalen Router arbeiten weiter mit den statischen Host-Routen aus Phase 1. Von den RTB-Routern wird ein 1-Mbps-Link zu den X.25-Switches, die den WiN-Zugang realisieren, als Backup-Verbindung (Stufe-1-Backup) eingerichtet.
Nutzung der Strecke: Durch RTB-Teilnehmer.
Ende: Betrieb wird als stabil erachtet, Backup funktioniert.

Figure 3: RTB-Konfiguration in der Phase 2; (Vergrößerung: ins Bild klicken)

Phase 3

Kriterium dieser Phase ist vornehmlich das Einrichten des Backups der Stufe 2, der in jedem Fall nur dem betrieblichen Verkehr zwischen München und Erlangen dienen soll, nicht dem RTB-Verkehr. Der Großteil der Tests (bis auf IP-Multicast) muss in dieser Phase abgeschlossen werden. Außerdem muss geklärt sein, ob IPX-Routing eingesetzt wird oder IPX über IP getunnelt wird.

Spätester Beginn dieser Phase: Anfang Mai 95
ergänzende Tests: WS-WS-Kopplung, IPX-Routing
Ziel: vollständiges dynamisches Routing (RTB-Router und lokale Router) Mögliche/notwendige IPX-Routing Konfiguration vollständig evaluiert und getestet.
Konfiguration: Dynamisches Routing auch auf den das RTB abgrenzenden lokalen Routern. Es werden nach wie vor jedoch nur die Host-Routen der RTB-Teilnehmer verbreitet. Als Routing-Protokoll wird BGP4 getestet. Einrichtung einer weiteren Backup-Route (Stufe-2-Backup) über das WiN für einen dedizierten PVC.
Nutzung der Strecke: Durch RTB-Teilnehmer.
Ende: IPX-Konfiguration geklärt.
Switches eingebunden und hinreichend getestet.
Backup funktioniert.
Betrieb wird als stabil erachtet.

Figure 4: RTB-Konfiguration in der Phase 3 und End-Konfiguration; (Vergrößerung: ins Bild klicken)

Phase 4

Diese Phase ist die 'endgültige' Konfiguration des RTB in dem Sinn, dass &#Auml;nderungen oder Tests nun nur noch in einem Wartungsfenster durchgeführt werden können. Die Multicast-Einführung wurde in diese Phase verschoben, da nicht sicher ist, wann diese Funktionalität auf den Wellfleet-Routern zur Verfügung steht und der Beginn dieser Betriebsphase davon nicht abhängig gemacht werden sollte. Da jedoch der Eintritt in diese Phase (wie bereits erläutert) noch von weiteren Kriterien abhängt, kann nur ein voraussichtlicher Beginn angegeben werden.

voraus. Beginn: Juni 95
Konfiguration: Der reguläre Betrieb zwischen München und Erlangen wird über einen separaten PVC dynamisch über die RTB-Strecke geroutet. Der RTB-Verkehr läuft über eigene PVC's und wird insbesondere wegen Überlastgefahr für die WiN-Anschlüsse in München und Erlangen bei Ausfall der RTB-Strecke nicht oder nur eingeschränkt über die eingerichteten Backups geführt.
Neben den Host-Routen werden nun auch Netz-Routen verwendet.
Konfigurationsänderungen sind nur noch in einem festen Wartungsfenster möglich.
ergänzende Tests: Multicast-Einführung nach Verfügbarkeit der entsprechenden SW in den Wellfleet-Routern im Rahmen der Wartungsfenster.
Nutzung der Strecke: Durch Gesamtverkehr München-Erlangen.

Leibniz-Rechenzentrum