Problemas de validación en dominio

Cada día los equipos informáticos son más rápidos y potentes, y ésto, aunque sorprenda, puede plantear algún problema.
Ya en su día me enfrenté a un problema de colapso de la red debido a que los enlaces troncales de la oficina eran de 100 Mbps y a medida que se cambiaban equipos y se instalaban impresoras compartidas, la red llegó a colapsar. La solución, aunque poco popular fue efectiva. Limitar en los conmutadores la velocidad de acceso a 10 Mbps.
El último problema y a mi entender más grave, es la velocidad con la cual se arrancan los equipos. Existe en las redes ethernet un protocolo imprescindible, el Spanning Tree, que evita que un cable mal puesto generando un bucle, provoque la caída de la red de datos. Por diseño, este protocolo tiene unos elevados tiempos de convergencia (tiempo que pasa desde que un puerto se levanta hasta que realmente admite datos). Este tiempo es necesario ya que se escucha la información de la red y del nuevo puerto para verificar que no se trata de un bucle.
Los más avispados ya sabréis por donde anda el problema. El tiempo de convergencia es de 30 segundos. Si el equipo intenta validarse en la red (u obtener la dirección por DHCP), antes de que transcurran estos 30 segundos, la red se "tragará" la información.
A continuación adjunto una receta de como tratar el problema. No la recomiendo en absoluto, ya que es mejor retrasar o hacer mayor el timeout de validación, que no arriesgarse a un bucle en la red, con la consecuente caída de la misma.
La solución pasa por eliminar el STP o reducir el tiempo de convergencia. Otros tiempos de espera son debidos a las negociaciones de configuración, pero son menos habituales y ya dependen mucho del tipo de equipo, marca, modelo, etc.

Es posible que los tiempos de negociación de los puertos de los conmutadores, retrase la disponibilidad de la red para:
* Obtener las direcciones del DHCP.
* Validarse correctamente en el dominio.

Estos tiempos de negociación se deben a los siguientes protocolos:
1.- STP.
2.- EtherChannel (No en todos los equipos).
3.- Velocidad / Modo.
4.- Puerto de enlace (DTP). (no en todos los equipos)

Procederemos de la siguiente manera para diagnosticar el posible fallo por el retardo:
Para averiguar el tiempo que se tarda en la negociación:

1.- Habilitar el modo de depuración sobre los puertos o sobre el spanning tree al maximo. Esto nos permitirá ver los cambios de estado del puerto y los tiempos (tiemstamps) en los cuales se producen.

2.- Deshabilitar el puerto de forma administrativa y volverlo a habilitar. Esto dejará en consola los tiempos de cambio entre cada estado del puerto. En teoría el protocolo STP tarda en converger 30 segundos, 15 segundos para la fase de listening y otros 15 segundos para la fase de learning. Los tiempos de negociación de la velocidad suelen rondar los 2 a 4 segundos.

3.- Es posible, aunque peligroso reducir el tiempo de convergencia del spanning tree, ya que ante un bucle, éste podría llegar a provocar una tormenta de broadcast, ya que los 30 segundos se usan para determinar si existen bucles. Para reducir el tiempo existe un comando denominado portfast

4.- Otros retardos en la negociación de la comunicación, para establecer la configuración final del puerto, podrían ser agravantes de la situación. Pero estos ya dependerán de características concretas de los equipos.

NOTA:
Adicionalmente hemos de tener en cuenta que es parametrizable el tiempo que espera el netlogon (servicio de inicio de sesion de Windows). Esto se establede por la variable ExpectedDialupDelay (de tipo Reg_Dword).
Esta variable se establece en el registro de windows (regedit), en la siguiente rama:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters.