[DHCP]Meerdere DHCP servers in een subnet

[Verwijderd]

medeTweakers,

De situatie is als volgt:
Grote klant van ons heeft een (Windows 2008) netwerk waarop rond de 1000 devices zich aanmelden op het netwerk en middels DHCP een IP-adres toegewezen krijgen. Het netwerk kent meerdere DC's, DNS-servers en DHCP-servers. Omdat er zich problemen voordoen met clients die niet kunnen aanmelden op het netwerk omdat de scope van DHCP server A vol zit, terwijl DHCP server B nog adressen beschikbaar heeft, ben ik gevraagd door de systeembeheerders om het probleem aan te pakken.

Het netwerk bestaat uit één groot subnet (in 't zelfde LAN, zonder routers (not-routed network) e.d.): 192.168.12.0/22. Er zijn 1022 te gebruiken IP-adressen. Er zijn twee DHCP servers: DHCP server A (IP-adres 192.168.15.x) en DHCP server B (IP-adres 192.168.15.x).

Er is in DHCP een superscope aangemaakt, waaronder 1 memberscope welke verantwoordelijk is voor de (gehele) range 192.168.12.0 t/m 192.168.15.254. Deze superscope en memberscope zijn op beide DHCP-servers aangemaakt. Exclusions en reserveringen zijn Microsoft recommended geconfigureerd op beide servers.

Wat er moet gebeuren:

• DHCP-servers moeten onderling communiceren. Zodra DHCP server A vol zit qua uitdelen IP-adressen, moet server B IP-adressen gaan uitdelen.
• De IP-range moet uitgebreid worden naar 192.168.12.0/16, zodat er 65534 adressen beschikbaar komen (192.168.0.0 t/m 192.168.255.254).

Probleem/ vraagstelling:
Ik heb veel 'best practices' gelezen, maar hoe de DHCP het beste in te richten is is me nog niet duidelijk. Wat moet ik doen met dit grote netwerk, waarbij alles in hetzelfde LAN/SUBNET zit? Momenteel is er een superscope met 'slechts' 1 memberscope, kan dit om beide DHCP-servers met elkaar te laten communiceren? Of is het beter om meerdere memberscopes aan te maken? Wat is de gemakkelijkste stap om dit netwerk uit te breiden naar een /22 netwerk (192.168.12.0/ 255.255.0.0)?

[Question Mark]

DHCP Best Practices

Use the 80/20 design rule for balancing scope distribution of addresses where multiple DHCP servers are deployed to service the same scope.

Using more than one DHCP server on the same subnet provides increased fault tolerance for servicing DHCP clients located on it. With two DHCP servers, if one server is unavailable, the other server can take its place and continue to lease new addresses or renew existing clients.

A common practice when balancing a single network and scope range of addresses between two DHCP servers is to have 80 percent of the addresses distributed by one DHCP server and the remaining 20 percent provided by a second.

Voor de rest vraag ik me af wat het probleem eigenlijk is? Een client hoort van elke DHCP-server welke zijn DHCP-discover broadcast ontvangt een DHCP-offer te ontvangen en kiest dan de "beste" offer. In jouw geval zal hij dan de offer moeten gaan kiezen van de server die nog ruimte in zijn scope heeft. Heb je al eens met een netwerksniffer gekeken wat er gebeurd als een client geen ip-adres kan krijgen?

[Verwijderd]

@Question Mark
Dank voor je reactie. Probleem is dat als DHCP server A vol zit wat uitdelen van adressen betreft, server B niet zijn 'ding doet' en geen adressen uitdeelt aan de clients. Tenminste: in 90% van de gevallen niet. Sommige devices krijgen netjes een IP-adres uit de range van DHCP server B als DHCP server A vol zit.

Wat betreft sniffering van netwerkpakketjes: dit moet ik nog proberen. Maar dan moet ik waarschijnlijk met een hub en packettracer aan de gang, of monitoringpoort op de managed switch instellen?

[Question Mark]

Kan, of je installeert een sniffer op een pc. Geeft een "ipconfig /release", start de sniffer en geef een "ipconfig /renew". Een hub ben ik nooit zo fan van bij dit soort zaken, je introduceert dan toch weer een extra component waardoor je niet helemaal eerlijk test (in dit geval een half duplex verbinding ipv full duplex). SPAN poort op je switch is dan netter.

Staat verder spanning tree portfast wel enabled op de accesspoorten? Dat wil ook nog wel eens problemen geven bij het verkrijgen van een ip-adres tijdens het booten van een systeem. Zorg dan ook dat je heel duidelijk inzichtelijk krijgt wanneer welk probleem nu precies optreed.