Dubbel IP adres, wat zijn de gevolgen?

[Anoniem: 53025]

Ik ben al lange tijd aan het zoeken naar een goed antwoord en ik kan het niet vinden. Stel er is een Windows netwerk met een DHCP server wat draait zoals het hoort. Nu sluit ik abusievelijk een niet-windows apparaat aan op het netwerk met een vast IP-adres. Dit apparaat is bijvoorbeeld een industriele PLC met TCP/IP capaciteiten.

1. Wat gebeurt er als dit apparaat hetzelfde adres heeft als een windows client?
2. Wat gebeurt er als dit apparaat hetzelfde adres heeft als een server?
3. Wat gebeurt er als dit apparaat hetzelfde adres heeft als de DHCP server?

Naar mijn idee krijgt bij vraag 1 de client een waarschuwing in het geval deze windows XP draait. Bij vraag 2 en 3 durf ik niet een 100% antwoord te geven.

De ellende is dat alle dingen die ik nu heb gevonden op het internet toch al gauw zo'n 4 jaar oud zijn. En dus gaan over windows NT of over andere "oude" serverpakketten.

Standaard geeft een Windows server een waarschuwing aan de client die het dubbele adres claimt. Maar dat is dan in het geval dat deze een windows-OS draait. Die vlieger gaat nu dus niet op (lijkt mij)

Een antwoord van "dat mag nooit" en "een echte systeembeheerder laat dat niet toe" heb ik al verzonnen.

Maar als ik tegen iemand zeg "dan gaat je hele netwerk plat" is dat dan absoluut waar of slechts een mogelijke optie?

De achterliggende gedachte is dat je bijvoorbeeld een klein netwerkje met bijvoorbeeld een hubje kunt maken binnen voor twee industriele apparaten met ethernet.Voor het gemak geef je apparaat 1 adres 192.68.0.2 en de ander 192.168.0.3. Gemakzucht dient de mens immers. Op een zeker moment valt het hubje uit en iemand is zo slim om de twee kabeltjes maar in de switch te steken die daarboven hangt. Alleen is die switch van het grote bedrijfsnetwerk......

[JackBol]

Windows zal de de TCP/IP stack stoppen totdat er geen dubbel IP adres meer gevonden wordt in het broadcast domain. Dat betekent dus dat je server down gaat. Ook je DHCP server. Het kan dus grote gevolgen hebben voor je netwekr.

[H!GHGuY]

het is bvb handig om een stuk van je scope te reserveren voor toekomstige toepassingen

dan kun je statische IP's toekennen (evt via MAC-adres in de DHCP) voor die nieuwe apparaatjes.

[Koffie]

Move PNS > NT

[jochemd]

Welke DHCP server gebruik je?
Gebruik je semi-statische IP adressen (IP-MAC in DHCP server gekoppeld)?
Draaien je servers (niet de DHCP server) middels DHCP of een vast IP adres?

[ Voor 26% gewijzigd door jochemd op 20-04-2005 19:53 ]

[joopv]

Dirk-Jan schreef op woensdag 20 april 2005 @ 17:46:
Windows zal de de TCP/IP stack stoppen totdat er geen dubbel IP adres meer gevonden wordt in het broadcast domain. Dat betekent dus dat je server down gaat. Ook je DHCP server. Het kan dus grote gevolgen hebben voor je netwekr.

De TS heeft het over een niet-windows apparaat wat tcp/ip praat.

In zo'n geval ligt het er aan hoe de tcp/ip stack in het apparaat opgezet is. Als het device d.m.v. een arp request een check doet op zijn eigen ip adres voordat het ding online komt is er niks aan de hand - het apparaat komt dan gewoon niet online met het reeds in gebruik zijnde ip adres.

Een (goede) dhcp server zal ook die check doen voor hij een nieuw ip adres uitgeeft. Je kunt dan ook in de meeste gevallen apparaten met vaste ip adressen in een gebied neerzetten wat ook door een dhcp server uitgedeeld wordt, al is dat natuurlijk geen goed systeembeheer.

Als het apparaat die check niet doet - en dat kan best, want in een PLC is vaak niet erg veel ruimte voor een zeer uitgebreide tcp/ip stack - dan heb je inderdaad een probleem.

[Anoniem: 25556]

In het genoemde voorbeeld, geef je zelf de IP adressen aan de apparaten. In dat geval lijkt me de oplossing vrij simpel: pak gewoon een heel ander netwerk.

Als het bedrijfsnetwerk bv. 192.168.1.x gebruikt, geef je industr. appar. dan 10.0.0.x.

Dan een van de servers aan zijn interface als 2e ip eentje uit 10.0.0.x geven, en laten routen.

Het ergste wat er nu kan gebeuren, is dat een van beide apparaten het adres van de server pakt. In dat geval is communicatie met de apparaten niet mogelijk. Niet meer en niet minder.

[leuk_he]

Anoniem: 53025 schreef op woensdag 20 april 2005 @ 17:43:

1. Wat gebeurt er als dit apparaat hetzelfde adres heeft als een windows client?
2. Wat gebeurt er als dit apparaat hetzelfde adres heeft als een server?
3. Wat gebeurt er als dit apparaat hetzelfde adres heeft als de DHCP server?

Naar mijn idee krijgt bij vraag 1 de client een waarschuwing in het geval deze windows XP draait. Bij vraag 2 en 3 durf ik niet een 100% antwoord te geven.

1. Waarschuwing en communicatie stopt.
2. Ik denk gelijk aan 1.
3 Niets, dhcp gebruikt volgens mij broadcast adressen om de dhcp servert ondekken.

Je kunt uiteraard in de dhcp server een range van adressen aangeven waaruit hij adressen verdeeld. Dus als je al zorgt dat deze niet conflicteren met je statische adressen scheelt dat weer in risico.

En uiteraard testen

[Anoniem: 62954]

Ik heb hier een klein beetje ervaring mee: Ik ben systeembeheerder op een basisschool waar met Windows2003 SBS draait, met windows XP clients. Ook liggen er een aantal HP printserver units, die een vast ip adres hebben.

Omdat het netwerk al bestond voordat ik er kwam te werken, wist ik niet dat die printserver er lagen, dus overlapte mijn DHCP scope het ip's van 2 van die apparaten. De computers met de identieke ip's gaven niet een foutmelding dat er een dubbel ip was gedetecteerd, zoals je zou verwachten. De DHCP server van Win2003 gaf ook gewoon het ip adres aan de desbetreffende clients.

De problemen waren nogal vaag met de clients. Het bestond uit het af en toe niet in kunnen loggen, omdat het domein niet werd gevonden, maar meestal lukte inloggen nog wel. Echter draaide software over het netwerk soms wel en soms niet, de problemen waren niet consistent reproduceerbaar, een echte nachtmerrie voor de systeembeheerder dus. Later kwam ik er pas achter dat dit kwam door de printservers op het netwerk, en was het probleem makkelijk opgelost.

De betreffende clients waren trouwens wel te bereiken over het netwerk via hun naam en ip adres. Als men echter een http request uitvoerde, pakte de printserver deze op en liet zijn configuratie-pagina zien. Of de printservers zelf werkte op dat moment weet ik niet, omdat ik die pas na het oplossen van het probleem had geconfigureerd (ik moest ze eerst zoeken door heel het gebouw ).

Dat is dus wat er gebeurde met een client in dit geval, wat er met je server of DHCP server zou gebeuren weet ik niet.

[alt-92]

Anoniem: 62954 schreef op woensdag 20 april 2005 @ 20:16:
Omdat het netwerk al bestond voordat ik er kwam te werken, wist ik niet dat die printserver er lagen, dus overlapte mijn DHCP scope het ip's van 2 van die apparaten.
[....]

Als men echter een http request uitvoerde, pakte de printserver deze op en liet zijn configuratie-pagina zien. Of de printservers zelf werkte op dat moment weet ik niet, omdat ik die pas na het oplossen van het probleem had geconfigureerd (ik moest ze eerst zoeken door heel het gebouw )[

daarom kan je dan ook beter van tevoren bv. een pingsweep doen, weet je welke IPs in gebruik zijn

[Anoniem: 53025]

Ok, een aantal reacties hier zijn redelijk bruikbaar, maar de echte "That's Why" m.u.v. het eerste antwoord zit er niet bij. Ik zal de vraag even toelichten:

Klanten kopen een aantal industriele producten met daarop een ethernetpoort. Omdat het hun bijvoorbeeld te lang duurt voordat de mensen van IT hun helpen willen ze zelf alles aan elkaar knopen buiten het bestaande bedrijfsnetwerk om. Op zich makkelijk, snel en eenvoudig te realiseren. Gewoon wat vaste adressen toewijzen (desnoods gebruikt men een router met ingebouwde DHCP-server) en een stand-alone PC gebruiken voor dit systeem en het draait als een zonnetje. Maar de situatie met dat kapotte hubje is een reeel praktijkgeval. Stel iemand verwijderd het hubje en steekt de kabels in de switch van het bedrijfsnetwerk. Wat dan?

Mijn advies daarom richting de klant is dat ze uit moeten kijken met wat ze doen; ze zouden voor zover mijn kennis reikt hun bedrijfsnetwerk plat kunnen gooien als de IP-adressen met elkaar conflicteren en met name als dat de Ip-adressen met serveradressen overeenkomen.

De vraag is dus:
1. Dit advies is absoluut correct
2. Dit advies is niet overbodig, maar de kans op echte problemen is "worst case"
3. Dit advies slaat nergens op, alles wordt door de servers in het bedrijfsnetwerk ondervangen.

[Bor]

Het totale netwerk platgooien is wel heel erg direct. Het hangt er maar net vanaf waar het ip adres eigenlijk 'van is'.

[JackBol]

Anoniem: 53025 schreef op woensdag 20 april 2005 @ 21:44:
1. Dit advies is absoluut correct

verkoop ze een switch en doe er 802.1x mee.

[JackBol]

Bor de Wollef schreef op woensdag 20 april 2005 @ 21:55:
Het totale netwerk platgooien is wel heel erg direct. Het hangt er maar net vanaf waar het ip adres eigenlijk 'van is'.

Van een DHCP server? van een DNS server? van je default gateway? nogal wat problemen lijkt mij

[Gomez12]

Antwoord 1 is mijns inziens correct gewoon vanwege het feit dat je niet weet hoe de klant zijn netwerk geconfigureerd is, hij kan een workstation ip pakken en dit niet goed doorgeven maar net zo goed een server-ip of een router-ip.

Klant ziet alleen dat er iets niet werkt als hij jouw ding verkeerd aansluit, klant is boos als je met deze info pas achteraf komt.
Bijv. in ons bedrijfsnetwerk is gewoon 1 t/m 25 gereserveerd voor servers, 26/75 voor overige randapparatuur, dhcp range van 100 tot 199 voor workstations, en dan 200/240 voor printers en dan 241/254 voor routers. Nu is alles behalve workstations vast ip. Lijkt me leuk als jij even met een plc met vast ip-adres van .1 eventjes een server bij ons neerhaalt...

[Anoniem: 53025]

Gomez12 schreef op woensdag 20 april 2005 @ 22:04:
Antwoord 1 is mijns inziens correct gewoon vanwege het feit dat je niet weet hoe de klant zijn netwerk geconfigureerd is, hij kan een workstation ip pakken en dit niet goed doorgeven maar net zo goed een server-ip of een router-ip.

Klant ziet alleen dat er iets niet werkt als hij jouw ding verkeerd aansluit, klant is boos als je met deze info pas achteraf komt.
Bijv. in ons bedrijfsnetwerk is gewoon 1 t/m 25 gereserveerd voor servers, 26/75 voor overige randapparatuur, dhcp range van 100 tot 199 voor workstations, en dan 200/240 voor printers en dan 241/254 voor routers. Nu is alles behalve workstations vast ip. Lijkt me leuk als jij even met een plc met vast ip-adres van .1 eventjes een server bij ons neerhaalt...

ehmz, ik doe dat verkeerd aansluiten zelf dus niet. Ik neem zelf altijd wat simpel netwerk spul mee om te testen wat daarna dus weer mooi terug naar de zaak gaat.

De reden waarom ik dit uiteindelijk vraag is dat ik niet wil dat ik straks een systeembeheerder brullend van het lachen aan de lijn krijg die vraagt hoe ik aan die onzin kom dat onze producten zijn netwerk kunnen platgooien. (in het ergste geval jou dus )

[leuk_he]

Anoniem: 53025 schreef op woensdag 20 april 2005 @ 21:44:
1. Dit advies is absoluut correct
2. Dit advies is niet overbodig, maar de kans op echte problemen is "worst case"
3. Dit advies slaat nergens op, alles wordt door de servers in het bedrijfsnetwerk ondervangen.

ze zijn ALLEMAAL te verdedigen.

3: in principe (kan) een dhcp server eerst adressen testen voordat hij ze uitgeeft. (dit is vaak een optie) Als het apparaat goed reageert op een ping wordt dat adres niet uitgegeven.

Als aanhanger van murphy(wet van behoud van elende) ,en murphy was een optimist moet ik echter toch voor optie 1 gaan. Het kan fout gaan en het zal fout gaan.

[Anoniem: 53025]

Mooizo, Ik heb nu genoeg dingen gelezen om een extra regel in o.a. de handleiding te laten opnemen.

Van fabriekswege staan de apparaten ingesteld op 192.168.0.1, maar ze ondersteunen echter ook Boot-P en DHCP. Zou het niet verstandiger zijn om de apparaten standaard op DHCP te zetten? Dan voorkom je denk ik al veel problemen.

[Anoniem: 25556]

Anoniem: 53025 schreef op woensdag 20 april 2005 @ 21:44:
Mijn advies daarom richting de klant is dat ze uit moeten kijken met wat ze doen; ze zouden voor zover mijn kennis reikt hun bedrijfsnetwerk plat kunnen gooien als de IP-adressen met elkaar conflicteren en met name als dat de Ip-adressen met serveradressen overeenkomen.

De vraag is dus:
1. Dit advies is absoluut correct
2. Dit advies is niet overbodig, maar de kans op echte problemen is "worst case"
3. Dit advies slaat nergens op, alles wordt door de servers in het bedrijfsnetwerk ondervangen.

Je introduceert een fout in een netwerk (=dubbel IP adres). Hoe hiermee omgegaan wordt is afhankelijk van het gehele netwerk, en alle apparaten in dat netwerk. Immers, ook al vangen je clients en servers het allemaal netjes op, wat als dat apparaat het IP krijgt van een printerservertje die daar niet mee om kan gaan?

Verder is er nooit zekerheid wat er precies gaat gebeuren. Ook al zou het volgens de theorie zo zijn dat een dergelijke fout (dubbel ip) geen enkel probleem zou mogen zijn, dit blijkt in de praktijk niet altijd waar. Het printerservertje gaat plat, waardoor de printerque op de fileserver crashed, enz.

De kans is misschien niet erg groot, maar als je maar genoeg van dit soort situaties creëert dan gaat het vroeger of later mis.

Ik denk niet dat het snel zal gebeuren dat een heel netwerk plat gaat door toevoeging van één enkel dubbel IP, zeker daar er tegenwoordig vnl gebruik gemaakt wordt van - al dan niet manageble - switches ipv. hubs.

Ik denk dat je klanten moet adviseren de apparaten in een eigen subnet te installeren, met een vast IP. Op die manier maakt het niet uit hoe ze het ding omstekkeren, het blijft werken. Dus bv. klant gebruikt 192.168.1.x als netwerk. Installeer de apparaten dan in 192.168.2.x en geef ze een vast IP. Geef één van de servers een 192.168.2.x ip, en laat hem routeren (of gebruik desnoods NAT) en stel deze als gateway voor 192.168.2.x in op alle apparaten.

Ik zou een algemene waarschuwing in de handleiding zetten. Klanten kunnen soms behoorlijk inventief zijn tijdens het aanleggen van een netwerk. Op deze manier leg je de verantwoordelijkheid bij de klant.

Iets als

Waarschuwing: Onjuiste installatie en/of aansluiting van dit apparaat kan storingen veroorzaken in het netwerk waarop het apparaat aangesloten wordt.
[...]

Default zou het al beter zijn om niet een 192.168.x.1 adres te gebruiken, aangezien .1 etc vaak gebruikt wordt voor servers. Waarom niet 172.18.198.132 als ip? De kans dat dat ergens gebruikt wordt, is verschrikkelijk klein. DHCP gebruiken is inderdaad ook een goede oplossing.

In alle gevallen blijf je met je probleem zitten, immers het kan zijn dat de gebruiker er zelf voor kiest een ander IP adres danwel DHCP in te stellen. Vandaar dat een waarschuwing altijd op zijn plek is imo

[ Voor 16% gewijzigd door Anoniem: 25556 op 20-04-2005 23:24 ]

[StevenK]

De DHCP rfc schrijft alleen voor (SHOULD) dat bij het opnieuw uitgeven van een eerder aan een ander uitgegeven adres de server via ICMP moet kijken of dat adres nog in de lucht is.

Windows DHCP servers doen dit, afaik, niet. Wel is het zo dat een windows client (vanaf de allereerste versie, overigens) voordat 'ie een ip-adres in de lucht gooit, eerst via arp kijkt of het adres niet al in gebruik is.

[Anoniem: 57365]

Anoniem: 53025 schreef op woensdag 20 april 2005 @ 22:41:
Mooizo, Ik heb nu genoeg dingen gelezen om een extra regel in o.a. de handleiding te laten opnemen.

Van fabriekswege staan de apparaten ingesteld op 192.168.0.1, maar ze ondersteunen echter ook Boot-P en DHCP. Zou het niet verstandiger zijn om de apparaten standaard op DHCP te zetten? Dan voorkom je denk ik al veel problemen.

dan lijkt me geheel afhankelijk van de functie en de keuze van de klant. geef ze de mogelijkheden en laat ze zelf kiezen... als de klant een beetje slim is, dan krijgen ze een vast ip (desnoods via dhcp) en wordt het gedocumenteerd.

[Bor]

Anoniem: 53025 schreef op woensdag 20 april 2005 @ 22:41:
Mooizo, Ik heb nu genoeg dingen gelezen om een extra regel in o.a. de handleiding te laten opnemen.

Van fabriekswege staan de apparaten ingesteld op 192.168.0.1, maar ze ondersteunen echter ook Boot-P en DHCP. Zou het niet verstandiger zijn om de apparaten standaard op DHCP te zetten? Dan voorkom je denk ik al veel problemen.

Ach ja, en als je dan 2 dhcp servertjes hebt die de zelfde range serven heb je nog een probleem. Goede procedures en afspraken met betrekking tot wie wat mag en kan aansluiten is een betere oplossing. Kijk bv eens naar mac filtering op de bedrijfsswitches.

[leuk_he]

Anoniem: 53025 schreef op woensdag 20 april 2005 @ 22:41:
Van fabriekswege staan de apparaten ingesteld op 192.168.0.1, .

Dit is toevallig net het adres dat veel configuraties(windows ics, en huistuinenkeueken router gebruiken om internet delen te regelen. ). Dus je zou internet en/of servers vaak onklaar maken met dit adres. ander adres kiezen helpt, dhcp lijkt me slimmer als default.


/edit:

wellicht een 169.254.* adres kiezen conform rfc 3330

169.254.0.0/16 - This is the "link local" block. It is allocated for
communication between hosts on a single link. Hosts obtain these
addresses by auto-configuration, such as when a DHCP server may not
be found.

[ Voor 27% gewijzigd door leuk_he op 22-04-2005 16:37 ]

[Pumbaa82]

Ik zou als bedrijfbeleid voorstellen om een 'belachelijke' range te nemen.
Waarbij de kans minimaal is dat je dezelfde netwerk reeks tegenkomt.

192.168.242.x, 10.13.37.x ofzo

Verder ergens in de voorwaarden opnemen dat het verboden is voor de klant om zelf de netwerk aansluiting aan te sluiten. en indien dit toch gebeurd het bedrijf waar jij voor werkt niet aansprakelijk kan worden gestelt voor enige schade.


Als een systeembeheerder van een klant zelf die apparatuur aansluit ligt de verantwoordelijkheid bij het systeembeheer van de klant.

Indien het netwerk alsnog later verbonden zou moeten worden aan een bedrijfsnetwerk neem je dit ook gewoon op in een contract/voorwaardes, waarbij dit door het bedrijf waar je voor werkt moet worden geregeld, en je dus met het systeembeheer van de klant kan overleggen wat vrij is.


Ik begrijp dat mijn oplossing niet antwoord geeft op je vraag, en waarschijnlijk dom zal afsteken tussen de mooie en geniale ingewikkelde antwoorden hier. Maar waarom moeilijk doen als je het in overleg zou kunnen doen met systeembeheer van de klant en dit probleem dus verkomt ipv een oplossing willen voor een probleem wat niet nodig is als je goede afspraken erover maakt.