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.
Ich empfehle eher Quad9. Keine Zensur, Sicherheitslisten (gibt auch ohne) und kein Logging. Sind auch zuverlässig und sowohl über DTAG als auch VF Anschlüsse zuverlässig erreichbar. Und seit DoT/DoH sowieso einfacher, auch am Android oder im Browser.
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…..
Oh Boy, lass gut sein…
Nachdem Dir schon mehrere weiter unten versucht haben darzulegen, dass Du neben der Sache liegt, belassen wir es dabei.
Einen schönen Abend…
Ja, die ganzen Hersteller irren.
Nur du weißt es.
Warst du nicht längst raus??
Auch für dich noch mal:
„By default the gateway monitoring daemon will ping the gateway IP address. This is not always desirable, especially in the case where the gateway IP address is local, such as on a cable modem or fiber CPE. In those cases it makes more sense to ping something farther upstream, such as an ISP DNS server or a server on the Internet."
https://docs.netgate.com/pfsense/en/latest/routing/gateway-configure.html
Aber nur mal als Ansatz, ob man sich hier nicht etwas verrannt hat.
Du meintest ja auch schon von Anfang an die Anforderungen zu kennen. Glaube ich eher nicht.
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….
Rate-Limiting?
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).
Du meinst ernsthaft dass hinter einer(!) IP hier genau was steckt- was intern sporadisch nicht erreichbar ist, extern aber gleichzeitig schon?
Dass ganze Hops extern erreichbar sind, aber intern nicht mal antworten?
Aha.
Schaue dir mal Anycast an! Damit kann man viele Kisten geografisch verteilt unter der gleichen IP-Adresse erreichen. Durch dynamisches Routing erreicht man dann immer die netzseitig nächste Kiste. Fällt die aus, dann wiederum die nächste. Wird z.B. auch oft bei den Root-Nameservern gemacht. Je nachdem wo du am Netz hängst, bekommst du eine andere Kiste unter der gleichen Adresse.
Hast du die verlinkten Artikel/ Foren gelesen?
Zeitweise fühlt sich der ns von Vodafone für sich selbst nicht authoritive..
Und das liegt dann am anycast, weil es geht wie es soll? Aha.
Klingt auch logisch. Und so funktional.
Das klingt wie eine BGP Route zum Prinz aus Zamunda…
Der georedundanz Vodafones von unitymedia übernommenen..
Wenn der Nameserver für eine Domain, die auf dem Nameserver liegt, non-authoritive zurückgibt, dann ist er doch erreichbar. Reden wir jetzt von Nameservern oder Resolvern? Dass diese erreichbar sind oder nicht? Oder dass die Resolver von den VF-Nameservern keine Antwort bekommen?
Siehe oben.
Hier sind fast alle nicht in der Lage das Grundproblem zu verstehen, weil sie zu faul sind die 2 Links vollständig zu lesen.
Dafür haben aber alle ganz schön viel Meinung.
Hier bin ich jetzt mal raus.
Werden hier zwei Probleme vermischt? Dieser Blogpost berichtet von Paketverlusten bei pings auf einen Resolver. In den verlinkten Forenbeiträgen geht es um die Erreichbarkeit von ns1/2/3.vodafone-ip.de. Manche Kunden können diese gar nicht erreichen. Beides passiert nur innerhalb des Vodafone-Netzes.
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.
???
Was spricht gegen einen vollständigen Funktionstest.
Eine stehe ISP Verbindung bedeutet ja noch nicht das die Anbindung nutzbar ist.
Umgekehrt denken.
Ist dein Gateway nicht erreichbar bist du offline. Und zwar sicher.
Ja, aber was bringt dir das Wissen? Du willst doch nicht wissen ob du Offline bist, sondern du willst wissen ob du Online bist. Und nicht in der Form, dass du irgendwas im ISP Backbone erreichst, sondern dass der Kunde (um den geht es doch letztlich??) die Leitung für irgendwelche wahrscheinlich nicht 100% definierte Endpunkte nutzen kann.
Das heißt, der einzig sinnvolle Test den man hier zur Link Überwachnung durchführen sollte ist eine (oder mehrere) Gegenstellen hinter! dem ISP Netz zu testen. Sind diese erreichbar, ist alles gut. Sind sie es nicht, switcht der WAN Link auf den zweiten ISP.
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?
Ich finde es als Fehler, die Infrastruktur von VF zu Monitoren. Sie kann sich und wird sich laufend ändern, und sichert auch nicht die Eigenschaften zu die hier gefordert sind.
Und Internet zu Monitoren ist schwer, weil das aus verflucht vielen Gegenstelle besteht.
Dass DNS instabil ist, was auch immer das bedeutet.. niemand zwingt einen den Provider DNS zu verwenden. Jedes Linux jeder Windows Server bringt einen recursive Resolver mit.
Also ich stolpere immer noch über diese Abschnitte: Schnelle Erkenntnis: Die eigenen DNS-Server von Vodafone sind aus dem Vodafone eigenen Netz nicht ohne Paketverlust pingbar.
UND
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.
NOCHMALS die Frage wo garantiert VF das diese Hosts pingbar sein müssen? Oder gibt es dazu eine RFC?
Du hast ein System unter falschen Annahmen gebaut und gibst nun VF die Schuld. VF will ich hier gar nicht verteidigen, sondern dich auf deinen Irrtum hinweisen. Sie können auf deinen Ping antworten oder es lassen, wenn das System mit seiner eigentlichen Aufgabe ausgelastet ist! Best effort – ping ist nicht die Hauptaufgabe eines DNS Servers.
Ich mach's mal kurz zum nachlesen für dich..
„By default the gateway monitoring daemon will ping the gateway IP address. This is not always desirable, especially in the case where the gateway IP address is local, such as on a cable modem or fiber CPE. In those cases it makes more sense to ping something farther upstream, such as an ISP DNS server or a server on the Internet."
https://docs.netgate.com/pfsense/en/latest/routing/gateway-configure.html
Sind aber auch Ottos, all diese Firewallfirmen…
Keiner weiß es besser als Reimar u Tomas..
Offenbar kaputtes Produkt.
Diese "Ottos" schreiben aber nicht, nimm den DNS Server des ISP.
Du zitierst es selbst: "In those cases it makes more sense to ping something farther upstream, such as an ISP DNS server or a server on the Internet."
Da steht unmissverständlich "it makes more sense" -> das ist also eine Sinnhaftigkeitsabwägung. Und da steht ebenso, "or a server on the Internet".
Warum so so beharrlich auf dem DNS Resolver von Vodafone herumreitest, ist hier völlig unverständlich.
Um es mal ganz simpel zu sagen. Wenn es nicht "wünschenswert" ist, den DNS Server des Providers zu pingen, dann nimm halt einen anderen wo das Ergebnis konsistent ist. Und ja, um so "weiter" weg das von deinem Anschluss steht, desto höher die Gefahr, dass externe Einflüsse die Tests beeinflussen. ABER und das ist der springende Punkt. Der Endkunde will nicht DNS Anfragen im Vodafone Netz rumschicken, gehe ich mal davon aus, sondern er will das Internet nutzen. In welcher Form auch immer. HTTP/HTTPS zu diversesten Zielen. Vielleicht IPSec oder SSL VPN oder was auch immer usw. Das sollte dann auch die Basis für den Uplink Test sein.
Übrigens noch ein Hinweis, die Textpassage kann sich auch ganz einfach an Kunden richten, die im selben ISP Netz Redundanzen über mehrere WAN Links unterhalten. Dann ergibt es natürlich mehr Sinn. Du willst aber dem Text nach Vodafone und Telekom paaren. Also sollte man da auch technisch überwachen, was von beiden Netzen aus eher gleich gut oder schlecht erreichbar ist. Idealerweise etwas, was extern von beiden liegt. Denn nur dann ist die Gewissheit vorhanden dass beim Switch der Leitung von Vodafone auf Telekom oder zurück überhaupt eine Verbindung zustande kommt.
Übrigens..
https://www.rfc-editor.org/rfc/rfc1788.html
;-)
Naja.. das ist ein RFC nicht das relevante RFC
es gibt keine "relevante" RFC. Das waren und sind schon immer Empfehlungen. Aus manchen wurden halt Standards – und aus manchen eben nicht. Unverbindlich.
Darauf zu beharren zeigt die besondere Weitsicht.
Man hat halt man RFC gesagt… Wie albern.
könnte dieser seltsame Unterschied zwischen innen und außen evtl. án den Zensur Maßnahmen liegen?
das diese Vodafon Zensur Server nur intern verwendet werden und gerne Mal überlastet sind.
VF wird auch sicherstellen wollen dass die Server die ihre Kunden betreiben keiner Zensur unter liegen und deshalb separate Server(hinter einer IP) haben?
Mal geht es problemlos stundenlang- mal 8 von 10 mal 5 von 10 Verlust.
Extern 0 Verlust.
Sporadische Zensur der Hops?
Betrifft ja nicht nur die DNS, aber dieses Detail haben ja schon mehrere überlesen.
Ne. Das hat niemand überlesen.
Dass VF schlecht ist, ist doch gar nicht der Punkt, das muss man im Vertrag mit VF klären. Und kann auch von niemanden hier verbessert/geändert werden.
Relevant ist dass von falschen Daten Ausgegangen wird, und deshalb ein schlechtes Ergebnis beim Monitoring erzielt wird.
Darauf hätte man Einfluss.
Dänischer "Egon-Olsen-DNS" regelt – wahlweise unicast/anycast und einer der Server ist (bisher) immer erreichabr gewesen!
VODAFONE-DN bitte was?
Bin Privatkunde bei Voodoofone. Und ja, es hat tatsächlich schon damit zu tun, damit mal alles läuft. Dns nutze ich schon lange alternative Bekannte in der Fb. Wir hatten vor einigen Monaten alles in allem ca. 6+ Wochen Probleme mit Internet und Telefon. Mehrere Tickets, Anrufe, Techniker war da, alles getestet, Router getauscht, etc. kurzzeitige Besserung und das Spiel ging weiter.
Bin schon seid KabelBw dabei und so was hab ich selbst da nicht erlebt. Der Techniker ebenfalls schon lange dabei, sagt ebenfalls nichts gutes über die Roten.
Letztendlich bestätigt der Artikel hier nur meine Vermutung und was im Forum geschrieben wurde (haben die ja dicht gemacht…) dass Vodafone der letzte Saftladen ist.
Sobald meine neue Leitung liegt, bin ich weg und hoffe auf Besseres. Wobei es nicht sonderlich schwer ist, Vodafone zu übertreffen.
hoffe es kommt jemand bis hierher, nun sollte jeder berufliche Admin wissen das Kabel ein shared Medium ist, und leider die Kabel netzte viel zu stark überprovisoniert sind, und nicht geeignet sind stabile schnelle Verbindungen zu gewährleisten. Ein DSL Anschluss immer vorzuziehen ist, die Provider leider selbst bei möglichem DSl nur ein Kabelanschluss schalten, besonders Vodafone praktiziert das so. Das hat nur ein Ziel – Gewinnmaximierung, der Kunde Spiel keinerlei Rolle. Auch als Geschäftskunden bist du = Privatkunde (C). Erst als B und A Kunde bekommst eigenen Ansprechpartner, und vielleicht bessere Unterstützung. Sonst gild das Motto "Kunde lügt". Nun es gibt auch gute Nachrichten – ersteinmal Glückwunsch zur Problemlösung. Dennoch sollte klar sein das DNS Zensur da ist, auch wenn wir braven Menschen denken, das betrifft uns nicht, gibt es weitere Gründe über das DNS Nachzudenken und es nicht als Standard laufen zu lassen. Die 2. Gute Nachricht heißt easybell.de. Dort gibt es keine Laufzeitverträge! Warum tut der Provider so was? Weil er überzeugt von seinen Produkten und Leistungen ist. Dazu kommt eine exzellente Kundenbetreuung mit kurzen Wartezeiten und ja dort wird man ernst genommen. Ergo Kabel Anschluss nur bei garantierter Bandbreite und nur zur Not, und niemals bei Vodafone. Und immer vor einem Standortwechsel oder Standortwahl die Bandbreiten checken!!! Und als Ersatz tatsächlich LTE mit einbinden als Fallback oder Dauernutzung. Ohne LTE Empfang No Way als Firmenstandort. Ohne Backup kein Mitleid ;-)
Geil. Typisch Internet.
Erstaunlich wie wenig Leute das Problem überhaupt verstanden haben.
Um so erstaunlicher dass ein Teil davon, so 500€ UG, hier um sich prügeln um sich als Helden aufzuspielen, im Internet sich als Security Experts darstellen und aber gleichzeitig ne Webseite für 99€ bauen.
Bester Abend seit langem! Danke an alle!
Ich verfolge den Verlauf der Diskussion auch mit wachsendem Unbehagen – wollte aber nicht als Moderator eingreifen. Es gibt eine Feststellung von Hendrik, die er bei einem Kunden gemacht hat. Das Ganze teilt er mit der Leserschaft, in der Hoffnung, dass ein anderer Betroffener daraus vielleicht Heu machen kann. Zurück kommt eine Kommentarlage, wie Du sie beschreibst – wenig hilfreich für meinen Geschmack und sehr, sehr unschön.
Günter, Vodafone allein die Schuld für das im Blog genannte Szenario/Problem geben zu wollen erscheint in Anbetracht der Tatsache, dass hier deren DNS fürs Monitoring Gateway genommen wurde eher billig.
Der anze Aufwand mit dem VPN Failover ist doch eben genau deshalb, weil man ganz offensichtlich den beiden ISPs nicht vertraut, mit Ausfall rechnet.
Wie kann man dann zum Monitoring des Gateways den DNS des ISPs wählen? Die DNS/ICMP Problematik einmal außen vor lassend, auf die von anderen schon zurecht hingewiesen wurde, nicht nur von Raimar und meiner Wenigkeit.
Idealerweise nimmt man bei VPN Vernetzungen dafür die Hosts unter der eigener Kontrolle, die festen IPs des Kunden der Gegenstelle zum Beispiel. Wo man weiß, dass nichts geblockt, rate-limited oder IPs alle paar Jahre ändern. Wo ein Ausfall dort das VPN dann auch eh egal sein dürfte, weil das Problem dann größer ist. Häufig werden dafür auch Quad1, Quad8 oder Quad9 genommen, nicht schön aber auch okay.
Insofern ist für mich Problem zur Hälfte von diesem Systemhaus selbst verursacht, ganz unabhängig von Vodafone und was man von denen hält.
Ich kann nur mit dem Kopf schütteln und hoffen dass Du in Siegen nicht Informatik studiert hast.. mit Abschluss..
@Günter
Das Problem dabei ist aber viel eher, wenn der Jenige, der da die Meldung abgibt, einfach irgendwelchen technischen Käse fabriziert und daraus sozusagen die "Beschwerde" generiert wird, ihm dann gesagt wird, ja das ist aber quatsch das so zu machen und er sich dann "von oben herab" äußert, kommt das mindestens genau so komisch.
Ja, es mag da bei Vodafone irgendwas sein. Aber mal ehrlich – einen DNS Resolver zu pingen und darauf sein Uplink Monitoring aufzubauen ist einfach technischer quatsch. Die Erreichbarkeit des Servers sagt nichts aus. Null. Zudem er auch nicht für irgendwas in der Kommunikation verwendet wird seitens des Endkunden (laut der Meldung). -> das heißt, die Erkenntnis, dass der Server antwortet ist allerbestenfalls nur die halbe Wahrheit über die Funktion des WAN Links über das Vodafone Netz.
Ein paar Hinweise dazu gab es schon – lieber ein System im Hauptstandort pingen (würde bspw. die Wege von etwaig vorhandener VPN Verbindungen unter den Standorten "abbilden"), oder ein System irgendwo in den weiten des INets, was keine Anycast IP ist. Das würde zumindest partiell den/einen Weg vom ISP Netz zum nächsten größeren Internet Knoten abdecken, wo die Provider untereinander peeren.
Aber statt da konstruktiv anzusetzen kommt nur eine relativ aggressive Haltung seitens Hendrik. Ich für meinen Teil hoffe, Niemals nie im Leben an so eine Person bei unseren/meinen Dienstleistern zu geraten, wo am Ende nicht mehr mein Wunsch als Kunde im Vordergrund zu stehen scheint, sondern nur das Konstrukt was da gebaut wurde, zu verteidigen. Letztlich bringt dem Kunden der Ping auf den Vodafone DNS exakt gar keinen Mehrwert, da es nichts über die Verfügbarkeit irgendwelcher Ressourcen über die Vodafone Leitung aussagt, die nicht im Vodafone Backend Netz stehen.
Was btw. noch dazu kommt, wenn das Routing schwenkt auf den Telekom ISP -> dann geht das Datenpaket einen komplett anderen Weg. Das Kabelnetz bei Vodafone und das DSL oder Glasfaser Netz bei der Telekom sehen sich bestenfalls irgendwo beim nächst gelegenen Internet Knoten. Der Pingtest vom Telekom Anschluss auf den Vodafone DNS sagt zudem schon perse mehr aus über die Funktion der Leitung als der Pingtest innerhalb der Vodafone Wolke. Denn über den Telekom Link geht das Paket eben über die Grenze des Providernetzes hinaus.
Bist Du jetzt echt der nächste, der ein upstream Gateway mit einem VPN Gateway zusammenwürfelt in dieser Diskussion? Ist ein Upstream Gateway- und zwar das Dir vom ISP zugewiesene, offline – dann ist der jeweilige WAN Anschluss auch offline. zu 100%.
Das ist alles was dahinter steckt. Und das machen wie gesagt, ausnahmlos alle Hersteller die was zu sagen haben so. Du hast auch die anderen Beiträge nicht gelesen..
Das hat mit den VPN dahinter *gar nichts* am Hut.
Und zum Thema "von oben herab"…
"wenn ein offenbar mittelprächtiges Systemhaus" …
"willst Du einzig und allein wissen" …
" erscheint mir nicht gerade helle" …
"Oh Boy"
Sind so aussagen von Personen, die ich ohne Grund in meinem Neztwerk nicht kenne…
Und noch ganz am Rande: (VPN) Datenpakete werden sich bei einem Schwenk nicht sehen. Nie. Die Source gibt es nicht mehr, so dass spätestens die Anwort nicht mehr ankommen kann.
Wieviele Kommentare von Leuten braucht es noch bis Du dein Vorgehen überdenkst?
Es war noch keines dabei welches sagt .. richtig, das müsste so funktionieren, tut es aber nicht, böses VF.
Dass VF offenbar eine schlechte Leitung dort hat, bezweifelt niemand.
ich hab gerade mal einen sinnvollen Kommentar dazu gelesen bis jetzt. Mit dem vom Lulli sogar noch einen witzigen (wenn auch nicht sinvoll).
Vielleicht sollte ich nach Techniker für Informationstechnik, Studium der Wirtschaftsinformatik und 23 Jahren Selbstständigkeit mit IT-Security den Job wechseln… Soll ich Troll im Blog werden?
Abgemacht.
Nein, ich würfel da nix zusammen. Ich versuche dir mitzuteilen, dass der Test gegen ein "Upstream Gateway" nur die halbe Wahrheit ist. Und nein, ein Test gegen ein Upstream Gateway wie du es offenbar durchführst, ist aufgrund der Fehleranfälligkeit nicht das, was man in dem konkreten Fall machen sollte. Denn der Test sagt nur etwas vom Weg des eigenen Anschlusses bis zu eben diesem Upstream Gateway aus. Nicht mehr und nicht weniger.
Um dir das mal ein sinnbildliches Beispiel zu bringen. Wenn du mit deinem Elektroauto in den Urlaub fährst, bringt es dir auch nicht, alle 100km mal in den Benzinkanister im Kofferraum zu gucken, ob noch Sprit drin ist. Das ist für das Elektroauto schlicht irrelevant. Du testest hier gegen ein System was in der Kommunikation letztlich irrelevant ist. (ein DNS Resolver Host, der nichtmal genutzt wird) Damit sagt der Test auch nichts aus.
Und nein, es ist falsch zu sagen, wenn das Upstream Gateway nicht erreichbar ist, ist deine Leitung unterbrochen. Wie du ja hier siehst. Die Erreichbarkeit des Gateways via ICMP ist schlicht nirgendwo garantiert. Was auch immer daran misszuverstehen ist.
Vielleicht bin ich der einzige der es verstanden hat..
Wenn ich mein Upstream Gateway von WAN A nicht erreiche schicke ich alles an Traffic an B. So ist das tatsächlich sehr oft.
VTI sagt mir, es ist hier mehr dahinter als ein klassischer IPsec Tunnel. Vermutlich werden also auch n-redundante Tunnel aufgebaut.
Da macht man dann ein State Kill um nicht auf das Timeout des Connection States zu warten Sinn.
Gerade bei RDP kann das so sehr viel Sinn machen.
Und „dynamische" Route bestätigt dass hier kein Failover werkelt, sondern die Tunnel vermutlich immer stehen, das wäre sogar großes Tennis…
Sicher ist allerdings dass ich an Hendriks stelle hier nichts mehr posten würde.. der falsche Ton kam mM nicht von ihm – im Gegenteil kommt hier jeder mit einer noch schlechteren Idee, nach der gar nicht gefragt wurde.
Typisch Internet halt.
Weiterscrollen ist etwas was viele wohl noch lernen müssen…
einer hats echt verstanden! Danke!
Das ist in sofern eben doch die ganze Wahrheit, hier geht es tatsächlich um Dinge wie default Routen und was ein Standardgateway so alles mit den Diensten einer Firewall anstellt.
Es fällt mir schwer den Schwachsinn aufzugreifen, aber nehmen wir mal an..
– Fall A, eine IP eines eigenen Servers, oder irgendwo im Internet (wurde ja so vorgeschlagen)
Der Server fällt aus (Hardware, Bagger in Leitung, Experte zieht das falsche Kabel): Alle WAN Gateways werden als offline deklariert. Es wird sich kein Tunnel aufbauen, weil die Firewall denkt es gibt kein Gateway mehr. Bingo! An allen Standorten, obwohl die WAN Anschlüsse ja gehen.
Das ist wirklich die albernste Lösung…
-Fall B, ich nehm die Gegenseite (IP) eines VPN
Auf der Gegenseite gibt es eine Störung des Anschlusses, somit fällt die Gegenseite auch auf Tier 2, obwohl Tier 1 (mehr Leitungskapazität) für default Routen ja noch gehen würde (in- out Traffic). Halbes Bingo!
– Fall C ich nehme, wie gewollt das Design der Firewall hersteller und Monitore das (zugewiesene) Standard Upstream Gateway
Das Gateway kann sich mit jeder verbindung dynamisch anpassen, ist also immer aussagekräftig. Ändert es sich beim Verbindungsaufbau, egal, bekommt die Firewall mit.
Die Leitung mit der höheren Kapazität Tier 1 ist das default Gateway. Fällt dies aus, Tier 2. Es wird sich, und scheinen ein paar nicht zu verstehen, sowieso kein Tunnel (neu)aufbauen wenn er sein Ziel nicht erreicht. Das kann er aber nur, wenn nicht von x Gateways alle schon offline markiert sind – Kein Bingo, alle gehen über Los.
Das ganze wird nur dann zum Problem, wenn es wie im VF Beispiel sporadisch nicht geht. Dann werden die default Routen zu Tier 1 neigen sofern das innerhalb der Toleranz "funkt".
Es gibt de facto keine Stelle wo ich darauf beharre nun den blöden DNS zu triggern, mit dem Kabelmodem ist mein Upstreamgateway aber noch im Haus. Das ist sicher dass das antworten wird (und kommt Fall A nahe).
Und wie netgate auch schreibt "In those cases it makes more sense to ping something **farther** upstream". Am liebsten hätte ich also den Hop direkt nach meinem inhouse Gateway genommen… Geht bei VF nicht, sperrt von Grundauf ICMP.
Und by the way: Der Kunde hatte das so 9 Jahre lang dass es keinerlei Probleme gab den DNS zu triggern. Es kam plötzlich und unerwartet. Auch schon ein Grund Grundsätzlich auf jedem WAN eine andere IP zu triggern…
Auch hat sich in dieser Zeit der DNS, die IP, nicht geändert. Das ändert sich übrigens extrem selten, ich habe gefühlt seit dem Nokia 3210 eine Telekom DNS IP in meinem Telefonbuch. Der ist immer noch rasant – seit 20 Jahren.
De facto gibt es doch diese ganzen "DNS muss nicht auf ICMP antworten" Märchen in der Praxis so gut wie nie.
Und wer meint er mache etwas sicherer indem er ICMP verbietet, der sollte sich fragen ob er nicht Busfahrer wird.
Ich frag mich wer hier wirklich schon mal mit mehrfach redundanten WAN und VPN, mit dynamischen Routen und dem Stichwort "reply-to" gespielt hat.
Augenscheinlich alle nicht. Mehr sag ich dazu mal nicht…
Vielleicht noch dass ich an der Entwicklung des ein oder anderen pf Sense Feature nicht unbeteiligt war…
das heißt übrigens auch nicht ohne Grund überall "gateway monitoring". Es hieße sonst "online montitoring".
By design.
Schon immer.
Vodafone-Mobilfunk kann ich nicht beurteilen, aber Internet können sie nicht:
– Nachbarin ist von Telekom zu UnityMedia/Vodafone-Kabel gewechselt und wegen ständiger Probleme zurück zur Telekom-DSL: nun läufts wieder
– Modemtausch bei einem Bekannten von alter Easybox zu Fritzbox am Vodafone DSL-Anschluss hat mich Tage gekostet, um das Ding zum Laufen zu kriegen (ich nutze Fritzboxen seit "Jahrzehnten" problemlos am Telekom-Anschluss). Pluspunkt: ich hatte einen super Hotliner (kompetent und freundlich) an der Strippe, man glaubt es kaum!
– E-Mail können sie auch nicht, das Userforum ist voller Probleme, mein altes Germanynet/Arcor-Postfach zickt auch gerne mal rum per POP3 oder IMAP, das liegt nicht am neuen iPhone (hab keins).
– Vodafone unterschlägt seit Monaten bei vielen Kunden (Freemail oder bezahlt) sämtliche (vermeintlichen) Spam-Mails. Spam-Ordner ist immer leer, egal, was man einstellt, soweit man was einstellen kann.
Auch Vodafone Kabel Kunde hier und kann die Beobachtungen komplett bestätigen….
Durch ausmessen der Leitung mit einem Fluke Netzwerkmessgerät was bei der Firma wo ich arbeite von der Fachabteilung genutzt wird konnte dies nachgewiesen werden. Die DNS Probleme bei Vodafone sind auch keine neuheiten und sind seit Jahren immer schlechter geworden ebenso der Kundenservice….
Mittlerweile rate ich jedem der das Vodafone Kabel netz nutzt eine Fritz.box von AVM sich zu nehmen und die DNS server auf google DNS umzuleiten 8.8.8.8 oder 8.8.4.4 oder andere DNS server hilft immens bei den DNS Fehlern….
hier auch noch ein sehr schönes Beispiel für unterirdischen Support…
Original Zitat eines Technikers beim Ausfall einer gesamten Straße: Ja das liegt definitiv nicht am Vodafone netz sondern an der Inhouse Verkabelung. Da können wir nichts machen sie müssen die Verkabelung im Haus neu machen.
Ticket wird geschlossen und man muss ein neues aufmachen. Die Ursache zu dem Zeitpunkt damals war veraltete Technik seitens Vodafone wo noch aus den 80er-90er Jahren Verstärker der Deutschen Post im Boden verbaut gewesen sind die massive Probleme verursacht haben… .
Dies wurde erst nach 2 Monaten und X Tickets wie auch Telefonaten mit dem Support erst herausgefunden und dem Glück das ein Techniker das Ticket bekam der bei der Telekom seine Ausbildung gemacht hat. Sich die Zeit nahm auf Fehlersuche zu gehen und dabei sich tierisch über seine Vorgänger aufgeregt hat.
Kann mir mal wer erklären was es mit folgendem Passus auf sich hat?
"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."
Das ließt sich so als geht/ging über den Vodafone Anschluss gar nix?
-> wieso aber die Schlussfolgerung und das rumreiten auf dem DNS Resolver Host via Ping?
Das Setup ist problematisch.
Also es gibt 2 Provider, zwei Leitungen.
Provider A und Provider B.
Nun wird zum Test ob der jeweilige Provider erreichbar ist der DNS genommen. Also es gibt einen Dienst der beide DNS Server regelmäßig anpingt.
Nun gibt es das Problem dass wenn die Leitung A aktiv ist , beide DNS Server erreichbar sind also A & B, und so die auf die Leitung B gewechselt wird weil dort anscheinend alles geht.
Nur bei der Leitung B gehen Pakete zum DNS Server B verloren.
Dadurch schaltet die Firewall wieder auf A.
Das ist nun vielleicht unerwartet, aber das Setup geht hier von falschen Fakten aus. Ping/ICMP wird quasi nie von jemanden garantiert.
Es gibt auch keine Sinnvolle Metrik in dem Setup die Leitung B zu testen.
Besser wäre es einen 3. Server zu verwenden als Metrik den der Kunde oder IT Dienstleister komplett kontrolliert.
@squat
Das verstehe ich soweit. Aber was ich nicht verstehe ist eben speziell die Aussage:
"Ein Arbeiten war nicht möglich. Sobald das Vodafone WAN beim Kunden deaktiviert wurde, lief die Firewall problemlos."
Das ergibt für mich keinen Sinn in der Konstellation. Denn wenn die FW aufgrund der schlechten Erreichbarkeit der DNS Resolver IP im Vodafone Netz das Routing schwenkt und die Pakete dann über den Telekom Anschluss raus gehen, dann muss ein Arbeiten doch möglich sein. Und wenn die FW meint, weil die Paketverlustrate gering ist, das wieder zurück auf Vodafone zu schwenken, dann muss das Arbeiten auch gehen. Denn in beiden Fällen wird die via ICMP getestete DNS Resolver IP ja gar nicht verwendet. Dort steht was von einem "State-Kill und zum Tunnelwechsel" -> was auch immer das sein soll. Tunnelwechsel klingt dass der VPN Tunnel zu irgendeiner Gegenstelle im Internet nicht mehr über die Vodafone- sondern über die Telekom Leitung raus geht. Natürlich kommt das beim Wechsel zu kurzen Unterbrüchen.
Hätte man hier anstatt irgend einer DNS Resolver IP die Gegenstelle des VPN Tunnels auf Erreichbarkeit getestet, dann würde der Schwenk zwischen den Leitungen auch nicht passieren. Aber sei es drum, selbst wenn man das nicht tut, das Konstrukt ist in der Form anfällig für false positives, weil die (schlechte) Erreichbarkeit des DNS Resolvers offenbar dazu dass der Tunnel über die Vodafone Anbindung abgebrochen wird. Das ist schlecht bis falsch konzeptioniert per Design. Eine Dritte Instanz ist dafür verantwortlich, ob mein Tunnel steht, obwohl diese Instanz gar nix zur Kommunikation beiträgt.
Das Setup ist problematisch, weil es nur das Peering von Provider A, B misst, aber nicht die Leitung.
Es ist ja nicht mal Sicher, dass via Provider A der DNS von Provider B der gleiche ist, wie via Leitung B, weil bei DNS auch Anycast verwendet wird.
Es ist nichtmal sicher, dass die DNS Server von Provider B im Netz von Provider B stehen.. die könnten die Leistung ja zugekauft haben.
Es wird auch nicht zugesichert, dass DNS Server überhaupt bei ICMP antworten müssen.
Dass das andauerende hin und her schalten bei der Firewall zu Problemen führt ist klar.
Wie gesagt, das Setup ist problematisch, weil es falsche Annahmen trifft.
ich machs kurz: Nein. Ihr zieht euch viel zu sehr am Stichwort DNS hoch. Völlig ohne Grund.
ISP interner Pool..
Werden hier zwei Probleme vermischt? Das hier beschriebene Problem ist ein Paketverlust beim ping auf einen Resolver. In den verlinkten Forenbeiträgen geht es um die Erreichbarkeit der Nameserver für die Vodafone-eigenen Domains. Manche Kunden können diese Nameserver überhaupt nicht erreichen. Beides passiert nur innerhalb vom Vodafone-Netz. Beim ersten Problem ist das Routing da, da die Paketverluste nicht 100% betragen. Beim zweiten Problem kommt gar keine Antwort. Das geht in Richtung Routing.
Eine Sinnvolle Aussage zum VF Netz ist nicht möglich. Denn es ist ein Netz, und ja nachdem welche Route genommen wird, durch das Netz geht alles, oder es geht nichts.
Die ganzen Berichte.. "bei mir gab es auch Fehler xxxx" vorallem bei der letzte Meile, bringen hier auch keine Erkenntnisse. Diese Probleme gibt es bei allen Providern.
Es ist mir eigentlich völlig egal ob VF da nun ein Problem hat oder nicht. Das Aussterben (Gott sei Dank) von Kabelanschlüssen wird das nicht aufhalten.
Ob man hier nun an ein Problem glaubt – oder nicht.
Aber man lebt schon am Ende der Realität das weichzuspülen..
@Hendrik
Manche Dinge vielleicht besser bei Fefe ansprechen.
Da ist manchmal das bessere Klientel!
Reden-Silver.
Ich habe die Kommentierung jetzt deaktiviert, da ich in den Kommentaren nicht erkennen kann, dass da noch viel zielführendes kommt – die Positionen sind ja hinreichend ausgetauscht – danke für euer Verständnis.