nicht angemeldet
/Netzwerk - ping problem
Morgen alle.
Bei uns in der WG tritt ein recht komisches, für mich absolut unverständliches problem auf.
Bei jegliche requests (domain/IP) auf eine domain die nicht gecasht ist -- also noch nicht besucht wurde), dauert der erste ping zwischen 4-30 sekunden.
Der DNS name wird sofort aufgelöst, aber der erste ping lässt auf sich warten.
Im netztwerk fungiert ein http://www.fli4l.de router als gateway und dns server, er hat das gleiche problem. Insgesammt befinden sich 11 rechner im Netz (windows, linux), über mehrere switches (was wohl nicht die ursache des problems ist).
Mir ist nicht ganz klar wie ich rausfinden kann ob es ein provider (http://www.qsc.de) problem ist oder vielleicht ein interner konfigurations fehler.
(Sorry für die komische topic)
Wäre dankbar für ratschläge jeder art.
Mfg entropie
-
Hallo
Bei jegliche requests (domain/IP) auf eine domain die nicht gecasht ist -- also noch nicht besucht wurde),
Wo gecached? Der Browser-Cache speichert keine für ping relevanten Daten zwischen.
Der DNS name wird sofort aufgelöst, aber der erste ping lässt auf sich warten.
Die DNS-Antwort kommt aus dem fli4l-DNS-Cache. Dafür muss ggf. keine Online-Verbindung bestehen.
dauert der erste ping zwischen 4-30 sekunden.
Im netztwerk fungiert ein http://www.fli4l.de router als gateway und dns server, er hat das gleiche problem.Aha. Also auch ein ping vom Router-System aus dauert zunächst mal 4-30 Sekunden? Dann wählt sich da irgendwas zunächst mal wieder beim Provider ein. Wie ist die Online-Anbindung gewährleistet? Modem oder ISDN oder DSL mit dial-on-demand direkt vom Router oder noch ein weitere externes Gerät zur ISDN- bzw. DSL-Einwahl?
viele Grüße
Axel
-
Hallo
Wo gecached? Der Browser-Cache speichert keine für ping relevanten Daten zwischen.
Das war mir klar, es ist ja auch nicht auschliesslich ein Browser problem. Allerdings:
beispiel google.de
Nach nem reboot meiner linux workstation mache ich nen ping auf google.de, der erste ping dauert wieder länger dann gehts. ALle weiteren pings auf google.de gehen normal schnell.
Nach nem reboot selbes problem -- das irritiert mich wirklich.Aha. Also auch ein ping vom Router-System aus dauert zunächst mal 4-30 Sekunden? Dann wählt sich da irgendwas zunächst mal wieder beim Provider ein. Wie ist die Online-Anbindung gewährleistet? Modem oder ISDN oder DSL mit dial-on-demand direkt vom Router oder noch ein weitere externes Gerät zur ISDN- bzw. DSL-Einwahl?
QDSL splitter mit 4 fach switch (modell nummer kann ich grad nicht on-the-fly sagen), und standard QSC DSL anschluss (1024/512)
Dazu fli4l, diskettenkonfiguration ohne zusätzliche module.
Der router ist immer on, und wählt sich sofort wieder ein. (abgesehen davon das die QSC zwangstrennung erst ca nach 1 woche zuschlägt)So long, danke schonmal
mfg entropie-
Hallo
QDSL splitter mit 4 fach switch (modell nummer kann ich grad nicht on-the-fly sagen), und standard QSC DSL anschluss (1024/512)
Dazu fli4l, diskettenkonfiguration ohne zusätzliche module.
Der router ist immer on, und wählt sich sofort wieder ein. (abgesehen davon das die QSC zwangstrennung erst ca nach 1 woche zuschlägt)Also ein Einwahlproblem ist es nicht.
beispiel google.de
Nach nem reboot meiner linux workstation mache ich nen ping auf google.de, der erste ping dauert wieder länger dann gehts. ALle weiteren pings auf google.de gehen normal schnell.
Nach nem reboot selbes problem -- das irritiert mich wirklich.Hm, reboot. Braucht DHCP solange, um die Lease zu bestätigen? Laufen noch andere Socket-Anwendungen hoch, die das Netzwerk blockieren?
Du kannst nur austesten, auf welcher Seite das Problem liegt. Wenn der fli4l-Router direkt am DSL hängt und auch ein ping vom laufenden Router-System aus dauert zunächst mal 4-30 Sekunden, dann liegts wahrscheinlich am Provider.
Du kannst mit einer Route-Verfolgung (tracert bei Windows bzw. traceroute bei Linux) herausbekommen, wo es hängt. Also Linux-Workstation bzw. Router rebooten und dann statt ping ein traceroute.
viele Grüße
Axel
-
-
-
Hello,
das Problem kenne ich auch noch aus den Zeiten unserer Internet-Standleitung von der Telekom.
Wir hatten einen Proxy-Server laufen und der hat manchmal sogar einen Timeout produziert.Erklärt wurde uns das damal damit, dass zwar die Namensauflösung "dichte by" stattfindet, aber bei selten aufgerufenen Seiten eben keinen Route zur Verfügung steht. Das heißt, dass jeder Hop erst ermitteln muss, wo es denn wohl weiter gehen könnte.
Das Programm traceroute (tracert) kann einem da mehr auskunft geben, was ungefähr passiert. Aber ggf. muss man die Anzahl der geprüften Hops erhöhen. Die Standardzahl reicht ggf. nicht.
Beim zweiten Aufruf einer solchen Seite sind die Hops bereits trainiert, wenn man nicht zu lange geartet hat. Dann ist nämlich die ARP-Liste bereits refresht.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
Moin!
Erklärt wurde uns das damal damit, dass zwar die Namensauflösung "dichte by" stattfindet, aber bei selten aufgerufenen Seiten eben keinen Route zur Verfügung steht. Das heißt, dass jeder Hop erst ermitteln muss, wo es denn wohl weiter gehen könnte.
Da hat man dir Schwachsinn erzählt. IP-Routing funktioniert nicht so.
Das einzige, was in Verbindung mit "selten aufgerufen" einen variablen und beim ersten Versuch recht langen Zeitanteil benötigt, ist die DNS-Auflösung. Es kann dauern, wenn die Namensauflösung über viele CNAME-Verweise, wenig Glue-Einträge und reichlich Subdomains mit Delegationen gehen muß, um die Ziel-IP herauszufinden. Und das ganze wird umso schlimmer, je langsamer die Leitungen sind oder gar Paketverluste auftreten.
Außerdem gibt es noch eine weitere Möglichkeit für eine langsame Erstantwort: Wenn die zu kontaktierende Gegenstelle nicht über eine Standleitung, sondern nur über eine "on-demand"-Leitung (z.B. ISDN-Callback-Dialup) angebunden ist und sich erst mit dem Internet verbinden muß, dann dauert der erste Datenaustausch naturgemäß auch recht lange. Sowas ist aber heutzutage die absolute Ausnahme.
Das IP-Routing selbst ist zwar durchaus dynamisch, es wird aber nicht erst "on-demand" aufgebaut, sondern entweder weiß der Router, wohin er das Datenpaket weiterleiten muß, oder er weiß es nicht (und wird dann entsprechend mit ICMP-Antworten aufwarten).
Das Programm traceroute (tracert) kann einem da mehr auskunft geben, was ungefähr passiert. Aber ggf. muss man die Anzahl der geprüften Hops erhöhen. Die Standardzahl reicht ggf. nicht.
Die Standardanzahl sind 30 Hops. Wenn man nicht gerade nach Takatukaland pingen will, sondern in Deutschland bleibt, dann sollte diese Zahl zu 99% ausreichen.
Beim zweiten Aufruf einer solchen Seite sind die Hops bereits trainiert, wenn man nicht zu lange geartet hat. Dann ist nämlich die ARP-Liste bereits refresht.
Es ist bei einem Router sehr sehr unwahrscheinlich, dass er erst die ARP-Einträge der mit ihm verbundenen anderen Router abfragen muß. Schließlich sitzen Router an zentralen Netzknoten und sollten eigentlich ständig irgendwelche Datenpakete austauschen, die ARP-Liste somit immer aktuell sein. Abgesehen davon finden ARP-Requests sowieso nur im lokalen Netzwerksegment statt, sind also verhältnismäßig schnell.
- Sven Rautenberg
-