Netzwerkproblem mit dem Gateway
Hallo, folgendes Problem bekomme ich nicht ganz gegriffen. Rufe ich den Befehl route auf so dauert es bei längere Zeit bis in der letzten Zeile das default-gateway angezeigt wird. Nach meinen Erfahrungen ist das ein Zeichen das mit dem Gateway was nicht stimmt. Das Problem ist das diese Verzögerung verschwindets sobald das Gateway einmal Kontakt ins Internet hatte. Danach wird das Gateway fast ohne Verzögerung angezeigt. Weiter habe ich den Effekt das das eingesetzte Wiki erhebliche Verzögerungen beim editieren hat. Diese Verzögerungen verschwinden in dem Moment indem auch die oben genannten Effekte mit dem Gateway verschwinden. Zu den eingesetzten Systemen: alle Suse 10 System 1 IP 3.101 DHCP/DNS/ Gateway via DHCP System 2 IP 3.160 alle Netzwerkdaten fest eingetragen da Server für MYSQL/DNS& DHCP System 3 IP 3.168 alle Netzwerkdaten fest eingetragen. Dieses System stell für das Netz das Gateway dar. Auf dem System 168 laufen eine Proxy sowie ein Firewall-Script. Das System routet das Netz 192.168.3 auf 192.168.33 weiter in dem dann der Router ins Internet steht Das System 168 ist nicht in meinem Verantwortungsbereich. Meine Frage: Was passiert genau bevor das Gateway mit dem Befehl route angezeigt wird? Wird das konfigurierte System in diesem Moment auf Erreichbarkeit und Funktion getestet? Was mich irritiert: Sobald die 168 eine Verbindung ins Internet hatte funktioniert alles einwandfrei ohne das Proxy oder Firewall-Script verändert wurden. Danke für Tips. Gruß --
Hallo, On 3/28/2006 8:36 PM, Ralf Prengel wrote:
Hallo,
folgendes Problem bekomme ich nicht ganz gegriffen. Rufe ich den Befehl route auf so dauert es bei längere Zeit bis in der letzten Zeile das default-gateway angezeigt wird. Nach meinen Erfahrungen ist das ein Zeichen das mit dem Gateway was nicht stimmt.
Nach meinen eher dass die Namensauflösung wartet. Probier mal ob 'route -n' ohne Verzögerung geht.
Das Problem ist das diese Verzögerung verschwindets sobald das Gateway einmal Kontakt ins Internet hatte.
Hmhm... typisches Symptom.
Danach wird das Gateway fast ohne Verzögerung angezeigt. Weiter habe ich den Effekt das das eingesetzte Wiki erhebliche Verzögerungen beim editieren hat. Diese Verzögerungen verschwinden in dem Moment indem auch die oben genannten Effekte mit dem Gateway verschwinden.
Dann wird's wohl das gleiche Phänomen sein. Frag' mich aber nicht welche externen Hosts Dein Wiki zu kontaktieren versucht... wenn Du's rausfinden willst sind tcpdump oder iptraf gute Ansätze. ...
Meine Frage: Was passiert genau bevor das Gateway mit dem Befehl route angezeigt wird?
Namensauflösung.
Wird das konfigurierte System in diesem Moment auf Erreichbarkeit und Funktion getestet?
Nö.
Was mich irritiert: Sobald die 168 eine Verbindung ins Internet hatte funktioniert alles einwandfrei ohne das Proxy oder Firewall-Script verändert wurden.
Ja, denn dann kann die Adresse des Default-Gateways quasi sofort bestimmt werden.
Danke für Tips.
Gern geschehen, Arno
Gruß
-- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de
Am Dienstag, 28. März 2006 20:18 schrieb Arno Lehmann:
Hallo,
On 3/28/2006 8:36 PM, Ralf Prengel wrote:
Hallo,
folgendes Problem bekomme ich nicht ganz gegriffen. Rufe ich den Befehl route auf so dauert es bei längere Zeit bis in der letzten Zeile das default-gateway angezeigt wird. Nach meinen Erfahrungen ist das ein Zeichen das mit dem Gateway was nicht stimmt.
Nach meinen eher dass die Namensauflösung wartet. Probier mal ob 'route -n' ohne Verzögerung geht.
Nur das ein normaler ping bzw. ein nslookup von einer unbeteiligen Machine aus auf das Gateway jederzeit klappt. Es scheint nicht ganz so einfach zu sein. Gibt es da irgendeine spezielle Option die nur im Zusamenhang mit dem Gateway zum tragen kommt? Gruß -- Ralf Prengel Dortund
Hallo, On 3/28/2006 10:56 PM, Ralf Prengel wrote:
Am Dienstag, 28. März 2006 20:18 schrieb Arno Lehmann:
Hallo,
On 3/28/2006 8:36 PM, Ralf Prengel wrote:
Hallo,
folgendes Problem bekomme ich nicht ganz gegriffen. Rufe ich den Befehl route auf so dauert es bei längere Zeit bis in der letzten Zeile das default-gateway angezeigt wird. Nach meinen Erfahrungen ist das ein Zeichen das mit dem Gateway was nicht stimmt.
Nach meinen eher dass die Namensauflösung wartet. Probier mal ob 'route -n' ohne Verzögerung geht.
Nur das ein normaler ping bzw. ein nslookup von einer unbeteiligen Machine aus auf das Gateway jederzeit klappt.
Hmm. Evtl. unterschiedliche Namensauflösung auf den unterschiedlich reagierenden Rechner, oder evtl. ist Anfrage der unbeteiligten Maschinen nicht nach dem externen sondern nach dem internen Interface des Gateways?
Es scheint nicht ganz so einfach zu sein. Gibt es da irgendeine spezielle Option die nur im Zusamenhang mit dem Gateway zum tragen kommt?
Ich kenne zumindest nur die 'normalen' Möglichkeiten, und da ist es m.E. meistens die Namensauflösung die für Verzögerungen sorgt wenn keine Internetverbindung besteht. Arno
Gruß
-- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de
Am Dienstag, 28. März 2006 20:18 schrieb Arno Lehmann:
Hallo,
On 3/28/2006 8:36 PM, Ralf Prengel wrote:
Hallo,
folgendes Problem bekomme ich nicht ganz gegriffen. Rufe ich den Befehl route auf so dauert es bei längere Zeit bis in der letzten Zeile das default-gateway angezeigt wird. Nach meinen Erfahrungen ist das ein Zeichen das mit dem Gateway was nicht stimmt.
Nach meinen eher dass die Namensauflösung wartet. Probier mal ob 'route -n' ohne Verzögerung geht.
route -n kommt sofort zurück. Es scheint ein DNS Thema zu sein. Nur warum? Im Netz stehen zwei DNS Server die auch bei verfügbar sind. Auf beiden betroffenen Rechner läuft der via Yast konfigurierte Ldap-Client. Kann der ggf. das Problem versachen? Gruß -- Ralf Prengel Dortund
Hallo, On 3/29/2006 10:33 PM, Ralf Prengel wrote:
Am Dienstag, 28. März 2006 20:18 schrieb Arno Lehmann:
Hallo,
On 3/28/2006 8:36 PM, Ralf Prengel wrote:
Hallo,
folgendes Problem bekomme ich nicht ganz gegriffen. Rufe ich den Befehl route auf so dauert es bei längere Zeit bis in der letzten Zeile das default-gateway angezeigt wird. Nach meinen Erfahrungen ist das ein Zeichen das mit dem Gateway was nicht stimmt.
Nach meinen eher dass die Namensauflösung wartet. Probier mal ob 'route -n' ohne Verzögerung geht.
route -n kommt sofort zurück. Es scheint ein DNS Thema zu sein. Nur warum? Im Netz stehen zwei DNS Server die auch bei verfügbar sind. Auf beiden betroffenen Rechner läuft der via Yast konfigurierte Ldap-Client. Kann der ggf. das Problem versachen?
LDAP... sollte eigentlich nur bei Verzögerungen beim Login zum Tragen kommen ;-) Etwas schwierig die Situation von hier zu analysieren. Ich fasse nochmal kurz zusammen: Rechner Gateway, mit zwei Netzwerkinterfaces, muss offenbar auf ein timeout warten um den Namen des default-Gateways zu finden. Rechner Host hat das Problem nicht. Rechner Host hängt am "internen" Netz des Gateways. Zwei interne Nameserver stehen zur Verfügung. Soweit das was ich vom Zustand in Erinnerung habe bzw. mir erschlossen habe. Stimmt das? In dem Fall scheint mir die Sache relativ einfach: Die internen Nameserver können die IP-Adresse des externen Interfaces (Defaultroute) nicht auflösen. Der route-Befehl auf Host muss aber die Adresse des externen Interfaces des Gateways nie auflösen, denn davon weiss er nichts - sein Gateway ist ja die interne Adresse des Gateways. Umgehen kann man damit verschiedenerweise: - den internen Nameservern die externe IP bekannt machen. Ist etwas unsauber, und blöd wirds wenn Du vom Provider wechselnde Adressen zugewiesen bekommst. - Problem ignorieren. Ist blöd wenn man oft z.B. fürs Monitoring die Defaultroute checken möchte. - Problem vermeiden durch Aufruf der nötigen Programme mit (meistens) -n um die Namensauflösung auszuschalten. Ist blöd wenn man eigentlich den Namen braucht weil die IP wechseln kann. - Problem weiträumig umfahren :-) indem z.B. nicht auf Namen oder IP-Adressen getestet wird, sondern nach dem Netzwerkinterface. Das mache ich so wenn ich Internetzugänge auf Verbindung und Status prüfe: Nachsehen ob das Interface existiert (z.B. dsl0 oder ppp0), nachsehen ob es UP ist und eine IP-Adresse hat die aus dem Adressraum des Providers kommt, und dann sehen ob ein ping an die P-t-P Adresse zurückkommt, oder, wenn das vom Provider nicht vorgesehen ist, ob ein traceroute auf eine Internetadresse als Hop mit erwarteter Adresse zurückkommt. Wenn das Problem ein ganz anderes ist, oder es Dir nicht ums Monitoring geht ignorier' meine obigen Ausführungen einfach... Arno
Gruß
-- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de
participants (2)
-
Arno Lehmann -
Ralf Prengel