Cómo configurar la agregación de enlaces (NIC Teaming) y sumar la velocidad de dos tarjetas de red

Inicio » Linux » Cómo configurar la agregación de enlaces (NIC Teaming) y sumar la velocidad de dos tarjetas de red

Cuando empiezas a exprimir un servidor, un NAS o un host de virtualización, enseguida descubres que una sola interfaz Gigabit se queda corta. La agregación de enlaces o NIC Teaming permite sumar varias tarjetas de red físicas en un único enlace lógico para ganar ancho de banda y además ganar tolerancia a fallos sin montar una infraestructura marciana.

En entornos domésticos avanzados, en pequeñas oficinas o en laboratorios con Proxmox, VMware, Hyper-V o Linux, esta técnica se ha vuelto casi imprescindible. Bien configurada, la agregación de enlaces evita cuellos de botella en copias de seguridad, acceso a NAS, clusters HA y en general en cualquier escenario donde hay muchos clientes tirando de un mismo servidor.

Qué es exactamente la agregación de enlaces (NIC Teaming)

En redes se utilizan muchos nombres para referirse al mismo concepto: Link Aggregation, LACP, NIC Teaming, bonding, port trunking o port channel. Todos apuntan a la misma idea: agrupar varias conexiones Ethernet físicas para que se comporten como una sola conexión lógica, con más ancho de banda y/o con redundancia.

Desde el punto de vista del sistema operativo, se crea un adaptador virtual que es el que recibe la configuración IP. Ese adaptador virtual se apoya en dos o más NIC físicas que trabajan en equipo. Si una se rompe, el tráfico puede seguir fluyendo por las demás. Si todas están sanas, el tráfico se reparte entre ellas según el algoritmo elegido.

Es importante entender que, salvo casos muy concretos, no vas a ver una única sesión TCP copiando a 2 Gbps solo por tener dos puertos de 1 Gbps. Lo que consigues es que varias conexiones simultáneas puedan usar cada una su gigabit y, en conjunto, el servidor pueda entregar 2, 4 u 8 Gbps según los enlaces que tenga agregados.

Otro punto clave es el papel del switch: en los modos de agregación basados en estándares (IEEE 802.3ad / 802.1AX) el switch debe estar configurado para agrupar los puertos. Si usas modos «independientes de conmutador» o modos de respaldo, no siempre hace falta configurar nada en el switch, pero entonces normalmente no se suma capacidad, sólo se consigue alta disponibilidad.

Tipos de NIC Teaming y modos de funcionamiento

Según el sistema operativo, el fabricante de la tarjeta o el propio switch, la terminología cambia, pero en esencia todos los modos de agregación encajan en unos pocos grupos bien definidos.

Muchos drivers de Broadcom, Intel o las propias funciones nativas de Windows y Linux hablan de varios perfiles de equipo de red. Los más habituales que vas a encontrar son:

• Smart Load Balancing (SLB) con conmutación por error: reparte el tráfico entre varios adaptadores principales. Si uno cae, el resto sigue trabajando; si todos fallan, entra en juego un adaptador en espera.
• SLB con failback deshabilitado: funciona igual, pero cuando la NIC que falló vuelve a estar disponible, el tráfico no se devuelve automáticamente; el equipo sigue usando las que ya están en servicio.
• Agregación dinámica de enlaces IEEE 802.3ad (LACP): agrupa múltiples enlaces físicos en un solo enlace lógico cuyo ancho de banda es la suma de los enlaces. Requiere que el switch del otro extremo soporte LACP y esté configurado correctamente.
• Enlace troncal genérico o agregación estática: muy similar a 802.3ad en cuanto a funcionalidad, pero sin negociación LACP. El switch debe configurarse manualmente en modo estático y no hace intercambio de PDU de LACP.

En el mundo Linux se habla de bonding y se definen varios modos clásicos, cada uno con sus particularidades:

• mode 0 (balance-rr): balanceo round-robin, distribuye paquetes de forma secuencial por todas las NIC; maximiza el throughput pero exige configuración de port-channel en el switch.
• mode 1 (active-backup): una interfaz activa y las demás en espera. Proporciona alta disponibilidad sin necesidad de configuración especial en el switch.
• mode 2 (balance-xor): selecciona la NIC en función de un hash (p.e. MAC origen/destino). Necesita EtherChannel en switches Cisco y equivalentes en otros fabricantes.
• mode 4 (802.3ad): implementación estándar de LACP en Linux; combina ancho de banda y redundancia, siempre que el switch tenga LACP habilitado en esos puertos.
• mode 5 (balance-tlb) y mode 6 (balance-alb): modos de balanceo de carga adaptativo que no exigen cambios en el switch.

En equipos NAS (Synology, QNAP, etc.) verás descripciones más amigables: Adaptive Load Balancing, IEEE 802.3ad dinámico, Balance XOR, Activo/En reposo, todos basados en estos mismos fundamentos. Cada modo prioriza más el rendimiento, la simplicidad de configuración o la tolerancia a fallos.

Requisitos básicos para que la agregación de enlaces funcione

Antes de empezar a crear equipos de NIC a lo loco, conviene revisar que se cumplen una serie de requisitos muy concretos en los enlaces que vas a agregar.

Para que Link Aggregation funcione de forma estable, la norma general es que todas las interfaces del grupo compartan características idénticas:

• Todos los enlaces deben funcionar en full-duplex.
• La velocidad de sincronización ha de ser exactamente la misma en todos los puertos (todos a 1 Gbps, o todos a 10 Gbps, etc.).
• Si usas VLANs, la configuración de etiquetado en el switch debe ser idéntica en todos los puertos del grupo (mismo modo access/trunk y mismas VLAN permitidas).
• No se da soporte a conexiones directas por cable cruzado entre máquinas para modos como LACP: tiene que haber un switch que gestione la agregación.

Si no cumples alguno de estos puntos, lo habitual es que el equipo se forme mal, que el switch no llegue a negociar el port-channel o que sufras cortes de conexión intermitentes muy difíciles de diagnosticar.

Una ventaja importante de la agregación es que, cuando uno de los enlaces físicos se cae, el enlace lógico sigue funcionando con el resto de puertos activos. Pierdes capacidad efectiva, pero mantienes la conectividad, lo que es crítico para servidores de ficheros, clusters, cabinas iSCSI, etc.

Algoritmos de balanceo de carga en Link Aggregation

Además del modo de agregación, los switches gestionables permiten elegir cómo se reparte el tráfico entre los enlaces físicos del grupo. Esto marca la diferencia entre un equipo bien afinado y otro que, en la práctica, no reparte casi nada.

La mayoría de switches medianamente decentes soportan varios algoritmos de hash. Los más frecuentes basan sus decisiones en las direcciones IP, MAC o en los puertos TCP/UDP de origen y destino:

• src-ip: elige el enlace según la IP de origen.
• dst-ip: se basa en la IP de destino.
• src-dst-ip: combina origen y destino IP para mayor granularidad.
• src-mac / dst-mac / src-dst-mac: lo mismo pero utilizando direcciones MAC.
• src-dst-ip-port: tiene en cuenta IPs y puertos TCP/UDP; es el algoritmo que mejor reparte el tráfico entre múltiples flujos.

Cuanto más granular es el algoritmo, mejor se reparten las conexiones entre los enlaces físicos, especialmente cuando tienes muchos clientes y servicios distintos golpeando a la vez a un NAS o servidor. Si sólo eliges por MAC, por ejemplo, es fácil que todo el tráfico hacia un cliente concreto caiga siempre por la misma interfaz.

En muchos switches puedes crear hasta 32 grupos de port trunk, con hasta 8 puertos por grupo, siempre que compartan velocidad y configuración. Este límite varía según el modelo, pero da una idea de hasta dónde se puede escalar una infraestructura basada en Link Aggregation.

NIC Teaming en Windows Server (2012, 2012 R2, 2016, 2019…)

Desde Windows Server 2012, Microsoft incluyó soporte nativo de NIC Teaming sin necesidad de drivers propietarios de Intel o Broadcom. Esto simplifica mucho la vida, porque todo se gestiona desde el propio sistema, tanto vía GUI como con PowerShell.

En la consola de Administrador del servidor, dentro de «Servidor local», verás un apartado llamado Agrupación de NIC. Cuando está deshabilitado, aparece como un enlace. Al pinchar, se abre el cuadro de diálogo de creación y gestión de equipos de NIC donde puedes:

• Seleccionar los adaptadores físicos que formarán parte del equipo.
• Crear un nuevo equipo asignándole un nombre descriptivo.
• Elegir el modo de teaming (independiente de conmutador, estático, LACP), el modo de balanceo de carga y, si quieres, definir un adaptador en espera.
• Configurar la membresía de VLAN para el equipo, ya sea VLAN por defecto o una VLAN específica.

En cuanto a modos, Windows ofrece opciones parecidas a las vistas antes: formación de equipos estática compatible con IEEE 802.3, modo independiente de conmutador y modo LACP. La combinación del modo de teaming y del algoritmo de hash (dirección, puerto Hyper-V, dinámico, etc.) determina si priorizas redundancia, suma de capacidad o una mezcla de ambos.

El modo dinámico, disponible en versiones recientes, suele ofrecer el mejor rendimiento global de balanceo de carga, porque aplica un hash basado en múltiples parámetros (IP, puertos, etc.) y además adapta el reparto de flujos de forma inteligente.

Configuración de NIC Teaming en Windows con PowerShell

Además de la interfaz gráfica, en Windows Server 2012 y superior es muy habitual usar PowerShell para crear y administrar equipos de NIC de forma automatizada, tanto en hosts físicos como en entornos con Hyper-V.

El flujo típico para crear un equipo básico de dos NIC podría ser así: abrir PowerShell como administrador y utilizar el cmdlet New-NetLBFOTeam para definir el equipo.

Por ejemplo, si tus interfaces se llaman «NIC1» y «NIC2» y quieres que el equipo se llame «NIC-Team», podrías lanzar:

New-NetLBFOTeam "NIC-Team" "NIC1","NIC2"

Este comando genera el adaptador de equipo que aparecerá luego en «Conexiones de red» como si fuera una nueva tarjeta. A partir de ahí, asignas IP, gateway y demás parámetros de red exactamente igual que harías con una NIC normal, e incluso puedes seguir ajustando propiedades del equipo con otros cmdlets de la familia NetLbfo.

En escenarios con Hyper-V, además, se aprovechan parámetros específicos como Port Hyper-V como algoritmo de equilibrio. Cada puerto virtual (cada vNIC de las máquinas virtuales) se mapea al equipo físico de forma que el hypervisor pueda repartir tráfico de muchas VMs sobre pocas NIC físicas con bastante eficiencia.

NIC Teaming en Windows 10

En el escritorio también se puede jugar con esto. Aunque Windows 10 no trae el panel gráfico de NIC Teaming de Windows Server, sí hereda parte de la funcionalidad vía PowerShell en forma de equipos de tipo «switch».

El procedimiento es muy simple: primero se listan los adaptadores disponibles con Get-NetAdapter para saber cómo se llaman. Después se usa el cmdlet New-NetSwitchTeam indicando el nombre del equipo lógico y las interfaces que quieres agrupar, por ejemplo:

New-NetSwitchTeam -Name "LAN" -TeamMembers "LAN1","LAN2"

Al finalizar, si ejecutas Get-NetSwitchTeam verás el estado del equipo, y en el panel de conexiones de red aparecerá un nuevo adaptador virtual asociado al equipo LAN. Sobre ese adaptador es donde configurarás TCP/IP; las interfaces físicas pasan a estar controladas por el equipo y no se tocan directamente.

Este enfoque es útil en estaciones de trabajo potentes que actúan como pequeños servidores, o para entornos de pruebas donde quieres simular un host con mayor ancho de banda agregado sin meterte todavía en servidores Windows completos.

Formación de equipos de NIC en Hyper-V y escenarios de laboratorio

Cuando montas clusters de Hyper-V con alta disponibilidad, simulando o reemplazando soluciones tipo vSphere, la red cobra un papel crítico. Separar tráfico de administración, almacenamiento iSCSI y tráfico de VM suele ser la recomendación estándar.

En un escenario típico con dos servidores Windows Server Datacenter, podrías tener NIC de 1 Gbps dedicadas a gestión y NIC de 10 Gbps para almacenamiento iSCSI y tráfico de VMs. Sobre estas últimas, crearías equipos (SET o NIC Teaming) para garantizar que si un puerto cae, el almacenamiento o las conexiones de las máquinas virtuales no se cortan.

El problema clásico llega cuando se mezclan VLANs de gestión, cluster y almacenamiento sobre el mismo equipo y no se coordinan bien los switches físicos, los vSwitch de Hyper-V y las VLAN etiquetadas. Si el equipo se usa como base para un Switch Embedded Teaming (SET) y no se ajustan bien los puertos de switch y las redes virtuales, el resultado es que el cluster no ve la red de gestión o que las VMs no tienen acceso a la red.

En estos casos, conviene respetar las guías de Microsoft para Hyper-V: crear equipos físicos estables, montar encima los vSwitch, y luego segmentar con VLANs y redes virtuales cada tipo de tráfico. No mezclar alegremente enlaces dedicados de gestión con port-channels mal definidos suele ahorrarte muchos dolores de cabeza.

Agregación de enlaces en VMware vSphere

En el mundo VMware el concepto es el mismo, aunque las piezas cambian de nombre. En ESXi puedes definir políticas de NIC Teaming y failover tanto en vSwitch estándar como en vSphere Distributed Switch, y asociarlas a port groups concretos.

Un equipo de NIC en vSphere permite repartir carga entre varias tarjetas físicas que cuelgan de un mismo vSwitch, sirviendo tanto tráfico de máquinas virtuales como de VMkernel (vMotion, iSCSI, NFS, etc.), y ofreciendo conmutación por error pasiva ante la caída de una interfaz.

VMware documenta en detalle las combinaciones posibles: modos de ordenación (Route based on originating virtual port, Route based on IP hash, etc.), definición de adaptadores activos, en espera y en modo unused, y las necesidades de configuración en el switch físico cuando optas por algoritmos basados en IP hash que exigen EtherChannel o LACP.

Los artículos de la base de conocimiento de VMware (como la KB 1004088) explican paso a paso cómo configurar NIC Teaming, qué políticas conviene usar en función de si el switch físico está o no configurado con port-channel, y cómo diagnosticar problemas cuando una mitad de la agregación está mal montada.

La idea clave es coordinar bien vSwitch, políticas de teaming y configuración de puertos de switch físico. Una mala combinación (IP hash en VMware con puertos independientes en el switch, por ejemplo) puede traducirse en bucles, MAC flapping y pérdida intermitente de conectividad.

Bonding y agregación de enlaces en Linux (canal bonding)

En Linux, la agregación de enlaces se implementa mediante el módulo de kernel bonding y se expone al sistema como interfaces especiales bondN (bond0, bond1, etc.). Estas interfaces actúan como tarjetas de red lógicas que integran varias NIC físicas.

En distribuciones como Red Hat Enterprise Linux 6, el módulo bonding no se carga por defecto. Puedes activarlo por primera vez con:

modprobe --first-time bonding

Si no devuelve errores, el módulo queda cargado en memoria, aunque esa carga inicial no es persistente tras un reinicio, a menos que exista una configuración de red que necesite bonding; en ese caso, los scripts de red se encargan de cargarlo automáticamente según las directivas declaradas.

La información sobre el módulo se puede consultar con:

modinfo bonding

La configuración clásica en RHEL y derivados se hace a través de los archivos /etc/sysconfig/network-scripts/ifcfg-*. Para crear una interfaz bond0, se genera un fichero ifcfg-bond0 con parámetros similares a los de una interfaz Ethernet, pero sustituyendo DEVICE por bond0 e incorporando la directiva clave BONDING_OPTS con los parámetros específicos del modo elegido.

Un ejemplo básico de ifcfg-bond0 podría ser:

DEVICE=bond0
IPADDR=192.168.1.1
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
NM_CONTROLLED=no
BONDING_OPTS="bonding parameters separated by spaces"

Las interfaces físicas que se adhieren al bond se describen en sus propios ficheros ifcfg-ethX, añadiendo MASTER=bond0 y SLAVE=yes. Un esquema típico sería:

DEVICE=ethX
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
NM_CONTROLLED=no

Una vez listos estos archivos, basta con reiniciar el servicio de red (por ejemplo con service network restart) para que se active la vinculación. El estado de cada bond se puede comprobar leyendo /proc/net/bonding/bondN, donde se muestra el modo activo, el estado de cada esclavo, el intervalo de monitorización MII y otros detalles.

En RHEL 6 es importante no mezclar configuraciones: los parámetros específicos de cada bond se deben pasar en BONDING_OPTS dentro de los ifcfg-bondN, y no en /etc/modprobe.d/bonding.conf, que se reserva para parámetros globales como max_bonds. Cambiar este archivo sólo surte efecto al recargar el módulo, lo que implica descargarlo primero si ya está en uso.

Bonding avanzado y creación de múltiples enlaces en Linux

Si necesitas más de un enlace de bonding, el proceso se extiende de forma bastante directa. Se crean varios ifcfg-bondN (bond0, bond1, etc.), cada uno con su propia IP, máscara y conjunto de BONDING_OPTS ajustados a su función.

Por ejemplo, podrías definir bond0 para tráfico de producción con IP en la red 192.168.2.0/24 y modo 802.3ad, y bond1 para tráfico de backup o cluster en 192.168.10.0/24 en modo active-backup. Cada conjunto de interfaces físicas se asigna al bond correspondiente editando sus ifcfg-ethX con MASTER=bond0 o MASTER=bond1 según toque.

La ventaja de este enfoque es que cada bond puede tener su propia política de agregación adaptada al tipo de tráfico, y la separación lógica (y a menudo física) de redes reduce el riesgo de saturar un único enlace o de mezclar tráfico sensible con tráfico masivo de copias.

Al igual que en otros sistemas, los modos que suman capacidad (balance-rr, 802.3ad, balance-xor) suelen requerir configuración explícita en el switch: EtherChannel en Cisco para modes 0, 2 y 3, y LACP para el modo 4, por ejemplo. Por el contrario, modos como active-backup, balance-tlb o balance-alb pueden funcionar con switches corrientes sin tocar nada en el extremo de red.

Link Aggregation en Proxmox: ejemplo práctico con bond0

En Proxmox, que se ejecuta sobre Debian, la red se configura también via /etc/network/interfaces, así que para crear un bond0 que sume dos interfaces físicas el procedimiento resulta bastante transparente para quien ya haya trabajado con networking en Linux.

Imagina un nodo con dos tarjetas enp1s0 y enp2s0. De entrada están asociadas a dos bridges distintos (vmbr0 y vmbr1) con sus IPs. La idea es unificarlas creando bond0, sumar velocidades y luego colgar de ese bond0 el bridge principal que usará el cluster o la LAN.

Primero se identifican los nombres de las tarjetas con ip a o desde la GUI de Proxmox en HOST → Sistema → Red. Una vez localizadas, se edita el archivo de interfaces, se hace una copia de seguridad por si acaso, y se define algo similar a:

auto enp1s0
iface enp1s0 inet manual

auto enp2s0
iface enp2s0 inet manual

auto bond0
iface bond0 inet static
bond-slaves enp1s0 enp2s0
bond-miimon 100
bond-mode balance-rr

auto vmbr0
iface vmbr0 inet static
address 192.168.2.169/24
gateway 192.168.2.69
bridge-ports bond0
bridge-stp off
bridge-fd 0

Tras guardar cambios, se reinicia el servicio de red con systemctl restart networking. En ese momento, es bastante probable que pierdas conectividad hasta que configures correctamente el switch, porque los puertos donde están enp1s0 y enp2s0 deberían agruparse en un trunk / port-channel.

En el switch HP Aruba, Cisco o el que uses, se crea el grupo de enlaces con los dos puertos físicos del host y se aplican las VLANs y el modo de agregación que vayas a usar. Cuando todo está coordinado, el host vuelve a ser accesible por su IP en vmbr0, pero ahora sobre bond0, con la suma de capacidad de los dos puertos.

Para comprobar la velocidad efectiva de bond0 en Proxmox, se puede usar ethtool bond0 y ver la negociación de cada esclavo. Desconectando uno de los cables de red puedes verificar la conmutación por error y que el enlace sigue respondiendo, aunque con mitad de capacidad.

Por qué Link Aggregation multiplica el rendimiento real de tu red

En muchas oficinas y hogares avanzados el cuello de botella está en que el NAS, servidor o PC sólo dispone de un puerto Gigabit. Aunque el switch sea rápido y el resto de ordenadores también sean Gigabit, todos compiten por los mismos 1 Gbps de subida y bajada desde el equipo central.

Escenarios típicos donde se nota este límite son: copias de seguridad masivas desde varios PCs al NAS, edición de vídeo directamente sobre almacenamiento en red, y acceso simultáneo de múltiples usuarios a contenidos multimedia o directorios compartidos.

Con Link Aggregation, un NAS con dos puertos Gigabit puede ofrecer hasta 2 Gbps de ancho de banda agregado, siempre y cuando esté conectado a un switch gestionable que soporte LACP o port trunking. Lo mismo aplica a un servidor de ficheros o a un host de virtualización con múltiples NIC.

En entornos con 10 Gbps también tiene sentido: agrupar varios enlaces de 10 Gbps da enlaces lógicos de 20, 30 o más gigabits, algo habitual en data centers y nubes privadas para interconectar switches troncales, clusters de bases de datos o cabinas de almacenamiento.

Por supuesto, no todo el mundo necesita esto. Para un usuario medio, una conexión de fibra de 500 Mbps o 1 Gbps es más que suficiente, y el coste de montar infraestructura con Link Aggregation (switch gestionable, tarjetas de red adicionales, NAS avanzado, etc.) no compensa. Esta tecnología empieza a tener sentido cuando se manejan grandes volúmenes de datos para varios usuarios a la vez o cuando buscas máxima disponibilidad en servicios críticos.

Equipos y sistemas que puedes usar con Link Aggregation

Para poder jugar a sumar enlaces no basta con que el sistema operativo lo soporte. Necesitas que el hardware de red también hable el mismo idioma. No todos los routers ni todos los switches soportan LACP o port trunking.

En el lado de red, la referencia suelen ser switches gestionables de gama media o alta y conviene revisar la compatibilidad de los componentes del PC. Muchos modelos domésticos avanzados y profesionales soportan Link Aggregation y permiten crear varios grupos de puertos agregados. En el ámbito de routers, algunos equipos de ASUS o NETGEAR incorporan dos puertos Gigabit LAN específicamente pensados para formar un LAG hacia un NAS o un switch.

En el extremo de los servidores, lo ideal es emplear tarjetas de red con soporte oficial de teaming/bonding. Las Intel y Broadcom de servidor suelen ofrecer perfiles específicos y herramientas propias, aunque hoy en día en Windows y Linux casi siempre es mejor aprovechar las capacidades de teaming nativas del sistema operativo.

Los NAS de fabricantes como Synology y QNAP de gama media-alta integran desde hace años dos o más puertos Gigabit con soporte de Link Aggregation. Su panel de control permite elegir modos como Adaptive Load Balancing, IEEE 802.3ad dinámico, Balance XOR o Activo/En reposo, e incluso, en entornos con Open vSwitch, equilibrar tráfico entre diferentes máquinas virtuales alojadas en el propio NAS.

En placas base gaming o workstation es cada vez más frecuente ver dos NIC de 1 Gbps integradas, y algunos modelos anuncian explícitamente compatibilidad con Link Aggregation cuando se combinan con un switch adecuado. Aun así, si tienes necesidades muy concretas, suele ser mejor instalar una tarjeta de red dedicada de mayor calidad, o directamente dar el salto a 2.5G, 5G o 10G.

Ventajas y limitaciones reales de la agregación de enlaces

Más allá de la cifra de gigabits, Link Aggregation aporta una serie de beneficios prácticos que conviene tener claros para decidir si merece la pena en tu caso concreto. No todo es velocidad bruta.

Entre las ventajas más claras encontramos:

• Mayor capacidad efectiva: varios enlaces físicos combinados ofrecen un ancho de banda agregado superior, útil para atender muchas conexiones simultáneas.
• Resistencia a fallos: si una interfaz muere o un cable se rompe, el tráfico se redirige por los enlaces restantes, reduciendo el impacto del fallo.
• Balanceo de carga: los algoritmos de hash reparten flujos entre NICs, evitando que una sola línea se sature mientras otras están ociosas.
• Gestión simplificada: a nivel de configuración IP y de firewall, se trata un único enlace lógico en lugar de varios enlaces independientes.
• Mejor aprovechamiento de recursos: se evitan situaciones donde una interfaz está reventada y otra infrautilizada al servir el mismo servicio.

En cuanto a limitaciones, lo principal es recordar que no siempre vas a doblar la velocidad de una sesión concreta, que necesitas hardware compatible (switch, NICs) y que la configuración incorrecta puede causar problemas de conectividad muy serios (bucles, flapping de MAC, pérdidas intermitentes).

Si lo que buscas es una única conexión punto a punto extremadamente rápida (por ejemplo, mover un fichero gigante entre dos equipos concretos), en muchos casos es más sencillo y eficiente montar directamente una red a 10 Gbps (tarjetas, switch y cableado adecuados) que intentar exprimir al máximo la agregación de varios enlaces Gigabit.

Con todo lo explicado, se entiende mejor cuándo compensa montar NIC Teaming o bonding: cuando varios usuarios o servicios simultáneos golpean al mismo equipo central y quieres que ninguno se quede sin ancho de banda ni sin servicio por una simple avería de cable o puerto. En ese escenario, la agregación de enlaces se convierte en una aliada muy potente para sacar todo el jugo tanto al hardware de red como al sistema operativo sin necesidad de reinventar la infraestructura desde cero.