Technischer Hintergrundbericht zu AT&T's Netzwerk-Verlangsamung
Am Montag, dem 15. Januar um ungefaehr 14:30 EST, hatte eines von AT&T's 4ESS Vermittlungseinrichtung in New York City ein kleines Hardware- Problem, welches normale Fehlerbehebungsroutinen innerhalb der Schalt- stelle aktivierte. Dieses veranlasste die Schaltstelle, kurzfristig alle neuen Anrufe zurueckzustellen, bis die Routine beendet war (4-6 Sekunden). Eine solche Zurueckstellung ist eine typische Wartungs- prozedur und normalerweise fuer die Anrufer nicht wahrnehmbar. An die angeschlossenen Schaltstellen wurden automatisch Nachrichten gesandt, dass waehrend dieser Zeit keine neuen Anrufe zu der New Yorker Schaltstelle geleitet werden sollten. Die entsprechenden Schaltstellen vermerkten in ihren Programmen, dass die New Yorker Schaltstelle kurz- zeitig nicht erreichbar war. Als die betroffene New Yorker Schaltstelle einige Sekunden spaeter bereit war, die Anrufbearbeitung wieder aufzunehmen, sandte es Anrufversuche (IAM - Initial Address Messages) an die angeschlossen Schaltstellen. Diese vermerkten sodann in ihren Programmen, dass New York wieder erreichbar war und somit auch neue Anrufe entgegennehmen konnte. Ein Prozessor in der 4ESS Vermittlung, der diese mit dem CCS7 Netzwerk verbindet, speichert obige Zustandsinformationen. Als dieser Prozessor (genannt Direct Link Node, DLN) in einer angeschlossenen Vermittlung den ersten Anrufversuch (IAM) von der vorher nicht-erreichbaren New Yorker Vermittlung erhielt, startete er einen Prozess um seinen Zustands- Speicher auf den neuesten Stand zu bringen. Aufgrund eines Software- Fehlers war dieser DLN Prozessor fuer einige Sekunden verwundbar gegen- ueber Unterbrechungen. In dieser verwundbaren Zeit verursachte der Empfang von zwei Anrufversuchen aus New York - innerhalb eines Inter- valls von 1/100 Sekunde - die Beschaedigung einiger Daten. Der DLN- Prozessor wurde dann vom Netz genommen, um neu gestartet zu werden. Da der DLN Prozessor doppelt vorhanden ist uebernahm sein Partner die Arbeit. Ein zweites Paar solcher dicht aufeinanderfolgender Anrufversuche traf den Partner in der verwundbaren Zeit, veranlasste seine Abkoppelung vom Netz und damit die kurzzeitige Isolation der Vermittlung vom CCS7 Signal-Netzwerk. Der Effekt breitete sich lawinenartig ueber das Netzwerk aus, als DLN Prozessoren in anderen Vermittlungen auf aehnlich Weise aus- fielen. Dieser instabile Zustand blieb aufgrund der zufaelligen Natur dieser Fehler und des konstanten Drucks durch die Belastung im Netzwerk, die immer wieder fuer die Anrufversuche sorgte, bestehen. Der Software-Fehler wurde unabwendbar als Teil des Mitte-Dezember Soft- ware Updates in allen 4ESS Vermittlungen im AT&T Netzwerk eingefuehrt. Dieser Update sollte die Leistung des Netzwerkes erheblich verbessern, indem den Vermittlungen ermoeglicht werden sollte, ein Backup Signal Netzwerk im Falle eines Problems mit dem Haupt-CCS7-Netzwerk schneller benutzen zu koennen. Zwar wurde die Software rigoros in Labor-Umgebungen getestet bevor sie eingefuehrt wurde, aber die einmalige Kombination von Ereignissen, die zu diesem Problem gefuehrt hatten, konnten nicht vorher- gesagt werden. Um dem Problem beizukommen und die Integritaet des Signal-Netzwerks wieder herzustellen, benutzten AT&T Ingenieure zuerst Standard- Prozeduren. Frueher waren diese mehr als ausreichend gewesen, um die Anrufverarbeitung wieder aufzunehmen. In diesem Fall waren sie nicht ausreichend. So wussten wir ziemlich frueh, dass wir ein nie gesehenes Probleme hatten. Gleichzeitig schauten wir uns die Gesetzmaessigkeiten der Fehlermeldungen an und versuchten zu verstehen, was sie uns ueber den Zustand mitteilten. Wir haben eine technische Unterstuetzungseinheit, die sich um Netzwerk- probleme kuemmert, und diese wurde unverzueglich eingeschaltet. Bell Lab Mitarbeiter in Illinois, Ohio und New Jersey stiessen einige Momente spaeter dazu. Da wir den Mechanismus, mit dem wir es zu tun hatten, nicht verstanden, mussten wir feststellen, was geschah, indem wir uns sowohl die weitergegebenen Signal-Nachrichten als auch die einzelnen Vermitt- lungsstellen anschauten. Wir konnten das Netzwerk stabilisieren indem wir kurzzeitig den Signalverkehr auf den Backup-Verbindungen unter- brachen. Diese half, die Belastung mit Nachrichten des betroffenen DLN Prozessor zu senken. Am Montag um 23:30 EST hatten wir die letzte Verbindung des Netzwerks bereinigt. Dienstag nahmen wir den fehlerhaften Programm-Update von den Vermitt- lungen und wechselten zeitweise wieder zu dem vorherigen Programm. Wir untersuchten dann das fehlerhafte Programm sehr genau, fanden die verdaechtige Software, nahmen sie mit ins Labor, und es war uns moeglich, das Problem zu reproduzieren. Seitdem haben wir den Fehler korrigiert, die Aenderung getestet und die Backup-Leitungen wieder hergestellt. Wir glauben, dass das Software Design, die Entwicklung und die von uns verwendeten Test-Prozesse auf einer soldiden, qualitativen Grundlage basieren. Alle zukuenftigen Ausgaben von Software werden weiterhin rigoros getestet werden. Wir werden die Erfahrung, die wir durch dieses Problem gewonnen haben, benutzen, um unsere Prozeduren weiter zu verbessern. Es ist wichtig zu bemerken, dass das Volumen von Anrufen am Montag nicht ungewoehnlich war; Es war sogar geringer als an einem normalen Montag, und das Netzwerk handhabte normale Belastungen an den vorhergehenden Wochentagen. Obwohl nichts in 100% der Faelle garantiert werden kann, war das, was am Montag passierte, eine Reihe von Ereignissen die nie zuvor aufgetreten war. Mit laufenden Verbesserungen an unseren Design- und Lieferprozeduren werden wir weiterhin versuchen, die Wahrscheinlich- keit fuer Vorfaelle dieser Art gegen Null zu senken. Uebersetzt von: Michael Niermann Redigiert von: Katja De Haney Quelle: comp.dcom.telecom, gepostet: Don H. Kemp (dhk@teletech.uucp) -----------------------------------------------------------------------------