24
DHCP Server 2008 R2 - DHCP Server - IP Adresskonflikte
Guten Abend, wir haben 1 DHCP Server und dazu 3 DNS Server, die jeweils auf unseren 3 DC's laufen. Wir haben jetzt täglich IP-Adressebkonflikte. Unsere Clients laufen unter XP auf Hardware, aber auch unter VMWare ESXi 5.0. Die DCHP Lease Dauer haben wir vor 4 Wochen auf 1 Tag Lease reduziert, aber die Konflikte haben wir weiterhin! Wer hat Ideen, was das sein kann? Viele Grüsse abinz
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 222932
Url: https://administrator.de/contentid/222932
Ausgedruckt am: 23.11.2024 um 00:11 Uhr
24 Kommentare
Neuester Kommentar
Verdeckter DHCP im Router? IP Lease korrupt oder in einem fix vergebenem Bereich?
Also den Router schliesse ich aus? Wie kenne ich korrupte IP Leases? Statische Adressen sind in einem anderen IP-Bereich. Die Clients versuchen ihr Glück, wenn die Konflikte auftreten, erst an der IP 20 ,,,, IP 22 .... IP24 ....und diese Adressen erscheinen dann als Bad IP Adress und werden spater dann aus DHCP und DNS gelöscht.
Gibt es dazu Logs? Tritt das zu bestimmten Zeiten oder andauernd auf?
hmmm, könnte es evtl sein dass es Notebooks gibt die sich irgendwie
mit LAN und WLAN gleichzeitg verbinden/verbunden haben ?
Schau mal ob MAC-Adressen in den Leases doppelt auftauchen.
Oder google mal die ersten Zeichen der betroffenen MAC-Adressen,
dann kannst Du Dir vielleicht über den Hersteller der Netzwerkkarten
ein Bild zu den Verursachern machen.... oder vielleicht habt Ihr in
der Doku ja die MACs festgehalten....dann könnte man es einkreisen
Worin besteht denn der Koflikt ? Einfach nur die Bad_Adress-Anzeige,
oder pingst Du einen DNS-Namen an und es kommt die falsche IP
(sprich auch die DNS-Auflösung läuft falsch)
Gruss
RS
mit LAN und WLAN gleichzeitg verbinden/verbunden haben ?
Schau mal ob MAC-Adressen in den Leases doppelt auftauchen.
Oder google mal die ersten Zeichen der betroffenen MAC-Adressen,
dann kannst Du Dir vielleicht über den Hersteller der Netzwerkkarten
ein Bild zu den Verursachern machen.... oder vielleicht habt Ihr in
der Doku ja die MACs festgehalten....dann könnte man es einkreisen
Worin besteht denn der Koflikt ? Einfach nur die Bad_Adress-Anzeige,
oder pingst Du einen DNS-Namen an und es kommt die falsche IP
(sprich auch die DNS-Auflösung läuft falsch)
Gruss
RS
Hallo RS,
MAC_NIC_Lan != Mac_NIC_WLAN. Anders dürfte es nicht sein.
Eher könnte es sein, dass einer oder mehrere PCs doch fixe IPs haben.
MAC_NIC_Lan != Mac_NIC_WLAN. Anders dürfte es nicht sein.
Eher könnte es sein, dass einer oder mehrere PCs doch fixe IPs haben.
hi certifiedit,
ja ist klar. Ich meinte hiermit dass ein Computername vielleicht 2x auftaucht,
(im DHCP und/oder in den DNS-Zonen),
also mit verschiedenen MACs (LAN & WLAN) oder so was. multihomed.
Aber das mit der fixen IP hört sich auch logisch an, falls dass einer am Client
auf "fix" umgestellt hat, aber das müsste dann doch mit Löschen der Lease und der evtl.
festen Lease erledigt sein und die Bad_Address dürfte nicht mehr auftauchen (?)
Gruss RS
Hallo RS,
ok, Missverständnis. Aber dennoch sollte ein Multi MAC,IP = DNS EIntrag keine BAD Adress zur Folge haben.
Ist aber hier alles etwas sehr im trüben fischen. Das letzte mal hatte ich solche Probleme bei einem antiquirten Kassensystem von 1995, das so proprietär ist, dass der (quasi) geschenkte Kundendienst günstiger ist, als sich durch eine Daten und Systemumstellung zu quälen.
ok, Missverständnis. Aber dennoch sollte ein Multi MAC,IP = DNS EIntrag keine BAD Adress zur Folge haben.
Ist aber hier alles etwas sehr im trüben fischen. Das letzte mal hatte ich solche Probleme bei einem antiquirten Kassensystem von 1995, das so proprietär ist, dass der (quasi) geschenkte Kundendienst günstiger ist, als sich durch eine Daten und Systemumstellung zu quälen.
1ja genau, mit den manchmal "wirren" Gedanken & Anregungen bringt man die Leute vielleicht auf die richtige Spur
so, jetzt www.AbinsBett.de
:O)
Danke für die Infos. Kann das Problem evtl. auch an den Clients liegen?
Hier mal ein Beispiel des Problems.
30,11/25/13,08:29:33,DNS Update Request,10.81.209.20,DEMZC109.DEMZINPA.ADS,,,0,6,,,
10,11/25/13,08:29:33,Assign,10.81.209.20,DEMZC109.DEMZINPA.ADS,00300590BE41,,1851440556,0,,,
30,11/25/13,08:29:33,DNS Update Request,10.81.209.20,DEMZC109.DEMZINPA.ADS,,,0,6,,,
13,11/25/13,08:29:33,Conflict,10.81.209.20,BAD_ADDRESS,,,0,6,,,
30,11/25/13,08:29:33,DNS Update Request,10.81.209.22,DEMZC109.DEMZINPA.ADS,,,0,6,,,
10,11/25/13,08:29:33,Assign,10.81.209.22,DEMZC109.DEMZINPA.ADS,00300590BE41,,2496778041,0,,,
31,11/25/13,08:29:34,DNS Update Failed,10.81.209.22,DEMZC109.DEMZINPA.ADS,,,0,6,,,
30,11/25/13,08:29:34,DNS Update Request,10.81.209.22,DEMZC109.DEMZINPA.ADS,,,0,6,,,
13,11/25/13,08:29:34,Conflict,10.81.209.22,BAD_ADDRESS,,,0,6,,,
32,11/25/13,08:29:34,DNS Update Successful,10.81.209.20,DEMZC109.DEMZINPA.ADS,,,0,6,,,
32,11/25/13,08:29:34,DNS Update Successful,10.81.209.20,DEMZC109.DEMZINPA.ADS,,,0,6,,,
32,11/25/13,08:29:34,DNS Update Successful,10.81.209.22,DEMZC109.DEMZINPA.ADS,,,0,6,,,
30,11/25/13,08:29:44,DNS Update Request,10.81.209.24,DEMZC109.DEMZINPA.ADS,,,0,6,,,
10,11/25/13,08:29:44,Assign,10.81.209.24,DEMZC109.DEMZINPA.ADS,00300590BE41,,2009963085,0,,,
30,11/25/13,08:29:44,DNS Update Request,10.81.209.24,DEMZC109.DEMZINPA.ADS,,,0,6,,,
13,11/25/13,08:29:44,Conflict,10.81.209.24,BAD_ADDRESS,,,0,6,,,
32,11/25/13,08:29:44,DNS Update Successful,10.81.209.24,DEMZC109.DEMZINPA.ADS,,,0,6,,,
32,11/25/13,08:29:44,DNS Update Successful,10.81.209.24,DEMZC109.DEMZINPA.ADS,,,0,6,,,
30,11/25/13,08:29:54,DNS Update Request,10.81.209.26,DEMZC109.DEMZINPA.ADS,,,0,6,,,
10,11/25/13,08:29:54,Assign,10.81.209.26,DEMZC109.DEMZINPA.ADS,00300590BE41,,3745990172,0,,,
32,11/25/13,08:29:54,DNS Update Successful,10.81.209.26,DEMZC109.DEMZINPA.ADS,,,0,6,,,
Hier mal ein Beispiel des Problems.
30,11/25/13,08:29:33,DNS Update Request,10.81.209.20,DEMZC109.DEMZINPA.ADS,,,0,6,,,
10,11/25/13,08:29:33,Assign,10.81.209.20,DEMZC109.DEMZINPA.ADS,00300590BE41,,1851440556,0,,,
30,11/25/13,08:29:33,DNS Update Request,10.81.209.20,DEMZC109.DEMZINPA.ADS,,,0,6,,,
13,11/25/13,08:29:33,Conflict,10.81.209.20,BAD_ADDRESS,,,0,6,,,
30,11/25/13,08:29:33,DNS Update Request,10.81.209.22,DEMZC109.DEMZINPA.ADS,,,0,6,,,
10,11/25/13,08:29:33,Assign,10.81.209.22,DEMZC109.DEMZINPA.ADS,00300590BE41,,2496778041,0,,,
31,11/25/13,08:29:34,DNS Update Failed,10.81.209.22,DEMZC109.DEMZINPA.ADS,,,0,6,,,
30,11/25/13,08:29:34,DNS Update Request,10.81.209.22,DEMZC109.DEMZINPA.ADS,,,0,6,,,
13,11/25/13,08:29:34,Conflict,10.81.209.22,BAD_ADDRESS,,,0,6,,,
32,11/25/13,08:29:34,DNS Update Successful,10.81.209.20,DEMZC109.DEMZINPA.ADS,,,0,6,,,
32,11/25/13,08:29:34,DNS Update Successful,10.81.209.20,DEMZC109.DEMZINPA.ADS,,,0,6,,,
32,11/25/13,08:29:34,DNS Update Successful,10.81.209.22,DEMZC109.DEMZINPA.ADS,,,0,6,,,
30,11/25/13,08:29:44,DNS Update Request,10.81.209.24,DEMZC109.DEMZINPA.ADS,,,0,6,,,
10,11/25/13,08:29:44,Assign,10.81.209.24,DEMZC109.DEMZINPA.ADS,00300590BE41,,2009963085,0,,,
30,11/25/13,08:29:44,DNS Update Request,10.81.209.24,DEMZC109.DEMZINPA.ADS,,,0,6,,,
13,11/25/13,08:29:44,Conflict,10.81.209.24,BAD_ADDRESS,,,0,6,,,
32,11/25/13,08:29:44,DNS Update Successful,10.81.209.24,DEMZC109.DEMZINPA.ADS,,,0,6,,,
32,11/25/13,08:29:44,DNS Update Successful,10.81.209.24,DEMZC109.DEMZINPA.ADS,,,0,6,,,
30,11/25/13,08:29:54,DNS Update Request,10.81.209.26,DEMZC109.DEMZINPA.ADS,,,0,6,,,
10,11/25/13,08:29:54,Assign,10.81.209.26,DEMZC109.DEMZINPA.ADS,00300590BE41,,3745990172,0,,,
32,11/25/13,08:29:54,DNS Update Successful,10.81.209.26,DEMZC109.DEMZINPA.ADS,,,0,6,,,
Und warum nicht "DHCP snooping" auf den Netzwerk Switches aktivieren, das unterbinded das problem ebenfalls sicher mit doppelten DHCP Servern im netz…
Zitat von @aqui:
Und warum nicht "DHCP snooping" auf den Netzwerk Switches aktivieren, das unterbinded
das problem ebenfalls sicher mit doppelten DHCP Servern im netz…
Und warum nicht "DHCP snooping" auf den Netzwerk Switches aktivieren, das unterbinded
das problem ebenfalls sicher mit doppelten DHCP Servern im netz…
warum....? dann hätten wir nur einen weiteren Thread,
hier im Forum gleich in der Switch-Abteilung :O)
Hallo
ich würde den Lease wieder höher stellen, an dem liegt das Problem sicher nicht.
Mit Wireshark würde ich den Netzverkehr anschauen, da sieht man schnell wer oder was die Fehler verursacht.
Eine fix vergebene IP-Adresse könnte natürlich die Fehler auslösen.
Wie sind die DNS server verlinkt: 1 (auch DC?) und 2 sollten über Kreuz sein und der Dritte auf 1 zeigen.
Beste Grüsse
Ivan
ich würde den Lease wieder höher stellen, an dem liegt das Problem sicher nicht.
Mit Wireshark würde ich den Netzverkehr anschauen, da sieht man schnell wer oder was die Fehler verursacht.
Eine fix vergebene IP-Adresse könnte natürlich die Fehler auslösen.
Wie sind die DNS server verlinkt: 1 (auch DC?) und 2 sollten über Kreuz sein und der Dritte auf 1 zeigen.
Beste Grüsse
Ivan
Zitat von @northeat:
Wie sind die DNS server verlinkt: 1 (auch DC?) und 2 sollten über Kreuz sein und der Dritte auf 1 zeigen.
Beste Grüsse
Ivan
Wie sind die DNS server verlinkt: 1 (auch DC?) und 2 sollten über Kreuz sein und der Dritte auf 1 zeigen.
Beste Grüsse
Ivan
hmmm, ich stelle an den DCs als DNS-Server immer nur den Server - also sich selbst - ein
der Rest kommt über AD zu den anderen DCs.
Gruss
RS
Zitat von @schmitzi:
> Zitat von @northeat:
>
> Wie sind die DNS server verlinkt: 1 (auch DC?) und 2 sollten über Kreuz sein und der Dritte auf 1 zeigen.
>
> Beste Grüsse
> Ivan
hmmm, ich stelle an den DCs als DNS-Server immer nur den Server - also sich selbst - ein
der Rest kommt über AD zu den anderen DCs.
Gruss
RS
> Zitat von @northeat:
>
> Wie sind die DNS server verlinkt: 1 (auch DC?) und 2 sollten über Kreuz sein und der Dritte auf 1 zeigen.
>
> Beste Grüsse
> Ivan
hmmm, ich stelle an den DCs als DNS-Server immer nur den Server - also sich selbst - ein
der Rest kommt über AD zu den anderen DCs.
Gruss
RS
Ist im Grunde auch irrelevant, da der 2. DNS nur zum Zuge kommt, wenn der erste nichts auflöst. Aber für den Fall des Falles ist es immer besser zwei als einen eingetragen zu haben.
Wir haben 3 DCs - davon ist einer DHCP und alle 3 DNS. DC1 ist DHCP, er selbst ist 1 DNS, DC2 ist 2 DNS, auf dem DC2 DNS überkreuz und auf den 3 DC DNS 1. DC1 und 2. DC3.
Wie nutze ich Wireshark um IP Konflikte zu finden und wo setze ich das Tool ein - lokaler Client auf dem Probleme auftreten?
Eine feste IP-Adresse schliesse ich aus! Wir haben da eine Trennung der statischen und dynamsichen Adressen.
Wie nutze ich Wireshark um IP Konflikte zu finden und wo setze ich das Tool ein - lokaler Client auf dem Probleme auftreten?
Eine feste IP-Adresse schliesse ich aus! Wir haben da eine Trennung der statischen und dynamsichen Adressen.
OK, ich war da ein bisschen voreilig. Wenn Du noch nie mit Wireshark gearbeitet hast und dir die verschiedenen Protokolle nichts sagen kann es schwierig werden.
Ich würde Dir also nun empfehlen auf einer Maschine wo das Problem auftritt, also wo der IP-Adressenkonflikt angezeigt wurde, unter Computerverwaltung / Ereignisanzeige / Windows-Protokolle / Sicherheit nach Fehler - Tcpip suchen. Da drinn steht die IP-Adresse welche den Konflikt ausgelöst hat und die Mac-Adresse der anderen Netzwerkkarte. Danach musst Du herausfinden wem die Mac/IPadresse gehört und auf den beiden involvierten Computern die Netzwerkeinstellungen kontrollieren.
Danach kannst Du zu 100% sicher sein, dass der Fehler nicht von einer Fixen IP stammt.
Zu 90% finde ich normalerweise die Fehler schon an diesem Punkt, die restlichen 10% können dann schon schwieriger werden.
Da der DHCP für die verteilung der Adressen zuständig ist würde ich als nächstes die Leases anschauen, was siehst du dort und wie kann es sein, dass er zwei gleiche IPs verteilt? Ich hab das noch nie gesehen.
Wie schon gesagt würde ich die Leasezeit wieder auf 40Tage stellen das macht dann auch die Fehlersuche einfacher.
Gruss
Ivan
Ich würde Dir also nun empfehlen auf einer Maschine wo das Problem auftritt, also wo der IP-Adressenkonflikt angezeigt wurde, unter Computerverwaltung / Ereignisanzeige / Windows-Protokolle / Sicherheit nach Fehler - Tcpip suchen. Da drinn steht die IP-Adresse welche den Konflikt ausgelöst hat und die Mac-Adresse der anderen Netzwerkkarte. Danach musst Du herausfinden wem die Mac/IPadresse gehört und auf den beiden involvierten Computern die Netzwerkeinstellungen kontrollieren.
Danach kannst Du zu 100% sicher sein, dass der Fehler nicht von einer Fixen IP stammt.
Zu 90% finde ich normalerweise die Fehler schon an diesem Punkt, die restlichen 10% können dann schon schwieriger werden.
Da der DHCP für die verteilung der Adressen zuständig ist würde ich als nächstes die Leases anschauen, was siehst du dort und wie kann es sein, dass er zwei gleiche IPs verteilt? Ich hab das noch nie gesehen.
Wie schon gesagt würde ich die Leasezeit wieder auf 40Tage stellen das macht dann auch die Fehlersuche einfacher.
Gruss
Ivan
Meint ihr es bewirkt etwas, wenn ich in den Eigenschaften des DHCP den Wert - Conflict detection attempt von 0 auf 10 erhöhe!
http://www.it-administrator.de/themen/netzwerkmanagement/80725.html
http://www.it-administrator.de/themen/netzwerkmanagement/80725.html
auf 5 mehr geht ja nicht erhöhe??
Hallo zusammen,
am Freitag hatten wir mal wieder einen IP-Adressenkonflikt einer reservierten Adresse. Die Folge ist in so einem Fall,
dass aufgrund der Reservierung der Client auf diese Adresse fest beharrt. Dies führt dazu, dass sich das
DHCP-Log über Stunden vollschreibt, wenn sich der Anwender nicht meldet, da er in einer Besprechung ist.
Bisher haben wir dann die DHCP-Reservierung gelöscht und eine Reserveriung auf eine neue IP
vorgenommen. Das hat dann manchmal auch wieder zu neuen IP-Konflikten geführt.
Ich habe dann an dem betroffenen Client(1) mit Wireshark den Traffic aufgezeichnet und gesehen mit welchem Client(2) der IP-Adressenkonflikt
bestand. Dieser Client(2) war ausgeschaltet. Als ich diesen Client(2) wieder einschaltete, erhielt er die IP wie im DHCP-Server
hinterlegt und der Client(1) erhielt wieder seine reservierte IP.
@northeat - danke für den Tipp Wireshark zu nutzen.
43 4.494755000 FujitsuS_99:b9:21 FujitsuS_99:b9:21 ARP 60 Gratuitous ARP for 10.81.209.46 (Reply) (duplicate use of 10.81.209.46 detected!)
Duplicate IP address detected for 10.81.209.46 (00:30:05:99:b9:21) - also in use by 44:37:e6:89:bf:72 (frame 40)
Frame showing earlier use of IP address: 40
Expert Info (Warn/Sequence): Duplicate IP address configured (10.81.209.46)
Message: Duplicate IP address configured (10.81.209.46)
Severity level: Warn
Sender MAC address: FujitsuS_99:b9:21 (00:30:05:99:b9:21) = Client(2)
Sender IP address: 10.81.209.46 (10.81.209.46)
Target MAC address: HonHaiPr_89:bf:72 (44:37:e6:89:bf:72)
Target IP address: 10.81.209.46 (10.81.209.46)
am Freitag hatten wir mal wieder einen IP-Adressenkonflikt einer reservierten Adresse. Die Folge ist in so einem Fall,
dass aufgrund der Reservierung der Client auf diese Adresse fest beharrt. Dies führt dazu, dass sich das
DHCP-Log über Stunden vollschreibt, wenn sich der Anwender nicht meldet, da er in einer Besprechung ist.
Bisher haben wir dann die DHCP-Reservierung gelöscht und eine Reserveriung auf eine neue IP
vorgenommen. Das hat dann manchmal auch wieder zu neuen IP-Konflikten geführt.
Ich habe dann an dem betroffenen Client(1) mit Wireshark den Traffic aufgezeichnet und gesehen mit welchem Client(2) der IP-Adressenkonflikt
bestand. Dieser Client(2) war ausgeschaltet. Als ich diesen Client(2) wieder einschaltete, erhielt er die IP wie im DHCP-Server
hinterlegt und der Client(1) erhielt wieder seine reservierte IP.
@northeat - danke für den Tipp Wireshark zu nutzen.
43 4.494755000 FujitsuS_99:b9:21 FujitsuS_99:b9:21 ARP 60 Gratuitous ARP for 10.81.209.46 (Reply) (duplicate use of 10.81.209.46 detected!)
Duplicate IP address detected for 10.81.209.46 (00:30:05:99:b9:21) - also in use by 44:37:e6:89:bf:72 (frame 40)
Frame showing earlier use of IP address: 40
Expert Info (Warn/Sequence): Duplicate IP address configured (10.81.209.46)
Message: Duplicate IP address configured (10.81.209.46)
Severity level: Warn
Sender MAC address: FujitsuS_99:b9:21 (00:30:05:99:b9:21) = Client(2)
Sender IP address: 10.81.209.46 (10.81.209.46)
Target MAC address: HonHaiPr_89:bf:72 (44:37:e6:89:bf:72)
Target IP address: 10.81.209.46 (10.81.209.46)
Gern geschehen.
Was ich nicht verstehe warum der eine Client eine falsche IP hatte und woher er diese bekommen hat?
Da stimmt jedenfalls etwas noch nicht. Stell auf jedenfall die Lease wieder hoch, das macht die Fehlersuche einfacher.
lg
Ivan
Was ich nicht verstehe warum der eine Client eine falsche IP hatte und woher er diese bekommen hat?
Da stimmt jedenfalls etwas noch nicht. Stell auf jedenfall die Lease wieder hoch, das macht die Fehlersuche einfacher.
lg
Ivan
1
Ja, die Lease habe ich wieder auf 7 Tage hochgestellt.
Die Frage ist warum die Fujitsu Maschine einen Gratious ARP schickt. Damit erzwingt sie einen ARP Eintrag aller Geräte im Netz:
http://de.wikipedia.org/wiki/Address_Resolution_Protocol#Gratuitous_ARP
http://wiki.wireshark.org/Gratuitous_ARP
Wie dir die GARP Erklärungen ja sagen darf auf ein Gratious ARP mit eigener IP niemals ein Reply kommen ! Bei dir kommt es aber.
Hast du das originale Paket dazu gesehen bzw. WER das eigentliche GARP schickt, denn das o.a. gesnifferte ist ja schon der Reply auf den GARP wo Client 2 rummeckert das ER diese IP besitzt und eben nicht der den GARP gesendet hat. Das müsste der böse Buhmann sein.
http://de.wikipedia.org/wiki/Address_Resolution_Protocol#Gratuitous_ARP
http://wiki.wireshark.org/Gratuitous_ARP
Wie dir die GARP Erklärungen ja sagen darf auf ein Gratious ARP mit eigener IP niemals ein Reply kommen ! Bei dir kommt es aber.
Hast du das originale Paket dazu gesehen bzw. WER das eigentliche GARP schickt, denn das o.a. gesnifferte ist ja schon der Reply auf den GARP wo Client 2 rummeckert das ER diese IP besitzt und eben nicht der den GARP gesendet hat. Das müsste der böse Buhmann sein.
DANKE
Den IP-Adresskonflikt gab es schon vor meiner Aufzeichnung. Die ersten GARPs, die ich gefunden habe, waren diese.
40 4.494477000 HonHaiPr_89:bf:72 Broadcast ARP 42 Gratuitous ARP for 10.81.209.46 (Request)
41 4.494620000 FujitsuS_99:b9:21 HonHaiPr_89:bf:72 ARP 60 Gratuitous ARP for 10.81.209.46 (Reply) (duplicate use of 10.81.209.46 detected!)
43 4.494755000 FujitsuS_99:b9:21 FujitsuS_99:b9:21 ARP 60 Gratuitous ARP for 10.81.209.46 (Reply) (duplicate use of 10.81.209.46 detected!)
46 4.541014000 FujitsuS_99:b9:21 HonHaiPr_89:bf:72 ARP 60 Gratuitous ARP for 10.81.209.46 (Reply) (duplicate use of 10.81.209.46 detected!)
Wie gehe ich dann am besten vor, wenn ich den Versucher gefunden habe.
Den IP-Adresskonflikt gab es schon vor meiner Aufzeichnung. Die ersten GARPs, die ich gefunden habe, waren diese.
40 4.494477000 HonHaiPr_89:bf:72 Broadcast ARP 42 Gratuitous ARP for 10.81.209.46 (Request)
41 4.494620000 FujitsuS_99:b9:21 HonHaiPr_89:bf:72 ARP 60 Gratuitous ARP for 10.81.209.46 (Reply) (duplicate use of 10.81.209.46 detected!)
43 4.494755000 FujitsuS_99:b9:21 FujitsuS_99:b9:21 ARP 60 Gratuitous ARP for 10.81.209.46 (Reply) (duplicate use of 10.81.209.46 detected!)
46 4.541014000 FujitsuS_99:b9:21 HonHaiPr_89:bf:72 ARP 60 Gratuitous ARP for 10.81.209.46 (Reply) (duplicate use of 10.81.209.46 detected!)
Wie gehe ich dann am besten vor, wenn ich den Versucher gefunden habe.
Zitat von @abinz9999:
40 4.494477000 HonHaiPr_89:bf:72 Broadcast ARP 42 Gratuitous ARP for 10.81.209.46 (Request)
Wie gehe ich dann am besten vor, wenn ich den Versucher gefunden habe.
40 4.494477000 HonHaiPr_89:bf:72 Broadcast ARP 42 Gratuitous ARP for 10.81.209.46 (Request)
Wie gehe ich dann am besten vor, wenn ich den Versucher gefunden habe.
Hi
Ich würde den PC oder das Device HonHaiPr_89 prüfen. Also die konfig und sollte das nicht helfen würde ich mir die Konfiguration von FujitsuS_99 anschauen.
LG Andy
