Tres servidores conectados entre sí, cada uno con dos tarjetas, y ni un solo switch de 25 GbE en la factura. Es de las decisiones con mejor relación entre lo que cuesta y lo que da de todo lo que se puede montar hoy. La wiki de Proxmox la documenta desde hace años y ofrece cuatro formas de cablearla. En el apartado de escenarios de fallo está el detalle que decide cuál eliges: con dos de las cuatro, el día que se rompe un cable los nodos se quedan viendo cosas distintas.
La frase exacta de la wiki es esta: «the nodes now have a different view, Node 2 can communicate with Node 3, while that is not possible for Node 1 anymore. You will see behavior such as Ceph showing the services on Node 3 to be down». Lo que cuenta está en la segunda mitad. En el nodo 3 no se ha roto nada. Sus discos están girando, sus OSD están arriba y sus datos están completos. Simplemente, el único sitio desde el que lo estás mirando es el que ya no lo ve.
Esa es la diferencia entre un fallo y una avería, y aquí se compra en el momento de elegir el cableado, meses antes de que nadie tropiece con el cable.
Todo el mundo ensaya que cae un nodo
El ensayo que sí se hace es apagar un servidor. Y sale bien: la propia wiki lo dice sin dramatismo —si cae el nodo 3, «the Ceph and Proxmox VE cluster will remain functioning, though with reduced redundancy»—. Es el escenario cómodo, porque la pérdida es total y simétrica: el nodo no está, y todos los que quedan están de acuerdo en que no está.
El escenario incómodo es otro: el cable suelto, el SFP que se calienta, el puerto que negocia a 1 Gb en vez de a 25 o el técnico que aprovecha una visita para «ordenar un poco». Ahí la pérdida es parcial y asimétrica, y eso es mucho peor que una pérdida total, porque cada nodo construye una respuesta coherente a partir de información incompleta y las tres respuestas no coinciden. En la pantalla no aparece «ha fallado un cable»: aparece un servicio caído en un sitio donde no hay nada caído.
Las cuatro formas de cablear tres nodos
El montaje es siempre el mismo triángulo: cada servidor con al menos dos tarjetas, cada una enchufada directamente a uno de los otros dos. Lo que cambia es qué se pone encima de esos cables. La wiki describe cuatro posibilidades, y lo que de verdad decide entre ellas no es el rendimiento: es qué pasa cuando cae un enlace, no un nodo.
- Enrutado simple. Cada paquete va solo al nodo destinatario. No necesita software adicional y da el mejor rendimiento de los cuatro. Si cae un enlace, no hay camino alternativo: visión partida.
- Enrutado con fallback. Lo mismo, pero con un protocolo de enrutado por encima: si el enlace directo cae, el tráfico sale por el nodo del medio. Rendimiento «similar» al simple; con un enlace menos, «a bit higher latency» y «the cluster will stay fully functional». Aguanta.
- RSTP. Un bucle con árbol de expansión rápido. Exige Open vSwitch, porque el puente de Linux solo lleva STP «without the rapid», y la diferencia no es cosmética: en las pruebas del propio Proxmox, RSTP se recupera «within a few seconds» y STP tarda unos 30 segundos, que es «long enough for Ceph to start to complain and throw some warnings». Aguanta, con un peaje permanente: mientras el bucle está completo, RSTP mantiene un corte artificial entre dos nodos, así que el tráfico entre esos dos pasa siempre por el tercero.
- Broadcast. Cada paquete se envía a los otros dos nodos. Es el de montaje más fácil y el que más ancho de banda gasta. Si cae un enlace: visión partida, igual que el enrutado simple.
Nuestra preferencia, dicha con todas las letras y sin pretender que sea la única defendible: enrutado con fallback. No porque sea el más elegante, sino porque es el único de los cuatro cuyo modo de fallo es «va más lento». Un sistema que se degrada en velocidad se puede explicar a las tres de la madrugada; uno que se degrada en coherencia genera media hora de diagnóstico antes de que alguien se acuerde de mirar un cable. RSTP llega a un sitio parecido, pero obliga a meter Open vSwitch en la ecuación, y cada pieza que añades al camino de los datos es otra que mantener.
Y una línea de la wiki que conviene leer antes de enamorarse del ahorro: «We recommend to use switches for clusters larger than 3 nodes or if a 3 node cluster should be expanded in the future». La malla es una respuesta a tres nodos. Si el plan a dos años es llegar a cinco, el switch entra en el presupuesto de este año, no en el del que viene.
Lo que ha cambiado: ahora enruta el hipervisor
Hasta hace poco, montar el enrutado con fallback significaba instalar FRR a mano, poner fabricd=yes en /etc/frr/daemons, escribir un frr.conf por nodo e inventarse un NET de IS-IS único para cada uno. Funciona perfectamente y mucha gente lo tiene así. Pero vive fuera del clúster: no está en la interfaz, no está en el control de acceso y no se replica.
Proxmox VE 9.0, el 5 de agosto de 2025, metió eso dentro con el nombre de fabrics: redes enrutadas entre los nodos, configurables desde Datacenter → SDN → Fabrics, con OpenFabric y OSPF. La 9.1 (19 de noviembre de 2025) las puso en el árbol de recursos informando de rutas, vecinos e interfaces. Y la 9.2, el 21 de mayo de 2026, añadió dos protocolos más y el control fino que faltaba:
- BGP como fabric, en modo eBGP unnumbered: cada nodo con su propio número de sistema autónomo, emparejándose con sus vecinos sobre las interfaces físicas «without requiring IP addresses on the fabric links».
- WireGuard como fabric, para túneles cifrados entre nodos o con terceros. Con un matiz que la documentación no esconde: «It does not provide dynamic routing by itself» —es transporte, y el enrutado dinámico lo pone OSPF o BGP por encima—.
- Listas de prefijos y route maps como objetos de primera clase del SDN, con su API, más redistribución de rutas en los fabrics OSPF y la posibilidad de simular un cambio antes de aplicarlo.
Cuatro protocolos de fabric dentro del panel del hipervisor en nueve meses y medio: tres que enrutan y uno que solo transporta. Para el caso que nos ocupa, la propia wiki recomienda el más sencillo: «Proxmox VE currently supports OSPF and OpenFabric. For simple setups, such as this one, we recommend OpenFabric, as it's easier to set up than OSPF». Esa página se editó por última vez el 27 de marzo de 2026, dos meses antes de que llegaran BGP y WireGuard; es un buen recordatorio de que, cuando dos páginas oficiales no dicen lo mismo, manda la que lleva fecha posterior.
El procedimiento cabe en un párrafo: creas el fabric, le das un nombre —ocho caracteres como máximo en OpenFabric, detalle que se descubre tarde— y un prefijo IPv4; añades cada nodo con su router-ID dentro de ese prefijo y marcas las dos interfaces de la malla. Si esas interfaces no llevan IP, trabajan en modo unnumbered y heredan la del nodo. Luego Apply Configuration, que genera y aplica la configuración de FRR en cada máquina, y a comprobar:
vtysh
show openfabric neighbor
show openfabric routeY luego, al instalar Ceph, el fabric aparece en el desplegable de redes disponibles del paso de configuración inicial. Hay un mando que conviene tocar con conocimiento: los intervalos Hello y CSNP, que el ejemplo de la wiki baja a 1 y 2. El texto declara el precio sin maquillarlo —«Lower numbers mean that the network will fail over faster in the case of link failures, but nodes will generate more traffic»—, y conviene decidirlo con esa frase delante.
La etiqueta que viene puesta de fábrica
Esto está en la primera página del capítulo de SDN de la documentación oficial, en el apartado «Current Status». Son tres líneas y dicen tres cosas distintas:
Core SDN, which includes VNet management and its integration
with the Proxmox VE stack, is fully supported.
IPAM, including DHCP management for virtual guests, is in tech preview.
Complex routing via FRRouting and controller integration are in tech preview.La tercera línea es la que nos ocupa, con una precisión que hay que hacer antes de seguir: Proxmox no escribe ahí la palabra «fabrics», escribe «complex routing via FRRouting», que es exactamente lo que un fabric es por debajo. La equivalencia la ponemos nosotros. Lo que no es nuestro es la segunda mención: la hoja de ruta publicada del proyecto fija como objetivo «Bring the remaining tech-preview parts of the SDN stack to full production readiness».
Nuestra lectura, que no es la única posible: eso no es un motivo para no usarlo. FRR es FRR, lleva años moviendo redes de verdad, y lo que está en vista previa es la capa de integración de Proxmox por encima. Pero sí es un motivo para decidir con los ojos abiertos qué cuelgas de ahí, y sobre todo para no enterarte de la etiqueta el día que algo se comporta raro. Hay una diferencia enorme entre «asumimos este riesgo porque nos compensa» y «no sabíamos que había un riesgo». La primera frase se dice en una reunión; la segunda, en un postmortem.
¿Y corosync, por ahí también?
Es la tentación evidente: ya tienes 25 GbE entre los tres nodos, ¿por qué no meter también el tráfico del clúster? La documentación de Proxmox contesta a esto sin ambigüedad:
ideally corosync runs on its own physically separated network.
Especially do not use a shared network for corosync and storage
(except as a potential low-priority fallback in a redundant configuration).La malla es la red de almacenamiento. Y las cifras que acompañan a esa recomendación son concretas: el stack de clúster «requires a reliable network with latencies under 5 milliseconds», y por encima de unos 10 ms con más de tres nodos la estabilidad «gets rather unlikely». Corosync no necesita ancho de banda, necesita que nadie le meta jitter; un recovery de Ceph a 25 Gb haciendo backfill es exactamente la clase de vecino que sí se lo mete. Ya contamos en su día > por qué ese reloj no es un número fijo, sino que crece con cada nodo que añades.
Traducido a compra: las dos tarjetas rápidas de la malla no son todas las tarjetas que necesitas. Hace falta además, como mínimo, una NIC dedicada para el enlace principal de corosync —que puede ser de 1 Gb de sobra— y la boca de gestión. Quien dimensiona el servidor contando solo los puertos de 25 Gb acaba compartiendo lo que la documentación pide expresamente no compartir. Y del comportamiento de un Ceph de tres nodos cuando pierde una pieza ya hablamos aparte en >.
Los cuatro ficheros que cambian de dueño
Esta es la parte que no sale en ninguna captura de pantalla y que, en empresas donde «redes» y «sistemas» son personas distintas —o proveedores distintos—, decide si el fabric es una mejora o una discusión. Activarlo mueve cuatro ficheros de un lado de la mesa al otro:
/etc/pve/sdn/— la fuente de verdad, y es del clúster. Listas de prefijos, route maps y fabrics viven aquí, replicados. Se editan desde la interfaz o la API, pasan por un estado pending y no hacen nada hasta que alguien pulsa aplicar./etc/network/interfaces— lo escribe el SDN. Por eso añadir o actualizar un nodo dentro de un fabric exige además permisoSys.Modifysobre ese nodo: la documentación lo justifica diciendo que la operación «involves writing to the node's /etc/network/interfaces file». Con una arista: si quitas una interfaz cuya entrada teníamanual, la IP «will not get removed on applying the SDN configuration»./etc/frr/frr.conf— generado. La configuración del clúster se traduce a estrofas de FRR y acaba aquí, en cada nodo. Si venías del montaje manual, la propia wiki avisa de la colisión: «This will not work in combination with the EVPN functionality from the Proxmox VE SDN as it will overwrite our FRR configuration»./etc/frr/frr.conf.local— la costura. Es donde caben tus añadidos propios por nodo, que se anexan encima de lo generado. Es el único punto del conjunto donde conviven a la vez lo que escribe Proxmox y lo que escribes tú, y por tanto el primero que hay que mirar cuando algo no cuadra.
Hay además dos cosas que el fabric crea sin preguntar y que conviene reconocer cuando aparezcan en un ip route. Una interfaz dummy con el router-ID como dirección, que hace de loopback y nace pasiva. Y, por cada fabric, una lista de acceso y un route map generados automáticamente para reescribir la dirección de origen de los paquetes salientes: gracias a eso un ping entre nodos sale desde la loopback y no desde la interfaz física. Varios nombres están reservados y no los puedes usar para los tuyos —only_default, loopbacks_ips, correct_src y cualquiera que empiece por pve_—.
La pregunta que abre este mapa es organizativa: ¿quién firma un cambio en esos cuatro ficheros? Porque desde el momento en que existe el fabric, una parte de la tabla de rutas se toca desde el panel de virtualización, con los permisos de virtualización y por la gente que administra virtualización. Si eso no se dice en voz alta antes, el primero que se entera es quien esté de guardia.
Tres avisos escondidos en la letra pequeña
Los tres están escritos en la documentación oficial, los tres son fáciles de saltarse y los tres cuestan una tarde.
- IPv6 solo va en OpenFabric, y exige reenvío IPv6 global. No hay forma cómoda de activarlo por interfaz como en IPv4, así que la receta de la documentación es un
post-up sysctl -w net.ipv6.conf.all.forwarding=1. El propio texto advierte de que eso afecta a cómo las interfaces manejan SLAAC, los anuncios de vecino y los de router. Un ajuste de un fabric que cambia el comportamiento IPv6 de toda la máquina. - Las listas de prefijos y los route maps deniegan por defecto al final. Es la semántica estándar de FRR, pero sorprende al que viene de otra herramienta. La documentación llega a enseñar el patrón: una entrada final de
permitsin condición, porque «without it the implicit deny at the end of the route map would drop all unmatched routes». - Si los nodos están virtualizados —laboratorio, prueba de concepto, formación—, las interfaces del fabric de cada nodo tienen que estar en puentes separados o en VLAN distintas. Si no, dice la wiki, «routing loops may occur». Es decir: el laboratorio donde ibas a ensayar esto es justo donde es más fácil montarlo mal.
Lo que no estamos diciendo
- ✗Que la malla sustituya al switch siempre. Sustituye al switch en tres nodos que van a seguir siendo tres. La recomendación de usar switches por encima de tres nodos, o si hay plan de crecer, es de Proxmox, no nuestra, y nos parece acertada.
- ✗Que «tech preview» signifique roto. Significa que el fabricante todavía no se compromete con esa capa al mismo nivel que con el resto, y lo dice en su propia hoja de ruta. Leer la etiqueta no es lo mismo que rechazar la función: es decidir con el dato encima de la mesa.
- ✗Que hayamos cronometrado las cuatro variantes en tu hardware. Los números de arriba son los que publica Proxmox, citados tal cual. Lo que ponemos nosotros es el criterio: qué modo de fallo aceptaríamos y por qué. Quien te venda un tiempo de conmutación para tu clúster sin haberlo medido en tu clúster te está dando el tiempo del suyo.
Si tienes la malla montada y no sabes con cuál de las cuatro, la respuesta está a una mirada: si hay un frr.conf con openfabric o un fabric en el panel de SDN, tienes fallback. Si hay un bond en modo broadcast o unas rutas estáticas en /etc/network/interfaces, estás en el grupo que se parte con un cable. Ninguna de las dos cosas es una emergencia hoy. Pero una de las dos conviene saberla antes de que alguien toque un latiguillo.
Fuentes (consultadas el 12-10-2026): las cuatro variantes de la malla, su comportamiento ante la pérdida de un enlace, los tiempos de RSTP frente a STP, los intervalos Hello/CSNP y la recomendación de OpenFabric salen de Full Mesh Network for Ceph Server (wiki oficial de Proxmox, última edición del 27-03-2026). El estado «tech preview» del enrutado complejo, los fabrics, los permisos, las listas de prefijos y los route maps, el modo unnumbered, la interfaz dummy, los nombres reservados y la nota de IPv6, del capítulo SDN de la documentación de Proxmox VE. Las citas sobre corosync y los umbrales de 5 y 10 ms, del capítulo de clúster. Fechas de las versiones, novedades de 9.0, 9.1 y 9.2 y el objetivo sobre las partes en vista previa, de la hoja de ruta oficial. Todas las frases entrecomilladas son literales de esas páginas. No somos resellers de Proxmox ni de VMware y no vendemos licencias de ninguna de las dos: operamos Proxmox VE con Ceph en producción y escribimos desde ahí.
¿Sabes qué pasa en tu clúster si esta noche se suelta un cable?
Eso no se descubre en una caída: se decide al diseñar. Diseñamos y operamos infraestructura y cloud sobre Proxmox VE, montamos el almacenamiento distribuido con Ceph que va debajo y, como operador con red propia, la parte de redes y comunicaciones la hacemos nosotros en vez de dejarla entre dos proveedores.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN