Site icon bintorosoft.com

19.2 GNS3 oder EVE-NG für CCNA-Labs einrichten

Red Snapper

Computer technology 3D illustration. Computation of big data center. Cloud computing. Online devices upload and download information. Modern 3D illustration. 3D rendering

Für CCNA-Labs sind GNS3 und EVE-NG zwei der wichtigsten Plattformen, weil sie Routing, Switching, VLANs, DHCP, NAT, ACLs und grundlegendes Troubleshooting realitätsnah abbilden können. Der Unterschied liegt vor allem im Betriebsmodell: GNS3 eignet sich sehr gut für lokale Einzelplatz-Labs auf dem eigenen Rechner, während EVE-NG stärker als zentrale, browserbasierte Lab-Umgebung gedacht ist. Wer die Plattform sauber einrichtet, spart später viel Zeit bei Image-Import, Konsolenzugriff, Ressourcenzuteilung und Fehlersuche. Für ein stabiles CCNA-Lab ist deshalb nicht nur die Wahl des Emulators wichtig, sondern auch die saubere Vorbereitung von Virtualisierung, Images, Netzwerkanbindung und Testtopologie. :contentReference[oaicite:0]{index=0}

Wann GNS3 und wann EVE-NG sinnvoll ist

Für klassische CCNA-Übungen mit einigen Routern, Switches und Hosts ist GNS3 auf einem leistungsfähigen Notebook oder Desktop oft der schnellste Einstieg. Die offizielle GNS3-Dokumentation empfiehlt auf Windows und macOS in den meisten Fällen die GNS3-VM, weil fortgeschrittene Topologien und QEMU-basierte Geräte dort robuster laufen als ein reiner Local-Server-Betrieb. Ein lokaler Dynamips-Start ohne VM ist zwar möglich, aber funktional eingeschränkter und eher für sehr einfache Labs geeignet. :contentReference[oaicite:1]{index=1}

EVE-NG spielt seine Stärken aus, wenn Labs zentral auf einer VM oder einem Server laufen sollen und die Bedienung über Weboberfläche erfolgen soll. Für Lernende ist das attraktiv, wenn mehrere Labs verwaltet, browserbasiert geöffnet und später leicht erweitert werden sollen. EVE-NG dokumentiert seine Plattform als VM- oder Bare-Metal-Deployment mit separaten Bereichen für Systemanforderungen, Installation, unterstützte Images und Web-UI-Funktionen. :contentReference[oaicite:2]{index=2}

Praktische Entscheidung für CCNA-Labs

Für ein typisches CCNA-Lab mit wenigen Routern, einem Layer-2-Switch und Endgeräten ist deshalb GNS3 häufig der einfachere Start. Wer dagegen von Anfang an eine serverartige Lab-Umgebung möchte, fährt mit EVE-NG sauberer. :contentReference[oaicite:3]{index=3}

Hardware, Virtualisierung und Basis-Vorbereitung

Bevor du GNS3 oder EVE-NG installierst, muss die Host-Plattform stimmen. GNS3 nennt für eine kleine Windows-Umgebung als empfohlene Basis unter anderem 4 logische Kerne, aktivierte Virtualisierungserweiterungen, 16 GB RAM und SSD-Speicher; für komplexere Umgebungen steigen die Empfehlungen auf 8 oder mehr logische Kerne, 32 GB RAM und mehr Speicherplatz. Für GNS3-VM-Setups nennt die Dokumentation als praktische Orientierung, bei einem Desktop mit 32 GB RAM etwa 4 bis 6 vCPUs und 16 GB RAM an die VM zu geben. :contentReference[oaicite:4]{index=4}

Was du vor der Installation prüfen solltest

Gerade bei CCNA-Labs ist weniger oft mehr: Statt sofort zehn Knoten zu starten, sollte die erste Topologie bewusst klein bleiben. Das reduziert CPU-Spitzen, vereinfacht das Troubleshooting und macht Fehler bei Image-Zuordnung oder Interface-Mapping schneller sichtbar. :contentReference[oaicite:5]{index=5}

GNS3 für CCNA-Labs Schritt für Schritt einrichten

GNS3 All-in-One und GNS3-VM vorbereiten

Der saubere Standard auf Windows und macOS ist: zuerst den GNS3-Client installieren, danach die GNS3-VM importieren und anschließend den Client mit der VM koppeln. Laut offizieller Dokumentation ist die GNS3-VM für QEMU-basierte Geräte auf Windows und macOS notwendig oder zumindest klar empfohlen; ohne VM bleibt der Einsatz auf einfache Local-Server-Szenarien begrenzt. :contentReference[oaicite:6]{index=6}

Für kleine Einstiegs-Labs kann GNS3 zunächst auch ohne VM gestartet werden. Sobald jedoch IOSv, IOSvL2, ASAv oder allgemein QEMU-basierte Appliances genutzt werden sollen, ist die GNS3-VM die richtige Betriebsart. Genau das ist für realistische CCNA-Labs mit virtuellen Cisco-Routern und -Switches in der Praxis entscheidend. :contentReference[oaicite:7]{index=7}

Erste GNS3-Topologie sauber aufbauen

Nach dem ersten Start sollte nicht sofort eine große Topologie entstehen. Für CCNA reicht als Funktionstest eine kleine Umgebung mit zwei Routern, einem Layer-2-Switch und zwei Hosts oder VPCS-Instanzen. Damit lassen sich IP-Adressierung, VLAN-Zuordnung, Default Gateway und Ping-Tests direkt validieren.

show ip interface brief
show vlan brief
show ip route
ping 192.168.10.1
ping 192.168.20.1

Mit dieser Minimal-Topologie lässt sich sehr schnell prüfen, ob Images korrekt booten, Konsolen funktionieren und das Projekt sauber speichert. Erst danach sollten DHCP, OSPF oder Router-on-a-Stick ergänzt werden.

Wichtige GNS3-Fehler am Anfang

Wenn ein Projekt instabil wirkt, liegt die Ursache in der Anfangsphase meist nicht an Cisco selbst, sondern an Host-Ressourcen, Hypervisor-Einstellungen oder einer falschen Trennung zwischen Local Server und GNS3-VM. :contentReference[oaicite:8]{index=8}

EVE-NG für CCNA-Labs Schritt für Schritt einrichten

EVE-NG als VM oder Bare Metal bereitstellen

EVE-NG ist von der Architektur her stärker serverorientiert. In der offiziellen Dokumentation sind Installation, Systemanforderungen und spätere Web-UI-Nutzung als zusammenhängender Betriebsweg beschrieben. Für CCNA-Labs ist der einfachste Start meist eine einzelne EVE-NG-VM auf VMware Workstation oder einem anderen Hypervisor, die danach per Browser verwaltet wird. :contentReference[oaicite:9]{index=9}

Wichtig ist, EVE-NG nicht wie eine normale Desktop-App zu betrachten. Die eigentliche Arbeit läuft in der VM, die Bedienung im Browser. Das ist für Lernende angenehm, verlangt aber saubere Hypervisor- und Netzwerkkonfiguration von Anfang an. :contentReference[oaicite:10]{index=10}

Client-Zugriff und Konsolen unter EVE-NG vorbereiten

Für EVE-NG ist der Konsolenzugriff ein wichtiger Teil des Setups. Die offizielle Download-Seite stellt dafür Client-Pakete bereit, die unter Windows und macOS unter anderem Telnet-, VNC- und Wireshark-Komponenten samt Wrappers installieren. Für Wireshark-Capture weist EVE-NG zusätzlich darauf hin, dass bei der ersten Nutzung eine Host-Key-Bestätigung und Authentifizierung erforderlich sein kann. :contentReference[oaicite:11]{index=11}

Gerade für CCNA-Labs ist dieser Schritt wichtig, weil viele Anfänger die VM zwar hochfahren, später aber an Telnet, VNC oder Capture scheitern. Die eigentliche Lab-Funktion steht und fällt dann nicht mit dem Image, sondern mit der lokalen Integration des Konsolenzugriffs. :contentReference[oaicite:12]{index=12}

Images in EVE-NG korrekt ablegen

EVE-NG liefert keine urheberrechtlich geschützten Hersteller-Images mit. Die offizielle Dokumentation sagt ausdrücklich, dass nur beschrieben wird, wie eigene, legal bezogene Images vorbereitet werden. Für Cisco-vIOS verweist EVE-NG direkt auf Cisco CML als Bezugsquelle; Cisco dokumentiert dort aktuelle Referenzplattformen und Images wie IOSv, IOL und IOL L2. :contentReference[oaicite:13]{index=13}

Für ein typisches Cisco-vIOS-Setup unter EVE-NG sehen die Grundschritte so aus:

mkdir /opt/unetlab/addons/qemu/vios-15.9
cd /opt/unetlab/addons/qemu/vios-15.9
mv vios-adventerprisek9-m.spa.159-3.m6.qcow2 virtioa.qcow2
/opt/unetlab/wrappers/unl_wrapper -a fixpermissions

Für vIOS-L2 ist das Muster identisch, nur mit einem Ordnernamen, der mit viosl2- beginnt. Der Befehl fixpermissions gehört zu den wichtigsten EVE-NG-Setupschritten, weil fehlerhafte Rechte später zu scheinbar unlogischen Boot- oder Startproblemen führen. :contentReference[oaicite:14]{index=14}

Das Image-Thema rechtlich und technisch sauber lösen

Bei CCNA-Labs ist nicht die Emulator-Software das eigentliche Lizenzthema, sondern die Images. Weder EVE-NG noch GNS3 liefern pauschal aktuelle, urheberrechtlich geschützte Cisco-Produktimages mit. Für EVE-NG nennt die Dokumentation Cisco CML ausdrücklich als Bezugsquelle für aktuelle vIOS-Images, und Cisco listet in der CML-Referenzplattform-Dokumentation aktuelle virtuelle Plattformen wie IOSv, IOL, IOL L2, CSR1000v oder CAT8000v auf. Das ist für Lernende der sauberste Weg, legal an passende Cisco-Lab-Images zu kommen. :contentReference[oaicite:15]{index=15}

Für CCNA besonders sinnvolle Knotentypen

Für CCNA müssen es nicht sofort große Security- oder Data-Center-Images sein. Kleine Routing- und Switching-Images booten schneller, verbrauchen weniger RAM und decken das Kerncurriculum sauber ab. :contentReference[oaicite:16]{index=16}

Das erste CCNA-Lab in GNS3 oder EVE-NG aufbauen

Empfohlene Minimal-Topologie

Mit dieser Topologie lassen sich fast alle frühen CCNA-Themen abdecken: Subnetting, Interface-Adressierung, statisches Routing, VLANs, Trunks, Default Gateway und Ping-basierte Verifikation. Der Schlüssel liegt darin, das Lab zuerst stabil lauffähig zu bekommen und erst danach Funktionen zu stapeln. Das gilt unabhängig davon, ob die Plattform GNS3 oder EVE-NG ist.

show ip interface brief
show interfaces trunk
show vlan brief
show ip route
ping 10.10.10.2
ping 10.20.20.2

Saubere Reihenfolge beim Aufbau

Diese Reihenfolge verhindert, dass mehrere Fehler gleichzeitig entstehen. Gerade in virtuellen Labs ist das wichtig, weil sonst nicht mehr klar ist, ob ein Problem vom Emulator, vom Image, von der Topologie oder von der Cisco-Konfiguration verursacht wird.

Typische Setup-Fehler und ihre Behebung

GNS3-Probleme

Wenn GNS3 auf Windows oder macOS mit IOSv oder IOSvL2 arbeiten soll, ist die Frage „mit VM oder ohne VM“ keine Nebensache, sondern ein Kernpunkt des Designs. Genau dafür empfiehlt die offizielle Dokumentation die GNS3-VM in den meisten praktischen Szenarien. :contentReference[oaicite:17]{index=17}

EVE-NG-Probleme

Bei EVE-NG hängen die meisten Startprobleme am Anfang nicht an Cisco-Kommandos, sondern an Image-Ablage, Berechtigungen und Client-Integration. Wer Upload-Pfad, Dateiname und fixpermissions sauber abarbeitet, vermeidet den größten Teil dieser Fehlerklasse. :contentReference[oaicite:18]{index=18}

::contentReference[oaicite:19]{index=19}

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.

Exit mobile version