… oder wenn der Fallback für den Ausfall sorgt. Gleich vorweg: Es handelt sich nicht um ein Problem, Bug, whatever in Verbindung mit Securepoint!

Ein Kunde mit einer CompanyConnect-Standleitung (nachfolgend CC genannt) der Telekom klagte über Ausfälle, die Fehlersuche war dabei relativ interessant.

Hinter dem Telekom-Equipment (NT, Cisco) kommt eine Securepoint UTM RC100 zum Einsatz. In der Vergangenheit oder genauer gesagt seitdem der CC eingerichtet wurde gab es immer wieder Probleme. Der vorangegangene langsamere SDSL mit 1.5 Mbit/s war hingegen immer stabil.

Aktuell stellte sich die Situation so dar, das es immer wieder zu Verbindungsabbrüchen kam, diese dauerten meist ca. 20 Sekunden, beim Surfen viel das Kunden-intern nicht weiter auf, zumal mit 5 Mbit/s die Geschwindigkeit gemessen an 16.000 ADSL oder VDSL mit bis zu 100 Mbit/s sowieso langsam ist und man es beim Kunden schlichtweg nicht anders gewohnt ist. Problem für die Performance ist der Standort, aber das ist ein anderes Thema. Jedenfalls vielen die Abbrüche in erster Linie beim VoIP des Geschäftsführes im Homeoffice auf.

Da es wie bereits erwähnt in der Vergangenheit schon immer wieder Probleme gab, wurde vor längerer Zeit ein syslog-Server eingerichtet, auf den die UTM loggt. Bei Auswertung der mittlerweile fünf GB umfassenden Protokolldatei viel dann schnell auf, das es seit Mitte März 2016 von anfänglich ca. 10 Abbrüchen am Tag zu mittlerweile 30 Abbrüche kommt. Dies allerdings unregelmässig über den Tag und die Nacht verteilt. Ein Zusammenhang mit der Leitungsauslastung konnte nicht hergestellt werden, da die Verbindung selbst dann abbrach, wenn nichts los war.

Offenbar mehrere Probleme

Interessant war das erste Gespräch mit der CC-Hotline, ein geringer Teil der Ausfälle konnte nachvollzogen werden, unter anderem das Wegbrechen aller vier Doppeladern. Aber es hies schnell, das beim Kunden ein Stromausfall gewesen sein muss, dies konnten wir allerdings verneinen, da sowohl das USV-Log als auch die Uptime von Geräten die nicht an der USV hängen dem widersprachen (unterschiedliche Phasen sind dabei berücksichtigt). Eine weitere Behauptung die Telekom-seitig aufgestellt wurde war, das z.B. an einem Samstag-Abend jemand den Stecker gezogen haben muss. Da allerdings beim Kunden nur Montags bis Freitags gearbeitet wird, konnte auch das ausgeschlossen werden. Vermutlich wollte man damit auf den sogenannten Putzfrauen-Fehler abzielen.

Jedenfalls wurde durch einen Telekom-Techniker vor Ort sicherheitshalber der NT ausgetauscht, da man sich sonst nicht anders den Ausfall aller vier Doppeladern gleichzeitig erklären konnte. Der Port im POP oder die Regeneratoren auf der Leitungsstrecke wären nicht das Problem, hies es.

Schuld ist immer der Kunde

Kurzum nervend war bei nahezu jedem Gespräch mit der Hotline als auch dem Techniker vor Ort, das es letztlich immer hies, der Kunde sei Schuld, da man keinen Fehler auf der Leitung oder beim Routing feststellen könne.

Ein halber Tag lang tut sich nichts beim Service

Nach dem erfolglosem Sicherheitstausch des NT folgte ein weiterer Anruf unsererseits bei der CC-Hotline nach zwei weitere Tage lang Abbrüche auftraten. Man klagte ein weiteres Mal das Problem und es wurde ein Rückruf versprochen. Als selbst nach sechs Stunden dieser nicht erfolgte meldeten wir uns erneut, dabei landeteten wir mehrfach in anderen Fachabteilungen, die nicht zuständig sind oder das Gespräch blieb mit einem Rauschen hängen. Nach mehreren Versuchen kam man dann doch durch und es hies ein Kollege aus der Diagnose müsste sich das Ganze nochmal ansehen. Kaum war dieses Telefonat beendet erfolgte der Rückruf, so entstand der Eindruck, das man jemanden sozusagen aufgeweckt hat.

Interessante Äusserungen des Remoteservice

Ein Techniker vom Telekom-Remoteservice fragte unter anderem, ob der NT als auch der Cisco-Router (beides Geräte von der Telekom gestellt) an einer USV hängen würden, denn es gäbe gehäuft Meldungen, das diese Geräte Probleme mit der Spannungsversorgung durch USV’en hätten und das zu Fehlern führen würde, die nicht protokolliert werden. Dies konnten wir allerdings verneinen.

Erst die beiläufige Bemerkung das er keinen Ping auf Google sondern auf Heise macht, weil Google es grad “nicht mag” wenn es angepingt wird, machte uns hellhörig. Der Fallback in der UTM ist gemäss Anleitung von Securepoint eingerichtet. Da wir bislang mit den Google-DNS-Servern 8.8.8.8 und 8.8.4.4 zwecks Erreichbarkeit durch Ping keine Probleme hatten, wurde dies einfach übernommen. Und genau hier liegt die Krux.

Problem an anderer Stelle, als vermutet

Einzelne Pings auf 8.8.8.8 und 8.8.4.4 zeigten mitunter keine Ausfälle, allerdings beim Dauerping gibt es grob gesagt jede Menge Verluste! Nicht immer am Stück, zwischendurch ist auch mal alles in Ordnung. Eine Gegenprüfung von unserem Anschluss aus (ebenfalls Telekom, aber kein CC, sondern VDSL mit fester IP) zeigte keine Verluste, auch nach mehreren Stunden nicht. Vermutlich gibt es ein Problem zwischen einem Teil-Netz der Telekom und Google. Ob das nun an mangelnden Peering, einem möglicherweise überlastetem Gateway liegt oder etwas anderem liegt, kann nicht gesagt werden.

Jedenfalls wurde aufgrund dieser Erkenntnis die “Ping-check Host”-Adresse im Fallback der UTM geändert und der Spuk war vorbei. Bleibt die Frage, was genau da zwischen Telekom und Google los ist und ob es weitere Probleme gibt. Bislang viel zumindest nichts weiter auf.

Was lernen wir daraus

Man sollte sich nicht nur auf Pings im eigenen Netz, dies geht Richtung Telekom, verlassen, sondern auch außerhalb eben dieses ein oder mehrere Ziele über einen längeren Zeitpunkt ansprechen. Ferner war die hautpsächliche Fehlersuche zu sehr auf die Leitung an sich bezogen, als auch mal “nach dem Rest” zu schauen.

Kurzum: Wer misst misst Mist.

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.