Cuando los equipos de infraestructura migran cargas de trabajo desde la nube gestionada a bare metal, suelen traer consigo una suposición oculta: que la red es problema de otro. En AWS o Azure, en gran medida lo era. Las NIC virtuales, los balanceadores de carga gestionados y los tejidos definidos por software abstraían cada cable, cada puerto de switch y cada decisión de failover. En bare metal, esa abstracción no existe por defecto. Volvés al hardware real, a decisiones reales sobre topología y a consecuencias reales cuando algo falla a las 3 de la madrugada.
Esto no es un problema: es una oportunidad para construir una red dimensionada para tu tráfico real, no inflada para el margen del proveedor. Pero requiere vocabulario y un marco de decisión que los valores predeterminados cloud-native nunca te obligaron a desarrollar. Ese marco comienza por entender el espectro de homing.
El espectro de homing: cuatro posiciones canónicas
Toda topología de red bare metal se ubica en algún punto de un espectro definido por dos variables: cuántos proveedores upstream conectás y cuántos enlaces físicos usás por proveedor. Las cuatro posiciones canónicas son:
- Single-homed: un enlace a un proveedor. Simple y económico; un fallo en un cable o transceptor te deja sin conexión.
- Dual-homed: dos o más enlaces a un único proveedor. Ganás redundancia a nivel de enlace, pero seguís dependiendo de un solo upstream. Una interrupción del lado del proveedor sigue cortando la conectividad.
- Single multi-homed: un enlace a cada uno de dos o más proveedores distintos. La diversidad de proveedores es buena, pero un único router en tu lado sigue siendo un punto de fallo.
- Dual multi-homed: dos o más enlaces a dos o más proveedores. Máxima resiliencia, máxima complejidad y el coste más alto. Reservalo para rutas de tráfico donde el tiempo de inactividad tiene un impacto directo en ingresos o seguridad.
La mayoría de los despliegues bare metal se sitúan entre dual-homed y dual multi-homed según sus requisitos de SLA y presupuesto. El objetivo es ajustar la topología al riesgo real, no replicar lo que el proveedor de nube hacía bajo la capa de abstracción.
Bonding de NIC: activo-pasivo vs. LACP
A nivel de servidor, el dual-homing consiste en conectar un servidor a dos puertos de switch upstream independientes. El sistema operativo los ve como dos interfaces físicas y necesitás decidir cómo presentarlas a las aplicaciones. Esa decisión es el modo de bonding.
Active-backup (Modo 1) mantiene una interfaz activa y aparca la otra como reserva en caliente. El SO monitoriza la primaria; si cae, promueve la de respaldo. El failover es limpio y predecible. La contrapartida es que pagás por dos uplinks pero usás solo uno a la vez, lo cual está bien si tu objetivo es redundancia pura y no mayor throughput.
LACP (Modo 4, IEEE 802.1AX) agrupa ambas interfaces en una única interfaz lógica y distribuye los flujos entre ellas. Desde la perspectiva de la aplicación hay un solo camino de red; desde la del switch, hay dos. Esto te da capacidad agregada entre flujos, pero no le da a ninguna conexión TCP individual más ancho de banda que el de un enlace miembro, porque el hardware hace hash por flujo para seleccionar el miembro. Entender esto importa para cargas de trabajo con pocos flujos de alto throughput: el bonding no las beneficiará del mismo modo que a cargas de trabajo con muchas conexiones paralelas.
La agregación de enlaces le da al tejido más capacidad y un camino de supervivencia. No le da a ninguna conversación individual más ancho de banda que el de un enlace miembro. Dimensioná tus uplinks según tu perfil de flujos real, no según el número agregado de la ficha técnica.
Un modo de fallo conocido que vale la pena mencionar: los servidores dual-homed con bonding mal configurado pueden descartar paquetes durante el failover de NIC. LACP depende de keepalives a nivel de protocolo entre la NIC y el switch; si esos temporizadores están mal configurados o el switch no soporta temporizadores LACP rápidos, el bond puede tardar varios segundos en reestabilizarse. Probá el failover bajo carga antes de confiar en él.
MC-LAG: eliminar el punto único de fallo en el switch
El LACP clásico agrupa puertos en un único switch físico, lo que convierte a ese switch en un punto único de fallo y anula gran parte de la redundancia que construiste a nivel de NIC. Multi-Chassis LAG (MC-LAG) resuelve esto permitiendo que dos switches físicos se coordinen y se presenten como un único partner LAG ante el servidor downstream. El servidor agrupa sus dos NIC como si hablara con un solo switch; en realidad, cada NIC se conecta a un dispositivo físico independiente. Un fallo completo del switch ahora elimina un miembro del bond en lugar de dejar al servidor sin conexión.
MC-LAG es el patrón estándar para racks bare metal en producción donde la redundancia a nivel de switch importa. El coste operativo es que los dos switches deben mantener un canal de sincronización, y los modos de fallo de ese canal deben entenderse y probarse. Los escenarios de split-brain, donde ambos switches creen que el otro ha fallado, requieren una política de desempate definida.
BGP multihoming en bare metal: cuándo usarlo
Para la redundancia de red bare metal en la capa de enrutamiento, el BGP multihoming es el mecanismo que te permite conectarte a múltiples proveedores upstream y hacer que el tráfico se desplace automáticamente cuando una ruta se degrada. Esto es distinto del bonding a nivel de enlace: BGP opera en la Capa 3 y puede enrutar alrededor de fallos de proveedor, no solo de fallos de cable.
El enfoque moderno de datacenter va más lejos. En lugar de agrupar uplinks entre un switch leaf y un spine, muchos operadores configuran un enlace de Capa 3 independiente a cada spine con una sesión BGP por enlace. Esto mantiene cada camino individualmente visible para el protocolo de enrutamiento, elimina LACP del uplink por completo y permite que el tejido converja sobre el estado de cada enlace individual en lugar de esperar un umbral de bundle. La regla general: usá ECMP donde los caminos son enrutados e independientes; reservá LAG para los lugares donde una única interfaz lógica simplifica genuinamente el diseño, como el dual-homing de un servidor a un par de switches o un trunk de Capa 2.
Los datacenters carrier-neutral son los que hacen práctico el BGP multihoming sin sobreaprovisionamiento. En un sitio carrier-neutral podés conectarte a múltiples proveedores de tránsito e intercambiar rutas directamente con peers, lo que significa que no comprás redundancia a través de la infraestructura de un único operador. Operamos nuestros sitios exactamente así: Tier III, carrier-neutral, certificados ISO 27001, con un SLA contractual de disponibilidad del 99,9% que refleja la redundancia física integrada en la instalación, no una promesa de marketing superpuesta a un uplink de un solo operador. La soberanía, aquí, es una garantía a nivel contractual: tus rutas de tráfico se rigen por la legislación europea y no transitan infraestructura sujeta a jurisdicción extranjera.
El marco de decisión: ajustar la topología al riesgo
El sobreaprovisionamiento en redes bare metal suele surgir de aplicar una plantilla de redundancia máxima a cada servidor sin considerar su función real. Un marco de decisión basado en el impacto del fallo evita esto:
- Clasificá la carga de trabajo según el coste del fallo. Un failover del primario de una base de datos tiene un perfil de coste diferente al de un nodo de procesamiento por lotes. Ajustá el nivel de topología a ese coste, no a una política uniforme.
- Identificá los modos de fallo reales. El fallo de NIC, de cable, de switch y de proveedor son eventos distintos con probabilidades diferentes. Diseñá para los que son plausibles en tu escala, no para los peores casos teóricos.
- Elegí la topología mínima que cubra los modos de fallo identificados. El bonding active-backup cubre el fallo de NIC y de cable. MC-LAG agrega el fallo de switch. BGP multihoming agrega el fallo de proveedor. Cada capa añade coste y complejidad operativa; incorpórala solo cuando el modo de fallo que cubre esté dentro del alcance.
- Probá la convergencia bajo carga. El failover de LACP, la reconvergencia de BGP y la recuperación de split-brain en MC-LAG tienen características de temporización que solo se hacen visibles bajo tráfico real. Medílas en staging antes de confiar en ellas en producción.
- Documentá la topología de forma explícita. Los equipos cloud-native a menudo no tienen documentación de topología porque el proveedor la abstraía. En bare metal, la topología es tuya. Un diagrama que muestre cada uplink, modo de bonding y sesión BGP es infraestructura operativa, no documentación opcional.
Cómo se ve esto en la práctica
Un rack de producción típico en un sitio carrier-neutral podría verse así: servidores dual-homed con bonds LACP Modo 4 a un par de switches top-of-rack que ejecutan MC-LAG, esos switches con uplinks mediante caminos de Capa 3 independientes hacia una capa spine que ejecuta ECMP, y el spine conectado a dos o más proveedores de tránsito vía BGP. Ese diseño cubre el fallo de NIC, cable, switch y proveedor sin duplicar cada componente. No es el diseño más económico posible, pero tampoco el más caro. Está dimensionado para los modos de fallo reales.
Los equipos que sobreaprovisionan suelen ser los que heredaron un modelo mental cloud-native donde la redundancia era invisible. Una vez que podés ver la topología y nombrar el modo de fallo de cada capa, podés tomar decisiones deliberadas en lugar de defensivas. Ese es el cambio que exige bare metal y la razón por la que recompensa a los ingenieros que se toman el tiempo de aprender el vocabulario.
