Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten
-
Ich sehe hier bei dir ganz klar ein Provider Problem, bzw. ein Problem mit deinen Internetverbindungen.
Ja ICMP wird von Router und Co. nachrangig behandelt, aber das bedeutet nur langsamer beantwortet und nicht wird einfach mal so verworfen.
Das mag zutreffen wenn der Router total am Anschlag läuft, aber dann hat man ganz andere Probleme als ICMP.Wenn bei dir, bei sauberem Monitoring, sagen wir mal WAN 1 auf 1.1.1.1 und WAN 2 auf 1.0.0.1 und dann fliegen hier ständig Meldungen rein offline. Dann hat das Provider ein echtes Problem. Wenn nicht auf deiner Strecke direkt, dann in seiner Routing Infrastruktur.
Aber eine Zombie WAN Strecke weiter nutzen, das ist auch nicht gerade zielführend.
Jedoch kann man nur so wirklich sehen was los ist, hier hat es heute Nacht IPv4 für 3-4h zerlegt, IPv6 lief weiter und Cloudflare hat auch hier weiter sauber geantwortet.
Und gerade der Resolver in der pfSense ist mega geil, da kannst du auch an den Einstellungen feilen, die eine oder andere Checkbox kann man gefahrlos setzen, da sind aber auch einige dabei die man nicht aktivieren sollte.
Nutze hier nur die 4MB default cache, aber DNS Reaktionszeiten sind nur beim Erstaufruf zu vermelden, dann immer <1ms und damit nicht mehr bemerkbar.Setze das aber auch in Kombination mit dem pfBlockerNG und hartem Regelwerk zum blocken jeder externen DNS oder DNS over https Anfrage ein.
Will ja nicht das man meinen DNS Schutz unterwandert und sich hier wieder was eintritt.Du solltest also dein ganzen Konzept noch mal überarbeiten.
Deine i5 IPU ist für das was du machst und was du an Internetleitungen hast so überdimensioniert wie sonst was.
Meine Kiste habe ich schon auf Adaptiv runter gestellt, die ist selbst dann noch viel zu schnell für ne GBit Leitung unterwegs. Bei 200 kannst deine auf Min stellen ohne das du hier was merken würdest.Zudem hinkt der Vergleich zum alten Router, denn die Umstände bei allen Providern habe sich schon wegen Corona massiv verändert, deutlich mehr Last, schlecht verfügbare Hardware, wenn überhaupt Hardware nachkommt.
Hier werden Teilweise alte Kisten weiter betrieben, weil nix neues nachkommt oder sogar bei defekten wieder alte Kisten als Flickwerk verbaut.Hier vor Coroan Unitymedia mit 400/40 und nie Probleme, dann kommt die Übernahme, ging auch noch. Dann wird groß 1000/50 vermarktet und das Desaster nimmt seinen lauf.
Total über buchte Segmente sind jetzt noch mal mit 60% mehr Spitzenlast unterwegs.
War hier auch ein 6-9 Monate langer Kampf bis das wieder stabil lief.Also noch mal ans Zeichenbrett und überlegen was willst du, was macht Sinn und was nicht.
Dann schauen wie du da hin kommst.Blockst du nix, kannst ja schauen was wie sauber DNS bei dir umsetzt:
https://www.grc.com/dns/benchmark.htm -
@nocling said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Wenn bei dir, bei sauberem Monitoring, sagen wir mal WAN 1 auf 1.1.1.1 und WAN 2 auf 1.0.0.1 und dann fliegen hier ständig Meldungen rein offline. Dann hat das Provider ein echtes Problem. Wenn nicht auf deiner Strecke direkt, dann in seiner Routing Infrastruktur.
Nicht ständig aber es kommt bzw. kam immer wieder vor, dass Pings zu Cloudflare oder auch zu Google nicht retour kamen und damit der Failover durchgeführt wurde (das war aber auch mit dem alten Router so).
Der Cisco RV345 war da extrem schnell - wenn man die Leitung abgesteckt hat ging da teilweise nicht einmal ein Ping verloren.
Ich habe versucht das auf der pfSense ähnlich hinzubekommen, ganz gelungen ist es mir nicht - d.h. aber natürlich auch, dass dadurch nicht erst bei 20% Packetloss umgeschalten wird.
Wahrscheinlich ist es aber besser die Werte auf Default zu lassen und dafür als Monitoring Adresse Cloudflare oder Quad9 oder so zu verwenden...Allerdings muss ich doch auch anmerken, dass da die pfSense GUI mit dem Kommentar "Use this if the gateway does not respond to ICMP echo requests (pings)." bei der "Monitoring IP" die Verwendung des Gateways selber schon auch nahelegt...
Aber wie auch immer - ich wüsste nicht wie ich meinen ISP hier dazu bewegen könnte wirklich in der Tiefe etwas zu machen bzw. auch nur zu monitoren.
Dazu bin ich als kleiner Einzelkunde schlicht und einfach zu bedeutungslos und es wird auch nur eine Transferleistung und eine Verfügbarkeit zugesichert (und die wird eingehalten). Eine Leitungsqualität - im Sinne von zB max ICMP Packetloss oder max Antwortzeiten wird nicht zugesichert.Leider kenne ich auch keine vernünftige Möglichkeit - abgesehen von den Bandbreitenmessungen (und die sind ja in Ordnung) - die "Qualität" eines Internetanschlusses objektiv so zu messen, dass das vom ISP auch anerkannt würde.
@nocling said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Und gerade der Resolver in der pfSense ist mega geil,
Danke für den Input, ich verstehe, dass der Resolver durchaus Vorteile mit sich bringt, momentan will ich diesen Aspekt aber (noch) nicht angehen.
@nocling said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Zudem hinkt der Vergleich zum alten Router, denn die Umstände bei allen Providern habe sich schon wegen Corona massiv verändert,
Meinen alten Cisco RV345 hier hab ich erst mit 12.5. deaktiviert - da können Covid bedingte Laständerungen also nicht neu hinzugekommen sein - wobei ich zugeben muss, dass ich das Gefühl nicht los werde, dass die Antwortzeiten von Websites (insbesondere von solchen die außerhalb von Europa liegen) am Wochenende schlechter sind.
Wäre schön, wenn man das irgendwie reproduzierbar objektiv messen könnte - aber wie gesagt ich wüsste nicht wie das zu bewerkstelligen wäre...@nocling said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Also noch mal ans Zeichenbrett und überlegen was willst du, was macht Sinn und was nicht.
Dann schauen wie du da hin kommst.Ich benötige primär eine stabile Internetverbindung (TelCo's etc), wobei Antwortzeiten (zB bei Websites) einen nicht Däumchen drehen lassen sollen. Wenn man sich wundert ob man jetzt auf einen Link geklickt hat oder nicht, ist das einfach nur lästig.
Ich werde wohl die Einstellungen für das Gateway-Monitoring bei Gelegenheit wieder auf die Default-Werte zurücksetzen und wirklich 1.1.1.1 oder so als Monitoring IP eintragen - bis dahin reicht es mir aber, wenn ich - bei Problemen - den ISP Router abziehe und die pfSense so auf die 2. WAN Leitung umschaltet.@nocling said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Blockst du nix, kannst ja schauen was wie sauber DNS bei dir umsetzt:
https://www.grc.com/dns/benchmark.htmJa, das hatte ich mir auch bereits angesehen:
(Was dabei leider nicht wirklich sichtbar wurde ist, dass manche Domains stets absurd hohe Auflösezeiten hatten - zB 1,6 Sekunden
Aber OK, das lag wohl am ISP DNS - seit ich den rausgeschmissen habe konnte ich das so nicht mehr beobachten...)Final benchmark results, sorted by nameserver performance: (average cached name retrieval speed, fastest to slowest) 192.168.150. 15 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ + Cached Name | 0,000 | 0,000 | 0,000 | 0,000 | 100,0 | + Uncached Name | 0,010 | 0,058 | 0,275 | 0,075 | 100,0 | + DotCom Lookup | 0,010 | 0,017 | 0,030 | 0,007 | 100,0 | ---<-------->---+-------+-------+-------+-------+-------+ Pi-Hole-2 Local Network Nameserver 192.168.150. 14 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ + Cached Name | 0,000 | 0,000 | 0,000 | 0,000 | 100,0 | + Uncached Name | 0,010 | 0,064 | 0,314 | 0,082 | 100,0 | + DotCom Lookup | 0,010 | 0,016 | 0,030 | 0,006 | 100,0 | ---<-------->---+-------+-------+-------+-------+-------+ Pi-Hole-1. Local Network Nameserver 192.168.150.25x | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ - Cached Name | 0,000 | 0,000 | 0,000 | 0,000 | 100,0 | - Uncached Name | 0,020 | 0,097 | 0,606 | 0,124 | 100,0 | - DotCom Lookup | 0,013 | 0,038 | 0,181 | 0,025 | 100,0 | ---<OOOOO-OO>---+-------+-------+-------+-------+-------+ pfSense. Local Network Nameserver 1. 0. 0. 1 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ - Cached Name | 0,007 | 0,008 | 0,010 | 0,001 | 100,0 | - Uncached Name | 0,010 | 0,074 | 0,301 | 0,084 | 100,0 | - DotCom Lookup | 0,009 | 0,044 | 0,187 | 0,053 | 100,0 | ---<-------->---+-------+-------+-------+-------+-------+ 1. 1. 1. 1 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ - Cached Name | 0,007 | 0,008 | 0,009 | 0,001 | 100,0 | - Uncached Name | 0,014 | 0,076 | 0,319 | 0,083 | 100,0 | - DotCom Lookup | 0,010 | 0,067 | 0,190 | 0,068 | 100,0 | ---<-------->---+-------+-------+-------+-------+-------+ 8. 8. 8. 8 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ - Cached Name | 0,010 | 0,025 | 0,050 | 0,011 | 100,0 | - Uncached Name | 0,024 | 0,078 | 0,297 | 0,073 | 100,0 | - DotCom Lookup | 0,025 | 0,038 | 0,053 | 0,009 | 100,0 | ---<-------->---+-------+-------+-------+-------+-------+ 8. 8. 4. 4 | Min | Avg | Max |Std.Dev|Reliab%| ----------------+-------+-------+-------+-------+-------+ - Cached Name | 0,010 | 0,026 | 0,055 | 0,013 | 100,0 | - Uncached Name | 0,025 | 0,077 | 0,339 | 0,075 | 100,0 | - DotCom Lookup | 0,025 | 0,039 | 0,053 | 0,010 | 100,0 | ---<-------->---+-------+-------+-------+-------+-------+ UTC: 2022-05-26, from 12:15:40 to 12:16:12, for 00:32,216Herzlichen Dank für das Feedback!
-
@jegr said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Außerdem ist der Resolver nur bei den ersten Hits natürlich langsamer, danach cached er die Anfragen eh und ist schneller als jeder externe Forwarder.
Danach ist er exakt gleich schnell wie ein Forwarder, denn das Ergebnis, welches der Forwarder zurückliefert, wird natürlich ebenfalls zwischengespeichert. Dazu kommt, dass die Latenzen zwischen einem Heimanschluss und (autoritativen) Nameservern in der Regel deutlich höher sind als die zwischen einem gut angebundenen Server und (autoritativen) Nameservern.
Ich bin absolut dafür, seinen eigenen Resolver zu verwenden, aber die Geschwindigkeit wird bei einem Heimanschluss mit an Sicherheit grenzender Wahrscheinlichkeit darunter leiden. Ob sie spürbar leidet, steht auf einem anderen Blatt.
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Ich werde wohl die Einstellungen für das Gateway-Monitoring bei Gelegenheit wieder auf die Default-Werte zurücksetzen und wirklich 1.1.1.1 oder so als Monitoring IP eintragen
Über das Verhältnis von
Latency Thresholds,Packet Loss ThresholdsundProbe Intervalkannst du doch eigentlich relativ fein einstellen, wie "mies" die Leitung sein muss, bevor sie als 'Down' gebrandmarkt wird. Siehe: https://docs.netgate.com/pfsense/en/latest/routing/gateway-configure.html (den Stecker kannst du ja dann immer noch von Hand abziehen, wenn dir die automatische Umschaltung zu lange dauert). -
@thiasaef said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Über das Verhältnis von Latency Thresholds, Packet Loss Thresholds und Probe Interval kannst du doch eigentlich relativ fein einstellen, wie "mies" die Leitung sein muss, bevor sie als 'Down' gebrandmarkt wird. Siehe: https://docs.netgate.com/pfsense/en/latest/routing/gateway-configure.html (den Stecker kannst du ja dann immer noch von Hand abziehen, wenn dir die automatische Umschaltung zu lange dauert).
Das ist wohl ein sehr 2-schneidiges Schwert, da die pfSense (zumindest bei mir) einen Link-Loss nicht direkt erkennt und in den Failover geht, sondern diesen auch über den Packet-Loss determiniert.
D.h. wenn ich diese Parameter relativ hoch setze um sicherzustellen, dass ein paar verlorene Pings zu einem entfernten Monitoringziel keinen Failover auslösen (und damit auch eine ev. aufrechte TelCo trennt), dauert auch ein Umschalten bei manuellem Abziehen eines Modems länger....Ideal wäre es mE 2 entfernte Monitoringziele eintragen zu können um den Status Down einer Line sicher erkennen zu können - aber das gibt es leider nicht...
-
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
dass ein paar verlorene Pings zu einem entfernten Monitoringziel keinen Failover auslösen
Mit den Defaulteinstellungen reagiert das Monitoring doch eigentlich schon relativ träge. Hast du wirklich so heftigen Paket Loss zu 1.1.1.1 oder 8.8.8.8, dass das regelmäßig fehlauslöst?
Ein Linkdown eines der 8 Ports deiner IPU führt übrigens seit pfSense 2.5 dazu, dass Unbound sich neu startet und damit auch der DNS Cache flöten geht. Was die Performance natürlich komplett killt.
-
@thiasaef said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Mit den Defaulteinstellungen reagiert das Monitoring doch eigentlich schon relativ träge. Hast du wirklich so heftigen Paket Loss zu 1.1.1.1 oder 8.8.8.8, dass das regelmäßig fehlauslöst?
Diese Leitungs-Beobachtungen stammten aus Zeiten mit dem alten RV345, der wie gesagt sehr schnell umgeschaltet hat. Darum bin ich bei den Gateways als Monitoringziel geblieben, zumal ja auch die GUI diese Verwendung irgendwie auch nahelegt. (siehe oben)
Um die pfSense etwas "agiler" für den Failover zu konfigurieren hatte ichPacket Loss thresholds: 1/10
Loss Interval: 500
Time Period: 50000
Alert interval: 500konfiguriert - auf den Gateways war das auch ganz ok- bis vor kurzem.
Heute Nacht habe ich dann 67 Mails von der pfSense bekommen, dass auf WAN_2 (der Backupleitung) packet loss stattgefunden hat, und das Gateway daher aus der Routinggroup entfernt wurde.
(Ich hatte interessanter Weise auch gestern und vorgestern solches Schluckauf mit dem WAN 2 ISP Router, aber das waren in Summe nur wenig, Nach einem reboot des ISP Modems war dann auch mal Ruhe.
Beachtlich war aber, dass wenn die pfSense packet loss vermeldet hat, die public IP des WAN 2 ISP Routers dabei von LAN Seite tatsächlich drop outs hatte, von der Internet Seite her (über das Handy & LTE getestet) aber geantwortet hat - ich hab' keine Idee was das wieder sein soll...
Wobei auf der Line ist sowieso "Hintergrundrauschen" das mE nicht von schlechten Eltern ist - durchschnittlich ~70kBit inbound, über 95% ARP Requests)Ich habe daher die obigen Werte wieder auf Default gesetzt - damit war natürlich mal Ruhe mit den Mails - aber trotzdem packet loss über die GUI auf der pfSense zu sehen (aber halt unterm Treshold...)
Um das Problem einzugrenzen hab ich das WAN_2 ISP Modem jetzt mal durch einen G3 Router ersetzt (kein Packetloss auf der pfSense zu bemerken - soweit ich das halt sagen kann).
Gleichzeitig habe ich den WAN_2 ISP Router an den alten RV345 angeschlossen, dahinter läuft jetzt mal ein Notebook mit Ping-Plotter - aber bis jetzt ist auch alles ruhig.
Wie mir solche esoterischen Probleme, die nicht wirklich einzugrenzen oder greifbar sind, an die Nieren gehen!
Nun gut - ich habe zusätzlich auch die Monitoring IP für WAN_2 einmal auf 9.9.9.10 gesetzt - ist ja auch nicht unwesentlich zu wissen, dass die pfSense für diese Monitoring IP's offenbar statische Routen setzt (nicht unter statischen Routen zu finden, aber im Log wird das vermerkt), die natürlich an das jeweilige Gateway gebunden sind.
D.h. man sollte wohl tunlichst keine Adressen verwenden die sonst aktiv in Verwendung sind, weil man sich sonst einen Wolf sucht, warum ein tracert dorthin nicht über die primäre Leitung gehen..
(wobei das Thema Tracert mit der pfSense ja offenbar überhaupt ein lustiges ist, insbesondere auch mit CoDel)@thiasaef said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Ein Linkdown eines der 8 Ports deiner IPU führt übrigens seit pfSense 2.5 dazu, dass Unbound sich neu startet und damit auch der DNS Cache flöten geht. Was die Performance natürlich komplett killt.
Ja. Und offenbar startet UBound auch jedes mal neu wenn DHCP Adressen in die DNS DB eingetragen werden...
Vielen lieben Dank für eure Unterstützung!
-
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
zumal ja auch die GUI diese Verwendung irgendwie auch nahelegt
Nein, die GUI bezieht sich nicht auf den Fall, dass man sich eine Routerkaskade bastelt, sondern darauf, dass das Gateway des ISPs nicht zwingend auf ICMP Anfragen antwortet und man dann händisch einen anderen Zielserver eintragen muss.
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Packet Loss thresholds: 1/10
Dann ist es kein Wunder, dass dir die Failover Detection regelmäßig um die Ohren flog.
-
@thiasaef said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Nein, die GUI bezieht sich nicht auf den Fall, dass man sich eine Routerkaskade bastelt, sondern darauf, dass das Gateway des ISPs nicht zwingend auf ICMP Anfragen antwortet
Sorry, das versteh ich jetzt nicht. Wo ist der Unterschied zwischen einem Router und dem ISP Gateway?
Und ist nicht das gesamte Internet letztendlich eine Kaskade an Routern?@thiasaef said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Dann ist es kein Wunder, dass dir die Failover Detection regelmäßig um die Ohren flog.
Für ein entferntes Monitoringziel hätte ich das ja verstanden - aber für ein Gerät, welches 50cm neben der pfSense bzw dem internen Router steht? Da hätte ich mir gedacht, dass eigentliche alle Pings durchgehen müssten...
Ach herrje - ich glaube ich muss das Bild von meinem Netzwerklayout überarbeiten - Provider Modems gibt es ja gar nicht...
Mea Culpa...
Mach ich sofort... -
Sorry, mir ist ein Fehler in meinem Netzwerklayout durch die Lappen gerutscht.
So sollte das passen:
WAN 1 WAN 2 : : : DSL-Provider : Cable-Provider : : | | .----+----. ISP .----+----. | Router1 | Router | Router2 | '----+----' '----+----' 93.83.54.r1/30 | | 212.186.67.r2/28 (WAN 1) | .---------. | (WAN 2) +------| pfSense |------+ 93.83.54.p1/30 '----+----' 212.186.67.p2/28 | LAN | 192.168.150.0/24 | .-----+------. .------------. | LAN-Switch |-------| 2 Pi-Holes | '-----+------' '------------' | 192.168.150.14 & 15/24 | ...-----+-----... (Clients/Servers) -
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Wo ist der Unterschied zwischen einem Router und dem ISP Gateway?
Dass ein vorgelagerter Router im Heimnetzwerk auch dann noch antwortet, wenn ein Bagger Kleinholz aus der Anschlussleitung gemacht hat, aber das hast du ja oben schon selbst erwähnt.
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Für ein entferntes Monitoringziel hätte ich das ja verstanden
Darauf hatte ich mich bezogen.
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
aber für ein Gerät, welches 50cm neben der pfSense bzw dem internen Router steht? Da hätte ich mir gedacht, dass eigentliche alle Pings durchgehen müssten...
Da hängt es auch vom Gerät (und von dessen Auslastung) ab, ob und wie viele der ICMP Requests unbeantwortet bleiben.
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Ich habe zusätzlich auch die Monitoring IP für WAN_2 einmal auf 9.9.9.10 gesetzt
Ich würde jeweils einen Tag lang Google, Cloudflare und Quad9 ausprobieren und dann das nehmen, was am stabilsten läuft. Von meinem Telekomanschluss aus läuft Cloudflare beispielsweise relativ mies. Unter Status / Monitoring kannst du dir die Paket Loss und Latenzen anzeigen lassen.
-
@thiasaef said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Ich würde jeweils einen Tag lang Google, Cloudflare und Quad9 ausprobieren und dann das nehmen, was am stabilsten läuft. Von meinem Telekomanschluss aus läuft Cloudflare beispielsweise relativ mies. Unter Status / Monitoring kannst du dir die Paket Loss und Latenzen anzeigen lassen.
Herzlichen Dank für den super Tip!
Ich werd' mir die Situation damit einmal eine Zeit lang ansehen und dann entscheiden wie ich weiter mache.Was ist denn so die Erwartungshaltung - ich meine was ist relativ gut, was ist relativ mies auf einer ISP / WAN Leitung?
Mir fehlen da total die Erfahrungswerte was eigentlich ok ist.... -
@eyetap an meinem SVDSL Anschluss sieht es mit
8.8.8.8alsMonitor IPfolgendermaßen aus:
-
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Der Cisco RV345 war da extrem schnell - wenn man die Leitung abgesteckt hat ging da teilweise nicht einmal ein Ping verloren.
abgesteckt ist auch Link Down Event - da bekommt jedes Gerät auch die Sense ein Interface Event und kann darauf reagieren. Auf "vorgeschalteter Router verliert Internet" kann sie nur reagieren (weil der Router läuft und pingt) indem sie dann irgendwann durch den GW Check merkt - oh die ping losses häufen sich. Das GW Pinging kann ja genau deshalb beliebig angepasst und verändert werden von loss über quality und lag und mehr oder weniger Pings etc. etc.
@thiasaef said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Ich bin absolut dafür, seinen eigenen Resolver zu verwenden, aber die Geschwindigkeit wird bei einem Heimanschluss mit an Sicherheit grenzender Wahrscheinlichkeit darunter leiden.
Leiden ist da aber sehr relativ. Ich stelle einfach mal zum Versuch in Abrede, dass man einen einzelnen Request von vllt. 250-350ms als schlechter Wert angenommen vs. einem Forwarder Wert von vllt 25-50ms SO hart merkt, wenn die darauf folgenden schlicht ~0 sind da Cache Wert? :)
@thiasaef said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Über das Verhältnis von Latency Thresholds, Packet Loss Thresholds und Probe Interval kannst du doch eigentlich relativ fein einstellen, wie "mies" die Leitung sein muss, bevor sie als 'Down' gebrandmarkt wird. Siehe: https://docs.netgate.com/pfsense/en/latest/routing/gateway-configure.html (den Stecker kannst du ja dann immer noch von Hand abziehen, wenn dir die automatische Umschaltung zu lange dauert).
Absolut, das ist genau das was ich weiter oben meinte! :)
Diese Leitungs-Beobachtungen stammten aus Zeiten mit dem alten RV345, der wie gesagt sehr schnell umgeschaltet hat. Darum bin ich bei den Gateways als Monitoringziel geblieben, zumal ja auch die GUI diese Verwendung irgendwie auch nahelegt. (siehe oben)
Ich glaube da missverstehst du den Satz:
"Enter an alternative address here to be used to monitor the link. This is used for the quality RRD graphs as well as the load balancer entries. Use this if the gateway does not respond to ICMP echo requests (pings)."
Da geht es um dein Gateway. Nicht um einen Router davor vom Provider wie ne Fritte o.ä., sondern bspw. bei DSL um dein Providergateway. Die Seite vom Uplink. DAS ist nämlich durchaus nicht ungewöhnlich, dass bei Telekom DSL Anschlüssen der direkte nächste Hop - dein Upstream Gateway NICHT pingt. Das ist sogar schon sehr sehr lange so. Bei anderen - wie Kabelboxen - pingt der next hop sogar gerne. Daher kann man den GW Ping überschreiben um überhaupt ne Antwort zu bekommen.
Tipp: einfach mal einen MTR/traceroute vom Gerät machen zu bspw. 1.1.1.1 und schauen, was die nächsten HOPs sind. Bei Telekom DSL ist - wenn man selbst PPPoE macht - der next hop "tot" und erst der übernächste antwortet. Bei Kabel antwortet der nächste schon. Daher kann man hier auch gerne bei DSL statt 1.1.1.1 o.ä. den übernächsten Hop von der Telekom nehmen, der oft sehr gut antwortet und auch nicht so weit von einem weg ist. :)
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
ist ja auch nicht unwesentlich zu wissen, dass die pfSense für diese Monitoring IP's offenbar statische Routen setzt (nicht unter statischen Routen zu finden, aber im Log wird das vermerkt), die natürlich an das jeweilige Gateway gebunden sind.
Das steht aber recht gut sichtbar und erklärt in der Doku. Es ist auch logisch, dass das gemacht wird, denn sonst wären diese IPs als Monitor völlig wertlos, wenn sie nicht per Host Route über das entsprechende Gateway geroutet würden - ohne das würde das Monitoring bspw. von WAN2 via 9.9.9.10 einfach die IP via WAN1 auflösen (weil Routing Table dann ja sagt - WAN1 ist alive & active) und dadurch würde der IF Down nicht erkennbar.
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Ja. Und offenbar startet UBound auch jedes mal neu wenn DHCP Adressen in die DNS DB eingetragen werden...
kommt drauf an welche aber ja, auch das steht IMHO in der Doku beschrieben. dynamische Client DHCP Registrations machen aber im DNS auch oftmals wenig Sinn. Statische DHCP Mappings werden einmal beim Start eingelesen. Aber ja, da ist noch ein Defizit.
--
Sorry jetzt erst gesehen, dass da ein ganze Teil an Diskussion nicht geladen wurde. Hatte ich übersehen :) -
@jegr said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Es ist auch logisch, dass das gemacht wird, denn sonst wären diese IPs als Monitor völlig wertlos, wenn sie nicht per Host Route über das entsprechende Gateway geroutet würden
Als Laie hätte ich gedacht, das Ganze wird statefull gemacht, also anlassbezogen und nicht mit festen Routen...
-
@thiasaef said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
an meinem SVDSL Anschluss sieht es mit 8.8.8.8 als Monitor IP folgendermaßen aus...
Die sind schon sehr schön. Ich komme hier auf folgende Werte (ausgeführt auf der pfSense)
--- 1.1.1.1 ping statistics --- 100 packets transmitted, 100 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 6.716/8.256/17.073/1.230 ms --- 8.8.8.8 ping statistics --- 100 packets transmitted, 100 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 9.961/11.173/12.397/0.846 ms@thiasaef said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
kein Wunder, dass dir die Failover Detection regelmäßig um die Ohren flog
Welche Werte haltet ihr denn für die Failover-Detection für vernünftig...?
@jegr said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Ich glaube da missverstehst du den Satz:
"Enter an alternative address here to be used to monitor the link. This is used for the quality RRD graphs as well as the load balancer entries. Use this if the gateway does not respond to ICMP echo requests (pings)."
Da geht es um dein Gateway. Nicht um einen Router davor vom Provider wie ne Fritte o.ä., sondern bspw. bei DSL um dein Providergateway. Die Seite vom Uplink.Ich muss gestehen, dass ich das überaus verwirrend finde. Für mich ist das Provider Gateway (= Provider Router) das erste Teil das dem Provider gehört und ohne das ich hier nicht ins Internet komme - also das Teil das dann die Daten nicht über Ethernet-Kabel sondern über entweder Telefonleitungen (xADSL) oder Koax weitergibt.
Genau das gleiche Teil dessen IP ich halt auch @System/Routing/Gateways als Gateway Adresse eingeben muss, damit das Routing überhaupt funktioniert.
Sonst habe ich hier keine Providerteile stehen.Ich denke die Situation könnte da in AT eine etwas andere sein als in DE....
@jegr said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Es ist auch logisch, dass das gemacht wird, denn sonst wären diese IPs als Monitor völlig wertlos, wenn sie nicht per Host Route über das entsprechende Gateway geroutet würden
Jein. Ich vermute doch, dass es da unterschiedliche Implementierungen gibt - in dem Sinn, dass diese statischen Routen ev. nicht unbedingt auch für das gesamte hinter dem Router gelten müssen - wäre ja durchaus auch möglich, dass das nur für den Router bzw nur auf dem jeweilgen WAN IF entsprechend geroutet wird.
@bob-dig said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Als Laie hätte ich gedacht, das Ganze
Ich glaube das ist exakt der Punkt - wobei ich den Begriff Laie hier großzügiger gefasst hätte - ich bin schon auch in der IT aktiv, aber nicht so sehr in der Netzwerktechnik, noch weniger im WAN-Bereich, und habe de facto keine Erfahrung mit unixoiden Systemen oder gar der pfSense.
Ich habe das Teil in einem Vortrag kennen gelernt und mir gedacht, dass das echt super ist und meinen RV345 (der demnächst EOL ist) ersetzen könnte - allerdings sehe ich mittlerweile für mich keine Chance mehr die pfSense auch nur in allen mich betreffenden Aspekten vollständig zu erfassen.
Dazu fehlt mir einfach das Hintergrundwissen und auch leider die Zeit - da bin ich wirklich auf die Unterstützung der Community angewiesen...
Und ja, es steht sehr viel in der Doku - das bedeutet aber nicht, dass man auch alles was man dort liest unmittelbar versteht oder sich merkt.... ich denke man lernt einfach kontinuierlich dazu...
Das ist keine Kritik an der pfSense oder Doku, das ist, denke ich aber, einfach menschlich....Mittlerweile bin ich wohl aber auch irgendwie an einem Punkt angelangt, an dem ich mir Gedanken mache, ob die pfSense nicht leider doch eine Nummer zu groß/komplex für mich ist.
Allerdings sind wirkliche Alternativen für Dual-WAN Router/Firewalls welche mehrere VLans etc unterstützen doch recht dünn gesät - und wenn ich mir ansehe was man da über Sicherheitslücken bei manchen Anbietern liest ist das auch nicht wirklich vertrauenserweckend... -
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
und wenn ich mir ansehe was man da über Sicherheitslücken bei manchen Anbietern liest ist das auch nicht wirklich vertrauenserweckend...
Und andere Firewalls kosten Geld...
Leider ist mir dein Thread schon zu groß geworden, aber zum Thema DNS ist mir aufgefallen, dass ich Probleme habe, wenn ich im Resolver Enable SSL/TLS Service aktiviere. Warum auch immer macht mir DoT im Heimnetz Probleme.
-
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Welche Werte haltet ihr denn für die Failover-Detection für vernünftig...?
Die Standardeinstellungen tun es vollkommen.
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
Für mich ist das Provider Gateway (= Provider Router) das erste Teil das dem Provider gehört und ohne das ich hier nicht ins Internet komme
Niemand hindert dich daran, das so zu definieren, aber dann darfst du dich auch nicht wundern, wenn dich Texte, die von einer sinnvollen Definition ausgehen, verwirren. Im Handbuch steht jedenfalls absolut unmissverständlich, wie es gemeint ist:
@eyetap said in Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten:
ob die pfSense nicht leider doch eine Nummer zu groß/komplex für mich ist.
Einfach weniger an den Standardeinstellungen rumpfuschen und nicht versuchen, alle Probleme auf einmal lösen zu wollen.
