geocaching.com – Zugriffsprobleme

Seit mehreren Wochen häufen sich die Beschwerden über geocaching.com. Diese reichen von „kein Login möglich“ über „sehr lange Ladezeiten“ bis „API funktioniert nicht“. Teils treten diese Probleme zeitlich beschränkt auf, z.B. verstärkt am Wochenende oder abends zwischen 20 und 24 Uhr. Wie üblich in solchen Fällen schießen dabei natürlich die Spekulationen ins Kraut, da ist von Serverausfällen die Rede, von Umbauarbeiten, ja sogar von Unfähigkeit seitens der Betreiber. Klar ist aber auch, dass solche Spekulationen nicht zur Lösungsfindung beitragen.

Beschränken sich die Probleme auf Europa?

Neben den deutschen Geocachern beschweren sich auch Schweizer, Franzosen und Österreicher. Wie es in anderen Ländern aussieht habe ich jetzt nicht recherchiert. Die Amis selbst haben keine Probleme und auch aus Australien ist nichts negatives zu lesen.

Bleiben wir mal in Deutschland. In der Facebookgruppe „Geocaching Community Deutschland“ mit über 5.800 Mitgliedern geht es besonders hoch her und sehr viele sehen die Ursache für die Probleme bei geocaching.com, also Groundspeak. Nun ist es immer leicht eine solche Schuldzuweisung zu machen, doch ganz so einfach ist das nicht, denn ein ebenfalls nicht unerheblicher Teil der Nutzer hat keinerlei Probleme. Des Weiteren ist es schon auf Grund der komplexen Netzwerkstrukturen des Internets mitunter gar nicht so einfach Fehlerursachen zu lokalisieren.

Es kann nicht (allein) an Groundspeak liegen!

Die Tatsache, dass sehr viele Nutzer überhaupt gar kein Problem mit geocaching.com haben, spricht dagegen, dass es am Server liegt. Das mögen jetzt einige nicht wahrhaben wollen, doch ich werde das in der Folge weiter ausführen.

Zunächst mal muss man die Nutzer unterschiedlich betrachten: die einen stellen fest, dass etwas nicht geht und sie sind aufgeschmissen und verärgert. In diesem Fall ist grundsätzlich der Server(betreiber) schuld. Die anderen versuchen Fehler zu analysieren und probieren Alternativen aus. Dabei stellen sie fest, dass der Server ja doch läuft, denn er ist auf einem anderen Weg erreichbar und es funktioniert.

Dies lässt den Schluss zu, dass das Problem irgendwo zwischen Nutzer und Server (geocaching.com) zu suchen ist. Das macht die Sache schwierig, denn wie bereits erwähnt ist das Internet ein komplexes, nicht wirklich transparentes, Netzwerk.

Ein weiterer Aspekt, der gegen serverseitige Ausfälle spricht, sind die Daten von Website-Checks die die Uptime und Antwortzeiten von beliebigen Websites überwachen. Einen solchen Server Status Check bieten verschiedene Dienstleister an.

gccomstatus

Versuch der Eingrenzung

Nachdem nicht nur in der o. g. Facebookgruppe, sondern auch im Geoclub- sowie Groundspeak-Forum die Meinungen über mögliche Ursachen zum Teil sehr kontrovers sind, habe ich mich mit möglichen Ursachen bzw. Fehlerquellen auseinandergesetzt. Zwei (nicht repräsentative) Umfragen zeigen dabei Trends auf, die nicht ganz unlogisch sind. Bei der Frage ob Probleme mit geocaching.com auftreten oder nicht haben 160 Nutzer geantwortet. 3/4 haben ein Problem (wobei das nicht weiter eingegrenzt wird) und 1/4 merkt davon gar nichts.

Bei der Frage nach dem verwendeten Provider haben 113 Nutzer geantwortet und davon gaben 71 die Dt. Telekom an, 15 mal wurde 1&1 genannt und  27 weitere Nutzer verteilen sich auf 6 weitere Provider. Somit sieht es so aus, als sei der größte Teil der Nutzer mit Problem im Netz der Dt. Telekom unterwegs.

Bei den Schweizer Geocachern ergibt sich ein ähnliches Bild, dort scheinen Cablecom-Nutzer die meisten Probleme zu haben.

Also ein Providerproblem?

Die Vermutung liegt zwar nahe, aber letztendlich bleibt das nur eine Vermutung, denn der Beweis lässt sich so natürlich nicht erbringen. Betrachten wir also mal (vereinfacht) die Struktur des Internet: das heimische Netzwerk ist i. d. R. über einen Router mit dem Netz des Internetproviders verbunden und wir gehen davon aus, dass diese Verbindung technisch in Ordung ist. Der Provider sorgt für die Anbindung an s Internet und stellt i. d. R. auch den DNS-Server, der Servernamen in IP-Adressen auflöst. Ein DNS-Server kann aber schon mal Probleme verursachen, z. B. wenn gleichzeitig eine sehr große Zahl von Anfragen kommt. Dann kann es zu Verzögerungen bei der Namensauflösung (Web-Adresse –> IP-Adresse) die auf Client-Seite (beim Nutzer) zu Timeouts führen. In der Praxis bedeutet das, dass unter Umständen keine Verbindung zum Zielserver aufgebaut wird. Im etwas günstigeren Fall kommt es nicht zwar nicht zu Timeouts, aber die Antwortzeiten sind sehr lange und dies resultiert in sogenannten „langsamen“ Verbindungen. Dabei wird zwar ein Datenverkehr zwischen Client und Server etabliert, aber die Daten-Pakete „tröpfeln nur durch die Leitung“ was Ladezeiten von einigen Minuten bedeuten kann.

DNS / Routing Alternativen

Man ist nicht zwingend auf den DNS-Server seines Providers angewiesen. Frei zugängliche Alternativen sind z. B. OpenDNS und Google Public DNS. Eine Erklärung zur Verwendung dieser öffentlichen DNS Dienste am Beispiel von Google Public DNS findet ihr bei Netzwelt.

Aus eigener Erfahrung kann ich bestätigen, dass ich sehr viel schneller im Internet unterwegs bin, seit ich Google DNS verwende. Außerdem konnte ich damit das Problem lösen, dass nach einem Firmwareupdate auf meinem Router kein Zugriff auf Twitter mehr möglich war. Eine Auswirkung bei geocaching.com habe ich selbst nicht, da ich keine Zugriffsprobleme mit der Seite habe.

Ein weiteres Indiz für ein Routing-Problem kann man herleiten, wenn z. B. mit dem PC über die DSL-Leitung die Seite nicht erreichbar ist, es aber mit dem Smartphone über die mobile Datenverbindung funktioniert. In dem Fall greift man über völlig verschiedene Netzstrukturen mit anderen Routings auf dasselbe Ziel zu, was hier den Unterschied und somit den Erfolg ausmacht.

Ein Tablet ohne SIM-Karte ist für diesen Versuch i. d. R. nicht geeignet, da es sich im selben Netz (WLAN) wie der PC befindet.

Um das Routing zu verändern ohne den Provider zu wechseln, gibt es verschiedene Möglichkeiten: zum einen kann man einen Proxy verwenden, zum anderen ein VPN. Beides ist für Laien nicht unbedingt trivial und auch entsprechende Browserplugins funktionieren nicht immer zufriedenstellend. Eine Lösung kann ZenMate sein.

Weitere mögliche Ursachen

Auf modernen Webseiten werden große Teile des Inhalts dynamisch, d. h. bei Zugriff generiert. Vieles davon wird unter Verwendung von AJAX Frameworks asynchron übertragen, die Datenströme sind dabei nicht „linear“. Dabei hat der Client (Browser) sehr viel mehr zu tun als bei statischen Webseiten. Verwendet man als Nutzer gleichzeitig noch lokale Scripts (z. B. GC little helper oder GC Comment auf Basis von Greasemonkey) kann es in der Kombination zu Laufzeitproblemen kommen, die im ungünstigsten Fall auch den Aufbau der Seite verhindern.

Auch das gleichzeitige Streamen von Video- oder TV-Inhalten kann die Surfgeschwindigkeit im heimischen Netzwerk beeinträchtigen, denn viele Router priorisieren Video-Streams gegenüber „normalen“ Datenpaketen zugunsten einer ruckelfreien Wiedergabe. Mit der zunehmenden Verbreitung von Video on Demand Diensten hält leider der Netzausbau nicht ganz Schritt, somit kann es in den Netzen der Provider durchaus auch zu Engpässen bei der zur Verfügung stehenden Bandbreite kommen kann.

Auch Klassiker wie Probleme mit dem Browsercache kann man nicht einfach ausschließen. Den Browsercache leeren schafft manchmal Abhilfe.

Datenverteilung via CDN

Gehen wir nun vom Client wieder zurück ins Netz. Um den weltweiten Anstieg von Serverzugriffen auf beliebte Dienste zu entzerren, setzen immer mehr Anbieter auf sogenannte CDNs (Content Delivery Network).  Damit lassen sich große Datenmengen die z. B. bei Mediadateien wie Videos und Bildern entstehen, unabhängig vom eigentlichen Webserver verteilen. Die CDNs entlasten normalerweise das Internet, weil sie die Daten von amerikanischen Anbietern regional ausgeben, z. B. direkt von deutschen Servern, statt die Daten jedesmal „über den Teich“ zu schicken. Aber auch hierbei werden DNS-Anfragen generiert, denn der anfragende Client muss wissen wo er die Daten tatsächlich anfordern soll. Teilweise stehen die CDN-Replica-Server auch direkt bei Providern oder Peering-Knoten um maximale Leistung zu bieten. Doch diese Beschleunigungsmechanismen haben auch ihre Tücken: es kann zu fehlerhaften Konfigurationen kommen die wiederum regional oder gar providerabhängig zu Problemen führen. Denn wenn die Mediadaten zu einer Webseite nicht beim Client ankommen, kann dieser die Seite u. U. nicht aufbauen und für den Nutzer ist nicht klar wo die Fehlerursache liegt.

Verbindungsprobleme in Deutschland

Vor ein paar Minuten kam ganz aktuell folgende Twittermeldung:

GC_verbindungsproblem

In diese Meldung sollte man jedoch nicht Serverprobleme bei Groundspeak hinein interpretieren. Das klingt in der Tat eher nach einem Netzwerkproblem und ist somit etwas anderes. Es könnte sogar ein Problem mit dem CDN sein: geocaching.com setzt auf AWS Cloudfront und die haben in der jüngeren Vergangenheit öfter Probleme gehabt.

Bleibt zu hoffen, dass die geocaching.com – Zugriffsprobleme bald gelöst werden und die Geocaching Community was das angeht wieder zur Ruhe kommt und dem eigentlichen Zwecke unseres Hobbies, der Dosensuche nachgehen kann.

Update (14:00 Uhr)

Zwischenzeitlich hat sich ein Admin im Groundspeak Forum zu Wort gemeldet.

Painting a picture from all of the information provided, I believe ecanderson and cezanne are on the right track with there being a tier 1 ISP routing issue affecting folks in Germany and possibly other parts of central Europe. This is based on posted traceroute (tracert) output of users experiencing dramatically increased latency on middle hops and even packet loss.

In all the examples that I’ve seen so far, the dramatic latency increases are occurring after your provider hands the packet off to a tier 1 ISP, but before it reaches our provider. So neither of our provider’s networks appear directly responsible, but some of the internet backbone peers that both of our providers rely on could be. Of the slow instances that I’ve reviewed, the traceroute output frequently shows routes that include tier 1 network providers Cogent and NTT. I found a relevant article on backbone/peering concerning Netflix that shows Cogent and NTT with higher latency than other providers and talks about the effect of slowing during peak times. Cogent also appears to have engaged in Quality of Service traffic deprioritization that might be worth noting.

Likely the best and only course of action is to draw attention to the routing issue and hope it gets resolved soon. I’ve initiated dialog with the network operations center of our provider, Internap, which you’ll see in the last couple of hops of the traceroute output that folks have posted. I know that we utilize several BGP peers, which appear to include Cogent and NTT based on network hop naming. While many ISPs have agreements with these providers as BGP peers, it doesn’t indicate if that agreement is direct or third-party, but they might have some influence in getting this resolved. I have asked for guidance on this situation and what options are available to us.

Grobe Übersetzung:

Zeichnet man ein Bild an Hand der vorliegenden Informationen, könnte es sich um ein Tier 1 ISP Routing Problem handeln, dass vor allem Leute in Deutschland betrifft und möglicherweise auch in anderen mitteleuropäischen Regionen. Dies basiert auf den Tracert Ergebnissen von Nutzern die dramatisch angestiegene Latenzen in den mittleren Hops und sogar Paketverluste zeigen.

[…]

Die wahrscheinlich beste und einzige Möglichkeit ist das Routing Problem zu beobachten und zu hoffen, dass es bald behoben wird. Ich habe den Dialog mit unserem Netzwerk Operations Center unseres Providers, Internap, eröffnet […] Ich weiß, dass wir einige BGP Peers benutzen, wie es scheint auch Cogent und NTT. Obwohl viele Provider Vereinbarungenn mit diesen BGP Peers haben, egal ob direkt oder über Dritte, könnten diese Einfluss auf die Problemlösung nehmen. Ich habe um Unterstützung in dieser Sache und den uns zur Verfügung stehenden Möglichkeiten angefordert.

1000px-Internet_Connectivity_Distribution_&_Core.svg

Relationship between the various tiers on Internet providers (Quelle: wikipedia)

Aktuell sieht es also nach einem Routingproblem aus, möglicherweise im Netz der Dt. Telekom, die in Deutschland ein „Tier 1 Netzbetreiber“ ist. Mal sehen wie das weiter geht und wie das Problem letztendlich gelöst wird.

Happy Caching!

Hinweis: dieser Artikel wird bei Bedarf aktualisiert bzw. folgen Updates.

Das könnte Dich auch interessieren...

22 Antworten

  1. Jörg sagt:

    Danke für die Informationen. Bislang dachte ich: was haben die nur, bei mir läuft doch alles. Gestern Abend hatte ich aber erstmals auch das Problem die Geocaching-Seite nicht öffnen zu können. Und ich bin übrigens auch Telekom-Kunde.

    Viele Grüße aus Limburg, Jörg

  2. Seekers98 sagt:

    Vielen Dank für den Artikel! Es tröstet etwas, wenn man erfährt, dass so viele andere auch diese Probleme haben. Ein weiterer Trost ist, dass ich momentan keinen Power-Trail loggen muss. 🙂
    Momentan ärgere ich mich, dass ich erst im Dezember die Premium-Mitgliedschaft verlängert habe. Ansonsten haben wir ja nichts in der Hand um Druck zu machen. Ihr von GeocachingBW habt doch gute Kontakte zu den Reviewern, oder? Könnte nicht über diesen Weg Groundspeak die Dringlichkeit nahe gebracht werden?
    Ich glaube ja gerne, dass das Problem nur in Europa besteht. Trotzdem finde ich es sehr seltsam, dass das Problem nur mit geocaching.com besteht und mit keinen anderen Seiten.
    Prinzipiell finde ich, dass es im Interesse der meisten Mitglieder sein dürfte, wenn sich Groundspeak zu allererst um eine reibungslose Funktion der Basis-Features kümmern würde und z.B. Hilfe von Experten in Europa holen. Wenn das alles flutscht, können sie von mir aus neue Souvenirs, Videso oder anderen Klimbim erfinden.

    • webmicha sagt:

      Die ITler von Groundspeak sind doch dran, siehe im Artikel den Twitterpost und Link zum Groundspeak-Forum. Das Problem konzentriert sich nach Aussagen von GS im Forum auf Deutschland. Mehr als das was ich bereits im Artikel beschrieben habe, kann ich derzeit auch nicht sagen. Die Fehlersuche bei IT-Problemen kann schon mal etwas dauern.

    • Gerd sagt:

      Typischer Fall von „ICH habe was zu meckern, also kümmert IHR Euch mal darum“ 🙁
      Die Reviewer haben mit dieser Problematik nichts zu tun und sind für DEIN Anliegen auch nicht zuständig. Warum nimmst Du das nicht selbst in die Hand, anstatt faul – oder feige – andere vorzuschicken?
      (mal ganz davon zu schweigen, dass es überhaupt nicht klar ist, ob Groundspeak für diese Probleme überhaupt (haupt)verantwortlich zeichnet)

      • Seekers98 sagt:

        Unglaublich, wie man hier wegen einem gut gemeinten Vorschlag angepampt werden kann… 🙁

        • webmicha sagt:

          Hallo Seekers98,

          Gerds kommentar ist schon pampig, aber er hat recht.

          Die Reviewer sind für die Verwaltung der Cachelistings zuständig. Sei können weder etwas an den aktuellen Netzwerkproblemen ändern, noch ist es ihre Sache technische Probleme der User weiterzutragen.

          Im Groundspeak-Forum beteiligen sich einige Cacher mit Beiträgen an der Fehlersuche. Das ist m. E. der richtige Weg, aber leider sind das nur wenige, obwohl das Gejammer in der Community groß ist.

          Das Ganze hat auch überhaupt nichts mit irgendwelchen Features oder Art der Mitgliedschaft zu tun, denn die geocaching.com Server funktionieren einwandfrei.

          • Seekers98 sagt:

            Hallo Micha,
            ich schreib dir mal auf anderem Wege, bevor es hier ausufert… 🙂
            so hoch kochen müssen wir das Thema nicht…

  3. SammysHP sagt:

    Öhm… soll das ein Witz sein?

    Die betroffenen Provider. Ist ja klar, dass die Telekom vorne liegt. Schließlich spiegeln die Zahlen ungefähr die tatsächliche Verteilung der Kunden wieder.

    DNS-Problem? Definitiv nein. Erstens ist das DNS-System praktisch nie überlastet. Warum auch? Da läuft kaum Traffic drüber und einmal angefragt, ist die Antwort im Computer zwischengespeichert.
    Zum anderen sollte man sich mal genauer anschauen, wann ein Timeout auftritt. Genau, wenn man sich versucht, mit dem Server zu verbinden. Dazu muss man natürlich zuvor den Namen aufgelöst haben. Und bei mir ist es immer so, dass die Seite langsam lädt, aber nie, dass die Verbindung nicht hergestellt werden kann. Und da das DNS nur vor der Verbindung (und auch nur einmalig) eine Rolle spielt, scheidet es aus.

    „In dem Fall greift man über völlig verschiedene Netzstrukturen auf dasselbe Ziel zu“ – und dann soll es am DNS liegen? Du meinst doch sicher eher das Routing.

    Auf die restlichen Punkte gehe ich nicht mehr ein, es tut einfach weh.

    „Wenn ich mit diesem Artikel zu etwas mehr Verständnis verhelfen konnte, und unnötige Spekulationen und Schuldzuweisungen damit zurückgehen, dann würde ich das sehr begrüßen.“

    Nein. In diesem Artikel konnte ich keine Information finden, die zumindest halbwegs richtig ist. Ich bin Informatiker, habe meinen Bachelor und arbeite gerade an meinem Master. Netzwerke sind mein tägliches Leben. Bitte verstehe es nicht falsch, aber dieser Artikel ist inhaltlich völlig falsch. „Wird bei Bedarf aktualisiert“ – ja, bitte, mach das!

    Kurze Theorie, woran es wirklich liegen könnte: DNS scheidet schonmal aus. Das ist einfach viel zu unwahrscheinlich. Sollte es wirklich bei einigen Providern vermehrt auftreten (ich sehe dafür immer noch keinen Beweis, da die Antworten aus der Umfrage nunmal die Providerverteilung widerspiegeln), dann müsste es am unterschiedlichen Peering liegen. Die Telekom beispielsweise möchte immer noch nichts mit dem DE-CIX zu tun haben und hat deswegen vermehrt Probleme mit der Geschwindigkeit. Da es aber auch bei anderen Providern auftritt, vermute ich etwas anderes.
    Zum einen natürlich die CDN, die Ergebnisse zwischenspeichern. Das funktioniert aber nur bei statischen Daten, nicht bei dynamisch generierten (und die Webseite selbst ist dynamisch generiert, schließlich zeigt sie bei jedem etwas anderes an). Beispielsweise werden Bilder von gc.com über CDN verteilt.
    Es gibt allerdings auch noch einen anderen Punkt: geocaching.com läuft nicht nur auf einem Server. Zwischen den Servern findet ein Loadbalancing statt, Anfragen werden also immer auf die am wenigsten ausgelasteten Server verteilt. Hierbei kann leicht etwas schief gehen. Das würde auch erklären, dass einige Benutzer weniger Probleme haben als andere. Es könnte nämlich sein, dass bestimmte Routen auf bestimmte Server geleitet werden und einige somit zu sehr ausgelastet sind.
    Eine weitere Engstelle ist die Datenbankanbindung. Soweit ich weiß setzt Groundspeak mehrere Datenbankserver ein (was bei den Datenmengen und Anfragen auch notwendig ist). Greifen nun sehr viele Nutzer auf gc.com zu, laufen die Anfragen von allen Servern, die die Seiten generieren, bei den Datenbankservern ein und a) überlasten diese oder b) überlasten das interne Netzwerk.

    In anderen Worten: Ich schiebe das Problem definitiv auf Groundspeak, gebe ihnen aber nicht die Schuld, da ein System mit einem so hohen Volumen nicht so leicht einzurichten ist.

    Sollte ich wieder Probleme mit gc.com haben, werde ich mir mal verschiedene Routen genauer anschauen und dann berichten, was ich herausgefunden habe.

    • webmicha sagt:

      Natürlich können DNS-Server überlastet werden/sein und das Routing benötig DNS, es sei denn man hat statische Routingtables. DNS-Anfragen sind auch während dem Seitenaufbau nötig wenn Inhalte von verschiedenen Servern, z. B. von einem CDN, eingebettet sind.

      Wenn die DB-Server überlastet wären, würde sich das nicht auf alle Nutzer auswirken?

      Jedenfalls danke für dein Feedback, ich freue mich auf deine eigene ausführliche Analyse 🙂

      • SammysHP sagt:

        Ja, DNS-Server können natürlich überlastet sein, dann würde das Problem aber auch bei allen anderen Webseiten auftreten (da DNS-Ergebnisse auch auf den vermittelnden DNS-Servern zwischengespeichert werden). Und die meisten Daten kommen immer noch von geocaching.com, nur ein paar Bilder liegen auf einem CDN, bei dem eine weitere DNS-Anfrage nötig wäre.

        Je nach der Redundanz der Datenbankserver müsste es sich bei allen Nutzern auswirken. Ist es nur ein Teil, dürfte der Bottleneck aber woanders liegen. Entweder sind die Frontendserver zum Teil überlastet oder die Anbindung von gc.com ans Rechenzentrum ist zu gering.

        Momentan ist die Seite bei mir vergleichsweise schnell. Dennoch habe ich kurz geschaut: Ping momentan rund 160 ms, was absolut ok ist. Das Routing ist bei der Telekom typisch etwas seltsam (NTT), vom DFN über Cogent (die haben ’ne Menge Hops…) und von meinem Server aus den USA in relativ flotten 25 ms und nur 6 Hops (auch über NTT).
        DNS <1ms (da in meinem lokalen DNS-Server zwischengespeichert), Verbindung <1ms (HTTP keep-alive), Warten einige hundert ms, Übertragen noch deutlich länger.
        Auffällig ist die dynamische Generierung aller CSS und JS Dateien. Normalerweise sollten die für alle Nutzer gleich sein (bis auf ein paar Tokens, die man auslagern könnte) und somit bietet es sich an, dafür auch ein CDN zu nehmen.

  4. SammysHP sagt:

    „Aktuell sieht es also nach einem Routingproblem aus, möglicherweise im Netz der Dt. Telekom“

    Nein, soweit würde ich (jetzt noch) nicht gehen, da ja auch andere Provider betroffen sein sollen. Das Peering der Deutschen Telekom ist aber wirklich mies, stelle ich immer wieder fest (vor allem bei YouTube).
    QoS ist auch ein Problem, denn eigentlich sollte das Internet neutral sein. Mit den immer größer werdenden Datenmengen ist die Kapazität an vielen Stellen aber ausgeschöpft und die Anbieter versuchen an leichtes Geld zu kommen.

    Packet loss ist natürlich auch ein Grund für einen schnellen Verbindungsaufbau, aber eine geringe Datenübertragung (vgl. congestion control, slow start), daran hatte ich oben nicht gedacht und es ehrlich gesagt auch nicht in dem Abschnitt erwartet.

    Mir stehen mehrere Routen über den Atlantik zur Verfügung und ich werde beobachten, ob es nur auf einer davon Probleme gibt.

  5. Christian sagt:

    Hallo Webmicha,

    das Problem konnte ich bei mir auch immer wieder feststellen.
    Über meinen VPN nach Rumänien, Israel, Schweiz, Holland, USA und Kanada konnte ich das Problem nicht mehr nachstellen.
    Scheint wirklich ein Netzproblem zu sein.

  6. SammysHP sagt:

    So, gerade dauert das Laden einer Seite wieder rund zwei Minuten. Bottleneck ist auf den ersten Blick die Atlantikverbindung von NTT.

    Packetloss beim Ping habe ich keinen und Wireshark wollte ich nicht extra starten. Meine Route über Cogent ist normal schnell, über NTT dauert es ewig. Wenn ich allerdings eine Route über NTT innerhalb der USA nehme, ist es auch schnell.

    Also entweder Atlantik-NTT oder das Peering zwischen der Telekom und NTT.

  7. Christian sagt:

    NTT wurde auch vom Groundspeak ITler als wahrscheinliche Problemquelle genannt, zusammen mit einem weiteren Backboneprovider, wenn ich mich jetzt recht entsinne. Und dann auch noch mal kurz zu den Providern… Ja, da stehen zwar mehr als nur die Telekom, aber zumindest welche davon (1&1) sind nur Telekom-Reseller. Ich habe Vodafone und keinerlei Probleme und bei den wenigen Vodafone-Kunden MIT Problemen kann es immer noch die Telekom sein, über deren Netz teils geroutet wird mangels eigener Leitungen von Vodafone.

    Ping ist witzigerweise selbst dann noch im üblichen Bereich, wenn bei jemandem Probleme auftreten, allerdings geht dann wohl der Packet loss schwer in die Höhe. Und ja, Groundspeak tut, was sie können und haben ihren Provider in die Ursachenforschung mit eingebunden.

    Und irgendwelche Performanceprobleme bei deren Servern würde ich schon aus dem Grund ausschließen, daß die Leute mit Problemen schlicht und ergreifend absolut gesehen einfach eine deutliche Minderheit sind.

    Ansonsten würde ich einfach mal davon ausgehen, daß das Problem in den nächsten Tagen gefunden wird, aber dazu muß es eben auch erst wieder auftreten, so doof das ist! Immerhin sind die Amis ja um die Zeit wach und können das Ganze somit also grundsätzlich live nachverfolgen!

    • webmicha sagt:

      Die Zeiten als 1&1 ein Reseller der Telekom war, sind schon lange vorbei. 1&1 bietet komplett eigene Produkte und Tarife an und kauft dafür Vorleistungen bei verschiedenen Telcos und ISPs ein. Die Telekom ist einer der Vorleistungserbringer. Die meisten 1&1 Kunden können mit eigenen Netzwerkleistungen versorgt werden, diese haben auch ein völlig anderes Routing als zB die Telekom, denn 1&1 betreibt eigene Backbone-Netze und ist u.a. am DE-CIX angeschlossen.

  8. cabiman sagt:

    Klasse Artikel und gut zu wissen, dass man nicht allein ist oder unter Halluzinationen leidet.
    Ich habe einfach mal die Google DNS Server in den DNS-Einstellungen eingetragen und sofort wurde gc.com sowohl in Firefox (was die letzten Tage eine Qual war) als auch Safari (hat gc.com gar nicht mehr angezeigt) sofort angezeigt. Bisher dürfte die automatische Einstellung des Routers genommen worden sein, was dann wohl die Telekom-DNS Server wären.

    Egal, es tut jetzt – Vielen Dank für den Hinweis

  9. TS sagt:

    Google DNS Server brachte bei mir keine Verbesserung.
    Das Problem der langen Zugriffszeiten tritt bei mir ca. ab 18:00 Uhr auf.

  1. 23. Januar 2015

    […] zu werden. Woran liegt das? Der Webmicha hat recherchiert und die Theorien plausibel dargestellt. Hier geht es zum umfangreichen Artikel von […]

  2. 23. Januar 2015

    […] zum Teil immer noch. So wie es mittlerweile aussieht, handelt es sich um ein Netzwerkproblem (wir berichteten) das hauptsächlich Nutzer in Mitteleuropa betrifft und in Deutschland vor allem Kunden mit einem […]

  3. 25. Januar 2015

    […] der Daten durchführen. In diesem Zusammenhang habe ich auf geocachingbw.de einen Interessanten Beitrag zu den Zugriffsproblemen […]

  4. 23. März 2017

    […] Ich hab da mal nen Blogartikel zu geschrieben […]