Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten
-
@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.
