 |
|
|
Zenith Tagebuch
Auf dieser Seite könnt Ihr den Verlauf aller Bemühungen seitens GIGAHERTZ Equipment Rental über die
Geschehnisse rund um die Veranstaltung "The Zenith" nachlesen. Für Kommentare und Gespräche bitten
wir Euch, ausschließlich das
eigens dafür angelegte Board zu verwenden.
Abschlußstatement Zenith
Nach einigen Gesprächen mit HP haben wir uns nun entschieden, den Fall von unserer Seite offiziell abzuschließen.
Technisch gibt es leider keine signifikant neuen Erkenntnisse seit dem ersten Statement von HP.
Auf Grund der Aussagen und des Verhaltens von HP gehen wir derzeit davon aus, dass das ungewöhnliche Verhalten des 5300XL bei angesprochenem Virus-Traffic im Design der Hardware festsitzt und nicht oder erst zu einem späteren Zeitpunkt gelöst werden kann.
Für uns bedeutet dies, den HP ProCurve 5300XL vorerst nicht mehr für Layer-3 Veranstaltungen einzusetzen.
Nochmals zur erwähnen sei hier allerdings ebenfalls, dass das Gerät im Layer-2 Betrieb nicht gefährdet ist und dort nach wie vor die gewohnt hohe Performance an den Tag legt.
Wir möchten an dieser Stelle auch ein weiteres Mal darauf hinweisen, dass die Ingenieure und Techniker von HP die Konfigurationsdateien des Teams mehrfach geprüft und für einwandfrei gehalten haben. Ein Konfigurationsfehler lag nicht vor.
Ebenfalls möchten wir nochmals hervorheben, dass das Problem beim z.B. HP ProCurve 9300M Routing Switch nicht auftritt (auch nicht im Layer-3 Betrieb), das resultierende Verhalten des 5300XL auf den Virus-Traffic ist nicht normal, für andere Geräte besteht daher zunächst keine Gefahr.
Oft wurde das Netzwerkteam in dem Punkt kritisiert, dass keine Ersatzhardware vorhanden war.
Hierzu ist nochmals zu sagen, dass im Client Bereich mehrere Switches als Spare in Göttingen vor Ort waren. Im Core-Bereich war ein komplett ausgebauter 5308XL Backbone als Spare vorhanden, dieser war auch zwingend notwendig um das Netz in der Nacht von Freitag auf Samstag wenigstens etwas stabilisieren zu können.
Zu Recht angebracht wird der Kritikpunkt, dass das Team bei einem neuartigen Konzept einen zweiten Core aus einer anderen Produktserie hätte vor Ort haben müssen. Dieser Kritikpunkt ist absolut korrekt und angebracht. Umso ärgerlicher ist die Tatsache, dass dies tatsächlich nur am Platz im Fahrzeug gescheitert ist. Es war geplant, das Gerät mitzunehmen, allerdings war in dem Sprinter welcher von Karlsruhe aus gefahren ist, kein Platz mehr für den großen 9308M Backbone.
Auch ist das Team selbst mit seinem Krisenhandling vor Ort nicht zufrieden: Der 9308M hätte schneller geordert werden müssen, um die lange Fahrzeit parallel zur Fehlersuche vor Ort laufen zu lassen. Das geschah zu spät, auch diese Kritik muss das Team annehmen. Dennoch ist es im Nachhinein wesentlich einfacher, zu erörtern, was man hätte besser machen müssen, in diesem Fall bleibt nur, beim nächsten Mal daraus zu lernen.
Was bleibt ist nochmals eine Entschuldigung des gesamten Teams für die Vorfälle auch wenn das Team nur in wenigen Punkten hätte besser reagieren können.
Dass das Team der Zenith zu besseren Leistungen fähig ist, wurde gleich nach der Zenith sowohl teilweise auf der Team Slaughterhouse als auch auf der CL3 im Dezember in der Messe Niederrhein demonstriert.
Für den Corebereich wird GIGAHERTZ sein Portfolio für Layer-3 Veranstaltungen konsequent ausbauen und neue Produkte aufnehmen, um einen Ersatz für den 5300XL im Layer-3 Bereich zu schaffen. Details hierzu folgen sehr bald.
HP kündigt "Virus Thrustler" an
Computerpartner News vom: 03.12.2004
Hewlett-Packard möchte Viren anders bekämpfen. Wie? Durch den wird "Virus Thrustler" (Virus-Bremse):
Diese Software werde ab 2005 in den ProLiant-Server und ProCurve-Switches arbeiten und in diesen, sollten sie von Viren befallen sein, dafür sorgen, dass deren Verbreitung wenn nicht gestoppt, so immerhin gedrosselt wird.
"Virus Thrustler" soll so funktionieren: Patentierte "Throttling"-Techniken können zwischen einem gängigen Server- und einem Viren-Prozess unterscheiden. Sobald beispielsweise eine Netzwerkverbindung hergestellt ist, diese aber genutzt wird für vireneübliches blitzschnelles Überschwemmung des jeweils verbundenen Ports, greift der "Thrustler" ein: Die Software limitiert die Zahl der Netzverbindungen auf 50 pro Minute.
Dadurch seien Viren, die sich direkt über das Netz verbreiten, einzudämmen, versprach Tony Redmond, Chief Technology Officer bei HP. "Jeder Wurm und jeder Virus, der von seiner Fähigkeit zur Selbstverbreitung abhängig ist, wird mit dieser Technik erreicht", sagte er. (wl)
Ob diese Technik für LAN-Parties von Bedeutung sein wird, und ob diese Lösung überhaupt eingesetzt werden kann, ohne den Spielebetrieb zu beeinträchtigen, bleibt abzuwarten.
Wir werden dies nach Veröffentlichung der Software prüfen und Euch auf dem Laufenden halten.
Erste Reaktionen von HP USA
Wir haben heute die ersten Reaktionen aus den USA erhalten:
"The nature of the traffic (every PC pinging every address in a class A network) definitely would cause the high CPU load. This pinging behavior is similar to how viruses like Sasser and Welchia function, creating a DoS. Every new address learned adds a SA/DA host pair to the routing table of the 5300XL. There is a finite amount of space for these entries. The behavior of the clients would have caused the 5300XL's hardware space to fill up. The addresses would then be subjected to an age timer. Basically, the 5300XL wasn't able to keep up with this learning process. It would then have no other option except to learn and route in software; which is much slower and explains why the CPU increased so dramatically."
In Deutsch: Wir haben in den Logs Millionen von Paketen ausfindig gemacht, welche einem Ping Paket an nicht existierende IP Adressen ähneln. Diese Pakete werden unter anderem von Welchia oder Sasser Viren generiert, Agrobot ist ebenfalls ein Kandidat. Diese SA/DA Paare werden in der Routing Tabelle eingetragen was die Tabelle zum Überlaufen bringt. Danach beginnt der 53er, in Software zu routen, was natürlich nicht an die Performance des Hardware-Routings heranreicht.
"...the problems have been identified in testing many times. Unfortunately, the problem is rooted in the routing design of the 5300XL and is not easily fixed. Usually the issues you were seeing are triggered by viruses and the resolution is to purge the viruses from the network..."
HP sitzt derzeit noch daran, herauszufinden, warum diese Müll-Pakete in der Routing Tabelle überhaupt eingetragen werden. Wir warten hier noch auf weitere Recherchen.
Was bereits sicher ist: Dieses Problem ist beim 53er nur im Routing-Betrieb relevant, wenn der 53er als reiner Layer-2 Switch (99% aller LANs) eingesetzt wird, tritt das Problem nicht auf. Die 53er waren auf der Zenith gegen Ende als Layer-2 Switch im Einsatz und haben dort auch einwandfrei funktioniert.
Was bereits klar ist: Eine der nächsten Firmware-Versionen wird sich mit dem Thema Virus-Throtteling befassen. Möglicherweise kann das Problem dadurch eingegrenzt werden.
Wir möchten an dieser Stelle der Virenbelastung im Netzwerk nicht die alleinige Schuld zuschieben, dies ist so erstmal eine erste Information aus dem Hause HP, die Recherchen laufen weiter und sind noch nicht abgeschlossen.
Fakt ist, dass das Thema Security auf LAN-Parties grundsätzlich neu überdacht werden muss.
Wir halten Euch auf dem Laufenden.
Statusupdate
Da derzeit die Lage etwas eingeschlafen scheint, anbei ein Statusupdate.
HP erhält Anfang Dezember neue Produkte, dementsprechend ist in der Entwicklungsabteilung derzeit sehr reger Betrieb. Dies hat natürlich auch Vorrang vor der Lösung unseres Problems.
Das Ganze zieht sich also etwas, allerdings ist die Auswertung der Log-Files so gut wie abgeschlossen. Es gibt bereits Vermutungen und Ansätze, sobald wir diese schriftlich vorliegen haben, werden wir sie hier posten.
Was den Verlauf der Strafanzeige betrifft, so kann diese als Nebeneffekt betrachtet werden, auf Grund des Amtswegs in Deutschland gehen wir nicht davon aus, dass sich hier dieses Jahr noch etwas tun wird.
Stay tuned.
GIGAHERTZ stellt Strafanzeige wegen Sabotage
Gestern haben wir im Fall "The Zenith" Strafanzeige wegen Sabotage gestellt.
Nähere Informationen können wir hier derzeit noch keine veröffentlichen, halten Euch aber wie gewohnt auch in dieser Sache auf dem Laufenden.
DVD mit Logfiles nun in den USA
Die Config-Files und Netzpläne sind ja nun schon seit der Zenith in den USA. Die von uns aufbereitete DVD mit den Sniffer-Files (ca. 4GB Daten) aus dem Zenith-Netzwerk ist nun auch auf dem Postwege unterwegs gewesen und ist heute in den HP-Labs in Kalifornien eingetroffen.
Wir gehen davon aus, dass die Analyse der Daten in USA etwa 2 Wochen in Anspruch nehmen wird.
Paralell dazu verfolgen wir eine weitere Spur zu den Netzproblemen, nähere Infos hierzu in den nächsten Tagen.
Techniker-Protokoll zum Ablauf der Zenith
Nach erfolgreicher Inbetriebnahme des Netzwerks in der Nacht von Donnerstag auf Freitag lief die Anlage einwandfrei und ohne Probleme bis in den Freitag Abend hinein. Bis zum Zeitpunkt des ersten Ausfalls waren etwa 800 - 900 Gäste anwesend.
Am Freitag Abend sprang die CPU Last von einem der HP ProCurve 5308XL Backbones unerwartet und plötzlich auf 99%, es kam zu massivem Packetloss und starken Lags in diesem Block. Zu diesem Zeitpunkt arbeiteten die beiden anderen Backbones (ebenfalls HP ProCurve 5308XL) noch einwandfrei.
Unser erster Lösungsversuch bestand darin, einen Hardwaredefekt des betroffenen Switches auszuschließen. Ein vierter HP ProCurve 5308XL wurde von uns als Cold-Standby-Lösung vorgehalten, so daß der Austausch des Backbones relativ schnell von Statten ging. Leider brachte der Austausch keinerlei Verbesserung, so daß wir einen Hardwaredefekt ausschließen müssen.
Alle drei Backbones waren in einem so genannten OSPF-Ring eingebunden. OSPF steht für "Open shortest Path first" und ist ein Lastausgleichendes Routing-Protokoll. Um eine Fehlkonfiguration bzw. eine Fehlfunktion in diesem Routing-Protokoll auszuschließen, wurde im nächsten Step von uns das OSPF deaktiviert und durch statische Routen ersetzt, der Backbone Ring wurde temporär deaktiviert. Auch dies brachte keine Verbesserung, so dass wir eine Fehlkonfiguration, zumindest im Routing, ebenfalls ausschließen konnten.
Der in Deutschland für die Netzwerkprodukte verantwortliche Manager bei Hewlett-Packard war zu Besuch auf der Zenith um uns über die Schulter zu schauen. Dies erwies sich als äußerst hilfreich, da er zu diesem Zeitpunkt den Kontakt zur Entwicklungsabteilung bei HP USA in Roseville, Kalifornien herstellte. Nach einer kurzen Situationsbeschreibung und der Übersendung unserer Sniffer-Logs äußerte der Techniker sehr schnell einige Vermutungen. Wir erhielten aus USA eine Beta-Firmware. Das Ergebnis des Firmware-Upgrades war leider kontraproduktiv, die Anzahl der gedroppten Pakete stieg weiter an, so dass wir wieder auf die aktuelle Firmware E.08.42 umgestiegen sind.
Nach einigen weiteren Telefonaten mit USA wurde die Internetverbindung zu den Usern gekappt und auf unseren Management-Server umgestellt, eine SSH Verbindung eingerichtet und nach kurzen Anlaufschwierigkeiten konnten wir einen Login auf dem Management-Interface der Switches von roseweb01.proxy.hp.com verzeichnen - der Techniker aus den USA hatte sich live in unser Netzwerk eingeklingt. Die Tests und Einrichtungsarbeiten hierfür hatten leider alleine fast eine Stunde in Anspruch genommen. Als weitere Hürde war zu bewältigen, dass der Techniker nicht wusste, welche Gegebenheiten in einem LAN-Party Netzwerk vorherrschen, so dass er eine gewisse Einarbeitungszeit benötigte um sich ein Bild von den Gegebenheiten zu machen.
Während zwei unserer Techniker in Zusammenarbeit mit dem HP Manager die Kommunikation übernahmen, wurde parallel von uns eine neue Konfiguration für einen Backbonesplit geschrieben. Idee war, den von hoher CPU Last betroffenen Backbone mit Hilfe des vorgehaltenen Ersatzgerätes zu splitten, also 2 Backbones aus einem zu machen.
Die Einarbeitungsphase des Technikers dauerte uns zu lange, so dass wir uns entschieden diesen Versuch abzubrechen und den bereits fertig vorbereiteten Backbonesplit durchzuführen. Das Gerät wurde im NOC fertig mit der Config bespielt, danach wurde vor Ort die Hälfte der Uplinks in den neuen Backbone eingesteckt. Die Freude über die stark gesunkene CPU Last war nur von kurzer Dauer, über 15 Minuten konnten wir zusehen, wie die CPU Last auf den beiden Split-Backbones nun stetig anstieg bis diese wieder über 65% lag und der Packet Loss wieder einsetzte.
Der nächste Versuch bestand darin, die Firmware auf den letzten Release der 7er Software downzugraden um ein Problem in der 8er Firmware auszuschließen. Inzwischen war auch die CPU Last im zweiten HP ProCurve 5308XL auf über 65% gestiegen, auch dort traten nun massive Lags und Packet Loss auf. Wir fuhren demnach ein Firmwaredowngrade auf Version E.07.40 an allen 4 Backbones.
Dieses Downgrade brachte keinerlei Verbesserung. Durch die massive Belastung der Geräte war zudem das Management-Interface so sehr in Mitleidenschaft gezogen, dass das Firmwareupgrade nur sehr langsam von statten ging.
Im nächsten Step, nachdem wir wieder auf die Firmware E.08.42 zurückgepatcht hatten, entschieden wir uns einige VLANs (Usergruppen) vom User-Backbone auf den Core-Backbone im NOC durchzutaggen, also das Routing für die betroffenen Userblöcke auf den Core-Backbone umzuziehen um den Userbackbone zu entlasten. Völlig überraschend und bisher ungeklärt ist, warum nach dieser Umkonfiguration die CPU Last an beiden Backbones (User-Backbone und Core-Backbone) weiter anstiegen.
Im nächsten Schritt wurden von uns verschiedene Befehle an den 53ern eingegeben, um den ICMP (z.B. Ping) Traffic einzuschränken, da wir an Hand von Sniffer Logs mittlerweile die Vermutung hatten, dass es mit dieser Art von Paketen etwas zu tun hatte. ICMP Redirects, ICMP Unknown, ICMP Reply limit und ICMP broadcast limit wurde dementsprechend auf allen 53ern deaktiviert. Dies hatte einen Abfall der CPU Last um 15% zur Folge, was leider nur ein Teilerfolg war, denn die Packet Loss blieben.
Nun stand ein radikaler Kahlschlag in der VLAN Struktur an. Das Netzwerk, welches bis dato aus etwa 50 VLANs bestand, wurde soweit konsolidiert, dass wir die Gäste in insgesamt nur noch 5 VLANs zusammengefasst hatten. Jedes der 5 VLANs war dann ein eigenständiges Layer-2 Netzwerk welches durch die Routing Switches dann noch über Layer-3 verbunden waren. Diese Umstrutkurierung benötigte eine sehr genaue und damit zeitintensive Vorbereitung, da hier kein Fehler passieren durfte. Nach erfolgreichem Abschluß der Konsolidierung trat jedoch keine Besserung im Netz auf.
Der letzte Ausweg war für uns nun, die gesamten Segmentierungen aufzulösen und die LAN in zwei physikalisch getrennte Layer-2 Netzwerke aufzuteilen. Dies resultierte in einem Lastabfall der CPUs auf 20 - 25%. Die beiden Blöcke liefen nun zunächst unabhängig voneinander, beide 900er Blöcke konnten nun bereits Blockintern einwandfrei spielen. Die Gameserver und der zweite Userblock wurde nun über Routing am Core-Backbone wieder angebunden. Dies führte, einhergehend mit der Verteilung neuer IP Adressen durch den Reboot der Client-Rechner jedoch wieder zu einem starken Lastanstieg, so dass der Blockübergreifende Traffic wieder unter Packet Loss zu leiden hatte.
Mittlerweile war der große HP ProCurve Routing Switch 9308M aus Karlsruhe eingetroffen. Dieser wurde nun als reiner Router in das Netzwerk integriert und die Verbindung unter den Userblöcken wurde nun über den 9308M hergestellt. Das Usernetz war nun einwandfrei und alle 1800 Clients hatten Verbindung untereinander - ohne Packet Loss. Der Zugriff auf die Gameserver war nach wie vor ungenügend.
Im letzten Step wurde dann auch das Routing der Server sowie das Routing der Interneverbindung vom 53er auf den 93er umgezogen. Es waren nun noch einige Einzelprobleme zu lösen, die auf Grund der ganzen Konfigurationsarbeiten aufgetaucht waren, dies war jedoch relativ schnell erledigt, so dass das Netzwerk nun einwandfrei und stabil bis zum Ende der Veranstaltung lief.
Auf Basis dieses Ablaufberichts beginnen wir nun, das Problem nachzustellen und die Fehleranalyse in Zusammenarbeit mit HP USA durchzuführen.
Netzpläne
Um einen besseren Überblick zu verschaffen, findet Ihr anbei einige Netz- und Blockpläne zum Netzwerkdesign auf der Zenith:
Es handelt sich hierbei um PDF-Dateien. Wir empfehlen euch, die Dateien mit einem Rechtsklick erst lokal zu speichern und nicht im Browser direkt zu öffnen.
Erstes Statement der Techniker zur Zenith
Das Netzwerk Team der "The Zenith" in Göttingen rund um Christian "KillingCobra" Heintze möchte sich hiermit vorab in aller Form bei allen Gästen und Veranstaltern der genannten LAN-Party für die netzwerktechnischen Vorkommnisse entschuldigen.
Die Probleme des Netzwerk-Systems konnten vom Team nicht kurzfristig gelöst werden, so daß ein vernünftiger Betrieb der LAN-Party erst ab Samstag möglich war.
Wir haben den Fall bereits in der Nacht von Freitag auf Samstag bei Hewlett-Packard in den USA eingekippt und sind derzeit dabei, das Problem mit Hochdruck zu analysieren um eine Aussage treffen zu können, warum das Problem aufgetreten ist, wo es herkam und wie es zukünftig verhindert werden kann.
Wir konnten bisher nur feststellen, dass kein Hardware-Defekt vorliegt. Der betroffene Switch wurde von uns ausgetauscht (bereits am Freitag), was zu keiner Verbesserung der Situation führte.
Wir möchten das Thema offenlegen und nicht totschweigen. Die Qualität des Netzwerkes entsprach in keinster Weise den Ansprüchen, die berechtigter Weise an uns gestellt wurden.
"Der Vorfall trifft das Team sehr hart. In wochenlanger Vorbereitungszeit wurde das Konzept entwickelt, validiert, verbessert und immer wieder getestet. Wir sind derzeit absolut ratlos.", so Christian "KillingCobra" Heintze, seines zeichens Hauptverantwortlicher Netzwerktechniker für die Zenith.
Wir sind um jede sinnvolle und erstgemeinte Hilfe dankbar. Wir werden auf unserer Web-Seite eine Case-Description öffen, wo wir alle Aktionen und Ergebnisse der Tests chronologisch einstellen werden, damit jeder zu jedem Zeitpunkt den aktuellen Status der Analyse einsehen kann und alle davon profitieren können.
Beginnen möchten wir die Coverage mit einem technischen Lagebericht (kommt morgen), in welchem wir die Situation beleuchten möchten, die Probleme aufzeigen möchten und unsere Lösungsversuche erläutern werden.
An dieser Stelle möchte ich noch darauf hinweisen, dass am Freitag zu der Zeit, als das Netzwerk noch einwandfrei lief, diverse Interviews von z.B. Christian aka KillingCobra gegeben wurden. In diesen Interviews wurde die Aussage getroffen, dass das Netzwerk perfekt läuft (was bis Freitag Abend auch der Fall war). Unglücklicherweise wurden diese Interviews teilweise erst am Freitag Nacht gepostet, so daß der Eindruck entstehen könnte, wir würden versuchen, das Ganze nach außen zu überspielen. Dies ist nicht der Fall und rührt tatsächlich daher, dass sich die Abgabe und das Posting des Interviews zeitlich überschnitten hatten. Wir werden entsprechend die Seiten bitten, eine Gegendarstellung zu posten bzw. unser hier aufgeführtes Statement zu veröffentlichen.
Im Moment bleibt uns nur, uns nochmals in aller Form für die Vorkommnisse (was auch immer nun der Grund dafür war) zu entschuldigen. Es tut uns sehr leid, dass es so gekommen ist, vor allem, weil die restliche Teamarbeit perfekt funktioniert hatte und auch alles hervorragend organisiert war, so war unser Eindruck. Wir werden alles in unserer Macht stehende tun, um dieses Problem zu identifizieren.
Ich apelliere an alle, diese Diskussion auf sachlicher Ebene zu führen. Kommentare von wegen "die Hardware von HP ist dafür nicht gebaut" oder sonstige Flamewars, insbesondere von anderen Equipment Verleihern, demonstrieren Unseriösität und enziehen sich jeglicher technischer Grundlage. Es sollte das Ziel sein, dieses Problem schnellstmöglich zu lösen.
Ich möchte zum Schluß noch herausheben, daß Christian und sein Team ein unglaubliches Engagement gezeigt haben und unter Verzicht auf nahezu jeglichen Schlaf alles menschenmögliche unternahmen, um die Situation in den Griff zu bekommen. Das dies erst am Samstag gelang, bedauern wir zu tiefst.
Frank Eckenfels für die Techniker der Zenith
GIGAHERTZ Equipment Rental
|
|
|
 |
