![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(272, 20%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ELP%3C/text%3E%3C/svg%3E)
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(275.2, 16%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EV%3C/text%3E%3C/svg%3E)
Hola López Pablo,
El mecanismo de tiempo de espera (timeout) de heartbeat para la conmutación por error (failover) de DHCP en Windows es una configuración del sistema programada de forma fija que no puede extenderse ni modificarse. Aunque es posible ajustar la propiedad StateSwitchInterval mediante el cmdlet Set-DhcpServerv4Failover, esto solo modifica el tiempo que espera el servidor antes de declarar a un socio como "Inactivo" (Down) tras un fallo de comunicación. Dicha acción no evita la detección inicial de la pérdida del heartbeat.
Dado que estas interrupciones son eventos de capa de transporte que ocurren en el puerto 647, esta configuración solo enmascara los síntomas sin abordar la causa raíz. Es imperativo centrarse en la resolución de problemas de la infraestructura de red subyacente para mitigar la pérdida de paquetes transitoria o los problemas de latencia que afectan la comunicación entre los nodos.
VPHAN