Heeft iemand ervaring met een redundante ISC-DHCPD setup? Wij lopen onder omstandigheden tegen het onderstaande verhaal aan. Voor de volledigheid omschrijf ik de hele sequence maar, omdat een en ander een aaneenschakeling van 'als, mits" lijkt te zijn. We hebben twee machines in failover config staan, in separate netwerken. Clients zitten niet in het lokale subnet maar praten via een 'sort-of' DHCP relay. Bij het ontvangen van de DISCOVER stuurt de relay deze gedupliceerd door naar beide servers. Een van beiden stuurt een OFFER, de andere logt "load balance to peer default". De relay stuurt de OFFER door naar de client, maar om nog onduidelijke redenen komt deze niet altijd aan. De client doet een timeout en stuurt vervolgens nog een DISCOVER met een identieke transaction-id. De relay stuurt deze weer door naar beide servers en blijkbaar interpreteert de redundante setup de hernieuwde DISCOVER met identieke transaction-id als een teken van transmissie problemen. In antwoord daarop sturen _beide_ servers een OFFER, het IP in deze offers is niet identiek en ook geen van beiden identiek aan de eerste OFFER. Dit gedrag van twee offers en de aanname dat dit het gevolg is van de herhaalde discover met identiek transaction-id is nergens op gebaseerd, bij deze tweede offer logt geen van beide servers namelijk een bijzondere melding. De relay stuurt beide offers door naar de client. De client selecteert (op nog onbekende gronden) een OFFER en stuurt een REQUEST naar het IP van de versturende server. De relay dupliceert dit pakket weer en stuurt het door naar de bij hem 2 bekend zijnde DHCP servers. Beide servers sturen een ACK, we nemen vooralsnog ongefundeerd aan dat beide servers dit doen omdat ze een failure-state vermoeden op grond van de herhaalde DISCOVER. Onder normale omstandigheden zou een enkele REQUEST ook een enkele ACK tot gevolg hebben, met een melding omtrent load-balancing op de 2e server. Beide servers zetten hun eigen IP in de server identifier in de ACK. De relay stuurt beide ACK's door naar de client. Een intermediate device (tussen relay en client) dropt de tweede ACK (commentaar: er is een sort of statemachine geimplementeerd die ook actief het DHCP verkeer in de gaten houdt en het blijkbaar nodig acht om de tweede ACK te droppen). Hier is sprake van een race-condition: als de eerste ACK van de machine blijkt te zijn waar de REQUEST heen is gegaan dan accepteert de client hem. Komt de ACK van de tweede machine aan dan pikt (in ieder geval die DHCP implementatie van Windows XP) de client hem niet, waarschijnlijk als gevolg van de server identifier. Er volgt weer een timeout van de client en het hele circus start opnieuw. Het droppen van de 2e ACK is geen probleem indien er geen twee OFFERS worden gedaan, die tweede ACK komt namelijk niet, ook al wordt de REQUEST wel degelijk richting beide servers gestuurd. De 2e server reageert in dat geval namelijk met een 'lease owned by peer' en stuurt in dat geval helemaal niets terug richting de client. Concreet mijn vraag: is het geschetste gedrag van de DHCP servers (eerst _een_ OFFER en bij herhaling van de DISCOVER met identieke transaction-id allebei een OFFER) zoals het zou moeten zijn? Elke andere input, behalve in reactie op bovenstaande vraag, is uiteraard ook welkom.