Si tienes un PC o servidor con varias tarjetas de red y quieres sacarles todo el jugo, es muy probable que hayas oído hablar del NIC Teaming en Windows 11. Esta técnica lleva años usándose en entornos profesionales, pero cada vez es más común verla también en laboratorios caseros, NAS montados a mano o pequeños servidores domésticos que mueven muchos datos por la red.
El problema es que en Windows 11 muchas de estas funciones están más escondidas o directamente recortadas respecto a Windows Server, así que no es tan intuitivo como abrir un asistente gráfico y listo. Hace falta entender qué es exactamente el NIC Teaming, qué tipos existen (LBFO clásico, SET, SDN…), qué limitaciones hay en sistemas cliente y cómo montarlo correctamente con PowerShell y un switch bien configurado.
¿Qué es NIC Teaming y por qué interesa en Windows 11?
Cuando hablamos de NIC Teaming o formación de equipos de NIC nos referimos a la posibilidad de juntar varias tarjetas de red físicas en un único adaptador lógico. A ojos de Windows ya no tienes dos o tres interfaces independientes, sino un solo adaptador “virtual” sobre el que configuras la IP, la máscara, la puerta de enlace y el DNS.
Este enfoque permite que el tráfico ya no dependa de una única tarjeta, sino de todas las NIC que se agrupan en el equipo. El objetivo es doble: sumar ancho de banda total (link aggregation) y ganar tolerancia a fallos, de modo que si un cable, un puerto del switch o un adaptador se muere, el resto continúe funcionando sin que pierdas conectividad.
Una forma sencilla de verlo es imaginar que tienes varios tubos de agua en paralelo y los unes en una sola tubería de mayor diámetro: el caudal total aumenta y un pinchazo en uno de los tubos no te deja seco. En red ocurre algo parecido: combinas la capacidad de varios enlaces y minimizas las consecuencias de una avería individual.
Para los servidores físicos es muy típico disponer de varios puertos Ethernet de 1 Gbps o 10 Gbps. En lugar de dejar algunos sin usar o repartirlos para tareas distintas, lo más lógico es agregarlos en un único equipo NIC que se encargue del balanceo de carga y la alta disponibilidad. Esto viene especialmente bien en servidores de archivos, entornos de virtualización, NAS caseros o equipos que sirven como centro de copias y medios.
En Windows Server el soporte de NIC Teaming está muy maduro desde hace varias versiones y se puede gestionar tanto desde el Administrador del servidor como mediante PowerShell. En Windows 10 y Windows 11 la historia cambia: no tienes un asistente gráfico integrado para el teaming clásico, muchas funciones de LBFO están pensadas para servidor y, sin embargo, existen cmdlets y soluciones alternativas que permiten conseguir resultados muy similares si sabes dónde tocar.
Diferencias entre NIC Teaming clásico, LBFO, SET y SDN
Para aclararnos con lo que se puede y no se puede hacer en Windows 11, conviene separar varios conceptos que a veces se usan como sinónimos: NIC Teaming (LBFO), Switch Embedded Teaming (SET) y redes definidas por software (SDN). Todos apuntan a mejorar rendimiento y disponibilidad, pero no funcionan igual ni están pensados para los mismos escenarios.
El NIC Teaming clásico, también conocido como LBFO (Load Balancing and Failover), fue la tecnología que Microsoft popularizó en versiones anteriores de Windows Server. Con LBFO puedes armar un equipo de NIC “independiente” del conmutador virtual de Hyper-V y exponer uno o varios adaptadores virtuales al host o a las máquinas virtuales, encargándose del balanceo y de la conmutación por error entre las tarjetas físicas.
Con la llegada de Windows Server 2016 y la apuesta fuerte por las redes definidas por software (SDN), aparece Switch Embedded Teaming (SET). En este modelo, la lógica de formación de equipos se integra directamente dentro del conmutador virtual de Hyper-V. En lugar de crear un equipo por fuera y luego enchufarlo al vSwitch, en SET son los adaptadores físicos agregados los que alimentan al propio vSwitch, reduciendo capas intermedias y mejorando la integración con la pila SDN.
SET se diseñó pensando en entornos de virtualización avanzados, donde entran en juego tecnologías como RDMA (Acceso Directo a Memoria Remota), NVGRE, VXLAN, NFV o controladoras de red. En estos escenarios el objetivo es bajar la latencia, exprimir al máximo el rendimiento y controlar el tráfico de muchas máquinas virtuales dentro de una arquitectura de red muy flexible.
En estaciones de trabajo y sistemas cliente como Windows 10 y Windows 11, la situación es más terrenal: normalmente no tienes un Hyper-V con SDN a gran escala, pero sí puedes disponer de varias tarjetas Ethernet que quieras agrupar para hablar con un switch gestionable, un router avanzado o un NAS que soporte agregación de enlaces. Ahí las opciones pasan por usar los cmdlets disponibles (por ejemplo New-NetSwitchTeam) para crear un equipo básico o recurrir a soluciones que restauran parte de las capacidades de LBFO en ediciones donde ya no vienen expuestas de forma oficial.
Ejemplo real: montar NIC Teaming en un NUC con Windows 11
Un ejemplo muy ilustrativo es el de un NUC Extreme de gama alta, que puedes encontrar de segunda mano a muy buen precio y que trae extras interesantes: almacenamiento SSD generoso, posibilidad de instalar una GPU ITX y, lo que aquí nos importa, dos interfaces Ethernet de 1 Gbps cada una. Este tipo de máquina es perfecta como mini servidor doméstico o de laboratorio (ver las especificaciones completas).
De fábrica, esos dos puertos RJ45 funcionan como interfaces independientes a 1 Gbps. Aunque conectes ambos al mismo switch, Windows los seguirá viendo como rutas separadas, así que no vas a sumar ancho de banda solo por enchufar dos cables. Para que el sistema los aproveche de forma conjunta hay que agruparlos mediante un equipo de NIC.
Antes de tocar Windows es fundamental preparar el switch gestionable donde vas a conectar el equipo. Muchos switches permiten crear un “trunk” o una agregación de enlaces (por ejemplo mediante LACP) con dos o más puertos. La idea es que esos puertos se comporten como un único enlace lógico de mayor capacidad, de modo que el NUC y el switch puedan intercambiar tráfico como si tuvieran una “tubería doble”.
Una vez que el trunk del switch está configurado, llega la parte de Windows 11. Lo primero es abrir una consola de PowerShell con permisos de administrador. Desde ahí, el comando clave para empezar es Get-NetAdapter, que lista todos los adaptadores de red presentes en el sistema, tanto físicos como virtuales.
En un escenario típico verás algo parecido a una interfaz Wi-Fi (por ejemplo, Intel Wi-Fi 6), dos NIC Ethernet cableadas (a lo mejor llamadas LAN01 y LAN02), alguna interfaz Bluetooth y, quizá, un adaptador adicional como un USB Ethernet de 1 Gbps. Lo que nos interesa es apuntar exactamente los nombres de las tarjetas que queremos incluir en el equipo, porque son los que utilizaremos en el comando de creación.
Creación de un Switch Team con PowerShell en Windows 11
Una vez identificadas las interfaces que van a formar el equipo (por ejemplo LAN01 y LAN02), el siguiente paso es crear el equipo como tal. para ello Windows 11 proporciona el cmdlet New-NetSwitchTeam, que permite definir un equipo de adaptadores orientado a escenarios de conmutación y agregación de enlaces.
El comando básico sería algo similar a: New-NetSwitchTeam -Name «LANTEAMING» -TeamMembers «LAN01″,»LAN02». Con esta orden PowerShell agrupa las dos NIC físicas bajo un adaptador lógico nuevo, que aparecerá en el sistema como si fuera una tarjeta adicional. A partir de ese momento, las propiedades IP se configuran sobre LANTEAMING y no directamente sobre LAN01 o LAN02.
Para comprobar que el equipo se ha creado correctamente, puedes ejecutar Get-NetSwitchTeam. El resultado debería mostrar un equipo con nombre LANTEAMING y una lista de miembros donde figuren LAN01 y LAN02. También es buena idea abrir el panel de conexiones de red de Windows para confirmar que el nuevo adaptador lógico aparece entre los disponibles.
Si después de crear el equipo lanzas un ipconfig, verás que la IP ya no está asociada a cada NIC física, sino al adaptador LANTEAMING. Es decir, la configuración de red (IP, máscara, puerta de enlace y DNS) se asigna al equipo lógico, mientras que las tarjetas físicas se convierten en “patas” que dan soporte a ese adaptador virtual.
En la práctica, el nuevo equipo suele obtener dirección IP mediante DHCP, y a menudo conserva la misma IP que tenía una de las tarjetas (por ejemplo LAN01) antes de formar el equipo, siempre que el proceso se haga sin cortar drásticamente la conexión. En cualquier caso, puedes configurar sin problema una IP estática, con su máscara, gateway y servidores DNS sobre el adaptador LANTEAMING igual que harías con una NIC convencional.
Una ventaja clara de este montaje es que si una de las interfaces falla (por ejemplo desconectas un cable), el equipo sigue teniendo red gracias a la otra. Pierdes ancho de banda agregado pero mantienes conectividad, lo que supone un plus de alta disponibilidad frente a fallos puntuales de cableado, puertos de switch o adaptadores de red.
Beneficios reales: ancho de banda agregado y tolerancia a fallos
Se suele simplificar diciendo que con NIC Teaming “duplicas la velocidad”, pero la realidad es algo más matizada. Cuando agregas dos enlaces de 1 Gbps correctamente configurados, lo que consigues es una capacidad total de hasta 2 Gbps repartida entre múltiples conexiones, no tanto un único flujo de 2 Gbps hacia un solo cliente.
En el día a día, esto se traduce en que si varios equipos acceden a la vez a tu NUC, NAS o servidor Windows 11, el sistema puede distribuir las diferentes sesiones entre las NIC que forman el equipo. La suma de todos los flujos puede acercarse a esos 2 Gbps, siempre que el switch soporte agregación de enlaces y el algoritmo de balanceo haga bien su trabajo.
La otra gran ventaja es la alta disponibilidad. Al tener varias tarjetas, varios cables y varios puertos de switch, se reduce mucho la probabilidad de un corte total de red. Si uno de los elementos falla, el equipo NIC continúa ofreciendo servicio a menor velocidad pero sin desconexiones completas. Para servidores con usuarios conectados o máquinas virtuales corriendo encima, esto es vital.
Incluso en un entorno doméstico avanzado, donde el servidor centraliza copias de seguridad, multimedia o entornos de pruebas, un corte de red en mitad de un backup largo o una sesión de streaming puede dar bastante guerra. Con el teaming de NIC, las pequeñas incidencias de hardware se amortiguan y pasan mucho más desapercibidas.
Eso sí, para notar realmente la mejora de rendimiento sostenido es importante que el resto de tu infraestructura acompañe: necesitas un switch gestionable con soporte de LACP u otro método de agregación, un router o firewall capaz de manejar ese caudal y, si usas NAS o cabinas de discos, que también dispongan de puertos múltiples con bonding o teaming compatible.
NIC Teaming en Windows 10 y Windows 11: particularidades y PowerShell
En Windows 10 y Windows 11, activar NIC Teaming no es tan amigable como en Windows Server, donde el Administrador del servidor te guía con un asistente gráfico. En sistemas cliente, el camino habitual pasa por PowerShell con permisos elevados y el uso de cmdlets como Get-NetAdapter y New-NetSwitchTeam.
La secuencia en Windows 10 es muy similar a la del ejemplo del NUC: primero se ejecuta Get-NetAdapter para ver qué interfaces hay disponibles y, después, se lanza un comando del estilo New-NetSwitchTeam -Name «LAN» -TeamMembers «LAN1″,»LAN2» ajustando los nombres a los que muestre tu equipo. Tras la creación puedes comprobar el resultado con Get-NetSwitchTeam y ver el nuevo adaptador lógico en el panel de conexiones.
En Windows 11 la filosofía es parecida, pero hay que tener en cuenta que Microsoft ha ido reduciendo el soporte oficial de LBFO en equipos cliente. Aun así, mucha gente sigue usando New-NetSwitchTeam para montar equipos básicos cuando los drivers lo permiten, y en algunos casos se tiran de scripts o herramientas externas para volver a habilitar funciones que ya no vienen expuestas de serie.
Un ejemplo muy curioso es el de un usuario que montó un NAS y servidor de medios con Windows 11 IoT Enterprise LTSC 2024 y se encontró con que no podía usar LBFO/NIC Teaming como hacía en Windows 10. Tampoco podía pasar a Windows Server porque algunas aplicaciones de su laboratorio no eran compatibles con esa edición. Tras investigar bastante y apoyarse en documentación no oficial, creó una solución de instalación única que restaura las capacidades de LBFO en Windows 11.
Esa solución, publicada en un repositorio de GitHub (hifihedgehog/Windows11LBFO), ha demostrado funcionar en Windows 11 Pro 24H2 y en Windows 11 IoT Enterprise LTSC 2024, tanto sobre hardware físico como en máquinas virtuales. Gracias a ello es posible volver a ver agregación de enlaces LACP entre routers avanzados, switches gestionables y servidores caseros, con múltiples clientes transfiriendo datos a la vez sin ahogar un único enlace.
Si quieres probar algo así, lo recomendable es revisar bien la documentación del repositorio, ver los requisitos y reportar cualquier problema en GitHub para que el autor pueda afinar el proceso. No deja de ser una solución avanzada y no oficial, pero abre la puerta a recuperar el comportamiento de NIC Teaming clásico en Windows 11 para entornos domésticos y de laboratorio exigentes.
Escenarios de red con NIC Teaming y SET en Windows Server
Aunque aquí nos centramos en Windows 11, entender cómo trata Windows Server el NIC Teaming ayuda a tener una visión más completa de hacia dónde van los tiros en redes modernas. En Windows Server 2016 y posteriores se definen muchos escenarios oficialmente admitidos donde intervienen NIC Teaming, SET y SDN.
En el ámbito de las redes definidas por software (SDN), existe la figura de la controladora de red, que permite desplegar y administrar una instancia de varios nodos capaz de gestionar la política de red mediante una API REST Northbound. Desde ahí se pueden crear y controlar redes virtuales basadas en Hyper-V Network Virtualization, utilizando encapsulaciones como NVGRE o VXLAN para construir topologías flexibles.
Dentro de los escenarios de Virtualización de Función de Red (NFV), Windows Server soporta el despliegue de equilibradores de carga de software tanto para tráfico norte-sur (entrada/salida del centro de datos) como este-oeste (entre máquinas virtuales), puertas de enlace de nivel 3, VPN IPsec de sitio a sitio (IKEv2), puertas de enlace GRE y enrutamiento de tránsito mediante BGP con redundancia M+N. En todos estos casos, contar con varias NIC físicas agregadas mediante SET o NIC Teaming contribuye a proporcionar ancho de banda y redundancia suficientes.
En lo que respecta a la plataforma de red, Windows Server permite usar NIC convergentes que combinan tráfico RDMA y Ethernet en un solo adaptador, crear rutas de baja latencia con Packet Direct habilitado en el conmutador virtual de Hyper-V y configurar SET para repartir flujos SMB Direct y RDMA entre dos adaptadores físicos como máximo. Aquí el teaming se integra de lleno con las funciones de virtualización.
Si miramos específicamente al conmutador virtual de Hyper-V, se soportan escenarios como crear un vSwitch con vNIC RDMA, un vSwitch con vNIC que aprovechan SET y RDMA, crear equipos SET dentro del propio conmutador y administrar esos equipos vía PowerShell. En este contexto, la formación de equipos de NIC ya no es un extra opcional, sino una pieza central de muchas arquitecturas de virtualización modernas.
Servicios relacionados: DNS, IPAM y otros componentes de red
El NIC Teaming no funciona aislado, suele convivir con servicios de red como DNS, DHCP o IPAM, especialmente en despliegues con Windows Server. Entender qué escenarios están soportados en estos servicios ayuda a encajar el papel de los equipos de NIC en la foto global.
Por ejemplo, en servidores DNS con Windows Server puedes definir directivas basadas en ubicación geográfica para dirigir el tráfico a distintas direcciones según el origen de la consulta, configurar DNS de cerebro dividido (split-brain) para dar respuestas internas y externas diferentes, aplicar filtros a las consultas, usar políticas para equilibrar la carga de aplicaciones a través de DNS y generar respuestas inteligentes en función de la hora del día.
Además, DNS puede trabajar con políticas de transferencia de zonas, integrarse con Active Directory Domain Services (AD DS) mediante zonas integradas, aplicar limitación de la tasa de respuesta para protegerse de determinados ataques y dar soporte a autenticación basada en DNS de entidades con nombre (DANE). Todo esto se beneficia de que el servidor tenga una red estable, con rutas redundantes y ancho de banda adecuado gracias al teaming.
En el campo de IPAM (IP Address Management), Windows Server te permite detectar y administrar servidores DNS y DHCP, así como rangos de direcciones IP en múltiples bosques de Active Directory federados. Puedes centralizar la gestión de zonas y registros, definir controles de acceso basados en roles muy granulares y delegar a grupos de usuarios concretos la administración de ciertas propiedades. Además, es posible automatizar buena parte de estas tareas con cmdlets de PowerShell específicos para IPAM.
Cuando estos servicios (DNS, DHCP, IPAM) se ejecutan sobre hosts con varias tarjetas agregadas mediante NIC Teaming o SET, ganan resiliencia y rendimiento. Un corte puntual de un enlace no tumba el servicio, y la agregación de ancho de banda ayuda a soportar mejor picos de consultas o renovaciones de direcciones sin estrangular un único puerto de red.
Creación, ampliación y eliminación de equipos NIC
Dentro de los escenarios de formación de equipos NIC admitidos en Windows Server y, con más cautela, en ciertos sistemas cliente, se contempla no solo la creación de equipos, sino también su modificación y eliminación de forma controlada. Esto te permite adaptar la topología de red sin tener que rehacer todo desde cero cada vez que cambian tus necesidades.
Al crear un equipo NIC en una configuración compatible, se seleccionan adaptadores del mismo tipo (por ejemplo dos tarjetas Ethernet de 1 Gbps) y se agregan bajo un nombre de equipo, eligiendo el modo de operación apropiado en función del soporte que ofrezca el switch (LACP, estático, independiente de switch, etc.). Además de New-NetSwitchTeam, tienes cmdlets para ajustar parámetros avanzados, comprobar el estado de los miembros y ver estadísticas de uso.
Si en algún momento necesitas más capacidad, puedes añadir adaptadores físicos adicionales a un equipo existente, siempre que la combinación sea compatible con el modo de teaming configurado. Esto permite, por ejemplo, empezar con dos NIC y más adelante sumar una tercera para ganar más ancho de banda o redundancia, siempre que tu switch y tus puertos disponibles lo permitan.
También es posible hacer lo contrario: retirar miembros del equipo, ya sea porque quieres usarlos para otros fines o porque estás reorganizando la red. El equipo seguirá funcionando con menos miembros, aunque con menos ancho de banda y menor tolerancia a fallos. Si lo dejas reducido a una sola NIC, en la práctica habrás perdido los beneficios del teaming, aunque mantendrás la configuración IP centralizada.
En último lugar, siempre tienes la opción de eliminar por completo un equipo NIC cuando ya no te haga falta. Al borrar el equipo, Windows desmonta el adaptador lógico y devuelve las tarjetas físicas a su estado original, sin la IP asociada al antiguo equipo. Este paso hay que planificarlo bien porque implica un cambio importante en la topología de red del host y puede dejar servicios inaccesibles si no reasignas las direcciones adecuadamente.
Toda esta flexibilidad, tanto en Windows 11 con PowerShell y soluciones específicas, como en Windows Server con SET y SDN, está pensada para que podamos exprimir al máximo el hardware de red disponible, ganando rendimiento, estabilidad y capacidad de recuperación cuando algo tan simple como un cable o un puerto decide fallar en el peor momento.
Gracias a las posibilidades que ofrecen NIC Teaming, LBFO, SET y los servicios de red asociados, hoy es relativamente sencillo construir desde un laboratorio doméstico hasta un entorno profesional donde el tráfico se distribuye de forma eficiente, se soportan fallos de hardware sin dramas y la infraestructura de red se adapta a medida que el proyecto crece y se complica. Comparte esta información y más usuarios conocerán del tema.