> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/es/modulo-1-fundamentos-de-arquitectura/04-core-fabric.md).
# Fabric central y redes
## ¿Qué es el tejido central?
La **tejido central** es una malla de red privada y de alta velocidad que interconecta todos los nodos en un sistema VergeOS. Es la base de cada implementación de VergeOS: toda la comunicación interna del clúster fluye por este tejido. El tejido central nunca se expone al tráfico externo.
Los tipos de tráfico que transporta el tejido central incluyen:
* **replicación vSAN** — escrituras de bloques de datos primarios y redundantes entre nodos participantes en almacenamiento
* **Coordinación del clúster** — comprobaciones de estado de los nodos, elección de liderazgo y sincronización del estado del sistema
* **Migración en vivo de VM** — transferencia del estado de memoria y CPU al mover VMs en ejecución entre nodos
* **Plano de control** — llamadas a la API, actualizaciones de configuración y comunicación de administración entre los servicios de VergeOS
El tejido central está diseñado para **baja latencia y alto rendimiento**. Como el rendimiento de vSAN depende directamente de la velocidad y la fiabilidad de la comunicación entre nodos, el tejido central es la red más crítica para el rendimiento en un sistema VergeOS.
{% hint style="info" %}
**Puente con VMware**
En VMware, vMotion, la replicación vSAN, la administración y otros tráficos entre nodos reciben cada uno su propio grupo de puertos VMkernel en un vDS, con VLAN y políticas de failover de uplinks por tipo de tráfico. El tejido central de VergeOS transporta todo el tráfico entre nodos sobre una única malla privada redundante: no hay grupos de puertos por tipo que planificar.
{% endhint %}
{% hint style="info" %}
**Puente con Nutanix**
La red de backplane de CVM a CVM de Nutanix necesita configuración explícita de VLAN/IP para el backplane, la CVM y la administración del hipervisor. El tejido central de VergeOS es una malla privada de Capa 2 sin IP ni VLAN: los nodos se descubren automáticamente entre sí.
{% endhint %}
## Redundancia de doble switch
Para tolerancia a fallos, el tejido central se ejecuta sobre **dos redes físicas independientes** — denominadas **Tejido central 1** y **Tejido central 2** (o Central 1 / Central 2). Cada red de tejido es su propio dominio de difusión aislado de Capa 2.
Cada nodo se conecta a **ambos** las redes de tejido. Si falla un switch o una ruta de cableado, la otra red de tejido mantiene la conectividad completa entre nodos sin interrumpir la replicación de vSAN, la migración en vivo ni la coordinación del clúster.
{% hint style="info" %}
**Conmutadores de Capa 2, Capa 3 gestionada por VergeOS**
Configuras los conmutadores físicos del tejido central para **solo Capa 2** — dominios de difusión aislados sin enrutamiento. VergeOS gestiona todo el direccionamiento y el enrutamiento de Capa 3 (la superposición de red central descrita abajo) sobre esas redes de Capa 2. No hay ninguna configuración de Capa 3 que hacer en los propios conmutadores.
{% endhint %}
```mermaid
graph TB
subgraph "Infraestructura física de conmutación"
SW1["Conmutador A
Tejido central 1
VLAN 900"]
SW2["Conmutador B
Tejido central 2
VLAN 901"]
end
subgraph "Nodo 1 (controlador)"
N1_CF1["NIC 1 → Tejido central 1"]
N1_CF2["NIC 2 → Tejido central 2"]
end
subgraph "Nodo 2 (controlador)"
N2_CF1["NIC 1 → Tejido central 1"]
N2_CF2["NIC 2 → Tejido central 2"]
end
subgraph "Nodo 3 (escalado horizontal)"
N3_CF1["NIC 1 → Tejido central 1"]
N3_CF2["NIC 2 → Tejido central 2"]
end
N1_CF1 --- SW1
N2_CF1 --- SW1
N3_CF1 --- SW1
N1_CF2 --- SW2
N2_CF2 --- SW2
N3_CF2 --- SW2
style SW1 fill:#e3f2fd,stroke:#1565c0
style SW2 fill:#e8f5e9,stroke:#2e7d32
```
### Reglas clave de diseño
| Requisito | Detalle |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Aislamiento** | Tejido central 1 y Tejido central 2 deben estar en sus propias redes dedicadas de Capa 2, completamente aisladas entre sí y del tráfico externo |
| **Tramas jumbo** | MTU 9216 o superior en todos los puertos de los conmutadores del tejido central (9216 admite la carga útil de 9000 bytes más etiquetas VLAN, encabezados y sobrecarga del inquilino) |
| **Cero saltos de switch** | Todos los nodos deben estar en la misma infraestructura de conmutación, sin saltos entre conmutadores en la ruta del tejido central; los saltos adicionales introducen latencia que degrada el rendimiento de vSAN |
| **Modo de puerto** | Puertos de acceso (sin etiqueta, una sola VLAN por red de tejido central) |
| **Spanning tree** | Deshabilitado en los puertos del tejido central (BPDU guard deshabilitado, portfast deshabilitado): no se debe usar STP para los enlaces del tejido central. Idealmente, este tráfico no debería salir del conmutador. |
| **Velocidad** | Se recomienda 10 Gbps o superior |
> **Nota del entorno de pruebas:** El entorno de pruebas de Terraform usa MTU 9142 para sus redes virtuales de tejido central. Las implementaciones de producción deben usar MTU 9216 o superior según la documentación oficial de VergeOS.
## Superposición de la red central
Encima de las dos redes físicas de tejido, VergeOS crea una **red central virtual** — una superposición lógica con el rango de direcciones `100.96.0.0/24`. Esta red central proporciona a cada nodo una dirección IP interna estable que utilizan los servicios de VergeOS.
La relación es:
* **Tejido central 1 y Tejido central 2** son los transportes de capa física (redes de Capa 2)
* **Red central (`100.96.0.0/24`)** es la superposición lógica que se ejecuta sobre ambos conmutadores de tejido
La red central abstrae la redundancia de doble ruta subyacente para que los servicios de VergeOS se comuniquen usando una sola dirección por nodo, independientemente de qué tejido físico esté activo.
### Asignaciones de direcciones IP
| Red | Nodo 1 | Nodo 2 | Nodo 3+ |
| -------------------- | ---------------------- | ---------------------- | --------------- |
| **Red central** | 100.96.0.2 | 100.96.0.3 | 100.96.0.(N+1) |
| **Tejido central 1** | 172.16.1.1 | 172.16.1.2 | 172.16.1.N |
| **Tejido central 2** | 172.16.2.1 | 172.16.2.2 | 172.16.2.N |
| **Externa** | Estática (configurada) | Estática (configurada) | DHCP o estática |
> Para la **Red central**, `100.96.0.1` está reservada como la puerta de enlace del clúster; las direcciones por nodo comienzan en `.2` para el Nodo 1 y aumentan a partir de ahí.
> La `172.16.1.0/24` y `172.16.2.0/24` las subredes del tejido central son las predeterminadas asignadas cuando se configuran las redes centrales **antes de** la red externa durante la instalación. Si la red externa se asigna primero, VergeOS asigna subredes diferentes a los tejidos centrales.
```mermaid
graph TB
subgraph "Superposición lógica"
CORE["Red central
100.96.0.0/24
MTU 9000"]
end
subgraph "Transporte físico"
CF1["Tejido central 1
172.16.1.0/24
MTU 9216"]
CF2["Tejido central 2
172.16.2.0/24
MTU 9216"]
end
CORE -->|"se ejecuta sobre"| CF1
CORE -->|"se ejecuta sobre"| CF2
style CORE fill:#fff3e0,stroke:#e65100
style CF1 fill:#e3f2fd,stroke:#1565c0
style CF2 fill:#e8f5e9,stroke:#2e7d32
```
## Conexiones de red del nodo
Un nodo VergeOS típico tiene **cuatro interfaces de red** — dos para el tejido central y dos para la red externa:
| NICs | Conexión | Propósito |
| --------- | ---------------- | ---------------------------------------------------------------------------------------- |
| NIC 1 | Tejido central 1 | Ruta principal para todo el tráfico entre nodos |
| NIC 2 | Tejido central 2 | Ruta redundante para todo el tráfico entre nodos |
| NIC 3 + 4 | Red externa | Acceso a la interfaz de administración/API, tráfico de usuarios, conectividad a Internet |
Los nombres reales de los dispositivos NIC varían según el hardware (p. ej., `eno1`, `enp3s0f0`, `eth0`). Durante la instalación, seleccionas qué NIC física corresponde a cada rol.
Las NIC externas normalmente están **agrupadas** (LACP o active-backup) para redundancia. VergeOS admite tanto el agrupamiento basado en switches (LACP) como su propio **agrupamiento por software** — no se requiere configuración del switch. Las dos NIC del tejido central **no deben** estar agrupadas: el LAG físico o el enlace de puertos interfieren con la redundancia integrada del tejido, que detecta una gama más amplia de problemas (paquetes descartados, desajustes de MTU, bloqueos de NIC, firmware defectuoso) a nivel de aplicación mejor que LAG. Cada NIC del tejido central se conecta a su propio switch independiente.
```mermaid
graph LR
subgraph "Nodo"
NIC1["NIC 1
Tejido central 1"]
NIC2["NIC 2
Tejido central 2"]
NIC3["NIC 3
Externa"]
NIC4["NIC 4
Externa"]
end
NIC1 --- CF1["Tejido central 1
MTU 9216+"]
NIC2 --- CF2["Tejido central 2
MTU 9216+"]
NIC3 --- BOND["Agregado (LACP / Active-Backup)"]
NIC4 --- BOND
BOND --- EXT["Red externa
MTU 1500"]
CF1 -.- CORE["Superposición de la red central"]
CF2 -.- CORE
style EXT fill:#fce4ec,stroke:#c62828
style BOND fill:#fce4ec,stroke:#c62828
style CF1 fill:#e3f2fd,stroke:#1565c0
style CF2 fill:#e8f5e9,stroke:#2e7d32
style CORE fill:#fff3e0,stroke:#e65100
```
## Separación entre red externa y tejido central
VergeOS impone una separación estricta entre el tráfico orientado al exterior y el tráfico interno del clúster. Son dos dominios de red fundamentalmente diferentes:
### Redes externas
* Conecta VergeOS a la infraestructura LAN/WAN existente
* Transporta tráfico de cara al usuario: acceso a la interfaz de administración, conectividad de cargas de trabajo de VM, acceso a Internet
* Usa MTU estándar (1500) salvo que las cargas de trabajo requieran tramas jumbo
* Configuradas como troncos VLAN (etiquetados 802.1Q) para admitir múltiples VLAN para la separación de inquilinos y cargas de trabajo
* Normalmente agregadas (LACP o active-backup) para redundancia
* Puede haber múltiples redes externas por sistema (p. ej., VLAN de administración, VLAN de producción, VLAN DMZ)
### Redes de tejido central
* Completamente privadas — nunca expuestas al tráfico externo ni a los usuarios
* Transportan todo el tráfico del sistema entre nodos (vSAN, migración, coordinación)
* Requieren tramas jumbo (MTU 9216+) para eficiencia de almacenamiento
* Configuradas como puertos de acceso (sin etiqueta, una sola VLAN por tejido)
* Siempre dos tejidos independientes para redundancia
* No debe haber saltos de switch entre nodos para mantener baja latencia
### La red DMZ
VergeOS crea automáticamente una **red DMZ** durante la instalación. La DMZ sirve como el punto central de conexión para todas las redes virtuales del sistema. Cada nube de VergeOS (ya sea el sistema host o un inquilino) tiene exactamente una red DMZ.
La DMZ proporciona **enrutamiento de Capa 3** entre redes. Cada tipo de red (externa, interna, central) tiene su propio router virtual con una interfaz en su propia red y otra interfaz en la DMZ. Cuando una red interna necesita llegar a una red externa, el tráfico fluye a través de la DMZ, donde se aplican las reglas de red y las políticas de firewall en el límite de enrutamiento.
La DMZ utiliza el `100.64.0.0/16` rango de direcciones. Cada router de red virtual — redes externas, redes internas, la red central y cualquier nube de inquilino anidada — tiene una interfaz DMZ a la que se le asigna una dirección de esta subred:
```mermaid
graph TB
ISP["ISP / Router ascendente"]
EXT["Router de red externa
Eth0: IP externa
Eth1/DMZ: 100.64.0.3"]
DMZ["Red DMZ
100.64.0.0/16
(centro de enrutamiento de Capa 3)"]
CORE["Router de red central
Eth0: 100.96.0.1/24
Eth1/DMZ: 100.64.0.2"]
INT1["Router de red interna
Eth0: 192.168.0.1/24
Eth1/DMZ: 100.64.0.4"]
TENANT["Red del inquilino
(desde la perspectiva del host)
Eth0: 100.96.0.1/24
Eth1/DMZ: 100.64.0.5"]
VM1["VMs"]
subgraph tenant_inside["Dentro del inquilino (su propio VDC)"]
T_EXT["Router externo del inquilino
Eth0: 100.96.0.2/24
Eth1/DMZ: 100.64.0.3"]
T_DMZ["DMZ del inquilino
100.64.0.0/16"]
T_INT["Router interno del inquilino
Eth0: 192.168.0.1/24
Eth1/DMZ: 100.64.0.4"]
T_VM["VM del inquilino"]
T_EXT <--> T_DMZ
T_INT <--> T_DMZ
T_INT <--> T_VM
end
ISP <--> EXT
EXT <--> DMZ
CORE <--> DMZ
INT1 <--> DMZ
TENANT <--> DMZ
INT1 <--> VM1
TENANT <--> T_EXT
style ISP fill:#fce4ec,stroke:#c62828
style EXT fill:#fce4ec,stroke:#c62828
style DMZ fill:#fff3e0,stroke:#e65100
style CORE fill:#e3f2fd,stroke:#1565c0
style INT1 fill:#e8f5e9,stroke:#2e7d32
style VM1 fill:#e8f5e9,stroke:#2e7d32
style TENANT fill:#e8eaf6,stroke:#283593
style tenant_inside fill:#e8eaf6,stroke:#283593
style T_EXT fill:#fce4ec,stroke:#c62828
style T_DMZ fill:#fff3e0,stroke:#e65100
style T_INT fill:#e8f5e9,stroke:#2e7d32
style T_VM fill:#e8f5e9,stroke:#2e7d32
```
Desde la perspectiva del host, un inquilino aparece como otra red conectada a la DMZ. En su interior, el inquilino tiene su propia pila de redes completa: su propia DMZ, router externo, redes internas y VMs; un Centro de Datos Virtual totalmente anidado.
{% hint style="info" %}
**Puente con VMware**
VergeFabric consolida lo que VMware distribuye entre grupos de puertos vDS, segmentos NSX-T y un firewall físico: el tejido central reemplaza a los grupos VMkernel para vSAN/vMotion/administración, las redes externas reemplazan a los uplinks vDS para el tráfico de VM, la red DMZ reemplaza las funciones de enrutador/firewall de NSX Edge, y las redes internas reemplazan los segmentos NSX-T con DHCP/DNS/enrutamiento/firewall integrados.
{% endhint %}
{% hint style="info" %}
**Puente con Nutanix**
Nutanix depende de VLAN estándar, del complemento Flow para la microsegmentación y de dispositivos externos para el enrutamiento y el firewall. VergeOS ofrece el equivalente de forma nativa: el tejido central reemplaza al backplane de la CVM (sin configuración de VLAN), las redes externas reemplazan a los uplinks basados en VLAN, la red DMZ gestiona el enrutamiento y el firewall, y las redes internas integran DHCP/DNS/enrutamiento/firewall.
{% endhint %}
## Modelos de diseño de red de producción
En producción, VergeOS admite varios modelos de diseño de red según el número de NIC por nodo y los requisitos de red externa. Todos los modelos mantienen el doble tejido central para redundancia.
### Modelo de 4 NIC (recomendado)
La configuración estándar de producción usa 4 NIC por nodo:
| NIC | Asignación | Configuración |
| ----- | ------------------------------- | ----------------------------------------- |
| NIC 1 | Tejido central 1 | Puerto de acceso, VLAN dedicada, MTU 9216 |
| NIC 2 | Tejido central 2 | Puerto de acceso, VLAN dedicada, MTU 9216 |
| NIC 3 | Externa 1 (agregado principal) | Puerto trunk, LACP, MTU 1500 |
| NIC 4 | Externa 2 (agregado secundario) | Puerto trunk, LACP, MTU 1500 |
Esto proporciona redundancia total tanto en el tejido central (dos rutas independientes) como en la red externa (par agregado).
### Modelo de 2 NIC
Un modelo de 2 NIC combina el tráfico del tejido central y el tráfico externo en los mismos puertos físicos usando etiquetado VLAN:
| NIC | Asignación | Configuración |
| ----- | -------------------------------- | ------------------------------------------------------------------------ |
| NIC 1 | Tejido central 1 + VLAN externas | VLAN nativa para el tejido central, VLAN etiquetadas para la red externa |
| NIC 2 | Tejido central 2 + VLAN externas | VLAN nativa para el tejido central, VLAN etiquetadas para la red externa |
Este modelo funciona bien para **puertos de red de 100 GbE** donde dos interfaces de alto ancho de banda proporcionan más que suficiente rendimiento tanto para el tejido central como para el tráfico externo. También es adecuado para sedes periféricas y despliegues de prueba de concepto. En este modelo puede usarse el agrupamiento por software de VergeOS para proporcionar redundancia de red externa a través de ambas NIC, mientras se mantiene la redundancia del doble tejido central.
## Cómo lo modela el entorno de pruebas de Terraform
En el entorno de pruebas de Terraform, el tejido central se modela como dos `vergeio_network` recursos en el sistema VergeOS del host:
* `core_fabric_1` — red de Capa 2, MTU 9142, sin DHCP
* `core_fabric_2` — red de Capa 2, MTU 9142, sin DHCP
Cada VM de nodo obtiene tres NIC:
1. **NIC 1** → red externa (administración y acceso de usuarios)
2. **NIC 2** → Tejido central 1
3. **NIC 3** → Tejido central 2
El entorno de pruebas usa MTU 9142 (en lugar de los 9216 recomendados para producción) porque la infraestructura de red virtual del sistema host introduce sobrecarga adicional. La superposición de red central (`100.96.0.0/24`) se ejecuta sobre ambas redes de tejido, tal como ocurre en producción.
## Puntos clave
| Concepto | Resumen |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Tejido central** | Malla privada entre nodos: transporta vSAN, migración, coordinación y tráfico del plano de control |
| **Redundancia doble** | Dos redes de tejido independientes (Central 1 + Central 2) en dominios separados de Capa 2 |
| **Requisitos de MTU** | 9216+ en producción (9142 en el entorno de pruebas): las tramas jumbo son obligatorias |
| **Superposición de red central** | Red `100.96.0.0/24` lógica que se ejecuta sobre ambos conmutadores de tejido y proporciona IP internas estables |
| **3 NIC por nodo** | Mínimo: 1 externa + 2 de tejido central. En producción normalmente se usan 4+ NIC con externa agregada |
| **Cero saltos de switch** | Los puertos del tejido central deben estar en la misma infraestructura de conmutación: no se permiten saltos entre switches |
| **Aislamiento del tráfico** | El tejido central nunca se expone al tráfico externo; las redes externas están completamente separadas |
| **red DMZ** | Centro de enrutamiento de Capa 3 creado automáticamente que conecta todas las redes virtuales del sistema |
## Siguientes pasos
Ahora que entiendes cómo están interconectados los nodos de VergeOS, el siguiente tema cubre cómo se organizan esos nodos en clústeres: [**Clústeres y tipos de nodo →**](/learn-the-platform/es/modulo-1-fundamentos-de-arquitectura/05-clusters-nodes.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.verge.io/learn-the-platform/es/modulo-1-fundamentos-de-arquitectura/04-core-fabric.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.