Ein Leser hat mich auf ein Problem beim Provider Vodafone hingewiesen. Beim Routing zu Vodafone-Internet-Anschlüssen scheint es Paketverluste zu geben, weil die Vodafone DNS-Server aus dem Vodafone-Netz nicht zuverlässig erreichbar sind. Das Problem wurde vom Leser bei Tests eines Kundensystems gefunden. Ich greife mal die Beschreibung in einem Blog-Beitrag auf. Vielleicht gibt es ja noch mehr Betroffene, denen das weiterhilft.
Anzeige
Hinweis eines Lesers auf Vodafone DNS-Probleme
Blog-Leser Hendrik W. hatte sich kürzlich bei mir auf Facebook in einer privaten Nachricht gemeldet und über DNS-Probleme bei Internet-Anbieter Vodafone berichtet. Auf meine Nachfrage hat er dann noch einige Details per E-Mail nachgereicht. Ich bereite die Erkenntnisse nachfolgend auf.
Szenario eines Kunden
Der Leser hat als IT-Dienstleister einen Kunden, der mehrere WAN-Anschlüsse an 3 Standorten betreibt. Als Internetanbieter kommen dort die Deutsche Telekom und Vodafone mit einem Kabelanschluss zum Einsatz. An den drei Standorten gibt es jeweils zwei WAN Anschlüsse, einen davon bei Vodafone Kabel.
Neue Firewall im Lab vorbereitet
Für den Kunden wurde nun eine neue Firewall eingerichtet und ein Gateway Online-Monitoring aufgesetzt. Damit Firewalls "plug&play" beim Kunden laufen, hat man beim IT-Dienstleister jeweils eine entsprechende Lab-Umgebung eingerichtet, wo mit den echten IPv4 -Adressen Tunnels usw. getestet werden können. Die Verbindungen dürfen dann halt nur nicht "rein & raus" ins echte Internet schrieb der Leser.
Beim IT-Dienstleister war im Lab als Gateway Monitoring IP der Vodafone Anschlüsse die IP-Adresse 81.210.129.4 eingetragen. Dies ist die IP-Adresse eines DNS-Servers, den der Kunde standardmäßig an seinem Anschluss zugewiesen bekam. Das Lab des Dienstleisters hängt nach außen an einem Telekom Glasfaser Anschluss – und alles funktionierte in der Testumgebung prima.
Anzeige
Probleme mit Ping auf Vodafone DNS-Server beim Kunden
Die Probleme finden an, als die Konfiguration der neuen Firewall beim Kunden in Betrieb ging. Es lief laut Aussage des Blog-Lesers "eine Woche", und dann gab es Probleme. Es kam zu Verbindungsabbrüchen, der WAN-Anschluss schaltete auf das Tier 2-Fallback, Telekom.
Die Paketverluste beim Monitoring wurden mit 15-25% ausgewiesen. Mal funktionierte der Anschluss (es wurde auf Tier 1 umgeschaltet), und die dynamische Route suchte sich wieder den Weg über das Vodafone-Netz zu deren DNS-Server. Dann gab es wieder Paketverluste, es kam zum State-Kill und zum Tunnelwechsel in der Firewall.
Ein Arbeiten war nicht möglich. Sobald das Vodafone WAN beim Kunden deaktiviert wurde, lief die Firewall problemlos. Aber das ist dann ein Betrieb ohne Fallback auf Vodafone, falls die Telekom-Anschlüsse ausfallen, und umgekehrt.
Vodafone NS-Server im Vodafone-Netz nicht pingbar
Schnelle Erkenntnis: Die eigenen DNS-Server von Vodafone sind aus dem Vodafone eigenen Netz nicht ohne Paketverlust pingbar. Von extern sind Pings auf die DNS-Server von Vodafone kein Problem.
Das führte dann letztendlich dazu, dass das dynamische Routing permanent nicht mehr wusste, wohin es Pakete senden soll. Bei rund 20-30% Paketverlust wurde das Gateway richtigerweise als offline eingestuft. Ein wichtiger Punkt, den der Leser erwähnte, ist, dass der Vodafone DNS-Server nie zur Namensauflösung der URLs verwendet wurde, sondern rein für den Trigger, ob der Anschluss online ist.
Ursachenforschung: Der lange Weg bis zur Erkenntnis
Was in obigem Abriss recht kurz zur Ursache führt, bedeutete in der Praxis eine länger Ursachenforschung und unendlich vielen Tickets bei Vodafone, einem Wechsel von Verstärkern und Modems und viel Zeit zum Testen.
Der Leser schrieb, dass es "an einem Anschluss es schon immer Probleme mit dem Vodafone-Kabelanschluss gab. Alle Firmenstandorte des Kunden erzeugten an diesem WAN-Anschluss nicht korrigierbare Fehler im 10k Bereich pro Sekunde.
Es wurde ein Störungsticket bei Vodafone aufgemacht. Der Techniker von Vodafone kam vor Ort, prüfte, sprach "von überlasteter Leitung" und verschwand. Dann kam die Nachricht, dass das Ticket geschlossen wäre, da die Überlastung nicht mehr vorhanden seien.
Aber die Fehler in dem Vodafone-Kabelmodems blieben unverändert bestehen. Es wurde ein neues Störungsticket bei Vodafone eingereicht. Dann wurden die Verstärker getauscht und neu eingepegelt, sowie ein neues Kabelmodem getestet. Das half alles nichts, die Fehler blieben, so der Leser.
Grenzwerte digital (DVB-C und HSI/Phone) in BK-Netzen (Vodafone)
Die Werte des Kabelmodems sahen für den Leser alle nicht berauschend aus, ein entsprechendes Dokument (siehe obiges Bild) aus dem Vodafone Kabelforum kommentierte ein Techniker mit den Worten "die Werte sind veraltet". Vodafone beharrte darauf dass der Internetanschluss per Kabel nun funktionierte.
Das war der Punkt, an dem der Leser ins Grübeln geriet. Er war der Meinung, dass es Sinn mache, ein Monitoring auf Provider-Server zu machen. Denn es hilft nicht, wenn "bei einem anderen Provider etwas ausfällt, obwohl der Anschluss eigentlich funktional ist".
Ein Beitrag im Vodafone-Forum
Dann fand der Leser den Beitrag Vodafone DNS Server (ns1.vodafone-ip.de usw) sind nicht aus dem Vodafone Kabelnetz erreichbar, bei dem ein Puzzleteils ins Bild fiel und alles erklärte. Auch auf Computer Base gibt es einen solchen Foreneintrag, der auf Probleme hinweist.
Der Verdacht: "Vielleicht sind ja tatsächlich nur vom Vodafone eigenen Netz die Server manchmal nicht erreichbar, obwohl deren Erreichbarkeit von extern aber konstant gegeben ist? Dass in obigem Forenbeitrag ein anderer Vodafone DNS-Server genannt wird, macht den Sachverhalt ja auch nicht besser.
Also hat der Leser die WAN-Verbindung zu Vodafone wieder aktiviert. Es gab wieder Paketverluste. Ein gleichzeitiger Ping aus dem Telekom-Netz zum Vodafone DNS-Server zeigte, dass dieser problemlos und durchgehend erreichbar war.
Anderer DNS-Server zu Monitoring hilft
Der Leser schrieb dann: "Heute arbeiten die Standorte problemlos, die Anschlüsse funktionieren wie gewünscht, auch wenn noch massive nicht korrigierbare Fehler das Kabel-Modem log fluten, so ein 256QAM Kanal 16 zum Beispiel." Die Lösung: Es wird zum Monitoring nun ein anderer DNS-Server verwendet, so dass die Firewall vernünftig routen kann und die WAN-Anschlüsse nicht als "offline" einstuft.
Wie schreibt der Leser: "Zusammenfassend lässt sich sagen, dass der Service für Business Kunden bei Vodafone noch unterirdischer geworden ist, als es damals unter Unitymedia der Fall war. Man hat außerhalb des regulären Ticketsystems schlicht kaum Möglichkeiten [zur Klärung von Problemen]."
An dieser Stelle mein Dank an den Blog-Leser für die Informationen. Vielleicht hilft das dem ein oder anderen Administrator oder IT-Dienstleister weiter, der sich an den internen DNS-Server von Vodafone die Zähne ausbeißt. Der Leser meinte: "Ich bin sehr gespannt auf das Feedback in deinem Blog!" Noch jemand, der solche Erkenntnisse gewonnen hat?
Anzeige
Moin,
für mich bekannt, hatte dieses nette Spiel bei einem meiner Kunden "LANCOM FW mit FAILOVER" Thema PING/DNS und Erreichbarkeit,
und das schon vor Jahren.
Da habe ich alle Vodafone DNS-Server an den letzten Platz durchgeschoben oder gestrichen :o)
Da kannst du lieber die Eigene Vodafone Client IP anpingen, kommst besser bei weg bei dem Laden *Lach*
Nimmst halt einen anderen Leuchtturm im Netz.
A Netz 500/50 Leitung Vodafone, B 25/5 Leitung EWE/Osnatel. (Telefonnetz-Notleitung)
Ewe/Osnanet in 15Jahre, mehr stündige Provider Ausfall, das war es auch schon an Problemen.
Vodafone: ohne Ende irgendwelche Probleme und Themen und selten Lösung oft nur Kompromisse oder ausreden.
DS_LITE/DUAL-STACK/FESTE IP, Leistungsschwankung in der Leitung wegen "zu vielen User die irgendwie irgendwas zu viel gleichzeitig benutzen", kaputte Server/Hardware, Routing, DNS, PING, PORTS, schlechte Kabel usw.
Total Überlastet der Laden. Da gibts leider so viele Negative Dinge, ob Business oder Endverbraucher.
Als Trost * den Support bei anderen Providern kannst du genau so vergessen.
Die Zeiten, wo du zum Telekomladen mit Ortstechnikern gehen kannst, sind bedauerlicherweise lange vorbei.
Wenn du als Admin oder einfacher User keine Vitamine hast, bei dem entsprechenden Provider, bekommst du auch keine guten Informationen bzw. Techniker/ADMINS ran.
Die meisten Supporter lesen nur vom Bildschirm ab, geben dir standardisierte Phrasen raus und oder schieben den Kram so lange umher, bis einer das Ticket dichtmacht, weil es gut aussieht und Feierabend ist. *Überforderung und oft kein technisches Vorstellungsvermögen.
Wieso muss ich gerade an" Asterix & Obelix Mission Kleopatra und Vodafonis" Denken :o)
Vodafone DNS verwendet man eh nicht allein wegen Zensur.
Einfach in Fritzbox Google, Cloudflare oder so als DoT rein und gut ist. :-)
Mache ich in der FB auch immer so, nur sicher sein, dass der dort eingestellte DNS Server auch durchgängig erreichbar ist und verwendet wird, kann man sich in diesen Zeiten leider nicht. Dazu lassen sich DNS Anfragen auf der Transport-Ebene zu leicht auf den Provider-eigenen DNS umleiten. Meines Wissens wurde das von einzelnen Provideren wenigstens temporär bereits so gemacht. Und wenn ich mir die aktuellen Bestrebungen in der EU so ansehe, befürchte ich, dass das permanter Standard werden könnte oder sogar per Order werden muss.
Die Frage ist, welches Land oder welche EU-Länder sind da die eigentlichen Treiber dahinter. Und gerade Deutschland hat da mit den schlechtesten Ruf.
Die miese Vodafone-DNS-Erreichbarkeit kann und muß ich leider bestätigen. Das ist allerdings kein neues Problem, sondern besteht seit JAHREN.
Vodafone ist technisch außerstande diese Fehlkonfiguration zu beheben. Die haben sich mit ihren vielen Aufkäufen hoffnungslos überfordert. Ähnlich toll ist das Zusammenlegen der Kundenzentren zwischen Kabel/DSL und den einzelnen Bundesländern verlaufen. -.-
Das größte Problem besteht meines Erachtens darin, daß viele Neukunden daran verzweifeln, ihren eigenen Router nicht aktivieren zu können, weil die Vodafone DNS wieder mal streiken.
Dann bedarf es einer Recherche, die entsprechenden IP-Adressen zu ermitteln und bei einem Client in der Hosts zu hinterlegen (weil, Router ist dann ja noch nicht so weit, um alternative DNS zu schlucken).
Was ich nicht verstehe. Warum wird als Gateway Monitoring IP der DNS eines ISPs hinterlegt? Das sollte immer ein Rechner unter eigener Kontrolle sein, idealerweise die IPs des Hauptsitzes. Einen fremden Server, hier der eines ISPs, der vermutlich Alive-Pings irgendwann wegfiltert oder wo die Verfügbarkeit unklar ist als Trigger für das eigene Failover zu hinterlegen erscheint mir nicht gerade helle.
Der Rest zum Kundenservice Unitymedia/Vodafone ist ebenfalls bekannt. Unitymedia war dabei um welten besser als Vodafone…
Es geht tatsächlich noch schlimmer, als bei Vodafone. Man mag es kaum glauben. :-D
https://de.trustpilot.com/review/www.swn.net
Kann ich nur bestätigen. Bezieht sich bei denen auf wirklich alles: Internet, Hin- und Wech-Betrieb, Linienverkehr der Busse, Energieversorgung.
@Thomas Jakobs
Ein ISP der seine Pings nur aus dem internen Netz, nicht aber von extern blockt? Aha.
Einen „Standort" zu pingen ist ja genau so ein Unsinn.
Ich will ja wissen ob der Anschluss zum Providernetz funktioniert- und nicht mehr.
Die Gateways der VTI „regeln" den Rest.
Vodafone hat ein massives internes Routingproblem….
Und der DNS wird hier nicht zur Auflösung genommen sondern als Trigger.
1. ICMP Ping || DNS
2. Wenn Du Failover für Dein VPN machst, willst Du einzig und allein wissen, ob Deine Gegenstelle in der Firmenzentrale erreichbar ist oder nicht. Da brauchst Du keinen externen Host, der noch nicht mal von Dir kommt.
> Ich will ja wissen ob der Anschluss zum Providernetz funktioniert- und nicht mehr.
Was Dir genau nichts bringt und nicht die Aufgabenstellung ist. Du willst VPN zur Firma.
> Die Gateways der VTI „regeln" den Rest.
Offensichtlich in diesem Falle wohl nicht…
> Vodafone hat ein massives internes Routingproblem….
Was zu beweisen wäre… wenn ein offenbar mittelprächtiges Systemhaus ein VPN Failover nicht hinbekommt, ein wenig brauchbares Beispiel um Vodafone (bei aller Abneigung meinerseits) an den Karren zu pinkeln und zu Behaupten deren Routing sei kaputt..
Na, die weiterführenden Links nicht mal gelesen? …
Da werkelt übrigens kein 0815 failover was dein Lancom auch kann- da geht es um so Dinge wie dynamische Routen…
Vielleicht erst mal alles verstehen worum es hier geht, bevor man so einen Unsinn vorschlägt.
Lass gut sein.. Ich nutze by the way kein Spielzeug…
nicht von Dir auf andere schliessen…
Naja… Spielzeug.
Hersteller, die Gateways mit icmp monitoren:
– Sophos
– Checkpoint
– Fortigate
– pfSense
– OPNsense
…
Sicher können die weniger als die Klitsche aus Dortmund.
Schreibst Du nicht selber in Deinem Blog:
"Resilienz
Ohne ein paar Worte zur Resilienz21 geht es nicht. Mir begegnen leider immer Netzwerke, wo von einem internen Host aus die komplette IT Infrastruktur überwacht wird. Kann man machen, nur schafft das unnötige und selbstgemachte Probleme. Kommen die typischen "Single Points of Failure"22 in Gestalt zentraler Mailserver, Firewalls oder Switches noch hinzu, sollte gehandelt werden."
Und dann schlägst Du hier ne VM als Monitoring beim 2,99€ Provider vor. Zugegeben, das überzeugt mich. Ist ja kein single point of fail…..
Bin auch Vodafone-Kunde und nutze die DNS-Server von Vodafone auch nicht. Diese Server waren öfters mal defekt und unterliegen der Zentur (CUII). DNS läuft bei mir über Pi.Hole & unbound ohne Probleme.
Der DNS wurde ja gar nicht zur Auflösung genommen- sondern als Trigger..
Es sind DNS Server keine ICMP Server.
Sind icmp Server sowas wie tcp oder udp Server?
So ist es! Wenn man einen DNS-Resolver zum Überwachen vom Internetanschluß nehmen möchte, dann sollte dies auch per DNS-Anfragen erfolgen. ICMP Echo könnte z.B. blockiert oder rate-limited sein. Und speziell bei Vodafone machen die DNS-Resolver schon lange immer wieder Probleme.
Dann zeig mir mal eine Firewall die loss, rtt usw via DNS Abfragen generiert…
Die meisten werden dpinger nehmen.
Bei Vodafone antworten aber die ersten hops gar nicht.. da ist es ja schon verlockend einen anderen Server vom Provider zu nehmen..
Wenn eine Firewall nur ICMP Echo kann, braucht es halt eine entsprechende Gegenseite. Und ein DNS-Resolver ist dafür eher weniger geeignet, da die ICMP Echo Requests Ressourcen verbrauchen, die bei der DNS-Auflösung dann fehlen. Es gibt Provider/ISPs, die ihre DNS-Resolver voll auslasten, weile jede zusätzliche Kiste höhere Kosten bedeutet. Darunter leidet natürlich auch die DNS-Performance.
Für das Abschalten von ICMP Echo (und auch anderen ICMP-Typen) auf Routern gibt es mehrere Gründe. Macht nicht nur Vodafone so. Ist aber leider blöd bei einer Fehlersuche.
Vodafone macht das ja gar nicht. Nur intern und nur sporadisch. Auch auf Hops! Siehe Links in Günters Beitrag….
und dann geht es von extern, aber intern nicht? Die Frage ist eher, was für ein Routing Problem hat Vodafone…
Ohne Kenntnis des Netzaufbaus kann man nicht automatisch auf ein Routingproblem schliessen. Es können z.B. überlastete DNS-Resolver oder überlastete Leitungen zwischen Backbone und Access-Router sein. Dazu kommt, dass DNS-Resolver und andere wichtige Dienste oft als Anycast laufen, d.h. viele Kisten mit der gleichen IP-Adresse für den Dienst (keine Ahnung ob das bei Vodafone der Fall ist).
Den Fehler habe ich auch gehabt. Habe bereits vor Jahren einen alternativen DNS in der Fritzbox eingetragen. Seitdem ist Ruhe… vorher regelmäßig Probleme gehabt.
Ich bin ebenfalls Vodafone-Kunde (mangels Alternative hier im Dorf) und betreue mehrere Kunden mit Vodafone-Anschluss. Das DNS-Problem ist altbekannt und tritt manchmal sehr deutlich hervor, wenn dann plötzlich zeitweise bestimmte Domänen nicht mehr erreichbar sind (häufig .com, manchmal aber auch .de, etc.).
Und wie viele meiner Vorredner hier: der Service ist von schlecht auf ultraschlecht gesunken. Die externen Firmen, die mit dem Service betraut sind, zucken nur noch mit den Schultern, wenn etwas von den technischen Problemen angesprochen wird: "da können wir nix machen, wenden Sie sich direkt an Vodafone" – und wo das dann landet kann sich jeder ausmalen…
Schlechte DNS-Performance gab es auch schon zu Arcor-Zeiten. Da hat sich nichts geändert. :( Die DTAG hatte in der Vergangenheit ebenfalls DNS-Probleme; hat aber vor einigen Jahren die Situation verbessert. Als Lösung bieten sich öffentliche DNS-Resolver, z.B. 1.1.1.1, oder lokale im eigenen Netz an.
Technischer Hinweis: vgwort wird im Absatz "Hinweis eines Lesers auf Vodafone DNS-Probleme" per http eingebunden und erzeugt dadruch z.B. im Firefox Browser einen "Verbindung nicht sicher" Hinweis beim Symbol neben der URL-Zeile.
Danke, ist korrigiert.
Als ob dieses Problem immer noch besteht?! Während der Pandemie hatte ich das gleiche Problem mit meinem Vodafone-Kabelinternet, welches ich durch einen anderen DNS-Server größtenteils beheben konnte. Bin ehrlich gesagt schockiert, dass sich diesbezüglich in über vier Jahren NICHTS getan hat. Aber hauptsache Preise erhöhen!
Wir haben einen VF Glasfaser Anschluss und ein Backup WLL (leider auch VF) in unserer Firma.
Vor drei Jahren etwa vier Tage vor Silvester war dann morgens ab ca. 10 Uhr ploetzlich gar kein Internet mehr da. VF Support angerufen, Ticket aufgemacht, unendlich oft mit dem GK Support telefoniert. Ticket eskaliert. Natuerlich waren alle VF APs im Weihnachtsurlaub und nicht erreichbar.
Irgendwann dann am zweiten Tag der Stoerung kam gegen 18 Uhr ein VF Techniker an. Meinem Eindruck nach absolut besoffen, war er nicht einmal in der Lage seienn Diagnose Laptop an den Router anzuschliessen und etwas auszulesen.
Nach weiteren zwei Tagen ohne Internet in der Firma und unzaehligen weiteren Telefonaten mit VF, ging unser Glasfaser dann auf einmal mitten im Gespraech mit der Hotline auf einmal wieder. Ursache?
Ein Techniker bei VF hat unsere Konfiguration auf irgend einem Backendsystem vollstaendig geloescht. Und VF hat es einfach vier Tage lang nicht geprueft und festgestellt.
Mein Fazit nach all den Jahren: nie wieder Vodafone.
Das Voadfone-Routingproblem ist so alt wie ein bekannter Weinbrand.
Einmal von der technischen Diskussion abgesehen stellt sich mir die Frage, warum einen Provider nehmen der für a. die Fehler und Probleme bekannt ist und b. noch bekannter dafür ist, diese in seltesten Fällen adäquat zu beheben. Ihr geht doch auch nicht immer und immer wieder zum gleichen Bäcker der Euch schimmliges Brot verkauft – oder etwa doch?
Grüße
Hilft einem Dienstleister aber nichts – wenn der Kunde nun mal diese WAN-Infrastruktur hat – imho …
es sei daran erinnert dass DNS erstmal mit UDP läuft.
Einen Paket Verlust bemerkt man nur durch time Out.
es kommt wohl doch öfters vor das das vergessen wird. ICMP Echo wird gerne Mal gesperrt, weil man damit Firewalls umgehen kann..
in sofern ist eine Ping kein Mittel um fest zustellen ob man online l ist. Microsoft hat zu diesem Zwecke Server laufen um die Connect ed Meldung geben zu können
Gedanke 1: Eventuell sind die problematischen DNS-Server im 'echten' VF-Netz und nicht im zugekauften Kabelnetz. Ist die Verbindung zwischen beiden nicht so prall gibt es da eventuell Paket losses…
Gedanke 2: Um die Verfügbarkeit der Leitung zu testen, durch das ganze Netz pingen? Interessant ist doch, ist die Leitung off oder on? Also pinge ich den Gateway auf Providerseite, nur so prüfe ich explizit die Leitung (und noch den Gateway, aber dessen Ausfall ist ja effektiv ein Leitungsausfall).
Genau so! Das Standard Gateway ist aber bei VF noch meist die zugewiesene IP -1, somit z.B. das Kabelmodem was noch bei dir ist. Der Nächste Hop blockt dann schon icmp.
Aber grundsätzlich macht man das so wie beschrieben..
Der Paketverlust ist ja nicht nur auf die DNS, sondern auf das halbe VF Netz beschränkt- manchmal geht es auch- und z.B. von extern immer. Wo bleiben die Pakete in deren Netz? Das ist ja die Kernaussage, die haben ihr eigenes Netz nicht im Griff… dabei egal ob DNS oder interne Hops.
Ich bin etwas erstaunt darüber, dass man ein System zweckentfremdet und sich dann darüber beschwert, dass es nicht geht. Es ist ja schon seit Jahren so, dass ich mich darauf verlassen kann, dass alle Systeme auf dem Weg brauchbare Diagnosehinweise liefern. Sei es ping oder traceroute. Wenn ich das also unbedingt will und damit Geld verdiene würde ich mir bei irgendeinem VM Anbieter die kleinste Kiste holen (1€ mtl. 1core/1gb ram) und diese anpingen oder was auch immer ihr als Test nehmen wollt. Das ist dann eure Kiste, euer Traffic und es gibt einen Ansprechpartner.
Schlichtweg Unsinn. Ich will beim Gateway Monitor eigentlich gar nicht ins Internet. Ich will wissen ob die ISP Verbindung steht.
Dankeschön für den wertvollen Kommentar. Wozu genau brauche ich eine Verbindung zum ISP wenn's danach nicht weitergeht?
Aber noch mal ein Versuch. Gibt es eine RFC dass ein DNS Server auf Pings antworten muss? Nein? Hat VF – abgesehen von allen Fehlleistungen – versprochen dass man den DNS pingen kann? Nein?
Also was soll die Diskussion? Es ist euer Problem und ihr müsst dafür eine Lösung finden, nicht VF.
Ihr kennt jetzt daa Problem und die Lösung ist trivial, aber es wird rumgefenzt…
Die Antwort ist einfach, weil ein schnelleres Tier ggf eine höhere Prio hat. Ganz einfach. Hier geht es doch darum warum aus dem interenen Netz Server sporadisch (!) nicht anworten, interne Anfragen (!) nicht konform auflösen. Hier geht es nicht darum bei "irgendeinem" VM Anbieter was zu bestellen, dessen Route im Zweifel noch unzuverlässiger läuft.
Lies mal die verlinkten Kommentare, damit Du das "dahinter" verstehst.
Und Du prüfts die Schnelligkeit mit ICMP Pings?!?!
Auf einen ISP internen Host?!?!
Einem DNS?!?!
Bravo!
Sag bitte nicht, dass Du andere auch so vernetzt?
Schnelligkeit? Du verstehst es wirklich nicht. Es geht um Leitungkapazität. Normalerweise prüft dann beim Gateway Monitorring auch tatsächlich das Gateway. Design technisch hast du aber bei Vodafone das Gateway bei dir im Haus. Somit ist es nutzlos.
Dann gehst du also beim Provider immer so weit, bis irgendwann jemand antwortet. Die Tunnels haben völlig autarke Gateways, die auch gemonitored werden. Das sagt aber nicht aus, ob er dein Wan Anschluss direkt weg hängt. Es ist sogar sehr wahrscheinlich, dass wenn ich den nächsten Provider Hop nicht erreiche, mein Internet auch nicht geht. Ich kann damit aber zum Beispiel eine Route zu der von dir genannten VM ausschließen. So schwer ist das doch gar nicht zu verstehen, oder?