Kommentar: Service-Provider
Eine Frage der Qualität
Wieder einmal habe ich einen Alptraum mit einem Service-Provider erlebt. Wieder einmal war ich zu gutgläubig und konnte mir nicht vorstellen, dass die Techniker meine Fragen nur partiell bearbeiten.
Ein größeres Unternehmen hatte Probleme mit seinen VoIP-Diensten und bat mich um Hilfe bei der Analyse ihres QoS-fähigen MPLS-WANs. Abgesehen von den offensichtlichen Probleme, dass sich die VoIP-Telefone und Remote-Gateways ohne ersichtlichen Grund immer wieder registrierten, berichteten die IT-Administratoren von veränderten QoS-DSCP-Einstellungen an einigen abgelegenen Standorten und von verloren gegangenen Heartbeats zwischen den Gateways und den Call-Servern.
Auf den ersten Blick sah es nach einem klassischen WAN-Problem aus. Anscheinend wurden die vier dem Kunden garantierten QoS-Queues nicht ordnungsgemäß bereitgestellt. Irgendetwas passierte bei der Übermittlung mit den QoS-Markierungen, so dass der VoIP-Verkehr nicht ordnungsgemäß von Ende-zu-Ende übermittelt wurde und irgendwo im Datenpfad hängen blieb. Der Service-Provider (der Betreiber des Zugangsnetzes des Kundens und der MPLS-Core) hatte seine Seite der Dinge zu überprüfen und berichtete, dass alles richtig konfiguriert ist.
Als wir mit unserer Analyse begannen, wurde sehr schnell klar, dass unsere QoS-Einstellungen in Ordnung waren. Das Problem bestand darin, dass die vom LAN über das WAN übermittelten TOS-Bits auf der WAN-Strecke verändert wurden. Da wir jetzt die Beweise in der Hand hielten, erbarmte sich unser Service-Provider noch einmal einen genaueren Blick auf sein Netzwerk zu werfen. Und welch ein Wunder, unser Provider fand einige Koppelkomponenten, bei denen die DSCP-Einstellungen nicht stimmten. Dieser Mangel wurde behoben und die Dinge sahen schon ein bisschen besser aus.
Aber von einigen Standorten aus gingen immer noch VoIP-Pakete verloren. Eine weitere Analyse auf Seiten des Service-Providers ergab, dass die im SLA vereinbarten QoS-Richtlinien nicht eingehalten wurden und auf einigen Zugangs-Routern die Menge des priorisierten Verkehrs falsch konfiguriert war. Auch dieser Fehler wurde behoben und die Dinge sahen schon wieder ein bisschen besser aus.
Aber es gab noch weitere Probleme. Einige Netze des Kunden agierten als Hub-Standorte für kleinere Büros. Der Service-Provider nutzte in diesen Netzen so genannte Aggregation-Switches. Diese wurden logisch in die Strecke zwischen den CEs und dem PE integriert. Es stellte sich heraus, dass man auf den Aggregation-Switches die Konfiguration des QoS vergessen hatte. Auch dieser Mangel wurde behoben und die Dinge sahen schon wieder ein bisschen besser aus.
Nach langen Diskussionen und einem noch längeren Überzeugungsprozess bekam ich endlich Einblick in die Konfigurationen der CE-Komponenten. Unser Service Provider war der Ansicht (und ist es noch immer), dass dieser Bereich in sein Verantwortungs- und Kompetenzgebiet fällt und daher der Kunde diese Informationen nicht benötigt. Man rechtfertigt diese Intransparenz mit dem Killerargument: „Firmengeheimnis“. Die Geheimnisse unseres Providers hätten uns nie interessiert, wenn das von ihm bereitgestellte Netz auch tatsächlich einwandfrei funktioniert hätte. Da jedoch immer wieder Proble auftraten, gewährte mir der Provider zumindest einen Blick in die QoS-Definitionen mehrerer CE-Router.
Ich fand heraus, dass auf einigen CE-Komponenten die QoS-Werte nicht stimmten. Diese wiedersprachen fundamental den ursprünglich vereinbarten QoS-Richtlinien. Inoffiziell erfuhren wir von einem redseligen Techniker, dass unser ursprünglicher QoS-Entwurf aus internen Gründen geändert worden war. Natürlich wurde mein Kunde nicht über die Änderungen informiert. An dieser Stelle blieb uns nur folgende Vermutung: Unser Service-Provider hat die DSCP-Einstellungen so modifiziert, dass diese der internen Klassifizierungsstruktur des Providers entspricht und somit der Kosten-Nutzeneffekt des Netzbetriebs optimiert wird.
- Eine Frage der Qualität
- Schlechter Service, komplizierte Beweisführung
Lesen Sie mehr zum Thema
