GNS3-Skalierung für anspruchsvolle Labs

# Horizontale Skalierung von GNS3 für ressourcenintensive Netzwerklabs

GNS3 ermöglicht es, ressourcenintensive Netzwerkknoten über mehrere virtuelle Maschinen mit externen Servern zu verteilen. Dieser Ansatz ist essenziell, um große Topologien mit IOS-XRv9K, CSR1000v und NSO zu simulieren, bei denen eine einzelne VM an vCPU- und RAM-Grenzen stößt. Der Autor beschreibt den Wechsel von einem Laptop (8 vCPU, 16 GB) zu einem auf Workstation basierenden VM-Cluster mit insgesamt 64 vCPU und 200 GB RAM.

Vergleich von Simulatoren und Anwendungsfällen

Unter den Tools für Netzwerklabs heben sich EVE-NG, PNETLab, GNS3 und containerlab hervor. GNS3 punktet bei der horizontalen Skalierung: Knoten werden über VMs verteilt, ohne manuelle Cloud-Einrichtung wie bei EVE-NG.

Wichtige Anwendungsfälle:

• Studium von Protokollen wie LISP, BGP und OSPF.
• Vorbereitung auf Prüfungen mit vendorspezifischen Images (IOS-XRv9K benötigt 4 vCPU pro Knoten).
• Proof of Concept vor der Bereitstellung.

Für Cisco SP-Labs (bis zu 50 Knoten) stürzen Standard-Simulatoren mit 8+ IOS-XRv9K ab: Einfrieren, Neustarts. Rechnung: 50 × 4 vCPU = 200 vCPU, unmöglich auf einer Maschine.

Ressourcenintensive Images und Container-Optimierung

IOS-XRv9K (4 vCPU, hoher RAM-Verbrauch) kann durch IOS-XRd ersetzt werden – eine containerisierte Steuerebenen-Version (1 vCPU, 2 GB RAM, Start in 30 Sekunden). Das reduziert die Last, behält aber die Funktionalität.

Hardware des Autors:

• SuperMicro X10DRL-i Server: 80 vCPU, 256 GB RAM, 2 NUMA-Knoten.
• OS: Windows 10 Pro (Gaming-Last), Workstation (Limit 32 vCPU/128 GB pro VM).
• 3 GNS3-VMs: Isolierung von IOS-XRv9K und CSR1000v.

GNS3-Architektur mit externen Servern

GNS3 umfasst Controller, GNS3 GUI/Web und Compute Nodes (VMs mit Docker/QEMU). Compute Nodes auf dem Desktop, Controller auf dem Laptop, verbunden über LAN.

Vorteile:

• Automatische Traffic-Weiterleitung zwischen VMs.
• Überwachung von CPU/RAM-Last über Server hinweg.
• Verteilung von Images über VMs für Ausgewogenheit.

Einschränkungen von GNS3 2.2.46

Trotz der Vorteile treten Probleme auf:

• Topologie lässt sich nicht öffnen – Hub in der .gns3-Datei löschen.
• ioll2-xe-17-12-01 startet nicht.
• Calvados AUX-Fehler in XRv9K (nicht kritisch).
• Speichern von Docker-Konfigs erfordert Volume-Einrichtung.
• Interface-Änderungen: Links trennen, bearbeiten, neu verbinden.

Schritt-für-Schritt-Einrichtung der Skalierung

• Planung: VMs nach NUMA zuweisen (mindestens 2–3), Ressourcen (64 vCPU, 200 GB). Knotentypen isolieren.

• Vorbereitung der GNS3-VMs:

- OVA herunterladen, statische IP setzen (Network → config).

- Port (Configure → config).

• Server hinzufügen: Edit → Preferences → Remote Servers → Add (IP, Name, keine Auth für LAN).

• Images: Spezifischen VMs zuweisen (duplizieren für Verteilung).

• Topologie: GNS3 übernimmt die Konnektivität automatisch.

Überwachung: Servers Summary zeigt Last an.

Wichtige Erkenntnisse

• IOS-XRd für Steuerebene nutzen: 1 vCPU/2 GB vs. 4 vCPU für XRv9K.
• Über 3+ VMs verteilen für 40–60 Knoten ohne Abstürze.
• Workstation-Limit: 32 vCPU/128 GB pro VM (NUMA).
• Docker-Volumes für persistente Konfigs.
• GNS3 > EVE-NG für Multi-VM ohne Clouds.

Das skaliert Labs auf Prüfungs-Niveau und umgeht Hardware-Limits, ohne Server zu mieten.

— Editorial Team