Cisco Konfiguration speichern: running-config vs. startup-config

Wer Cisco-Router oder Cisco-Switches administriert, kommt an einem Thema nicht vorbei: Konfigurationen müssen zuverlässig gespeichert werden. Genau hier passieren im Alltag besonders viele, vermeidbare Fehler. Das wichtigste Stichwort lautet Cisco Konfiguration speichern – und damit verbunden die Unterscheidung zwischen running-config und startup-config. Viele Einsteiger ändern eine Einstellung, testen kurz, alles funktioniert – und nach einem Neustart ist die gesamte Arbeit verschwunden. Der Grund ist simpel: Die laufende Konfiguration (running-config) befindet sich im Arbeitsspeicher und wird nicht automatisch dauerhaft gesichert. Erst wenn Sie die Konfiguration in die Startkonfiguration (startup-config) schreiben, bleibt sie nach einem Reload erhalten. In diesem Artikel erfahren Sie verständlich, wie Cisco die Konfigurationsspeicherung organisiert, welche Befehle Sie im Alltag wirklich brauchen, welche Stolperfallen typisch sind und wie Sie Änderungen professionell absichern. Dazu gehören auch Best Practices wie kontrollierte Änderungen, differenzierte Prüfkommandos, saubere Backups und ein Vorgehen, das Sie vor unangenehmen Überraschungen schützt – egal ob im Lab, im kleinen Firmennetz oder in größeren Umgebungen.

Table of Contents

Grundlagen: Was bedeuten running-config und startup-config?

Auf Cisco-Geräten existieren typischerweise mindestens zwei zentrale Konfigurationsstände:

  • running-config: Die aktuell aktive Konfiguration. Sie wird im RAM (Arbeitsspeicher) gehalten und steuert sofort das Verhalten des Geräts.
  • startup-config: Die Konfiguration, die beim Booten geladen wird. Sie liegt in einem nichtflüchtigen Speicher (typisch NVRAM oder ein vergleichbarer persistenter Speicher, je nach Plattform).

Das entscheidende Praxisprinzip lautet: Änderungen in der running-config wirken sofort, sind aber ohne explizites Speichern nach einem Neustart weg. Die startup-config ist Ihr „sicherer Stand“, der beim nächsten Reload geladen wird.

Warum Cisco diese Trennung nutzt

Die Trennung hat einen sehr praktischen Zweck: Sie können Änderungen testen, ohne sie sofort dauerhaft zu übernehmen. Das ist besonders wertvoll, wenn Sie Konfigurationen schrittweise anpassen, Fehler schnell zurückrollen oder in Wartungsfenstern arbeiten. Im Labor ist es angenehm, im Betrieb ist es oft essenziell.

Wo liegen die Konfigurationen – und was passiert beim Booten?

Vereinfacht läuft der Ablauf beim Start eines Cisco-Geräts so ab:

  • Das Gerät bootet das Betriebssystem (Cisco IOS oder IOS XE, abhängig von der Plattform).
  • Es versucht, die startup-config aus dem persistenten Speicher zu laden.
  • Die geladene startup-config wird zur running-config und ist ab diesem Moment aktiv.

Wenn keine startup-config vorhanden ist (zum Beispiel nach einem Factory Reset), startet das Gerät mit einem minimierten Grundzustand. In vielen Fällen erscheint dann ein Setup-Dialog oder das Gerät wartet auf manuelle Konfiguration.

Wichtige Begriffe im Speicher-Kontext

  • RAM: flüchtig, verliert Inhalte bei Neustart oder Stromausfall.
  • NVRAM / Flash: nichtflüchtig, bleibt bei Neustart erhalten (Bezeichnungen können je nach Plattform variieren).
  • running-config: aktiv im RAM.
  • startup-config: persistent gespeichert, beim Booten geladen.

Wenn Sie Plattformdetails oder Befehlsvarianten nachschlagen möchten, ist der Anchor-Text Cisco IOS Command Reference eine zuverlässige Anlaufstelle.

Die wichtigsten Befehle: Anzeigen, vergleichen, speichern

Im Alltag brauchen Sie vor allem drei Fähigkeiten: running-config anzeigen, startup-config anzeigen und die running-config in die startup-config speichern.

running-config anzeigen

show running-config

startup-config anzeigen

show startup-config

running-config dauerhaft speichern

Der Standardbefehl lautet:

copy running-config startup-config

Viele Administratoren nutzen außerdem die Kurzform:

write memory

Beide Befehle verfolgen das gleiche Ziel: Die aktuelle running-config wird in den persistenten Speicher geschrieben und steht beim nächsten Boot als startup-config zur Verfügung.

Schnelle Kontrolle, ob gespeichert wurde

Nach dem Speichern ist es sinnvoll, die startup-config kurz zu prüfen:

show startup-config

Alternativ können Sie gezielt nach einer gerade geänderten Zeile suchen, zum Beispiel mit Filter:

show startup-config | include hostname

Typische Alltagsszenarien: Wann welche Konfiguration zählt

Die Unterscheidung klingt theoretisch, ist aber in der Praxis ständig relevant. Einige typische Situationen:

Sie ändern ein Interface und testen sofort

Wenn Sie ein Interface konfigurieren, ändern Sie die running-config. Der Effekt ist sofort sichtbar:

configure terminal
interface gigabitethernet0/0
description Uplink
no shutdown

Wenn Sie jetzt neu starten, ist die Änderung nur dann dauerhaft, wenn Sie gespeichert haben.

Sie verlieren nach einem Reload die Konfiguration

Das passiert, wenn die Änderungen in der running-config nicht in die startup-config geschrieben wurden. Im Betrieb ist das kritisch, weil ein ungeplanter Stromausfall denselben Effekt haben kann wie ein Neustart.

Sie testen eine Änderung bewusst ohne Speichern

Das ist ein legitimes Vorgehen: Sie probieren eine Anpassung aus, prüfen das Verhalten und verwerfen sie später wieder – entweder durch Rücknahme der Konfig oder durch einen Reload ohne Speichern (je nach Prozess). Wichtig ist, dass Sie das absichtlich tun und nicht aus Versehen.

Best Practice: Erst verifizieren, dann speichern

Ein professioneller Workflow speichert nicht blind „nach jedem Tastendruck“, sondern nach einem kurzen Plausibilitätscheck. Bewährt hat sich diese Reihenfolge:

  • Änderung vornehmen (möglichst in kleinen, klaren Schritten).
  • Relevante Statusprüfung mit show-Befehlen durchführen.
  • Wenn das Ergebnis korrekt ist: speichern.
  • Optional: Konfig-Backup extern ablegen.

Prüfkommandos, die fast immer passen

  • show ip interface brief (Interface-Status und IPs)
  • show running-config | section interface (Interface-Abschnitte prüfen)
  • show ip route (Routing prüfen)
  • show logging (Hinweise in Logs)

Gerade auf Switches kommen häufig dazu:

  • show vlan brief
  • show interfaces trunk
  • show spanning-tree

Stolperfallen: Warum das Speichern trotz „copy run start“ manchmal nicht klappt

In der Praxis gibt es einige typische Gründe, warum Konfigurationen nicht wie erwartet persistent werden.

Sie speichern, aber auf dem falschen Gerät

In Multi-Session-Umgebungen (Jump Hosts, mehrere Tabs, viele Geräte) ist das häufig. Ein eindeutiger Hostname hilft, Fehler zu vermeiden. Prüfen Sie vor dem Speichern kurz:

show running-config | include hostname

Sie speichern nicht, weil der Prompt nicht offensichtlich ist

Viele Administratoren glauben, sie hätten gespeichert, weil sie „aus dem Konfigmodus raus“ sind. Aber end oder Ctrl+Z speichert nicht. Nur ein explizites copy running-config startup-config (oder Äquivalent) schreibt dauerhaft.

Schreibschutz oder Speicherprobleme

In seltenen Fällen verhindern Speicherprobleme das Schreiben. Dann sehen Sie oft Fehlermeldungen. Prüfen Sie im Zweifel, ob die startup-config wirklich die neue Zeile enthält, und kontrollieren Sie den verfügbaren Speicher (plattformabhängig). Bei anhaltenden Problemen ist die herstellerseitige Dokumentation der beste Bezugspunkt, zum Beispiel über den Anchor-Text Cisco Support.

Konfigurationsänderungen durch externe Systeme

In professionellen Umgebungen können Änderungen auch durch Automatisierung oder zentrale Systeme erfolgen (z. B. Konfig-Management). Das ist grundsätzlich sinnvoll, kann aber verwirren, wenn parallel manuell gearbeitet wird. Best Practice ist ein klarer Prozess: Wer ändert was, wann, und wie werden Änderungen versioniert?

running-config und startup-config vergleichen: Unterschiede schnell erkennen

Gerade nach Änderungen ist es hilfreich zu wissen, ob running-config und startup-config noch auseinanderlaufen. Je nach Plattform und Feature-Set gibt es unterschiedliche Möglichkeiten. Eine einfache, robuste Methode ist, gezielt die relevanten Abschnitte beider Konfigurationen anzusehen und zu vergleichen.

Gezielt prüfen statt alles lesen

Nutzen Sie Filter, um nur das zu sehen, was Sie interessiert:

show running-config | section line vty
show startup-config | section line vty

Oder für SSH-Einstellungen:

show running-config | include ip ssh|ip domain-name
show startup-config | include ip ssh|ip domain-name

So erkennen Sie schnell, ob die Änderungen bereits persistiert wurden.

Konfigurations-Backups: Warum Speichern allein nicht reicht

Das Speichern in die startup-config schützt vor dem Verlust durch Neustart, aber nicht vor Bedienfehlern, Hardwaredefekten oder ungewollten Änderungen. Für einen stabilen Betrieb sollten Sie zusätzlich externe Backups einplanen. Typische Methoden sind:

  • Backup auf einen Server (z. B. via SCP/SFTP, je nach Gerät)
  • Versionierung in einem Repository (Konfig als Textdatei)
  • Zentrales Netzwerkmanagement/Automatisierung mit Change-Historie

Wenn Sie sichere Übertragungswege statt unsicherer Protokolle nutzen möchten, bietet der Anchor-Text Cisco Secure Copy (SCP) / SFTP hilfreiche Hintergrundinformationen.

Praktische Routine für ein manuelles Backup

Auch ohne großes Tooling können Sie ein einfaches Vorgehen etablieren:

  • Vor der Änderung: aktuellen Stand sichern (Text-Export der running-config).
  • Änderung durchführen und testen.
  • Nach der Änderung: running-config speichern und erneut exportieren.
  • Beide Stände versioniert ablegen (Datum, Ticket, Kurzbeschreibung).

Konfiguration sicher ändern: „Rollback“-Denken mit Cisco-CLI-Grundlagen

Ein weiterer Grund für die Trennung zwischen running-config und startup-config ist die Möglichkeit, Änderungen kontrolliert zu testen. Gleichzeitig sollten Sie ein „Rollback“-Mindset entwickeln: Was tun Sie, wenn die Änderung unerwartete Effekte hat?

Änderungen mit „no“ rückgängig machen

Viele Konfigurationszeilen lassen sich mit no entfernen. Beispiel:

no ip ssh version 2

Oder eine Route entfernen:

no ip route 0.0.0.0 0.0.0.0 203.0.113.1

Das ist besonders dann hilfreich, wenn Sie die Änderung sofort zurücknehmen möchten, ohne einen Neustart zu riskieren.

Warum ein Reload ohne Speichern riskant sein kann

In produktiven Umgebungen ist „reload ohne Speichern“ selten die richtige Lösung, weil ein Neustart selbst Auswirkungen hat (Downtime, Nachbarschaften, Tunnel, Routing-Konvergenz). Besser ist es, Änderungen sauber zurückzunehmen und dabei die Services aktiv zu beobachten.

Speichern im Alltag: Welche Befehle sich bewährt haben

Für den täglichen Betrieb hat sich ein kleines Set an Kommandos etabliert, das Sie nahezu immer brauchen:

  • show running-config (aktueller Stand)
  • show startup-config (persistenter Stand)
  • copy running-config startup-config (dauerhaft speichern)
  • show running-config | include <TEXT> (gezielt prüfen)
  • show startup-config | include <TEXT> (gezielt prüfen)

Wenn Sie in Konfigurationsmodi sind und schnell prüfen möchten, hilft häufig der do-Befehl:

do show ip interface brief

Praxisbeispiel: Eine kleine Änderung – und wie Sie sie sauber persistieren

Angenommen, Sie wollen den SSH-Zugriff auf einem Gerät absichern und konfigurieren eine VTY-Line. Typischer Ablauf:

configure terminal
line vty 0 4
login local
transport input ssh
exec-timeout 10 0
end

Jetzt prüfen Sie, ob die Konfiguration in der running-config korrekt steht:

show running-config | section line vty

Wenn alles passt, speichern Sie:

copy running-config startup-config

Und kontrollieren anschließend kurz, ob die startup-config die Änderung enthält:

show startup-config | section line vty

Checkliste: Cisco Konfiguration speichern ohne Überraschungen

  • Vor Änderungen: kurz Gerät/Hostname prüfen.
  • Änderungen in kleinen Blöcken durchführen.
  • Nach jedem Block verifizieren (Show-Befehle).
  • Erst nach erfolgreichem Test: copy running-config startup-config.
  • Startup-config stichprobenartig prüfen (Filter nutzen).
  • Zusätzlich externes Backup erstellen, wenn es produktiv ist.
  • Änderung dokumentieren (Ticket, Datum, Zweck).

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

  • Netzwerkdesign & Topologie-Planung

  • Router- & Switch-Konfiguration (Cisco IOS)

  • VLAN, Inter-VLAN Routing

  • OSPF, RIP, EIGRP (Grundlagen & Implementierung)

  • NAT, ACL, DHCP, DNS-Konfiguration

  • Troubleshooting & Netzwerkoptimierung

  • Packet Tracer Projektentwicklung & Dokumentation

  • CCNA Lern- & Praxisunterstützung

Lieferumfang:

  • Konfigurationsdateien

  • Packet-Tracer-Dateien (.pkt)

  • Netzwerkdokumentation

  • Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Related Articles