10 votos

Mensaje de error "Se ha superado el límite de nombres de la tarjeta adaptadora de red del ordenador local".

Permítanme comenzar diciendo que ya he buscado en muchas fuentes información o una resolución, pero no he podido encontrar una solución permanente.

Problema: De forma aleatoria, sin motivo aparente, el servidor Windows comienza a responder con el mensaje de error cuando intenta acceder a cualquier recurso de red. No importa si se trata de una unidad de red, una ruta UNC o un enlace simbólico. Además, los clientes tampoco pueden acceder al servidor cuando se produce este error. El Escritorio Remoto indica que no se puede encontrar la máquina cuando intento conectarme. PING devolverá la IP asignada, pero indica que la solicitud ha expirado. No hay información en el registro de eventos de Windows para este error.

El servidor es una máquina virtual que ejecuta Windows Server 2016. Solo hay una tarjeta de red virtual asignada y no hay VLAN segmentadas.

A partir de http://support.microsoft.com/kb/319504 - Me doy cuenta de que esto es para una versión antigua de Windows, pero de hecho me sale "system error 68 has occurred" cuando ejecuto el comando "net use * \server\folder " en el momento en que el servidor está produciendo el error. Sin embargo, ninguna de las formas de solucionar el problema funciona.

Me cuesta creer que se hayan utilizado todos los puertos efímeros. Ejecutando el comando "netsh int ipv4 show dynamicport tcp" actualmente muestra que hay 16384 puertos disponibles para su uso.

Ejecutando "netstat -ano" en el momento en que el servidor está produciendo el error se muestran muy pocos recursos de red en uso (menos de 50). Los estados son de escucha o establecido. No hay sesiones o puertos atascados en time_wait o close_wait.

Siguiente, https://support.microsoft.com/en-us/help/929851/the-default-dynamic-port-range-for-tcp-ip-has-changed-in-Windows-vista . Este artículo confirma lo que estoy viendo para el rango dinámico de puertos, que comienza con 49152 en lugar de entre 1024 y 5000. También me mostró el comando netsh utilizado anteriormente.

La mayoría de las búsquedas en Google me remiten a support.microsoft.com/kb/319504, que es el primer artículo al que he ido, o son para un producto no relacionado (como BizTalk o Exchange).

La máquina virtual tiene una carga ligera. No hay muchos clientes conectados. El único software instalado actualmente es SQL Server 2016.

Si reinicio la máquina virtual, el error desaparece durante unos días. Luego vuelve. Y lo realmente extraño es que tengo 2 VM que están actuando de esta manera. La máquina anfitriona de la VM funciona sin errores. Y todas las otras máquinas virtuales en ese host están trabajando sin error. La red subyacente no tiene problemas reportados tampoco. Todas las máquinas están en el mismo dominio.

No sé qué es lo que produce el error. Cualquier ayuda será muy apreciada.

Gracias

1voto

Manuel Puntos 31

Empecé a tener exactamente este mismo problema en un Hipervisor Windows Server 2016. Mis resultados de netstat me muestran más o menos lo mismo que el post original en cuanto a conexiones establecidas/escuchas - nada fuera de lo común.

Aquí es donde las cosas se ponen interesantes: Había configurado este hipervisor como un repositorio de registro de Watchguard para el cortafuegos y me he dado cuenta de que cuando se produce el problema de conectividad, un elemento de este servicio de registro también falla. No estoy seguro de si este fallo es el huevo o la gallina, pero el servicio de registro utiliza PostgreSQL-8.2 y se ejecuta como un servicio configurado para iniciarse 'Automáticamente'. El servicio se encuentra que no se está ejecutando y cuando trato de iniciarlo manualmente en este estado se inicia y luego se detiene. He observado algunas instancias colgadas del proceso postgres.exe que siguen ejecutándose a pesar de que el servicio está detenido. Si finalizo esos procesos, puedo iniciar el servicio PostgreSQL-8.2 y la conectividad de red del servidor vuelve a ser normal de repente.

Todavía no estoy seguro de cómo evitar que esto suceda, sin embargo, o si el servicio PostgreSQL está causando esto o sólo un dominó en una cascada de fallos.

Esto puede no ser exactamente lo que hay que buscar en la mayoría de los casos, pero podría ser una pista para que otros busquen un servicio o proceso que ha colgado la conectividad de red.

0voto

BMDan Puntos 4643

La configuración de red de tu máquina virtual es relevante aquí. Por favor, compártala.

Aunque estoy más familiarizado con Linux que con Windows, si estás utilizando una red de puente simple, podría imaginar que esto ocurra ya sea debido al agotamiento de recursos causado por uno o más otros nodos (dos VMs y un host compartiendo una IP, y entre ambos agotan todos los efemas), o simplemente porque el puerto efímero que el sistema desea utilizar ya está en uso por otra VM o el propio host y Windows ingenuamente asume que tiene derechos exclusivos sobre todos los puertos, lo que significa que un fallo de bind en min(in_use_port + 1, max_port) indica inequívocamente un agotamiento de los puertos. El único aspecto que no encaja con esta hipótesis es que ping no responde. Ping es ICMP, y no tiene nada que ver con la disponibilidad de los puertos efímeros, o la falta de ella.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X