Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Teils lange Ladezeiten von Websites und hohe DNS Antwortzeiten

    Scheduled Pinned Locked Moved Deutsch
    24 Posts 5 Posters 3.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Bob.DigB
      Bob.Dig LAYER 8 @JeGr
      last edited by

      @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... 😦

      1 Reply Last reply Reply Quote 0
      • E
        EyeTap @thiasaef
        last edited by EyeTap

        @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...

        Bob.DigB T 2 Replies Last reply Reply Quote 0
        • Bob.DigB
          Bob.Dig LAYER 8 @EyeTap
          last edited by Bob.Dig

          @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.

          1 Reply Last reply Reply Quote 0
          • T
            thiasaef @EyeTap
            last edited by

            @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:

            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. Another case is when an ISP is prone to upstream failures, so pinging a host on the Internet is a more accurate test to determine if a WAN is usable rather than testing the link itself. Some popular choices include Google public DNS servers, or popular web sites such as Google or Yahoo. If the IP address specified in this box is not directly connected, a static route is added to ensure that traffic to the Monitor IP address leaves via the expected gateway. Each gateway must have a unique Monitor IP address.

            @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.

            1 Reply Last reply Reply Quote 2
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.