unbeantwortete ICMP Requests (Ping)
geschrieben am 05.05.2007 um 07:27 von adlerjunge
Hallo, bin mir nicht ganz sicher ob es sich hier um ein Problem oder um eine protokolltechnische Eigenheit handelt. Sniffe mit Wireshark einen Port auf einem Switch via Portmirror (D-Link Switch). Sehe die üblichen Datenpakete, die zu erwarten waren sowie diverse Broadcasts. Soweit, so gut. In dem Capturefile sind aber auch ICMP-Requests (Ping) auf Adressen zu sehen, die an dieser Stelle eigentlich nichts zu suchen hätten. Nach Recherche stelle ich fest, dass es sich hierbei um Drucker in diesem Netz handelt, die ausgeschaltet waren(die Drucker sind nicht an dem Switch mit der Wiresharkmessung angeschlossen). Die MAC-Adressen dieser Drucker wurden anscheinend vom Router gezogen, da hier der ARP-Timeout bei 4 Stunden liegt. Nach einem clear arp waren diese Pakete (natürlich) nicht mehr zu sehen. Frage: Werden ICMP-Requests als eine Art Broadcast im LAN versendet, wenn die Zieladresse (Drucker) nicht antwortet oder woran könnte dieser Effekt liegen ???
geschrieben am 05.05.2007 um 12:40 von bewa
Re: unbeantwortete ICMP Requests (Ping)
Moin.
In dem Capturefile sind aber auch ICMP-Requests (Ping) auf Adressen zu sehen, die an dieser Stelle eigentlich nichts zu suchen hätten. Nach Recherche stelle ich fest, dass es sich hierbei um Drucker in diesem Netz handelt, die ausgeschaltet waren(die Drucker sind nicht an dem Switch mit der Wiresharkmessung angeschlossen).
An welchem (Layer2-)Switch die Drucker angeschlossen sind, ist bei funktionierendem Netz für einen "Ping" egal. Sind die Drucker denn im gleichen L3-(Sub-)Netz, also im gleichen IP-Subnetz? Wer sendet denn die Echo Requests? Clients? Aus dem gleichen Subnetz?
Die MAC-Adressen dieser Drucker wurden anscheinend vom Router gezogen, da hier der ARP-Timeout bei 4 Stunden liegt.
Was meinst du mit "vom Router gezogen"? Normalerweise beantwortet der Router nicht die ARP-Anfragen stellvertretend für Clients die im gleichen Netz stehen.
Nach einem clear arp waren diese Pakete (natürlich) nicht mehr zu sehen.
Welche? Die ICMP-Echo-Requests? Die Aussage macht so technisch keinen Sinn. Wenn nichts mehr im ARP-Cache steht und jemand möchte pingen, dann schickt er halt einen ARP-Request und danach wieder die ICMP-Echo-Requests.
Frage: Werden ICMP-Requests als eine Art Broadcast im LAN versendet,
Bitte bei ICMP immer sauber formulieren was gemeint ist. Du meinst Echo Requests ("Ping")? Die können als Broadcast (IPv4) oder Unicast (IPv4+IPv6) verschickt werden.
wenn die Zieladresse (Drucker) nicht antwortet oder woran könnte dieser Effekt liegen ???
Daher oben die Frage wer diese Pakete sendet. Ich habe mir das länger nicht mehr näher angeschaut, würde aber spontan auf einen Druckertreiber oder einen Druckdienst tippen, der schauen möchte ob der Drucker noch an ist.
geschrieben am 06.05.2007 um 10:04 von adlerjunge
Re: unbeantwortete ICMP Requests (Ping)
Moin.
In dem Capturefile sind aber auch ICMP-Requests (Ping) auf Adressen zu sehen, die an dieser Stelle eigentlich nichts zu suchen hätten. Nach Recherche stelle ich fest, dass es sich hierbei um Drucker in diesem Netz handelt, die ausgeschaltet waren(die Drucker sind nicht an dem Switch mit der Wiresharkmessung angeschlossen).
Hallo bewa, erstmal Danke, dass du dich der Sache angenommen hast. Ne Menge Fragen, ich versuche mal, diese so gut wie möglich zu beantworten
An welchem (Layer2-)Switch die Drucker angeschlossen sind, ist bei funktionierendem Netz für einen "Ping" egal. Sind die Drucker denn im gleichen L3-(Sub-)Netz, also im gleichen IP-Subnetz? Wer sendet denn die Echo Requests? Clients? Aus dem gleichen Subnetz?
Also, die Drucker befinden sich im gleichen L3-Subnetz wie auch der PC, dessen Port ich gesnifft hatte. Die Echo Requests kommen von einem remoten Netz, dort steht ein Unix-Server auf dem lt. einem Admin ein Script läuft, welches die Verfügbarkeit von bestimmten Druckern prüft.
Die MAC-Adressen dieser Drucker wurden anscheinend vom Router gezogen, da hier der ARP-Timeout bei 4 Stunden liegt.
Was meinst du mit "vom Router gezogen"? Normalerweise beantwortet der Router nicht die ARP-Anfragen stellvertretend für Clients die im gleichen Netz stehen.
Ist nur eine Vermutung, da der/die Drucker ausgeschaltet war(en) könnte jemand im Netz den Arp-Request beantworten, in dessen ARP-Cache noch ein Eintrag für diesen Drucker vorhanden ist, in diesem Fall evtl. der Router.
Nach einem clear arp waren diese Pakete (natürlich) nicht mehr zu sehen.
Welche? Die ICMP-Echo-Requests? Die Aussage macht so technisch keinen Sinn. Wenn nichts mehr im ARP-Cache steht und jemand möchte pingen, dann schickt er halt einen ARP-Request und danach wieder die ICMP-Echo-Requests.
HHmmm, den clear arp habe ich auf dem Router durchgeführt. Danach waren auf dem Snifferprotokoll keine ICMP-Echo-Requests für die besagten(ausgeschalteten) Drucker mehr zu sehen, da anscheinend nun niemand mehr einen Eintrag im ARP-Cache für diese Drucker besitzt. Gut was ich dann im Protokoll sehe sollte wären die ARP-Requests, leider habe ich auf ARP-Requests mehr oder weniger nicht geachtet, werde ich Morgen mal gleich nachholen.
Frage: Werden ICMP-Requests als eine Art Broadcast im LAN versendet,
Bitte bei ICMP immer sauber formulieren was gemeint ist. Du meinst Echo Requests ("Ping")? Die können als Broadcast (IPv4) oder Unicast (IPv4+IPv6) verschickt werden.
Ja, ich meinte Echo-Requests. Bedeutet das, wenn wie geschehen ein ARP-Request für eine Rescoure, die derzeit nicht aktiv ist, aufgelöst(beantwortet) wird, ein Ping (Echo-Request) als Broadcast durchs L2-Netz gesendet wird, weil z.B. die entsprechende MAC-Adresse in den MAC-Adresss-Tabellen der L2-Switche nicht zu finden ist?
wenn die Zieladresse (Drucker) nicht antwortet oder woran könnte dieser Effekt liegen ???
Daher oben die Frage wer diese Pakete sendet. Ich habe mir das länger nicht mehr näher angeschaut, würde aber spontan auf einen Druckertreiber oder einen Druckdienst tippen, der schauen möchte ob der Drucker noch an ist.
geschrieben am 06.05.2007 um 13:44 von bewa
Re: unbeantwortete ICMP Requests (Ping)
Moin.
Also, die Drucker befinden sich im gleichen L3-Subnetz wie auch der PC, dessen Port ich gesnifft hatte. Die Echo Requests kommen von einem remoten Netz, dort steht ein Unix-Server auf dem lt. einem Admin ein Script läuft, welches die Verfügbarkeit von bestimmten Druckern prüft.
Das ist doch dann soweit erstmal korrekt?! Das Script soll ja scheinbar diese Pings aussenden, die du gesehen hast.
Was meinst du mit "vom Router gezogen"? Normalerweise beantwortet der Router nicht die ARP-Anfragen stellvertretend für Clients die im gleichen Netz stehen.
Ist nur eine Vermutung, da der/die Drucker ausgeschaltet war(en) könnte jemand im Netz den Arp-Request beantworten, in dessen ARP-Cache noch ein Eintrag für diesen Drucker vorhanden ist, in diesem Fall evtl. der Router.
Das sollte er nicht machen, da es technisch keinen Sinn ergibt. Aber das kannst du schnell raus finden. Arp-Cache auf dem Client leeren, einen der nicht angeschalteten Drucker anpingen und dann im Dump nachschauen ob jemand für den Drucker geantwortet hat.
Ein ARP-Request wird eigentlich nur dann stellvertretend für einen Host beantwortet, wenn Proxy ARP eingesetzt wird. Was das ist findest du z.B. in Wikipedia. Es kommt heutzutage recht selten vor. Kommt sowas trotzdem vor, ist es normalerweise ein Fehler oder ein Angriff. (ARP Poisoning)
HHmmm, den clear arp habe ich auf dem Router durchgeführt. Danach waren auf dem Snifferprotokoll keine ICMP-Echo-Requests für die besagten(ausgeschalteten) Drucker mehr zu sehen, da anscheinend nun niemand mehr einen Eintrag im ARP-Cache für diese Drucker besitzt. Gut was ich dann im Protokoll sehe sollte wären die ARP-Requests, leider habe ich auf ARP-Requests mehr oder weniger nicht geachtet, werde ich Morgen mal gleich nachholen.
Das darf den Ping gar nicht interessieren! Der Protokoll-Stack schaut nur nach, ob für das Ziel (wenn es im gleichen Subnetz ist) oder für das Gateway (Ziel in anderem L3-Subnetz) ein ARP-Eintrag da ist. Wenn nicht, macht er einen ARP-Request. Siehe z.B.
http://upload.wikimedia.org/wikipedia/de/f/fd/ARP_und_Routing.png
Der einzige Unterschied darf also nur sein: Wenn der ARP-Cache auf dem Host, von dem aus die pingst von dir geleert wurde, siehst du für jedes Ziel das du von diesem Host aus anpingst ARP-Requests.
Ja, ich meinte Echo-Requests. Bedeutet das, wenn wie geschehen ein ARP-Request für eine Rescoure, die derzeit nicht aktiv ist, aufgelöst(beantwortet) wird, ein Ping (Echo-Request) als Broadcast durchs L2-Netz gesendet wird, weil z.B. die entsprechende MAC-Adresse in den MAC-Adresss-Tabellen der L2-Switche nicht zu finden ist?
Ein Ping kann wie gesagt als Broadcast oder Unicast gesendet werden, meistens handelt sich um einen Unicast. Viele Clients ignorieren auch einen Broadcast Ping, auch wenn sie das theoretisch nicht sollten.
Wenn der Zielrechner nicht (mehr) in der Tabelle des Switches enthalten ist, sendet er den Frame auf allen Ports, ausgenommen derjenige auf dem er ihn empfangen hat. Das macht er solange, bis ein Rechner mit der entsprechenden MAC-Adresse geantwortet hat. Das hängt aber nicht mit ARP zusammen - der Switch kann höchstens ARP-Pakete nutzen, um Adressen zu lernen.
geschrieben am 06.05.2007 um 16:10 von adlerjunge
Re: unbeantwortete ICMP Requests (Ping)
Was meinst du mit "vom Router gezogen"? Normalerweise beantwortet der Router nicht die ARP-Anfragen stellvertretend für Clients die im gleichen Netz stehen.
Ist nur eine Vermutung, da der/die Drucker ausgeschaltet war(en) könnte jemand im Netz den Arp-Request beantworten, in dessen ARP-Cache noch ein Eintrag für diesen Drucker vorhanden ist, in diesem Fall evtl. der Router.
Das sollte er nicht machen, da es technisch keinen Sinn ergibt. Aber das kannst du schnell raus finden. Arp-Cache auf dem Client leeren, einen der nicht angeschalteten Drucker anpingen und dann im Dump nachschauen ob jemand für den Drucker geantwortet hat.
Ein ARP-Request wird eigentlich nur dann stellvertretend für einen Host beantwortet, wenn Proxy ARP eingesetzt wird. Was das ist findest du z.B. in Wikipedia. Es kommt heutzutage recht selten vor. Kommt sowas trotzdem vor, ist es normalerweise ein Fehler oder ein Angriff. (ARP Poisoning)
Bei dem Router handelt es sich um einen L3-Switch von Cisco, lt. Cisco ist Proxy-ARP defaultmäßig auf sämtlichen Interfacen eingeschaltet, zumindest ist es so bei dem beschriebenen Fall. Wäre das jetzt eine Erklärung für das Verhalten ? Irgendwie verliere ich jetzt den Überblick. Ob Proxy-Arp oder auch nicht, ich bin davon ausgegangen, dass der Router (oder L3-Switch) bei einem IP-Paket (in diesem Fall Echo Request) aus Richtung des WAN-Inferfaces zunächst immer auf seine ARP-Table schaut, ob er für die Destination(Ziel)-IP-Adresse in seinem LAN einen Eintrag besitzt, wenn ja, wird die entsprechende MAC-Adresse übernommen, wenn nein wird ein ARP-Request versendet. Wenn wie bei meinem Vorgang sich auf dem Router auf Grund eines konfigurierten ARP-Timeouts von 4 Stunden noch sehr alte Einträge befinden werde diese (natürlich) trotzdem verwendet !?
HHmmm, den clear arp habe ich auf dem Router durchgeführt. Danach waren auf dem Snifferprotokoll keine ICMP-Echo-Requests für die besagten(ausgeschalteten) Drucker mehr zu sehen, da anscheinend nun niemand mehr einen Eintrag im ARP-Cache für diese Drucker besitzt. Gut was ich dann im Protokoll sehe sollte wären die ARP-Requests, leider habe ich auf ARP-Requests mehr oder weniger nicht geachtet, werde ich Morgen mal gleich nachholen.
Das darf den Ping gar nicht interessieren! Der Protokoll-Stack schaut nur nach, ob für das Ziel (wenn es im gleichen Subnetz ist) oder für das Gateway (Ziel in anderem L3-Subnetz) ein ARP-Eintrag da ist. Wenn nicht, macht er einen ARP-Request. Siehe z.B.
http://upload.wikimedia.org/wikipedia/de/f/fd/ARP_und_Routing.png
Der einzige Unterschied darf also nur sein: Wenn der ARP-Cache auf dem Host, von dem aus die pingst von dir geleert wurde, siehst du für jedes Ziel das du von diesem Host aus anpingst ARP-Requests.
Ja, ich meinte Echo-Requests. Bedeutet das, wenn wie geschehen ein ARP-Request für eine Rescoure, die derzeit nicht aktiv ist, aufgelöst(beantwortet) wird, ein Ping (Echo-Request) als Broadcast durchs L2-Netz gesendet wird, weil z.B. die entsprechende MAC-Adresse in den MAC-Adresss-Tabellen der L2-Switche nicht zu finden ist?
Ein Ping kann wie gesagt als Broadcast oder Unicast gesendet werden, meistens handelt sich um einen Unicast. Viele Clients ignorieren auch einen Broadcast Ping, auch wenn sie das theoretisch nicht sollten.
Wenn der Zielrechner nicht (mehr) in der Tabelle des Switches enthalten ist, sendet er den Frame auf allen Ports, ausgenommen derjenige auf dem er ihn empfangen hat. Das macht er solange, bis ein Rechner mit der entsprechenden MAC-Adresse geantwortet hat. Das hängt aber nicht mit ARP zusammen - der Switch kann höchstens ARP-Pakete nutzen, um Adressen zu lernen.[/quote]
geschrieben am 07.05.2007 um 11:52 von bewa
Re: unbeantwortete ICMP Requests (Ping)
Bei dem Router handelt es sich um einen L3-Switch von Cisco, lt. Cisco ist Proxy-ARP defaultmäßig auf sämtlichen Interfacen eingeschaltet, zumindest ist es so bei dem beschriebenen Fall.
Proxy-Arp würde ich immer abschalten, ("no ip proxy-arp") wenn es nicht benötigt wird und lieber sauber routen. Das verursacht sonst u.U. Seiteneffekte wenn man sie gar nicht gebrauchen kann und nicht damit rechnet.
Schalte es doch mal ab und schau nach was passiert. Wenn es dann zu Schwierigkeiten kommt kannst du es ja schnell wieder einschalten - dann läuft aber bei eurem Routing auch etwas falsch und funktionierte bisher nur zufällig dank Proxy-Arp.
Wäre das jetzt eine Erklärung für das Verhalten ?
Proxy-ARP greift, wenn sich die beiden kommunizierenden Hosts in verschiedenen IP-Subnetzen befinden. Dann greift der dazwischen installierte Router ein und manipuliert gezielt den ARP-Verkehr in beide Richtungen. Heutzutage fast immer unnötig - einfach die beiden Hosts komplett konfigurieren (inkl. Gateway) und dazwischen routen.
Ob Proxy-Arp oder auch nicht, ich bin davon ausgegangen, dass der Router (oder L3-Switch) bei einem IP-Paket (in diesem Fall Echo Request) aus Richtung des WAN-Inferfaces zunächst immer auf seine ARP-Table schaut, ob er für die Destination(Ziel)-IP-Adresse in seinem LAN einen Eintrag besitzt, wenn ja, wird die entsprechende MAC-Adresse übernommen, wenn nein wird ein ARP-Request versendet.
Ja, soweit richtig wenn ich gerade nichts übersehen habe.
Wenn wie bei meinem Vorgang sich auf dem Router auf Grund eines konfigurierten ARP-Timeouts von 4 Stunden noch sehr alte Einträge befinden werde diese (natürlich) trotzdem verwendet !?
Ja, die werden solange verwendet bis entweder ein gratious arp paket kommt, oder der timer abläuft. Fliegen sie dann aus der Tabelle kommt wieder ein ARP-Request.
Ich verliere jetzt auch langsam den Überblick? Was genau ist denn jetzt deine Frage? :-)
Du hattest vorher mal erwähnt, das keine "Pings" mehr kamen, nachdem du den ARP-Cache geleert hast. Das "darf" aber nicht daran liegen - wenn kein Eintrag mehr im ARP-Cache ist, dann schickt er halt einen ARP-Request.
[ Dieses Thema im Live-Forum aufrufen ]
|
