cisco-iosxe-mcp

Ein MCP-Server, der Cisco IOS-XE-Geräte als Werkzeuge bereitstellt, die ein LLM-Client aufrufen kann. Benannte operative Lesevorgänge sowie ein Konfigurationsänderungspfad, der die genaue Befehlsliste anzeigt, sie unter configure terminal revert timer anwendet, überprüft, ob das Gerät in einer neuen Sitzung noch antwortet, und erst dann bestätigt.

Es kommuniziert über MCP per Streamable HTTP, läuft also als eigener Dienst im Netzwerk und nicht als lokaler Unterprozess eines Clients. Der Transport zum Gerät erfolgt über die IOS-XE-CLI per SSH, mittels scrapli.

Entwickelt für universal-network-director, einen chatgesteuerten Multi-Vendor-Netzwerkmanager mit einer menschlichen Genehmigungshürde für jeden Schreibvorgang – aber es ist ein eigenständiger MCP-Server und funktioniert mit jedem MCP-Client.

Nicht verbunden mit, unterstützt von oder empfohlen durch Cisco Systems, Inc. „Cisco“ und „IOS-XE“ sind Marken der jeweiligen Inhaber und werden hier nur zur Beschreibung der Kommunikationspartner dieser Software verwendet.

Das Sicherheitsmodell

Zweistufig, gleiche Form wie der Junos-Pfad – mit einem ehrlichen Unterschied, den Sie verstehen müssen, bevor Sie es nutzen.

Schritt 1 – Vorschau zeigt die Befehlsliste, keinen Diff

preview_config_change gibt die genauen Befehle zurück, die gesendet würden, das Gerät, an das sie gehen, und den aktuellen Zustand der Zeilen, die sie berühren. Sie genehmigen das.

Dies ist schwächer als ein Junos show | compare. Junos lädt eine Kandidatenkonfiguration und das Gerät berechnet den echten Diff; IOS-XE hat keine Kandidatenkonfiguration, daher gibt es nichts, um das Gerät nach einem Diff zu fragen. Die Vorschau hier ist die Änderung wie geschrieben, abgeglichen mit dem aktuell Konfigurierten – nicht die eigene Darstellung des Geräts, was das Ergebnis wäre. Lesen Sie die Befehle, nicht nur die Zusammenfassung.

Schritt 2 – Anwenden unter einem Revert-Timer

write_apply_config_block akzeptiert nur eine Vorschau-ID – es kann nichts anwenden, das nicht vorher in der Vorschau war. Die Befehle werden unter configure terminal revert timer <n> eingegeben: sofort wirksam, aber IOS-XE macht die Konfiguration automatisch rückgängig, es sei denn, ein configure confirm trifft rechtzeitig ein. Dieser Server verbindet sich dann in einer neuen SSH-Sitzung erneut, um nachzuweisen, dass das Gerät noch erreichbar ist, und bestätigt nur, wenn dies der Fall ist. Schließen Sie sich selbst aus, macht die Box die Änderung rückgängig.

Gerätevoraussetzung, die Junos nicht hat: Die IOS-archive- Funktion muss konfiguriert sein (archive / path ...) oder der Revert-Timer hat keinen Rollback-Punkt und das Sicherheitsnetz ist stillschweigend nicht vorhanden. get_archive_status meldet dies pro Gerät, und write_apply_config_block lehnt ab, wenn es fehlt, anstatt ungeschützt anzuwenden.

Es gibt bewusst kein freiformatiges Befehlswerkzeug. Jeder operative Lesevorgang führt einen Befehl aus, der aus einer festen Vorlage plus validierten Argumenten besteht. Die eine Stelle, an der das Modell frei Text zusammenstellt – ein Konfigurationsblock – ist abgesperrt, wird einem Menschen wörtlich gezeigt und unter dem Revert-Timer angewendet.

Related MCP server: Itential MCP Server

Lesen Sie dies, bevor Sie es auf die Produktion richten

Drei der neunzehn Werkzeuge ändern den Zustand, und dieser Server fragt nicht vor der Ausführung. Das Präfix write_ ist eine Konvention, damit Ihr Client sie absperrn kann.

Beachten Sie die Asymmetrie, die das Präfix kodiert: write_ bedeutet „Ein Mensch muss dies genehmigen“, nicht „dies bearbeitet die Konfiguration“. write_save_config fügt überhaupt keine Konfiguration hinzu und ist abgesperrt, weil das Dauerhaftmachen einer Änderung eine Entscheidung ist, die jemand bewusst treffen sollte.

cancel_reload ist bewusst nicht abgesperrt – es ist eine Wiederherstellungsaktion, und das Erfordern einer Genehmigungsrunde, um einen anstehenden Neustart zu stoppen, ist der falsche Kompromiss.

Schränken Sie das Gerätekonto auf schreibgeschützt ein, es sei denn, Sie beabsichtigen spezifisch, dass die Schreibvorgänge funktionieren. Diese Kontrolle lebt auf dem Gerät, nicht in diesem Code.

Der MCP-Endpoint hat keine Authentifizierung

Dieser Server stellt seine Werkzeuge jedem zur Verfügung, der seinen Port erreichen kann. Es gibt kein Token, keine Client-Authentifizierung, kein TLS auf der MCP-Seite.

MCP_HOST standardmäßig aus diesem Grund auf 127.0.0.1. Das Container-Image setzt 0.0.0.0, weil es muss, was bedeutet, dass das Veröffentlichen des Container-Ports einen uneingeschränkten Pfad zu Ihren Routern auf diesem Interface freigibt. Halten Sie es in einem internen Netzwerk mit dem Client oder terminieren Sie TLS und Authentication davor.

Geräteinventar

Geräte-Anmeldedaten liegen in einer JSON-Datei, die schreibgeschützt in den Container eingebunden ist – nie im Image, nie eingecheckt. Sie enthält Klartext-SSH-Anmeldedaten, also chmod 600 drauf und besitzen Sie als die UID, unter der der Container läuft.

Gleiche Form wie das Junos-Gateway-Inventar, also ein Format zum Lernen, plus ein optionales enable_password:

{
  "csr-lab": {
    "ip": "192.0.2.53",
    "port": 22,
    "username": "automation",
    "auth": { "type": "password", "password": "..." }
  }
}

enable_password wird nur gelesen, wenn ein Gerät es tatsächlich benögt – ein Konto, das bereits Privileg 15 hat, landet bei # und benögt keine sekundäre Eskalation. .

Verwenden Sie eine andere Datei als die des Junos-Gateway. Getrennte Container mit getrennten Anmeldedaten sind der Grund, warum die Server überhapt getrennt sind: Ein Bug in diesem kann icht Ihre Firewals erreichen.

Container-UID. Das Image erstellt bewusst einen passwd-Eintrag für UID 1000. scraplis system-Transport führt das ssh-Binär aus, und OpenSSH weigert sich zu laufen, wenn die aufrufende UID keinen /etc/passwd-Eintrag hat – das Symptom ist ein irreführendes „EOF reading from transport“ anstatt etwas, das die Ursache benennt.

Ausführung

docker build -t cisco-iosxe-mcp .
docker run --rm \
  -v "$PWD/secrets/devices.json:/app/config/devices.json:ro" \
  --user 1000:1000 \
  -p 127.0.0.1:8004:8004 \
  cisco-iosxe-mcp

Tests

docker run --rm cisco-iosxe-mcp python test_arg_validation.py
docker run --rm cisco-iosxe-mcp python test_reload.py

Beide sind offline – kein Gerätekontakt, keine Anmeldedaten erforderlich. test_reload.py wiederholt die exakten Bytes, die ein echtes IOS-XE-Gerät für reload in 5, reload cancel und die Bestätigungsaufforderungen gesendet hat, einschließlich des Falls, dass die Speicherungsaufforderung nie erscheint.

Werkzeugreferenz

TOOLS.md enthält die werkzeugweise Referenz: Argumente, was jedes zurückgibt, welche Genehmigung benötigen und die Begründung für das Sperrdesign.

Lizenz

Apache-2.0. Siehe LICENSE.