- NIC Teaming permite agrupar varias tarjetas de red físicas en un único adaptador lógico para ganar ancho de banda y alta disponibilidad.
- En Windows 11 ya no se soporta Intel PROSet/ANS, por lo que el teaming clásico depende de PowerShell, Hyper-V o soluciones no oficiales.
- Windows Server mantiene una gestión nativa y gráfica de NIC Teaming, mientras que en entornos cliente hay que combinar herramientas y configuraciones.
- La correcta configuración del switch (LACP, VLAN y grupos de puertos) es clave para que el NIC Teaming funcione de forma estable y eficiente.
Si tienes un equipo con varias tarjetas de red físicas y te apetece exprimirlo un poco más, configurar NIC Teaming en Windows 11 puede ser una forma muy interesante de ganar ancho de banda efectivo y, sobre todo, de mejorar la alta disponibilidad de la conexión. Aunque esta función nació y se ha mimado más en Windows Server, con algunos trucos y con la ayuda de PowerShell todavía es posible llevarla a ciertos escenarios con Windows 11.
A lo largo de este artículo vamos a ver cómo funciona el NIC Teaming, qué limitaciones tiene en Windows 11 frente a Windows 10 y Windows Server, cómo aprovecharlo en entornos con Hyper-V y qué opciones hay hoy en día para seguir usando tecnologías tipo LBFO (Load Balancing/Failover). Además, integraremos comandos prácticos de PowerShell, advertencias importantes y alguna que otra experiencia real para que no te lleves sorpresas una vez lo pongas en marcha.
Qué es NIC Teaming y por qué interesa en Windows 11
Cuando hablamos de NIC Teaming nos referimos a la capacidad de agrupar varias interfaces de red físicas en un único adaptador lógico. Ese adaptador virtual es el que se ve en el sistema operativo como si fuera una única tarjeta de red, pero por debajo está utilizando varias NIC reales en paralelo.
El objetivo principal es conseguir tres grandes beneficios de red: mayor ancho de banda agregado (por ejemplo, dos interfaces de 1 Gbps trabajando juntas), tolerancia a fallos si una de las tarjetas o cables se cae, y balanceo de carga entre diferentes flujos de tráfico para repartir el uso de la red.
Esta funcionalidad se incorporó de forma nativa en Windows Server 2012 y versiones posteriores, bien a través del Administrador del servidor, bien mediante PowerShell. En sistemas de escritorio como Windows 10 y Windows 11, la película es distinta: el soporte se ha ido recortando, sobre todo por parte de Intel, que ha dejado de ofrecer Intel PROSet e Intel ANS (Advanced Network Services) en Windows 11.
En Windows Server es sencillo crear un team desde la consola gráfica, mientras que en Windows 10 y ciertas ediciones de Windows 11 la forma más realista de lograr algo parecido pasa por PowerShell, por el conmutador virtual de Hyper-V o por soluciones no oficiales que restauran LBFO.
Limitaciones y cambios de Intel PROSet / ANS en Windows 11
Un punto clave que suele pillar por sorpresa es que Intel PROSet e Intel Advanced Network Services ya no se soporten en Windows 11 ni en futuras versiones de Windows cliente. Estas tecnologías eran precisamente las que permitían, desde los drivers de Intel, crear equipos (teams) y VLAN directamente sobre las tarjetas de red.
Intel ha dejado claro que Windows 10 es el último sistema operativo cliente que soporta de forma oficial Intel PROSet y ANS, incluyendo todas las capacidades de teaming y VLAN ligadas a esos drivers. En Windows 11, aunque los drivers de red de Intel existen y se actualizan, ya no incluyen esas características avanzadas para agrupar interfaces.
En algunos foros se ha comentado la posibilidad de usar el comando de PowerShell New-NetSwitchTeam en Windows 11 para crear equipos. Desde Intel se indica que han visto que el comando puede ejecutarse, incluso en alguno de sus portátiles, pero no garantizan en absoluto que el team creado funcione correctamente o sea estable.
Además, la documentación oficial de Microsoft para el módulo NetSwitchTeam señala que, en ediciones cliente de Windows, estos cmdlets se pueden usar solo para administrar de forma remota el conmutador extensible de Hyper-V en servidores, y no para ejecutar el conmutador directamente en el propio sistema cliente.
Por tanto, la respuesta “oficial” es clara: no hay ANS en Windows 11 y, con ello, desaparece el mecanismo tradicional de teaming basado en drivers Intel. Lo que sí puedes explorar son las opciones ligadas al switch de Hyper-V, a LBFO restaurado o a configuraciones avanzadas en Windows Server si tu entorno lo permite.
Ejemplo práctico: NIC Teaming en un equipo con Windows 11
Para entender cómo se puede llegar a usar NIC Teaming en Windows 11, vamos a tomar como referencia un caso concreto: un usuario que adquiere un Intel NUC Extreme 9 de segunda mano, con un SSD de 2 TB y espacio para una gráfica ITX. Este equipo, además de ser una pequeña bestia, dispone de dos interfaces Ethernet de 1 Gbps, pensadas precisamente para trabajar en paralelo.
La idea del usuario es crear un NIC Teaming con esas dos interfaces para duplicar el ancho de banda efectivo y conseguir cierta tolerancia a fallos. A nivel de hardware, esto es perfecto: dos puertos físicos conectados a un switch gestionable permiten montar un enlace agregado hacia el equipo.
Lo primero que hace es configurar su switch HP para que los dos puertos donde se conecta el NUC funcionen en modo trunk y permitan la agregación de enlaces. Esto suele implicar activar LACP o un modo estático de trunk, según el modelo de switch y la topología de red que se quiera desplegar.
Una vez ajustada la parte de red, abre una consola de PowerShell con privilegios de administrador en Windows 11 para ver qué interfaces tiene disponibles y preparar el terreno antes de crear el team.
Con el siguiente comando obtiene el listado de adaptadores de red presentes en el sistema, en su caso LAN01 y LAN02 como tarjetas principales, además de otros interfaces como la Wi-Fi o adaptadores USB:
Una vez identificadas las interfaces que van a formar parte del equipo, ejecuta el comando de PowerShell para crear el team, usando como nombre lógico LANTEAMING y agregando LAN01 y LAN02 como miembros:
Tras unos segundos, puede comprobar que el equipo virtual se ha generado correctamente mediante Get-NetSwitchTeam, que muestra el nombre del team y las interfaces que lo componen:
Desde las propiedades del nuevo adaptador lógico se observa que la velocidad efectiva aparece como 2 Gbps, fruto de la suma de las dos interfaces de 1 Gbps. A partir de ahora, el tráfico puede repartirse entre los puertos físicos, y si uno de ellos deja de estar disponible, el otro mantiene la conectividad.
Al ejecutar un ipconfig se ve claramente que el sistema operativo expone el nuevo adaptador LANTEAMING, mientras que las tarjetas físicas quedan “ocultas” a nivel de configuración IP:
En este caso, la dirección IP entregada por el DHCP coincide con la que antes tenía la interfaz LAN01, pero ahora esa IP se asocia al equipo LANTEAMING, no a la NIC física. Si uno de los dos puertos cae (por ejemplo, desconectando el cable de LAN01), la velocidad se reducirá al enlace restante, pero la conectividad se mantiene.
Este tipo de configuración ofrece por tanto alta disponibilidad de red frente a fallos de tarjeta, de puerto del switch o incluso de latiguillo, todo ello de manera relativamente transparente para el sistema operativo y para las aplicaciones que solo ven un adaptador de red lógico.
NIC Teaming en Windows 10 con PowerShell
En Windows 10 la situación es un poco menos enrevesada, ya que todavía se solapan las opciones nativas de Microsoft con las de Intel ANS. Una forma habitual de montar NIC Teaming es utilizar PowerShell para crear un Switch Team, tal y como se hace en el ejemplo anterior, pero con un sistema oficialmente soportado.
La idea es la misma: contamos con dos o más interfaces de red físicas, por ejemplo LAN1 y LAN2, y queremos que funcionen como una sola. Lo primero es verificar que las interfaces estén activas y con el driver correcto mediante el comando Get-NetAdapter, comprobando el estado y la velocidad de enlace.
Después abrimos una consola de PowerShell con permisos de administrador y creamos el equipo con un comando muy similar al siguiente, indicando el nombre del team y las tarjetas que se van a integrar:
Si todo va bien, al ejecutar Get-NetSwitchTeam veremos que el equipo aparece como creado y en estado correcto, listo para recibir una configuración IP y funcionar como adaptador lógico principal del sistema. A partir de ahí, desde el archivo CPL en Windows (Centro de redes y recursos compartidos) podemos gestionar la IP del nuevo adaptador, igual que haríamos con cualquier otra interfaz de red.
Las conexiones de Windows 10 quedarán reorganizadas: el sistema mostrará el adaptador de team y dejará las NIC físicas como parte del conjunto, sin configuraciones IP propias. De nuevo se obtiene balanceo de carga y failover, dependiendo del modo configurado y de la compatibilidad del switch remoto.
NIC Teaming en Windows Server desde el Administrador del servidor
En los sistemas Windows Server (2012, 2016, 2019 y ediciones posteriores) el NIC Teaming se puede gestionar de forma totalmente gráfica desde el Server Manager, sin necesidad de recurrir siempre a PowerShell, aunque los cmdlets siguen estando disponibles y son muy útiles para automatizar despliegues.
Dentro de la sección de Servidor local en el Administrador del servidor, justo encima de la información de las tarjetas de red, aparece la opción de NIC Teaming. Si figura como deshabilitada, basta con hacer clic en ese estado para abrir el asistente de configuración correspondiente.
En la ventana de administración de NIC Teaming veremos un panel con los adaptadores físicos detectados. Seleccionando uno de ellos en el apartado de adaptadores e interfaces podremos agregarlo a un nuevo equipo (team). En ese momento se nos pedirá un nombre para el team, que será el que utilice el sistema para crear el adaptador lógico asociado.
Una vez indicado el nombre y seleccionadas las interfaces que formarán parte del equipo, se pueden desplegar las opciones avanzadas, donde aparecen parámetros como qué adaptadores estarán activos y cuáles en espera, el modo de balanceo de carga (por ejemplo, hash de direcciones o modo dinámico) y el tipo de teaming (independiente del switch o dependiente, LACP, etc.).
Algunas de estas opciones no tendrán efecto si estamos trabajando sobre máquinas virtuales en lugar de interfaces físicas, pero en entornos físicos permiten afinar mucho el comportamiento del team, según se busque prioritariamente rendimiento o tolerancia a fallos.
Una vez creado el equipo, el nuevo adaptador de red lógico aparece en el sistema como si fuera una NIC más, pudiéndose configurar desde el Centro de redes y recursos compartidos del servidor. Más adelante siempre es posible volver al asistente de NIC Teaming para añadir o quitar interfaces, cambiar el modo de trabajo o rehacer parte de la configuración.
Conmutador virtual de Hyper-V y VLAN en Windows
Otro elemento muy relacionado con el NIC Teaming en entornos Microsoft es el conmutador virtual de Hyper-V. Este switch permite que las máquinas virtuales creadas en un host de Hyper-V se comuniquen con otras máquinas, ya sea en la misma máquina, en la red interna o hacia redes externas.
Antes de poder instalar y configurar un conmutador virtual, el equipo debe cumplir ciertos requisitos previos, como disponer de hardware compatible con virtualización (Intel VT-x, AMD-V), tener activado Hyper-V en las características de Windows y contar con al menos una NIC física adecuada que pueda enlazarse al conmutador.
Una vez se cumplen estos requisitos, se puede crear un conmutador virtual básico desde el Administrador de Hyper-V o a través de PowerShell. Existen tres tipos principales de conmutador: externo, interno y privado. El más interesante para NIC Teaming y escenarios de producción es el conmutador externo, que enlaza las máquinas virtuales con la red física.
Los conmutadores virtuales externos tienen una opción para permitir que el sistema operativo de administración comparta el adaptador de red seleccionado. Es decir, la misma NIC física puede ser utilizada por el host (Windows) y por las máquinas virtuales que se conecten a ese conmutador, gestionando el tráfico a través del switch extensible de Hyper-V.
Además, se puede configurar la identificación de VLAN (VLAN ID) tanto en los adaptadores de red de las máquinas virtuales como en los propios conmutadores virtuales. En conmutadores internos o externos, se puede establecer un identificador de VLAN concreto; el sistema operativo de administración y las VM que se comuniquen a través de ese switch virtual utilizarán ese mismo ID de VLAN.
Si se necesita un control más fino, el conmutador virtual se puede ajustar con propiedades avanzadas como el modo de puerto, la VLAN nativa o diferentes opciones de etiquetado. Para ello es frecuente recurrir a PowerShell, asegurándose de que la configuración de Hyper-V es compatible con la de los switches físicos y del resto de la red.
Una vez se ha creado y configurado el conmutador virtual, conviene revisar documentación relacionada sobre configuración de redes virtuales, servicios de DHCP y routing en entornos Hyper-V, ya que el rendimiento y la estabilidad de la infraestructura virtual dependen mucho de cómo esté montado todo el conjunto.
Restaurar LBFO y NIC Teaming clásico en Windows 11
Ante la desaparición de Intel ANS y la falta de soporte oficial de LBFO (Load Balancing/Failover) en Windows 11, algunos usuarios avanzados han optado por buscar formas alternativas de seguir usando NIC Teaming en equipos de laboratorio o entornos no críticos.
Un ejemplo reciente es el de un usuario que, al montar un NAS y un servidor de medios con Windows 11 IoT Enterprise LTSC 2024, se encontró con que no podía habilitar LBFO como hacía en Windows 10. Tampoco podía migrar a Windows Server porque algunas aplicaciones de laboratorio eran incompatibles con ese sistema.
Tras investigar bastante y apoyarse en el trabajo previo de otros investigadores (como Graham Sutherland, que recopila documentación muy valiosa sobre este tema), acabó desarrollando una solución de instalación única que restaura las capacidades de LBFO en Windows 11. Esa solución está publicada en un repositorio de GitHub:
https://github.com/hifihedgehog/Windows11LBFO
Con este método ha conseguido que el teaming tipo LBFO funcione en Windows 11 Pro 24H2 y Windows 11 IoT Enterprise LTSC 2024, tanto en máquinas virtuales como en hardware físico. La comunidad va probando la solución y reportando incidencias mediante issues en GitHub, lo que permite ir puliendo detalles.
La gran ventaja de esta aproximación es que se recuperan capacidades avanzadas de agregación de enlaces, como la compatibilidad con LACP o el balanceo eficiente de tráfico entre varias NIC y un router o switch gestionable. En el caso concreto del laboratorio casero mencionado, ver funcionar una agregación de enlaces LACP entre el router y el host (con múltiples clientes transfiriendo datos a la vez) es una auténtica alegría para quien disfruta afinando su red.
No obstante, hay que tener en cuenta que este tipo de soluciones no son oficiales ni están soportadas por Microsoft, por lo que su uso debe limitarse a entornos de pruebas o laboratorios donde se asume cierto riesgo y se dispone de tiempo para hacer troubleshooting si algo se rompe tras una actualización.
Alta disponibilidad, balanceo de carga y escenarios de uso
Más allá de la parte técnica, conviene tener claro qué aportan de verdad el NIC Teaming y LBFO en el día a día. El beneficio más evidente es la alta disponibilidad de la conexión de red: si uno de los enlaces físicos falla (tarjeta, puerto del switch, latiguillo, etc.), el otro sigue en funcionamiento y la conectividad se mantiene sin que el sistema operativo tenga que cambiar a otro adaptador manualmente.
El segundo gran pilar es el balanceo de carga. Dependiendo del modo configurado (ejemplo: hash de IP, hash de MAC, modo dinámico), el tráfico se reparte entre las diferentes NIC del equipo. Esto no siempre significa que una sola sesión vaya el doble de rápida, pero sí que varias conexiones simultáneas pueden aprovechar de manera mucho más eficiente los enlaces disponibles.
En entornos domésticos avanzados o de laboratorio, esto se nota especialmente cuando se realizan transferencias simultáneas desde varios clientes hacia un NAS o un servidor multimedia. En lugar de saturar una sola interfaz, el tráfico se distribuye y la experiencia de todos los clientes mejora.
En escenarios de producción, como servidores de archivos, máquinas que alojan múltiples máquinas virtuales con Hyper-V o hosts que sirven aplicaciones críticas de negocio, el NIC Teaming se convierte en una pieza más del puzzle de alta disponibilidad, junto a clústeres, almacenamiento redundante y fuentes de alimentación dobles.
Eso sí, para aprovechar de verdad el potencial de teaming, es importante que la configuración del switch o router sea coherente con la del equipo. Activar LACP, definir correctamente los grupos de puertos, revisar las VLAN y asegurarse de que el modo de balanceo de carga es compatible son tareas que marcan la diferencia entre un team estable y uno lleno de problemas intermitentes.
En definitiva, el NIC Teaming sigue siendo una herramienta muy potente para quienes necesitan ir un paso más allá de la conexión de red básica, aunque en Windows 11 haya que combinar soluciones nativas, Hyper-V y proyectos de la comunidad para lograr lo que antes se conseguía con unos pocos clics en Intel PROSet o en el Administrador del servidor.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.