> 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/de/modul-1-architekturgrundlagen/04-core-fabric.md).
# Zentrales Fabric & Netzwerk
## Was ist die Core Fabric?
Das **Core Fabric** ist ein privates, Hochgeschwindigkeits-Netzwerkmesh, das alle Knoten in einem VergeOS-System miteinander verbindet. Es ist das Rückgrat jeder VergeOS-Bereitstellung — die gesamte interne Clusterkommunikation läuft über dieses Fabric. Die Core Fabric wird niemals externem Traffic ausgesetzt.
Zu den Verkehrstypen, die über die Core Fabric laufen, gehören:
* **vSAN-Replikation** — Primäre und redundante Schreibvorgänge von Datenblöcken zwischen speicherbeteiligten Knoten
* **Cluster-Koordination** — Knoten-Gesundheitsprüfungen, Führungswahl und Synchronisierung des Systemzustands
* **Live-Migration von VMs** — Übertragung von Speicher- und CPU-Zustand beim Verschieben laufender VMs zwischen Knoten
* **Kontrollebene** — API-Aufrufe, Konfigurationsaktualisierungen und Verwaltungskommunikation zwischen VergeOS-Diensten
Die Core Fabric ist ausgelegt auf **geringe Latenz und hohen Durchsatz**. Da die vSAN-Leistung direkt von der Geschwindigkeit und Zuverlässigkeit der Kommunikation zwischen den Knoten abhängt, ist die Core Fabric das Netzwerk mit der höchsten Leistungsrelevanz in einem VergeOS-System.
{% hint style="info" %}
**VMware Bridge**
In VMware erhalten vMotion, vSAN-Replikation, Verwaltung und anderer Verkehr zwischen Knoten jeweils eine eigene VMkernel-Portgruppe auf einem vDS, mit VLANs und Uplink-Failover-Richtlinien pro Verkehrstyp. Die VergeOS Core Fabric transportiert den gesamten Verkehr zwischen den Knoten über ein redundantes privates Mesh — es müssen keine Portgruppen pro Typ geplant werden.
{% endhint %}
{% hint style="info" %}
**Nutanix Bridge**
Nutanix' CVM-zu-CVM-Backplane-Netzwerk benötigt eine explizite VLAN/IP-Konfiguration für die Backplane, die CVM und das Hypervisor-Management. Die VergeOS Core Fabric ist ein privates Layer-2-Mesh ohne IPs oder VLANs — Knoten erkennen sich automatisch.
{% endhint %}
## Dual-Switch-Redundanz
Zur Fehlertoleranz läuft die Core Fabric über **zwei unabhängige physische Netzwerke** — bezeichnet als **Core Fabric 1** und **Core Fabric 2** (oder Core 1 / Core 2). Jedes Fabric-Netzwerk ist eine eigene isolierte Layer-2-Broadcast-Domäne.
Jeder Knoten verbindet sich mit **sowohl** Fabric-Netzwerken. Fällt ein Switch- oder Kabelpfad aus, hält das andere Fabric-Netzwerk die vollständige Konnektivität zwischen den Knoten ohne Unterbrechung der vSAN-Replikation, Live-Migration oder Cluster-Koordination aufrecht.
{% hint style="info" %}
**Layer-2-Switches, Layer 3 von VergeOS übernommen**
Sie konfigurieren die physischen Core-Fabric-Switches für **nur Layer 2** — isolierte Broadcast-Domänen ohne Routing. VergeOS übernimmt die gesamte Layer-3-Adressierung und das Routing (das unten beschriebene Core-Netzwerk-Overlay) über diese Layer-2-Netzwerke. Auf den Switches selbst ist keine Layer-3-Konfiguration erforderlich.
{% endhint %}
```mermaid
graph TB
subgraph "Physische Switch-Infrastruktur"
SW1["Switch A
Core Fabric 1
VLAN 900"]
SW2["Switch B
Core Fabric 2
VLAN 901"]
end
subgraph "Knoten 1 (Controller)"
N1_CF1["NIC 1 → Core Fabric 1"]
N1_CF2["NIC 2 → Core Fabric 2"]
end
subgraph "Knoten 2 (Controller)"
N2_CF1["NIC 1 → Core Fabric 1"]
N2_CF2["NIC 2 → Core Fabric 2"]
end
subgraph "Knoten 3 (Scale-out)"
N3_CF1["NIC 1 → Core Fabric 1"]
N3_CF2["NIC 2 → Core Fabric 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
```
### Wichtige Designregeln
| Anforderung | Details |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Isolation** | Core Fabric 1 und Core Fabric 2 müssen auf ihren eigenen dedizierten Layer-2-Netzwerken liegen, vollständig voneinander und vom externen Verkehr isoliert |
| **Jumbo Frames** | MTU 9216 oder höher auf allen Core-Fabric-Switch-Ports (9216 berücksichtigt die 9000-Byte-Nutzlast plus VLAN-Tags, Header und Tenant-Overhead) |
| **Keine Switch-Hops** | Alle Knoten müssen sich auf derselben Switching-Fabric befinden, ohne Switch-Hops im Pfad der Core Fabric — zusätzliche Hops führen zu Latenz, die die vSAN-Leistung beeinträchtigt |
| **Port-Modus** | Access-Ports (untagged, ein VLAN pro Core-Fabric-Netzwerk) |
| **Spanning Tree** | Auf Core-Fabric-Ports deaktiviert (BPDU Guard deaktivieren, PortFast deaktivieren) — STP sollte nicht für Core-Fabric-Verbindungen verwendet werden. Idealerweise würde dieser Verkehr den Switch nicht verlassen. |
| **Geschwindigkeit** | 10 Gbit/s oder höher empfohlen |
> **Hinweis zum Playground:** Der Terraform-Playground verwendet MTU 9142 für seine virtuellen Core-Fabric-Netzwerke. Produktionsbereitstellungen sollten gemäß der offiziellen VergeOS-Dokumentation MTU 9216 oder höher verwenden.
## Core-Netzwerk-Overlay
Auf Basis der beiden physischen Fabric-Netzwerke erstellt VergeOS ein **virtuelles Core-Netzwerk** — eine logische Überlagerung mit dem Adressbereich `100.96.0.0/24`. Dieses Core-Netzwerk stellt jedem Knoten eine stabile interne IP-Adresse bereit, die von den VergeOS-Diensten verwendet wird.
Die Beziehung ist:
* **Core Fabric 1 und Core Fabric 2** sind die Übertragungen auf physischer Ebene (Layer-2-Netzwerke)
* **Core-Netzwerk (`100.96.0.0/24`)** ist das logische Overlay, das auf beiden Fabric-Switches aufsetzt
Das Core-Netzwerk abstrahiert die zugrunde liegende Redundanz mit doppeltem Pfad, sodass VergeOS-Dienste eine einzelne Adresse pro Knoten verwenden, unabhängig davon, welches physische Fabric aktiv ist.
### IP-Adresszuweisungen
| Netzwerk | Knoten 1 | Knoten 2 | Knoten 3+ |
| ----------------- | ----------------------- | ----------------------- | ------------------ |
| **Kernnetzwerk** | 100.96.0.2 | 100.96.0.3 | 100.96.0.(N+1) |
| **Core Fabric 1** | 172.16.1.1 | 172.16.1.2 | 172.16.1.N |
| **Core Fabric 2** | 172.16.2.1 | 172.16.2.2 | 172.16.2.N |
| **Externe** | Statisch (konfiguriert) | Statisch (konfiguriert) | DHCP oder statisch |
> Für das **Core-Netzwerk**, `100.96.0.1` ist als Cluster-Gateway reserviert; die Adressen pro Knoten beginnen bei `.2` für Knoten 1 und steigen von dort aus.
> Das `172.16.1.0/24` und `172.16.2.0/24` Core-Fabric-Subnetze sind die Standardwerte, die zugewiesen werden, wenn die Core-Netzwerke konfiguriert werden **vor dem** das externe Netzwerk während der Installation. Wenn das externe Netzwerk zuerst zugewiesen wird, weist VergeOS den Core Fabrics andere Subnetze zu.
```mermaid
graph TB
subgraph "Logisches Overlay"
CORE["Core-Netzwerk
100.96.0.0/24
MTU 9000"]
end
subgraph "Physischer Transport"
CF1["Core Fabric 1
172.16.1.0/24
MTU 9216"]
CF2["Core Fabric 2
172.16.2.0/24
MTU 9216"]
end
CORE -->|"läuft über"| CF1
CORE -->|"läuft über"| CF2
style CORE fill:#fff3e0,stroke:#e65100
style CF1 fill:#e3f2fd,stroke:#1565c0
style CF2 fill:#e8f5e9,stroke:#2e7d32
```
## Knoten-Netzwerkverbindungen
Ein typischer VergeOS-Knoten hat **vier Netzwerkschnittstellen** — zwei für die Core Fabric und zwei für extern:
| NICs | Verbindung | Zweck |
| --------- | ----------------- | ------------------------------------------------------------------ |
| NIC 1 | Core Fabric 1 | Primärer Pfad für den gesamten Verkehr zwischen Knoten |
| NIC 2 | Core Fabric 2 | Redundanter Pfad für den gesamten Verkehr zwischen Knoten |
| NIC 3 + 4 | Externes Netzwerk | Zugriff auf Management-UI/API, Benutzerverkehr, Internetverbindung |
Die tatsächlichen NIC-Gerätenamen variieren je nach Hardware (z. B. `eno1`, `enp3s0f0`, `eth0`). Während der Installation wählen Sie aus, welche physische NIC welcher Rolle zugeordnet wird.
Die externen NICs sind typischerweise **gebündelt** (LACP oder Active-Backup) zur Redundanz. VergeOS unterstützt sowohl switchbasiertes Bonding (LACP) als auch sein eigenes **softwarebasiertes Bonding** — keine Switch-Konfiguration erforderlich. Die beiden Core-Fabric-NICs **dürfen nicht** gebündelt werden — physisches LAG oder Port-Bonding beeinträchtigt die eingebaute Redundanz der Fabric, die eine breitere Palette von Problemen (verlorene Pakete, MTU-Mismatches, NIC-Blockierungen, fehlerhafte Firmware) auf Anwendungsebene erkennt, als LAG es kann. Jede Core-Fabric-NIC verbindet sich mit ihrem eigenen unabhängigen Switch.
```mermaid
graph LR
subgraph "Knoten"
NIC1["NIC 1
Core Fabric 1"]
NIC2["NIC 2
Core Fabric 2"]
NIC3["NIC 3
Extern"]
NIC4["NIC 4
Extern"]
end
NIC1 --- CF1["Core Fabric 1
MTU 9216+"]
NIC2 --- CF2["Core Fabric 2
MTU 9216+"]
NIC3 --- BOND["Bond (LACP / Active-Backup)"]
NIC4 --- BOND
BOND --- EXT["Externes Netzwerk
MTU 1500"]
CF1 -.- CORE["Core-Netzwerk-Overlay"]
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
```
## Trennung von externem Netzwerk und Core Fabric
VergeOS erzwingt eine strikte Trennung zwischen extern gerichtetem Verkehr und internem Clusterverkehr. Dies sind zwei grundlegend unterschiedliche Netzwerkdomänen:
### Externe Netzwerke
* VergeOS mit vorhandener LAN/WAN-Infrastruktur verbinden
* Benutzergerichteten Verkehr übertragen: Zugriff auf die Management-UI, VM-Workload-Konnektivität, Internetzugang
* Standard-MTU (1500) verwenden, sofern Workloads keine Jumbo Frames erfordern
* Als VLAN-Trunks konfiguriert (802.1Q-getaggt), um mehrere VLANs für Tenant- und Workload-Trennung zu unterstützen
* Typischerweise gebündelt (LACP oder Active-Backup) für Redundanz
* Kann mehrere externe Netzwerke pro System geben (z. B. Management-VLAN, Produktions-VLAN, DMZ-VLAN)
### Core-Fabric-Netzwerke
* Vollständig privat — niemals externem Verkehr oder Benutzern ausgesetzt
* Transportieren den gesamten Systemverkehr zwischen den Knoten (vSAN, Migration, Koordination)
* Erfordern Jumbo Frames (MTU 9216+) für Speichereffizienz
* Als Access-Ports konfiguriert (untagged, ein VLAN pro Fabric)
* Immer zwei unabhängige Fabrics für Redundanz
* Müssen zwischen den Knoten null Switch-Hops aufweisen, um geringe Latenz zu gewährleisten
### Das DMZ-Netzwerk
VergeOS erstellt automatisch eine **DMZ-Netzwerk** während der Installation. Die DMZ dient als zentraler Verbindungspunkt für alle virtuellen Netzwerke im System. Jede VergeOS-Cloud (ob Host-System oder Tenant) hat genau ein DMZ-Netzwerk.
Die DMZ bietet **Layer-3-Routing** zwischen Netzwerken. Jeder Netzwerktyp (extern, intern, Core) hat seinen eigenen virtuellen Router mit einer Schnittstelle in seinem eigenen Netzwerk und einer Schnittstelle in der DMZ. Wenn ein internes Netzwerk ein externes Netzwerk erreichen muss, fließt der Verkehr durch die DMZ, wo Netzwerkregeln und Firewall-Richtlinien an der Routing-Grenze angewendet werden.
Die DMZ verwendet den `100.64.0.0/16` Adressbereich. Jeder Router eines virtuellen Netzwerks — externe Netzwerke, interne Netzwerke, das Core-Netzwerk und alle verschachtelten Tenant-Clouds — hat eine DMZ-Schnittstelle, der eine Adresse aus diesem Subnetz zugewiesen wird:
```mermaid
graph TB
ISP["ISP / Upstream-Router"]
EXT["Router des externen Netzwerks
Eth0: externe IP
Eth1/DMZ: 100.64.0.3"]
DMZ["DMZ-Netzwerk
100.64.0.0/16
(Layer-3-Routing-Hub)"]
CORE["Router des Core-Netzwerks
Eth0: 100.96.0.1/24
Eth1/DMZ: 100.64.0.2"]
INT1["Router des internen Netzwerks
Eth0: 192.168.0.1/24
Eth1/DMZ: 100.64.0.4"]
TENANT["Tenant-Netzwerk
(aus Sicht des Hosts)
Eth0: 100.96.0.1/24
Eth1/DMZ: 100.64.0.5"]
VMs
subgraph tenant_inside["Innerhalb des Tenants (sein eigenes VDC)"]
T_EXT["Externer Router des Tenants
Eth0: 100.96.0.2/24
Eth1/DMZ: 100.64.0.3"]
T_DMZ["Tenant-DMZ
100.64.0.0/16"]
T_INT["Interner Router des Tenants
Eth0: 192.168.0.1/24
Eth1/DMZ: 100.64.0.4"]
Tenant-VMs
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
```
Aus Sicht des Hosts erscheint ein Tenant als ein weiteres Netzwerk, das mit der DMZ verbunden ist. Intern verfügt der Tenant über seinen eigenen vollständigen Netzwerk-Stack — seine eigene DMZ, seinen eigenen externen Router, interne Netzwerke und VMs — ein vollständig verschachteltes virtuelles Rechenzentrum.
{% hint style="info" %}
**VMware Bridge**
VergeFabric fasst zusammen, was VMware über vDS-Portgruppen, NSX-T-Segmente und physische Firewall aufteilt: Die Core Fabric ersetzt VMkernel-Gruppen für vSAN/vMotion/Verwaltung, externe Netzwerke ersetzen vDS-Uplinks für VM-Verkehr, das DMZ-Netzwerk ersetzt die Funktionen von NSX-Edge-Router/Firewall und interne Netzwerke ersetzen NSX-T-Segmente mit integriertem DHCP/DNS/Routing/Firewall.
{% endhint %}
{% hint style="info" %}
**Nutanix Bridge**
Nutanix setzt auf Standard-VLANs, das Flow-Add-on für Mikrosegmentierung und externe Appliances für Routing/Firewalling. VergeOS bietet das Äquivalent nativ: Die Core Fabric ersetzt die CVM-Backplane (keine VLAN-Konfiguration), externe Netzwerke ersetzen VLAN-basierte Uplinks, das DMZ-Netzwerk übernimmt Routing/Firewalling und interne Netzwerke bündeln DHCP/DNS/Routing/Firewall.
{% endhint %}
## Modelle für das Produktionsnetzwerkdesign
In der Produktion unterstützt VergeOS mehrere Netzwerkdesign-Modelle, abhängig von der Anzahl der NICs pro Knoten und den Anforderungen des externen Netzwerks. Alle Modelle behalten die doppelte Core Fabric für Redundanz bei.
### 4-NIC-Modell (empfohlen)
Die Standard-Produktionskonfiguration verwendet 4 NICs pro Knoten:
| NIC | Zuordnung | Konfiguration |
| ----- | -------------------------- | --------------------------------------- |
| NIC 1 | Core Fabric 1 | Access-Port, dediziertes VLAN, MTU 9216 |
| NIC 2 | Core Fabric 2 | Access-Port, dediziertes VLAN, MTU 9216 |
| NIC 3 | Extern 1 (primärer Bond) | Trunk-Port, LACP, MTU 1500 |
| NIC 4 | Extern 2 (sekundärer Bond) | Trunk-Port, LACP, MTU 1500 |
Dies bietet vollständige Redundanz sowohl auf der Core Fabric (zwei unabhängige Pfade) als auch im externen Netzwerk (gebündeltes Paar).
### 2-NIC-Modell
Ein 2-NIC-Modell kombiniert Core-Fabric- und externen Verkehr über dieselben physischen Ports mithilfe von VLAN-Tagging:
| NIC | Zuordnung | Konfiguration |
| ----- | ----------------------------- | ----------------------------------------------- |
| NIC 1 | Core Fabric 1 + externe VLANs | Native VLAN für Core, getaggte VLANs für extern |
| NIC 2 | Core Fabric 2 + externe VLANs | Native VLAN für Core, getaggte VLANs für extern |
Dieses Modell eignet sich gut für **100-GbE-Netzwerkports** wo zwei Schnittstellen mit hoher Bandbreite mehr als genug Durchsatz sowohl für die Core Fabric als auch für externen Verkehr bieten. Es eignet sich auch für Edge-Standorte und Proof-of-Concept-Bereitstellungen. In diesem Modell kann VergeOS-Software-Bonding verwendet werden, um die Redundanz des externen Netzwerks über beide NICs hinweg bereitzustellen, während die doppelte Core-Fabric-Redundanz erhalten bleibt.
## Wie der Terraform-Playground dies modelliert
Im Terraform-Playground wird die Core Fabric als zwei `vergeio_network` Ressourcen auf dem Host-VergeOS-System modelliert:
* `core_fabric_1` — Layer-2-Netzwerk, MTU 9142, kein DHCP
* `core_fabric_2` — Layer-2-Netzwerk, MTU 9142, kein DHCP
Jede Knoten-VM erhält drei NICs:
1. **NIC 1** → Externes Netzwerk (Management und Benutzerzugriff)
2. **NIC 2** → Core Fabric 1
3. **NIC 3** → Core Fabric 2
Der Playground verwendet MTU 9142 (anstelle der in der Produktion empfohlenen 9216), da die virtuelle Netzwerkinfrastruktur des Host-Systems zusätzlichen Overhead verursacht. Das Core-Netzwerk-Overlay (`100.96.0.0/24`)
## Wichtige Erkenntnisse
| Konzept | Zusammenfassung |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Core Fabric** | Privates Mesh zwischen den Knoten — transportiert vSAN-, Migrations-, Koordinations- und Kontrollverkehr |
| **Doppelte Redundanz** | Zwei unabhängige Fabric-Netzwerke (Core 1 + Core 2) auf separaten Layer-2-Domänen |
| **MTU-Anforderungen** | 9216+ in der Produktion (9142 im Playground) — Jumbo Frames sind obligatorisch |
| **Core-Netzwerk-Overlay** | Logisch `100.96.0.0/24` Netzwerk, das auf beiden Fabric-Switches aufsetzt und stabile interne IPs bereitstellt |
| **3 NICs pro Knoten** | Minimum: 1 extern + 2 Core Fabric. In der Produktion werden typischerweise 4+ NICs mit gebündeltem externem Netzwerk verwendet |
| **Keine Switch-Hops** | Core-Fabric-Ports müssen sich auf derselben Switching-Fabric befinden — keine Switch-Hops erlaubt |
| **Verkehrsisolation** | Die Core Fabric wird niemals externem Verkehr ausgesetzt; externe Netzwerke sind vollständig getrennt |
| **DMZ-Netzwerk** | Automatisch erstellter Layer-3-Routing-Hub, der alle virtuellen Netzwerke im System verbindet |
## Nächste Schritte
Nachdem Sie nun verstanden haben, wie VergeOS-Knoten miteinander verbunden sind, behandelt das nächste Thema, wie diese Knoten in Cluster organisiert werden: [**Cluster & Knotentypen →**](/learn-the-platform/de/modul-1-architekturgrundlagen/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/de/modul-1-architekturgrundlagen/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.