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.
