Hallo,
nehmen wir an, die IP-Adresse meines Laptops wäre nicht über DHCP vergeben sondern ich hätte diese selbst von Hand konfiguriert und dabei versehentlich die IP-Adresse des Default-Gateways eingegeben.
Welches Verhalten würde sich im Netzwerk ergeben???
Danke für Eure antworten. Jens
Hallo,
nehmen wir an, die IP-Adresse meines Laptops wäre nicht über
DHCP vergeben sondern ich hätte diese selbst von Hand
konfiguriert und dabei versehentlich die IP-Adresse des
Default-Gateways eingegeben.
Welches Verhalten würde sich im Netzwerk ergeben???
Zumindest ein Teil der anderen Clients im Netz würde zumindest einen Teil des Traffics, der nach draußen soll, an Deinen Laptop schicken. Wer genau welchen Traffic genau statt zum Gateway zu Dir schickt, hängt davon ab, wer jeweils beim ARP schneller ist.
Unter’m Strich: Für Deinen Laptop wäre alles hinter dem default gateway überhaupt nicht erreichbar, für alle anderen vermutlich nur in katastrophaler Verbindungsqualität oder evtl. auch gar nicht.
Je nach Umfeld würde der zuständige Netzwerkadmin auch noch ein Wörtchen mit Dir reden.
Gruß,
Malte
Welches Verhalten würde sich im Netzwerk ergeben???
Beim booten meldet einer der beiden einen Konflikt und schaltet seine Netzwerkschnittstelle ab. Jeder Rechner prüft bei der Initialisierung seiner Netzwerkkarte, ob die IP-Adresse schon vergeben ist.
Halten sich die Betriebssysteme nicht an diese Regelung, können die beiden halt nicht miteinander kommunizieren, und der Rest im Netz ist verwirrt. Ist der Router betroffen, dürften einige Kisten ein Problem haben, ins Internet zu kommen - je nachdem, was der arp-Cache so meldet. Wer sie wie verhält, kann man nicht voraussagen, da es drauf ankommt, wessen arp-Cache wann welche Eintragungen macht.
Welches Verhalten würde sich im Netzwerk ergeben???
Beim booten meldet einer der beiden einen Konflikt und
schaltet seine Netzwerkschnittstelle ab. Jeder Rechner prüft
bei der Initialisierung seiner Netzwerkkarte, ob die
IP-Adresse schon vergeben ist.
Nur so nebenbei: Dieses Verhalten ist keineswegs Standard (AFAIK) oder irgendwie verbindlich vorgegeben, und insbesondere im Serverumfeld mitunter unerwünscht oder sogar schädlich.
Gruß,
Malte
Nur so nebenbei: Dieses Verhalten ist keineswegs Standard
(AFAIK) oder irgendwie verbindlich vorgegeben, und
insbesondere im Serverumfeld mitunter unerwünscht oder sogar
schädlich.
Ermm… naja, also für Failover wird der Stack erst aktiv, wenn der Heartbeat ausfällt - weil sonst auch alle Clients dezent verwirrt wären.
Zumindest bei M$ sind auch alle Systeme schon sehr lange so „abgesichert“, siehe
http://support.microsoft.com/kb/120599
Der SBS deaktivert den Stack (wird 0.0.0.0), NT und 2k schalten das Interface sogar ab, Netboot gibt einen BSOD usw. Bei 2k3:
„When the stack is first initialized or when a new IP address is added, gratuitous ARP requests are broadcast for the IP addresses of the local host. The number of ARP requests to send is controlled by the ArpRetryCount registry parameter described in Appendix A, which defaults to 3. If another host replies to any of these ARP requests, the IP address is already in use. When this happens for an interface with a single manually-configured address, the Windows-based computer still boots; however, the interface containing the offending address is disabled, a system log entry is generated, and an error message is displayed. If the host that is defending the address is also a Windows-based computer, a system log entry is generated, and an error message is displayed on that computer. In order to update the ARP caches on other computers, the offending computer re-broadcasts another ARP request, spoofing the MAC address of the defending computer, to restore the proper values in the ARP caches of the other computers.
A computer using a duplicate IP address can be started when it is not attached to the network, in which case no conflict would be detected. However, if it is then plugged into the network, the first time that it sends an ARP request for another IP address, any computer running a version of Windows with the Windows NT codebase with a conflicting address detects the conflict. The computer detecting the conflict displays an error message and logs a detailed event in the system log. A sample event log entry is shown below:
The system detected an address conflict for IP address 10.199.40.123 with the system having network hardware address 00:smiley:D:01:0F:7A:B5. Network operations on this system may be disrupted as a result.
DHCP-enabled clients inform the DHCP server with a DHCPDecline message when an IP address conflict is detected and, instead of disabling the TCP/IP protocol, they request a new address from the DHCP server and request that the server mark the conflicting address as bad.“
(Microsoft Windows Server 2003 TCP/IP Implementation Details)
Apples MacOS verhält sich ebenso, der „jüngere“ gibt nach, bei Linux müßte ich nun lügen. Es gibt aber keinen Zwang es so zu regeln, RFC sind ja auch keine Gesetze, daher meine Bemerkung zum OP „wenn sie sich daran halten“.
Zumindest bei M$ sind auch alle Systeme schon sehr lange so „abgesichert“
Gut, im Serverumfeld spielt Windows ja nicht so die große Rolle. Konkret machen solche ARP-Spielereien Probleme, wenn Du gewollt ARP manipulierst, wie es bspw. in manchen load-balancing Szenarien der Fall ist, oder wenn man proxy arp auf dem gateway einsetzt (in Verbindung mit no-local-switching/protected port auf den Switches bietet das eine ganz angenehme Separation der Server auf Layer 2).
Ich kenne dieses „duplicate ip detection“ feature eigentlich nur von alten Red Hat Systemen, machen die Windows Server-Versionen das auch oder nur die Clients?
Gruß,
Malte
Ich kenne dieses „duplicate ip detection“ feature eigentlich
nur von alten Red Hat Systemen, machen die Windows
Server-Versionen das auch oder nur die Clients?
Der lange Text ist aus der Doku zu Windows 2003 - also Server, der 2008er dürfte sich da aber gleich verhalten. Man kann aber das ARP-pollen in der Registry abschalten, so daß er keine Chance hätte, eine doppelte IP-Adresse zu erkennen. Bis auf sehr wenige spezielle Anwendungen ist das Ganze ja auch durchaus sinnvoll.
Doppelte MACs (wie gerne bei den alten SBus-Quad-NICs bei Sun) sind aber mindestens genauso übel, da hab ich mir auch schon mal 'nen Wolf gesucht. Oder falsches Bonding, bei dem sich dann *nix-Kisten alle 1-2s im Log beschweren, daß sich da eine MAC geändert hätte… So bekommt man auch /var/log voll… *g*
Hallo Zusammen…
„Beim booten meldet einer der beiden einen Konflikt“ …wer ist denn mit einer von beiden gemeint???
Hallo Zusammen…
„Beim booten meldet einer der beiden einen Konflikt“ …wer
ist denn mit einer von beiden gemeint???
Die meisten Betriebssysteme (Windows, Mac OS X, verschiedene Linuxe) senden beim Initialisieren der Netzwerkschnittstelle einen Rundruf (gracious ARP) ins lokale Netz, den man in etwa so umschreiben könnte: „Hallo, ich hab die MAC-Adresse soundso und nehme als IP-Adresse die a.b.c.d - jemand was dagegen?“. Hat einer was dagegen (weil dieser selbst schon die IP-Adresse verwendet), dann wird die Schnittstelle i.d.R. nicht aktiviert und es erscheint eine Fehlermeldung. Je nach System warnt auch der andere mit einer Fehlermeldung. Dieses Verhalten ist gängig, aber nicht zwingend.
Gleiches gilt beim „anstöpseln“ ans Netz, da hier meist die gleichen Mechanismen ablaufen. Keine Warnung gibt es hingegen, wenn man z.B. die beiden Geräte an unterschiedlichen Hubs/Switches hat und die dann miteinander verbindet. Für die Rechner ändert sich an ihrer Schnittstelle nichts, sie bemerken den Zusammenschluss nicht. Was dann passiert, ist nicht vorhersehbar.