ASA-FirePOWER-Modul hat keine Management-Route zur FMC

Die FMC zeigt das Modul als nicht erreichbar, die Registrierung bleibt auf ausstehend, und ein Ping aus dem Inneren der ASA funktioniert einwandfrei. Bei einem bestehenden ASA-FirePOWER-Deployment ist diese Kombination normal. Das Modul hat seine eigene Management-Adresse, sein eigenes Standard-Gateway und seine eigenen Routing-Entscheidungen, und eine physische Management-Verbindung mit der ASA auf manchen Plattformen teilen führt diese nicht zu einem Netzwerk-Stack zusammen. Zwei Geräte antworten aus zwei verschiedenen Blickwinkeln auf derselben Leitung.

Das Folgende gilt für Module, die bereits in Betrieb sind. Bestimmen Sie Chassis-Modell, Modultyp und unterstützte Softwareversion, bevor Sie ein Portdiagramm aus einer Anleitung anwenden.

Zeichnen Sie das Modul als eigenen Host

Beginnen Sie das Diagramm mit der Management-IP des Moduls, Maske und Standard-Gateway, dem VLAN, das diese Verbindung tatsächlich trägt, und der FMC-Adresse, die erreicht werden muss. Schreiben Sie dann in einem getrennten Kasten die Interface-Adressen der ASA und ihre vollständige Routing-Tabelle. Wenn die beiden Kästen am Ende ein Subnetz mit Adressen verschiedener Eigentümer teilen, haben Sie den interessanten Teil des Problems gefunden.

Der Leitfaden zum ASA-FirePOWER-Modul zeigt, wie sich Portanordnungen zwischen Plattformen unterscheiden, einschließlich gemeinsamer Management-Verkabelung, bei der ASA und Modul getrennte Adressen im selben Segment führen. Dieses Hardwarediagramm ist eine Eingabe für das Design, keine Fußnote.

Finden Sie, wo der Rückweg bricht

Nehmen Sie ein kerngeführtes Layout. Das Modul schickt FMC-gebundenen Verkehr zu einem Layer-3-Kern, der Kern leitet das entfernte Management-Ziel zum Inside-Interface der ASA weiter, und das Standort-VPN trägt es auf die andere Seite. Die entfernte Site braucht dann eine Route zurück zum Management-Subnetz des Moduls. Jeder Hop dieser Kette kann korrekt sein, während diese letzte Route fehlt, und deshalb sieht der Fehler so oft wie ein defekter Tunnel aus.

Lesen Sie die eigene Sicht der ASA, bevor Sie etwas ändern:

show interface ip brief
show route
show running-config interface

Der dritte Befehl ist wichtig, weil eine vergessene Interface-Adresse genau das ist, was den Rückweg auf dem falschen Gerät landen lässt.

Prüfen Sie, was die ASA als verbunden ansieht

Hat die ASA eine Adresse im Management-Subnetz des Moduls, besitzt ihre Connected-Route dieses Präfix. Eine statische Route zum Kern verdrängt die Eigentümerschaft der Connected-Route nicht, also kommt das Paket zur ASA zurück und bleibt dort stehen. Die Registrierung scheitert dann an einer Stelle, die mit Anmeldedaten nichts zu tun hat.

Schließen Sie nicht, dass eine bestimmte Anti-Spoofing-Prüfung das Paket verworfen hat, solange Sie nicht die eigenen Beobachtungen der Appliance vor sich haben. Vergleichen Sie stattdessen das Ingress-Interface, die gewählte Zielroute und die unterstützte Grenze zwischen Management- und Datenweiterleitung für diese Plattform. Diese drei Fakten legen den Topologiekonflikt meist offen, bevor jemand anfängt, Registrierungsschlüssel zurückzusetzen.

Wählen Sie eine Korrektur, die das Modul verbunden lässt

Die Adresse der ASA aus diesem Segment zu entfernen und einen gemeinsamen Port physisch zu deaktivieren sind keine gleichwertigen Maßnahmen. Auf Plattformen, auf denen das Modul über dieselbe physische Management-Verbindung läuft, entfernt das Deaktivieren des Ports die einzige Verbindung des Moduls — Sie hätten ein Routing-Problem in eine tote Appliance verwandelt. Bevorzugen Sie die Änderung, die die Eigentümerschaft des Management-Routings neu zuweist, und planen Sie sie mit dem Netzwerkeigentümer anwesend.

Eine zweite unterstützte Option ist, dem administrativen Pfad der ASA ein eigenes Segment zu geben, damit das Management-Subnetz des Moduls einen Eigentümer hat. Das kostet eine Adresse und etwas Dokumentation und beseitigt die Mehrdeutigkeit dauerhaft. Welchen Weg Sie auch wählen, bestätigen Sie danach, dass das Modul weiterhin sowohl die FMC als auch seine DNS- oder NTP-Quellen erreicht.

Registrieren Sie erst, wenn der Pfad stimmig ist

Planen Sie, sobald der Rückweg sauber ist, die Management-Konnektivität und die Registrierungsparameter anhand der passenden Release-Anleitung von FMC und Modul. Halten Sie Registrierungsgeheimnisse aus gemeinsamen Notizen und Tickets heraus und widerstehen Sie der Versuchung, als Diagnoseschritt neu zu registrieren: ein frischer Schlüssel auf einem defekten Pfad erzeugt nur denselben Fehler mit neuerem Zeitstempel.

Akzeptieren Sie den Pfad aus dem eigenen Management-Stack des Moduls statt aus einem von der ASA ausgehenden Ping, denn die Quelle des Tests ist genau das, was unter Verdacht steht. Notieren Sie den nächsten Hop des Moduls, die VPN-Auswahl der ASA und die Antwortroute der FMC, und behalten Sie für beide Management-Rollen eine unabhängige Wiederherstellungsmethode. Dieser Eintrag ist es, der einen reparierten Transport von einer erfolgreichen Registrierung trennt.

Wenn das Modul endlich in der FMC erscheint, führen Sie dieselben drei Befehle erneut aus und speichern Sie die Ausgabe neben dem Diagramm. Die nächste Person, die dieses Management-Segment anfasst, braucht genau diesen Vergleich.