[w2k3 DHCP] opgesplitste DHCP scopes

[Verwijderd]

Allereerst de situatie:

Op locatie A staan 2 W2k3 DHCP servers. Deze bedienen ieder de helft van een DHCP scope op dat subnet. (DHCP scope gedefinieerd met op de ene server de eerste helft excluded en de andere server de tweede helft van de scope exluded) De scope is dusdanig ruim dat de hele locatie genoeg heeft aan de helft van de scope dus zal er zelfs indien er een DHCP server uitvalt genoeg IP adressen beschikbaar zijn.

Nu is er op Locatie B een veel kleinere scope beschikbaar. Daar zijn op dit moment de werkplekken statisch geconfigureerd.
De bedoeling is dat op de router het IP helper address ingesteld gaat worden naar de DHCP servers op Locatie A zodat de werkstations dynamisch een IP adres gaan ontvangen van de DHCP server op Locatie A.

Nu ben ik niet 100% zeker hoe een DHCP request afgehandeld gaat worden op moment dat op DHCPserver 1 er geen ip adressen meer beschikbaar zijn, maar wel op DHCPserver2.

Ik heb in de documentatie niet terug kunnen vinden wat er dan precies gebeurd. Kan iemand me daar over informeren?

Ik zou graag weten wat er gebeurd als:
- DHCPscope op een subnet wordt op 2 DHCPservers gedefinieerd (ieder met 50% exlusion)
- DHCPServer1 heeft geen beschikbare ipadressen (alle ipadressen in scope zijn uitgegeven)
- DHCPServer1 reageert als eerste op een DHCPDiscover

Wordt er dan simpel een NACK gegeven en komt er een nieuwe Discover?
Of pakt DHCPServer2 automatisch de aanvraag op?
Of loop ik het risico dat er na een NACK een autoIP door de client gegenereerd wordt (iets wat ik persé NIET wil)

Het is NIET mogelijk om de scope op Locatie2 te vergroten!

Alvast bedankt voor de gouden tip

[Muggie]

Je clients sturen een DHCP request uit, beide servers reageren op de request met een offer, je client neemt (volgens mij) de eerste die binnenkomt (kan zo snel het criterium niet vinden dat gehanteerd wordt voor het accepteren van een van meerdere DHCP offers).

Zal een van de dhcp servers uit zijn scope lopen dan zal deze negatief of niet antwoorden op een DHCP request en zal je client de DHCP offer van de andere server oppakken.

[Verwijderd]

Ik weet niet of het gedrag te voorspellen is, maar ik denk wel dat het makkelijk te testen is.

2 kleine scopes configureren, en kijken of clients ook van server 2 DHCP snoepen.

Wellicht interresant om te gelijkertijd wireshark aan te zetten om te kijken wat er voorbij komt.

[Predator]

Je zal gewoon 2 ip helper-address commando's moeten gebruiken, elk naar 1 van de DHCP servers.
De client krijgt 2 DHCPoffers en gaat de eerste die antwoord nemen (wie eerst antwoord is te controlleren door hogere conflict detection pogingen te zetten op de dhcp server die jij laten wilt doen antwoorden.

Als de vrij adressen op 1 zijn uitgegeven, dan zal de client maar 1 geldig offer krijgen.

Maar je kan gewoon ook overal de volledig range configureren en actief zetten. Zolang je maar conflict detection niet afzet. Wij werken zo al jaren zonder problemen voor DHCP fallback over WAN (en fallback op de LAN).

Wat wij wel merken (en bevestigd door sniff logs) is dat de conflict detection op W2k3 soms anders reageert dat die zou moeten. Zo zien we soms geen detections, of minder dan ingesteld. Maar dat geeft ook geen problemen.

[Verwijderd]

Dank voor de feedback.
Ik had zelf ook al het vermoeden dat beide DHCP servers een offer zouden sturen zodra een client een request stuurt
Ik ga voor de zekerheid toch eerst testen wat er gebeurd als 1 scope uit zijn ipadressen loopt. Het lijkt me zo dat er in dat geval het offer van de 2e DHCP gebruikt gaat worden door de client.

[TrailBlazer]

ja dat werkt gewoon zo de 1e die geen ruimte meer heeft zal geen offer meer sturen. Overigens werkt predators reeks ook wel hoewel ik dat ersoonlijk wat minder netjes vind. Conflict detetction is, naar mijn idee, om eventuele fuckups te voorkomen en niet om er gebruik van te maken tijdens normaal gebruik. Het zou mooier zijn als de 2 DNS servers met elkaar synchroniseren, maar dat schijnt niet te kunnen.

[Asteroid9]

TrailBlazer schreef op zondag 09 september 2007 @ 09:29:
ja dat werkt gewoon zo de 1e die geen ruimte meer heeft zal geen offer meer sturen. Overigens werkt predators reeks ook wel hoewel ik dat ersoonlijk wat minder netjes vind. Conflict detetction is, naar mijn idee, om eventuele fuckups te voorkomen en niet om er gebruik van te maken tijdens normaal gebruik. Het zou mooier zijn als de 2 DNS servers met elkaar synchroniseren, maar dat schijnt niet te kunnen.

Met wat scripting kun je de DHCP servers wel synchroniseren, maar erg eenvoudig is het niet nee.
Zou toch een leuke optie zijn, misschien komt die nog wel eens.

[Brahiewahiewa]

Ik begrijp de achtergrond van je probleem niet helemaal. Wat probeer je nu eigenlijk te realiseren?
Je hebt nu twee subnets met elk hun eigen DHCP server en om een of andere reden wil je dat clients uit het subnet2 de DHCP server op subnet1 gaan gebruiken. Waarom?

Als je redundancy wilt, breng je normaal gesproken 20% van de scope onder op je backup server (en die 20% exclude je op je primaire server zie http://www.microsoft.com/...vices/ignsbp_3.mspx#EFHAC). Dat zou in jouw geval betekenen dat je 20% van de scope van subnet1 op de dhcp server van subnet2 zet en 20% van de scope van subnet2 op subnet1. Om je clients van subnet2 de dhcp server van subnet1 als primaire server te laten gebruiken zie ik geen meerwaarde.

Overigens is het in dit opzicht interessant om te weten wat een windows dhcp client doet als hij zijn lease niet verlengd krijgt: de client gaat dan de default gateway pingen. Als de default gateway er nog is en een ARP voor z'n eigen IP-adres levert niks op, dan handhaaft hij z'n IP-adres.

Als je je zorgen maakt over APIPA adressen dan lees je Routing Does Not Work When Multiple Adapters Use Automatic Private IP Addressing Simultaneously

[TrailBlazer]

Brahiewahiewa schreef op maandag 17 september 2007 @ 10:54:
Als je redundancy wilt, breng je normaal gesproken 20% van de scope onder op je backup server (en die 20% exclude je op je primaire server zie http://www.microsoft.com/...vices/ignsbp_3.mspx#EFHAC). Dat zou in jouw geval betekenen dat je 20% van de scope van subnet1 op de dhcp server van subnet2 zet en 20% van de scope van subnet2 op subnet1. Om je clients van subnet2 de dhcp server van subnet1 als primaire server te laten gebruiken zie ik geen meerwaarde.

en als de primaire DHCP server sterft heb je nog maar 20% van je ip adressen over lekkere redundancy

[Brahiewahiewa]

TrailBlazer schreef op maandag 17 september 2007 @ 11:05:
[...]en als de primaire DHCP server sterft heb je nog maar 20% van je ip adressen over lekkere redundancy

Denk je dat bij het uitvallen van een DHCP server alle clients meteen hun IP-adres kwijtraken? Je hebt een kwart van de helft van je lease-tijd om een nieuwe server in de lucht te brengen; een uur dus, als je'm op de standaard van 8 uur laat staan. Als dat voor jou niet genoeg is, moet je de lease-tijd verhogen, of een geclusterde DHCP server neerzetten

[ Voor 3% gewijzigd door Brahiewahiewa op 17-09-2007 17:02 ]

[TrailBlazer]

het ligt heel sterk aan je omgeving denk ik of je het daarmee redt. Bij mij op het werk heeft iedereen een laptop. De ene keer werk je vanaf de 3e verdieping de andere keer vanaf een vergaderzaal op de 5e of op mijn vaste werkplek op de begane grond. Omdat al deze verdiepingen een eigen VLAN hebben moet je continue je IP adres vernieuwen. Dus het verhogen van je lease time heeft dan geen zin.
Ook is het vervangen van een server echt geen klusje van een uur in ieder geval niet bij ons. Eerst moet india doorhebben wat er aan de hand is. Dus dat zijn de 1e 2 uur. Dan gaan ze aan de local site support vragen of er spanning op staat en we zijn weer 2 uur verder. Dan hebben ze eindelijk door dat die server echt dood is. Dan gaan ze Getronics bellen. kortom voor je het weet zijn we 8 uur verder. Dus wordt er een volledige redundantie gemaakt door alle scopes 2 keer zo groot te maken en te verdelen over 2 servers.

[ Voor 39% gewijzigd door TrailBlazer op 17-09-2007 18:05 ]

[Verwijderd]

Brahiewahiewa schreef op maandag 17 september 2007 @ 17:01:
[...]
Denk je dat bij het uitvallen van een DHCP server alle clients meteen hun IP-adres kwijtraken? Je hebt een kwart van de helft van je lease-tijd om een nieuwe server in de lucht te brengen; een uur dus, als je'm op de standaard van 8 uur laat staan. Als dat voor jou niet genoeg is, moet je de lease-tijd verhogen, of een geclusterde DHCP server neerzetten

De 80-20 regel is slechts 1 van de oplossingen. De 50-50 regel is ook vrij veel gebruikt. Echter dat houdt wel in dat je max 50% van het aantal ip's in een subnet kan uitgeven (zeg 125 ip's in een c klasse subnet) ipv 80% (zeg 200 ip's in een c klasse subnet).

Overigens is het niet helemaal waar wat je zegt. Je hebt geen garanties dat er een ipnummer vrij is op je 2de dhcp server.
De DHCP server, die het eerste reageert, zal een ip afgeven, normaal gesproken is dat wel de dhcp server op het eigen subnet, maar als die server toevallig net druk was, kan je dhcp relay best sneller zijn geweest...

De kwart van de helft gaat ook uit dat leases gelijkmatig verdeeld over de hele lease tijd worden uitgegeven. in praktijk is er bijna altijd een piekmoment, wanneer de meesten mensen beginnen...

[Verwijderd]

TrailBlazer schreef op maandag 17 september 2007 @ 18:01:
het ligt heel sterk aan je omgeving denk ik of je het daarmee redt. Bij mij op het werk heeft iedereen een laptop. De ene keer werk je vanaf de 3e verdieping de andere keer vanaf een vergaderzaal op de 5e of op mijn vaste werkplek op de begane grond. Omdat al deze verdiepingen een eigen VLAN hebben moet je continue je IP adres vernieuwen. Dus het verhogen van je lease time heeft dan geen zin.
Ook is het vervangen van een server echt geen klusje van een uur in ieder geval niet bij ons. Eerst moet india doorhebben wat er aan de hand is. Dus dat zijn de 1e 2 uur. Dan gaan ze aan de local site support vragen of er spanning op staat en we zijn weer 2 uur verder. Dan hebben ze eindelijk door dat die server echt dood is. Dan gaan ze Getronics bellen. kortom voor je het weet zijn we 8 uur verder. Dus wordt er een volledige redundantie gemaakt door alle scopes 2 keer zo groot te maken en te verdelen over 2 servers.

laptop gebruikers met veel wisselende locaties zijn zowieso irritant. Tenminste als ze niet netjes de tijd nemen om helemaal hun laptop af te sluiten met netwerkkabeltje in de laptop

En de 50-50 regel dus

[TrailBlazer]

Verwijderd schreef op maandag 17 september 2007 @ 19:08:
[...]


laptop gebruikers met veel wisselende locaties zijn zowieso irritant. Tenminste als ze niet netjes de tijd nemen om helemaal hun laptop af te sluiten met netwerkkabeltje in de laptop

En de 50-50 regel dus

dat doe ik dus nooit gewoon kabel eruit en naar een vergaderruimte. Kebel er weer in. Gevolg outlook hangt de hele computer op voor 5 minuten en dan weer verder

[mookie]

hoewel ik zelf ook liever 50-50 ga is de 80-20 regel in principe ook wel goed.
De server die een deel excluded heeft zal die adressen niet uitgeven als nieuwe adressen via een offer maar wel verlengen als een client daarom vraagt. In de praktijk zie ik dan ook wel regelmatig dat de server die de adressen uit mag delen te laat is en dat vervolgens de 2de server het wel toestaat om een excluded adres door een client te laten hergebruiken en het registreerd. Kan ook gewoon eindeloos verlengt worden, je hebt alleen een probleem als je niet-excluded range vol zit en je hebt nieuwe clients die nog geen adres hebben en die eerste DHCP server doet het nog steeds niet.

Terug op het verhaal van de TS: er staat me bij de elke DHCP server zelf minstens 1 adres in de range van een scope moet hebben om daar adressen aan uit te delen.
Als voorbeeld:
Site A heeft 172.16.x.x/255.255.0.0 en site B heeft 172.17.x.x/255.255.0.0
Beide scopes bestaan op een server in site A.
De server in site A heeft als IP adres 172.16.1.1
Wat ik me afvroeg (ik moet hetzelfde op gaan zetten) is of de DHCP server in site A ook een adres in 172.17.x.x nodig heeft om adressen uit te delen of niet. Wellicht is dat met een DHCP helper/dhcp relay op een router niet nodig... ik heb namelijk wisselende antwoorden gevonden op internet en toevallig zie ik nu iets dergelijks voorbijkomen alvorens ik hetzelf ging testen.

Dus ik ben benieuwd naar de reactie van de TS en met name of hij de DHCP server in site/range A ook een adres moet geven in site/range B om het te laten werken...

Niet om dit topic mezelf toe te eigenen maar het is redelijk on-topic en wellicht is de TS zo vriendelijk om het te vermelden als hij alles aan de gang heeft gekregen...

[TrailBlazer]

Nee hoor dat is niet nodig. Als de router een DHCP request ontvangt forward deze het request naar de server. De source wordt dan aangepast van 255.255.255.255 naar het broadcast netwerk van de interface waarop de broadcast binnenkomt. Dus in jouw voorbeeld 172.17.255.255 De DHCP server zoekt dan de scope waar deze broadcast dan binnenvalt en vervolgens stuurt hij een reply. Weer naar dat broadcast netwerk 172.17.255.255

[Verwijderd]

TrailBlazer schreef op maandag 17 september 2007 @ 19:34:
[...]

dat doe ik dus nooit gewoon kabel eruit en naar een vergaderruimte. Kebel er weer in. Gevolg outlook hangt de hele computer op voor 5 minuten en dan weer verder

en dan hopen dat de dns scavenging langer staat dan de dhcp lease time. Krijg je leuke effecten van als je software distributie applicaties gebruikt. Netjes afloggen schoont je dns entry op namelijk

[TrailBlazer]

dns scavenging ???

[alt-92]

DNS scavenging ja

Of wilde je tot aan het einde der tijden overal loze pointers en A-records met verouderde IP adressen van 20 segmenten in je DNS houden ?

[Brahiewahiewa]

TrailBlazer schreef op woensdag 19 september 2007 @ 18:54:
dns scavenging ???

How DNS dynamic updates work together with the DNS "aging and scavenging" process in Windows 2000 and in Windows Server 2003

[TrailBlazer]

blijkt maar weer dat ik me meer moet gaan verdiepen in alles wat zich boven laag 4 bevindt