Tres servidors connectats entre si, cadascun amb dues targetes, i ni un sol switch de 25 GbE a la factura. És de les decisions amb millor relació entre el que costa i el que dona de tot el que es pot muntar avui. La wiki de Proxmox la documenta des de fa anys i ofereix quatre maneres de cablejar-la. A l'apartat d'escenaris de fallada hi ha el detall que decideix quina tries: amb dues de les quatre, el dia que es trenca un cable els nodes es queden veient coses diferents.
La frase exacta de la wiki és aquesta: «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». El que compta és a la segona meitat. Al node 3 no s'ha trencat res. Els seus discos giren, els seus OSD estan actius i les seves dades són completes. Simplement, l'únic lloc des d'on ho estàs mirant és el que ja no el veu.
Aquesta és la diferència entre una fallada i una avaria, i aquí es compra en el moment de triar el cablejat, mesos abans que ningú ensopegui amb el cable.
Tothom assaja que cau un node
L'assaig que sí que es fa és apagar un servidor. I surt bé: la mateixa wiki ho diu sense dramatisme —si cau el node 3, «the Ceph and Proxmox VE cluster will remain functioning, though with reduced redundancy»—. És l'escenari còmode, perquè la pèrdua és total i simètrica: el node no hi és, i tots els que queden estan d'acord que no hi és.
L'escenari incòmode és un altre: el cable solt, l'SFP que s'escalfa, el port que negocia a 1 Gb en comptes de a 25 o el tècnic que aprofita una visita per «endreçar una mica». Allà la pèrdua és parcial i asimètrica, i això és molt pitjor que una pèrdua total, perquè cada node construeix una resposta coherent a partir d'informació incompleta i les tres respostes no coincideixen. A la pantalla no apareix «ha fallat un cable»: apareix un servei caigut en un lloc on no hi ha res caigut.
Les quatre maneres de cablejar tres nodes
El muntatge és sempre el mateix triangle: cada servidor amb almenys dues targetes, cadascuna endollada directament a un dels altres dos. El que canvia és què es posa damunt d'aquests cables. La wiki descriu quatre possibilitats, i el que de debò decideix entre elles no és el rendiment: és què passa quan cau un enllaç, no un node.
- Encaminament simple. Cada paquet va només al node destinatari. No necessita programari addicional i dona el millor rendiment dels quatre. Si cau un enllaç, no hi ha camí alternatiu: visió partida.
- Encaminament amb fallback. El mateix, però amb un protocol d'encaminament per sobre: si l'enllaç directe cau, el trànsit surt pel node del mig. Rendiment «similar» al simple; amb un enllaç menys, «a bit higher latency» i «the cluster will stay fully functional». Aguanta.
- RSTP. Un bucle amb arbre d'expansió ràpid. Exigeix Open vSwitch, perquè el pont de Linux només duu STP «without the rapid», i la diferència no és cosmètica: a les proves del mateix Proxmox, RSTP es recupera «within a few seconds» i STP triga uns 30 segons, que és «long enough for Ceph to start to complain and throw some warnings». Aguanta, amb un peatge permanent: mentre el bucle és complet, RSTP manté un tall artificial entre dos nodes, de manera que el trànsit entre aquests dos passa sempre pel tercer.
- Broadcast. Cada paquet s'envia als altres dos nodes. És el de muntatge més fàcil i el que més amplada de banda gasta. Si cau un enllaç: visió partida, igual que l'encaminament simple.
La nostra preferència, dita amb totes les lletres i sense pretendre que sigui l'única defensable: encaminament amb fallback. No perquè sigui el més elegant, sinó perquè és l'únic dels quatre el mode de fallada del qual és «va més lent». Un sistema que es degrada en velocitat es pot explicar a les tres de la matinada; un que es degrada en coherència genera mitja hora de diagnòstic abans que algú es recordi de mirar un cable. RSTP arriba a un lloc semblant, però obliga a posar Open vSwitch a l'equació, i cada peça que afegeixes al camí de les dades és una altra de mantenir.
I una línia de la wiki que convé llegir abans d'enamorar-se de l'estalvi: «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 és una resposta a tres nodes. Si el pla a dos anys és arribar a cinc, el switch entra al pressupost d'enguany, no al de l'any vinent.
El que ha canviat: ara encamina l'hipervisor
Fins fa poc, muntar l'encaminament amb fallback volia dir instal·lar FRR a mà, posar fabricd=yes a /etc/frr/daemons, escriure un frr.conf per node i inventar-se un NET d'IS-IS únic per a cadascun. Funciona perfectament i molta gent ho té així. Però viu fora del clúster: no és a la interfície, no és al control d'accés i no es replica.
Proxmox VE 9.0, el 5 d'agost del 2025, va posar això a dins amb el nom de fabrics: xarxes encaminades entre els nodes, configurables des de Datacenter → SDN → Fabrics, amb OpenFabric i OSPF. La 9.1 (19 de novembre del 2025) les va posar a l'arbre de recursos informant de rutes, veïns i interfícies. I la 9.2, el 21 de maig del 2026, va afegir dos protocols més i el control fi que faltava:
- BGP com a fabric, en mode eBGP unnumbered: cada node amb el seu propi número de sistema autònom, aparellant-se amb els veïns sobre les interfícies físiques «without requiring IP addresses on the fabric links».
- WireGuard com a fabric, per a túnels xifrats entre nodes o amb tercers. Amb un matís que la documentació no amaga: «It does not provide dynamic routing by itself» —és transport, i l'encaminament dinàmic el posa OSPF o BGP per sobre—.
- Llistes de prefixos i route maps com a objectes de primera classe de l'SDN, amb la seva API, més redistribució de rutes als fabrics OSPF i la possibilitat de simular un canvi abans d'aplicar-lo.
Quatre protocols de fabric dins el panell de l'hipervisor en nou mesos i mig: tres que encaminen i un que només transporta. Per al cas que ens ocupa, la mateixa wiki recomana el més senzill: «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». Aquesta pàgina es va editar per última vegada el 27 de març del 2026, dos mesos abans que arribessin BGP i WireGuard; és un bon recordatori que, quan dues pàgines oficials no diuen el mateix, mana la que porta data posterior.
El procediment cap en un paràgraf: crees el fabric, li dones un nom —vuit caràcters com a màxim a OpenFabric, detall que es descobreix tard— i un prefix IPv4; afegeixes cada node amb el seu router-ID dins d'aquest prefix i marques les dues interfícies de la malla. Si aquestes interfícies no duen IP, treballen en mode unnumbered i hereten la del node. Després Apply Configuration, que genera i aplica la configuració d'FRR a cada màquina, i a comprovar:
vtysh
show openfabric neighbor
show openfabric routeI després, en instal·lar Ceph, el fabric apareix al desplegable de xarxes disponibles del pas de configuració inicial. Hi ha un paràmetre que convé tocar amb coneixement: els intervals Hello i CSNP, que l'exemple de la wiki baixa a 1 i 2. El text declara el preu sense maquillar-lo —«Lower numbers mean that the network will fail over faster in the case of link failures, but nodes will generate more traffic»—, i convé decidir-ho amb aquesta frase al davant.
L'etiqueta que ve posada de fàbrica
Això és a la primera pàgina del capítol d'SDN de la documentació oficial, a l'apartat «Current Status». Són tres línies i diuen tres coses diferents:
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ínia és la que ens ocupa, amb una precisió que cal fer abans de continuar: Proxmox no hi escriu la paraula «fabrics», escriu «complex routing via FRRouting», que és exactament el que un fabric és per sota. L'equivalència la posem nosaltres. El que no és nostre és la segona menció: el full de ruta publicat del projecte fixa com a objectiu «Bring the remaining tech-preview parts of the SDN stack to full production readiness».
La nostra lectura, que no és l'única possible: això no és un motiu per no fer-ho servir. FRR és FRR, fa anys que mou xarxes de debò, i el que està en vista prèvia és la capa d'integració de Proxmox per sobre. Però sí que és un motiu per decidir amb els ulls oberts què hi penges, i sobretot per no assabentar-te de l'etiqueta el dia que alguna cosa es comporta estrany. Hi ha una diferència enorme entre «assumim aquest risc perquè ens compensa» i «no sabíem que hi hagués un risc». La primera frase es diu en una reunió; la segona, en un postmortem.
I corosync, també per aquí?
És la temptació evident: ja tens 25 GbE entre els tres nodes, per què no posar-hi també el trànsit del clúster? La documentació de Proxmox contesta això sense ambigüitat:
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 és la xarxa d'emmagatzematge. I les xifres que acompanyen aquesta recomanació són concretes: el stack de clúster «requires a reliable network with latencies under 5 milliseconds», i per sobre d'uns 10 ms amb més de tres nodes l'estabilitat «gets rather unlikely». Corosync no necessita amplada de banda, necessita que ningú no li posi jitter; un recovery de Ceph a 25 Gb fent backfill és exactament la mena de veí que sí que l'hi posa. Ja vam explicar al seu dia > per què aquest rellotge no és un número fix, sinó que creix amb cada node que afegeixes.
Traduït a compra: les dues targetes ràpides de la malla no són totes les targetes que necessites. Cal a més, com a mínim, una NIC dedicada per a l'enllaç principal de corosync —que pot ser d'1 Gb de sobres— i la boca de gestió. Qui dimensiona el servidor comptant només els ports de 25 Gb acaba compartint el que la documentació demana expressament no compartir. I del comportament d'un Ceph de tres nodes quan perd una peça ja en vam parlar a part a >.
Els quatre fitxers que canvien de propietari
Aquesta és la part que no surt a cap captura de pantalla i que, a empreses on «xarxes» i «sistemes» són persones diferents —o proveïdors diferents—, decideix si el fabric és una millora o una discussió. Activar-lo mou quatre fitxers d'un costat de la taula a l'altre:
/etc/pve/sdn/— la font de veritat, i és del clúster. Llistes de prefixos, route maps i fabrics viuen aquí, replicats. S'editen des de la interfície o l'API, passen per un estat pending i no fan res fins que algú prem aplicar./etc/network/interfaces— l'escriu l'SDN. Per això afegir o actualitzar un node dins d'un fabric exigeix a més permísSys.Modifysobre aquest node: la documentació ho justifica dient que l'operació «involves writing to the node's /etc/network/interfaces file». Amb una aresta: si treus una interfície l'entrada de la qual teniamanual, la IP «will not get removed on applying the SDN configuration»./etc/frr/frr.conf— generat. La configuració del clúster es tradueix a estrofes d'FRR i acaba aquí, a cada node. Si venies del muntatge manual, la mateixa wiki avisa de la col·lisió: «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. És on caben els teus afegits propis per node, que s'annexen damunt del que s'ha generat. És l'únic punt del conjunt on conviuen alhora el que escriu Proxmox i el que escrius tu, i per tant el primer que cal mirar quan alguna cosa no quadra.
Hi ha a més dues coses que el fabric crea sense preguntar i que convé reconèixer quan apareguin en un ip route. Una interfície dummy amb el router-ID com a adreça, que fa de loopback i neix passiva. I, per cada fabric, una llista d'accés i un route map generats automàticament per reescriure l'adreça d'origen dels paquets sortints: gràcies a això un ping entre nodes surt des de la loopback i no des de la interfície física. Diversos noms estan reservats i no els pots fer servir per als teus —only_default, loopbacks_ips, correct_src i qualsevol que comenci per pve_—.
La pregunta que obre aquest mapa és organitzativa: qui signa un canvi en aquests quatre fitxers? Perquè des del moment en què existeix el fabric, una part de la taula de rutes es toca des del panell de virtualització, amb els permisos de virtualització i per la gent que administra virtualització. Si això no es diu en veu alta abans, el primer que se n'assabenta és qui estigui de guàrdia.
Tres avisos amagats a la lletra petita
Els tres estan escrits a la documentació oficial, els tres són fàcils de saltar-se i els tres costen una tarda.
- IPv6 només va a OpenFabric, i exigeix reenviament IPv6 global. No hi ha manera còmoda d'activar-lo per interfície com a IPv4, així que la recepta de la documentació és un
post-up sysctl -w net.ipv6.conf.all.forwarding=1. El mateix text adverteix que això afecta com les interfícies gestionen SLAAC, els anuncis de veí i els de router. Un ajust d'un fabric que canvia el comportament IPv6 de tota la màquina. - Les llistes de prefixos i els route maps deneguen per defecte al final. És la semàntica estàndard d'FRR, però sorprèn qui ve d'una altra eina. La documentació arriba a ensenyar el patró: una entrada final de
permitsense condició, perquè «without it the implicit deny at the end of the route map would drop all unmatched routes». - Si els nodes estan virtualitzats —laboratori, prova de concepte, formació—, les interfícies del fabric de cada node han d'estar en ponts separats o en VLAN diferents. Si no, diu la wiki, «routing loops may occur». És a dir: el laboratori on anaves a assajar això és justament on és més fàcil muntar-ho malament.
El que no estem dient
- ✗Que la malla substitueixi el switch sempre. Substitueix el switch en tres nodes que continuaran sent tres. La recomanació d'usar switches per sobre de tres nodes, o si hi ha pla de créixer, és de Proxmox, no nostra, i ens sembla encertada.
- ✗Que «tech preview» vulgui dir trencat. Vol dir que el fabricant encara no es compromet amb aquesta capa al mateix nivell que amb la resta, i ho diu al seu full de ruta. Llegir l'etiqueta no és el mateix que rebutjar la funció: és decidir amb la dada damunt la taula.
- ✗Que haguem cronometrat les quatre variants al teu maquinari. Els números de dalt són els que publica Proxmox, citats tal qual. El que hi posem nosaltres és el criteri: quin mode de fallada acceptaríem i per què. Qui et vengui un temps de commutació per al teu clúster sense haver-lo mesurat al teu clúster t'està donant el del seu.
Si tens la malla muntada i no saps amb quina de les quatre, la resposta és a una mirada: si hi ha un frr.conf amb openfabric o un fabric al panell d'SDN, tens fallback. Si hi ha un bond en mode broadcast o unes rutes estàtiques a /etc/network/interfaces, ets al grup que es parteix amb un cable. Cap de les dues coses és una emergència avui. Però una de les dues convé saber-la abans que algú toqui un llatiguet.
Fonts (consultades el 12-10-2026): les quatre variants de la malla, el seu comportament davant la pèrdua d'un enllaç, els temps d'RSTP davant d'STP, els intervals Hello/CSNP i la recomanació d'OpenFabric surten de Full Mesh Network for Ceph Server (wiki oficial de Proxmox, última edició del 27-03-2026). L'estat «tech preview» de l'encaminament complex, els fabrics, els permisos, les llistes de prefixos i els route maps, el mode unnumbered, la interfície dummy, els noms reservats i la nota d'IPv6, del capítol SDN de la documentació de Proxmox VE. Les cites sobre corosync i els llindars de 5 i 10 ms, del capítol de clúster. Dates de les versions, novetats de 9.0, 9.1 i 9.2 i l'objectiu sobre les parts en vista prèvia, del full de ruta oficial. Totes les frases entre cometes són literals d'aquestes pàgines. No som resellers de Proxmox ni de VMware i no venem llicències de cap de les dues: operem Proxmox VE amb Ceph en producció i escrivim des d'aquí.
Saps què passa al teu clúster si aquesta nit es desconnecta un cable?
Això no es descobreix en una caiguda: es decideix en dissenyar. Dissenyem i operem infraestructura i cloud sobre Proxmox VE, muntem l'emmagatzematge distribuït amb Ceph que hi va a sota i, com a operador amb xarxa pròpia, la part de xarxes i comunicacions la fem nosaltres en comptes de deixar-la entre dos proveïdors.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN