Dpinger Gateway offline
-
Hello Community
Mein Gateway-Status wird dauernd als offline angezeigt mit einem Verlust von 100%.
Die Ursache dafür konnte ich nicht ausfindig machen. Hat jemand von euch eine Idee, was los sein könnte?Die Systemprotokollierung zeigt mir folgendes:
Zeitpunkt Prozess PID Nachricht
Jan 10 00:42:31 dpinger WAN_DHCP 87.245.100.1: Alarm latency 0us stddev 0us loss 100%
Jan 10 00:42:29 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 87.245.100.1 bind_addr 87.245.100.49 identifier "WAN_DHCP "Herzlichen Dank
-
Im Grunde bedeutet das nichts weiter, als dass das Gateway nicht auf Pings antwortet. Manche verweigern einfach die Antwort.
Wenn du Verbindung zum Internet hast, ist sonst alles in Ordnung.Wenn das Internet funktioniert und du das lästige rote "Gateway Offline" loswerden möchtest, hast du die Möglichkeit, das Gateway Monitoring zu deaktivieren oder eine andere beliebige IP, die über das jeweilige Gateway gerouted wird (also in deinem Fall, eine Adresse im Web) und auf Pings antwortet, als Monitoring-IP einzutragen.
Beides ist in den Gateway-Einstellungen in System > Routing > Gateways möglich. -
Vielen herzlichen Dank, nun funktioniert es.
-
Kleine Frage am Rande. Würde der Eintrag des localhost (127.0.0.1) als Monitoring-IP nicht gleichwohl zur Problemlösung führen?
-
Zur Problemlösung beitragen, ja, aber das macht nicht mehr Sinn als das Monitoring zu deaktivieren. Das Gateway würde immer als online angezeigt werden, ohne dass der Zustand wirklich überprüft worden wäre.
Sollte das Monitoring eine brauchbare Info liefern, muss es eine IP prüfen, die nur über dieses Gateway erreichbar ist.
-
IIRC legt pfSense auch eine feste Route, über das entsprechende WAN interface, für die Monitor IP an. Da sollte also schon eine IP aus dem WAN eingetragen werden.
-
Genau was Grimson sagt. Deshalb sollte man bei einem custom Monitoring GW Eintrag auch darauf achten, ob man ggf. schon DNS Server unter System/General fix auf ein WAN eingetragen hat. Es kam schon vor, dass hier beim Monitoring GW jemand 8.8.8.8 für das WAN1 eingetragen hatte, bei den DNS Settings 8.8.8.8 aber auf WAN2 verdrahtet war. Damit kommt das Routing garantiert aus dem Tritt ;)
-
Zustimmung, ihr habt alle drei recht. 8) Man kann hier im Forum wie in den Doc's jedoch auch nachlesen das die Zugewiesene Monitoring IP zu Problemen führten kann. (Ping wird nicht retourniert, blocked legitimate connection, usw). Wie von euch beispielhaft gezeigt, wird in solchen fällen geraten eine externe IP w.z.b. die von Google als Monitoring IP zu verwenden. Nachteil: Die Latenzen werden erhöht, weil jede andere externe IP als die des WAN/Anbieter-Servers weiter entfernt ist. Eine andere alternative wäre das Monitoring auszuschalten. Damit wären die Latenzen wieder im Grünen, das Monitoring jedoch off und damit auch das Load Balancing. Was btw nicht zwingend auf 2 WAN gehen muss.
Meine Überlegung ging daher in die Richtung das Monitoring auf 127.0.0.1 zu setzen, wodurch die Latenzen tief, und das interne Load Balancing erhalten bleiben sollte. Nachteil klar, die Auswertungen vom Monitoring sind zu nichts zu gebrauchen. Falsch?
Sorry wen die Links fehlen. Ich hab zwar nochmal danach gesucht, wurde auf die schnelle jedoch nicht fündig. ;)
Grüsse
-
Die bei dem Gateway angezeigte Latenz ist ja nur jene, die für die Monitoring-IP gilt. Die ist für eine entfernte IP mit mehreren Hops natürlich höher als für lokale und für den Localhost natürlich am kleinsten.
Das bedeutet aber nicht, dass sich an den Latenzzeiten allgemein etwas ändert.
Einziger Nachteil, man kann durch das Monitoring einer entfernten IP keine gute Aussage über die Latenz der eignen Internet-Anbindung machen, bspw. bei DSL. Doch sagt es mir, ob die Verbindung steht oder nicht, und das ist das, was mich interessiert. Daher ist meine Empfehlung, eine möglichst "nahe" IP für das Monitoring zu wählen, die auf Pings antwortet, aber jenseits der Internetanbindung ist. Das lässt sich mit Traceroute ermitteln.Ich habe hier bspw. ein Internet-Gateway, das zwar auf Pings antwortet, jedoch diesseits der Internetanbindung liegt. Das zu monitoren ist sinnfrei. Ich hätte zwar schöne kleine Latenzen, doch das GW wird ggf. als online angezeigt, jedoch ist die Internetverbindung tot. Daher monitore ich eine entfernte IP stattdessen.
Grüße
-
Was virago sagt, plus:
wodurch die Latenzen tief, und das interne Load Balancing erhalten bleiben sollte.
Nein, zumindest nicht nach meinem Verständnis. Das LoadBalancing wäre dann völlig im Eimer. Wenn ich bspw. 2 Lines Uplink nutze, DSL und Kabel, jeweils über deren eigene Providerrouter mit exposed Host (weil benötigt), und ich setze hier mein Monitoring GW NICHT auf einen externen Host, sondern entweder auf den Router selbst oder auf 127.0.0.1 dann bekomme ich ein always-on grün mit tollem niederer Latenz. Die Latenz hat aber überhaupt keine (große) Auswirkung auf das Gateway/Monitoring (außer dass eine zu hohe Latenz im 3-4 stelligen Bereich angemängelt wird), sondern der up/down Status ist wichtig. Wenn mir DSL stirbt (oder Kabel), was ich als Default/WAN1 nutze, dann bekommt die interne LB Gruppe davon gar nichts mit, weil kein Down des Gateways signalisiert wird. Und damit ist es nicht nutzbar im Eimer.
Daher muss ich bei vorgeschaltetem Router/GW bzw. bei sowas wie TDSL (weil das Telekom Gateway meistens >90% NICHT pingbar ist) immer einen externen Monitoring Host setzen, sonst bekomme ich keine Aussage in die Logik rein, ob wirklich ein GW down ist oder nicht und es folgt auch kein Umschalten/wegnehmen eines GWs in den Gateway Gruppen.
Grüße
-
.. Wenn ich bspw. 2 Lines Uplink nutze, DSL und Kabel..
Nein eben das nicht. Ääh ja, also ja du hast recht. Genau dies war es jedoch was ich gezielt ausschließen wollte, daher auch der hinwies auf die lokalen Netzwerke. Bspw. LAN, GAST & 1 WAN anstelle DSL, Kabel & 1 LAN. Bei letzterem bin ich ja auch ganz bei dir. Ebenso bei virago's Argumentation. Wisst ihr was ich meine?
-
Wisst ihr was ich meine?
Öhm…
Nein eben das nicht. Ääh ja, also ja du hast recht. Genau dies war es jedoch was ich gezielt ausschließen wollte, daher auch der hinwies auf die lokalen Netzwerke. Bspw. LAN, GAST & 1 WAN anstelle DSL, Kabel & 1 LAN.
Nee jetzt nicht mehr, jetzt bin ich ernsthaft verwirrt :)
-
-
Soweit ich verstanden hab ist es auch möglich ein Multi-LAN Load Balancing einzurichten. Also das ganze über die lokalen Ports wie LAN, GAST, DMZ usw zu ziehen. Mit dem Ziel die geringen Kapazitäten vom WAN zu jeder Zeit möglichst effizient auszuschöpfen, und zu verhindern das bspw bei der nächsten Party oder Messe das Gäste-WLAN nicht kollabiert, wehrend im eigenen Netz noch reichlich Kapazität wäre.
???Bei Multi-WAN ist das ja was ganz anderes, mit auch weil Load Balancing (Lastverteilung) und Failover (Ausfallsicherheit) nicht das selbe sind.
-
Soweit ich verstanden hab ist es auch möglich ein Multi-LAN Load Balancing einzurichten. Also das ganze über die lokalen Ports wie LAN, GAST, DMZ usw zu ziehen.
OK das mag jetzt nicht eloquent ausgedrückt sein… aber HÄ? Ich verstehe gerade nicht, wie und warum man ein LB über LAN Interfaces ziehen sollte - was soll das bringen? Im LAN wird nicht mit Gateways geroutet somit auch keinerlei Sinn, ein LAN GW anzugeben um das dann auch noch zu balancen?! Ich verstehs nicht, sorry :)
-
Naja macht ja nichts. Ich meine jedenfalls gelesen zu haben das neben Multi-WAN, Load Balancing auch für Multi-LAN eingerichtet erden kann. Sollte dies so eingerichtet sein, kann ich mir vorstellen das Monitoring auf looback unter gegeben Umständen sinnvoll sein könnte. Die für mich spannende Frage ist ob es funktioniert, und ob es auch nach eine neustart funktionieren würde?
Ansonsten denke ich mir mal Abschalten, es sei den man hat wirklich ein aktives Load Balancing installiert oder hängt 24/7 hinter der BRD Grafik um Live mitverfolgen zu können wie das iNet ausfällt. ;D ;D ;D -
Ich verstehe LoadBalancing bei MultiLAN immer noch nicht - wie soll das funktionieren? :o
-
Ich verstehe LoadBalancing bei MultiLAN immer noch nicht - wie soll das funktionieren? :o
Vielleicht eine Verwechslung mit dem LoadBalancing bei einem LAGG, oder das LoadBalancing von z.B. HAProxy. In beiden Fällen hat das aber nichts mit dem Gateway Monitor zu tun.
-
Wäre durchaus möglich, mit auch weil ich mich nicht darum gekümmert hab. Bloß aufgeschnappt und naja.. Sollte eine Verwechslung vorliegen dann jedoch bestimmt nicht mit einem LAGG, und beim HAProxy wäre ich mir nicht-mehr so sicher. Aber nein, dann doch eher als eine der wohl verflossenen Einrichtungshilfen für Traffic Shaper, Layer7 oder so-was. Wobei ich es eigentlich schon im Sinne der Lastverteilung in Erringung habe. Und zwar in dem Sinne das Engpässe um Multi-LAN -bspw an einer Messe wo das Gäste WLAN chronisch geflutet wird- möglichst zu vermeiden, und die Bandbreite des Routers optimal zu nutzen (das stärkere LAN obsiegt den schwächeren). Das wäre sicherlich interessant zu verfolgen, jedoch nicht der wichtigste Punkt, nicht meine Frage, und insbesondere OT. Nicht war ? ;D ;)
