De ASA FirePOWER-module heeft geen beheerroute naar FMC

FMC toont de module als onbereikbaar, de registratie blijft op in afwachting staan en een ping van binnen de ASA werkt feilloos. Bij een bestaande ASA FirePOWER-implementatie is die combinatie normaal. De module heeft zijn eigen beheeradres, zijn eigen standaardgateway en zijn eigen routeringsbeslissingen, en een fysieke beheerverbinding met de ASA delen op sommige platforms voegt die niet samen tot één netwerkstack. Twee apparaten antwoorden vanuit twee verschillende gezichtspunten op dezelfde draad.

Het volgende geldt voor modules die al in gebruik zijn. Bepaal het chassis-model, het moduletype en de ondersteunde softwareversie voordat u een poortdiagram uit een handleiding toepast.

Teken de module als een aparte host

Begin het diagram met het beheer-IP van de module, het masker en de standaardgateway, de VLAN die die verbinding daadwerkelijk draagt, en het FMC-adres dat moet worden bereikt. Schrijf daarna in een apart kader de interfaceadressen van de ASA en de volledige routeringstabel. Als de twee kaders uiteindelijk een subnet delen met adressen van verschillende eigenaren, hebt u het interessante deel van het probleem gevonden.

De handleiding voor de ASA FirePOWER-module laat zien hoe poortindelingen tussen platforms verschillen, inclusief gedeelde beheersbekabeling waarbij de ASA en de module aparte adressen op hetzelfde segment hebben. Dat hardwarediagram is een invoer voor het ontwerp, geen voetnoot.

Zoek waar het retourpad breekt

Neem een via de kern gerouteerde opstelling. De module stuurt FMC-verkeer naar een Layer 3-kern, de kern stuurt de externe beheerbestemming naar de binneninterface van de ASA, en de site-VPN draagt het naar de andere kant. De externe site heeft dan een route terug nodig naar het beheersubnet van de module. Elke hop in die keten kan correct zijn terwijl die laatste route ontbreekt, en daarom ziet de storing er zo vaak uit als een gebroken tunnel.

Lees het eigen beeld van de ASA voordat u iets wijzigt:

show interface ip brief
show route
show running-config interface

Het derde commando is belangrijk omdat een vergeten interfaceadres precies datgene is waardoor het retourpad op het verkeerde apparaat belandt.

Controleer wat de ASA als verbonden beschouwt

Als de ASA een adres heeft op het beheersubnet van de module, bezit zijn verbonden route dat prefix. Een statische route naar de kern verdringt het eigendom van de verbonden route niet, dus het pakket komt terug bij de ASA en stopt daar. De registratie mislukt dan op een punt dat niets met inloggegevens te maken heeft.

Concludeer niet dat een specifieke anti-spoofingcontrole het pakket heeft laten vallen tenzij u de eigen waarnemingen van het apparaat voor u hebt. Vergelijk in plaats daarvan de inkomende interface, de gekozen bestemmingsroute en de ondersteunde grens tussen beheer en data voor dat platform. Die drie feiten leggen het topologieconflict meestal bloot voordat iemand registratiesleutels gaat resetten.

Kies een correctie die de module verbonden houdt

Het adres van de ASA van dat segment verwijderen en een gedeelde poort fysiek uitschakelen zijn geen gelijkwaardige acties. Op platforms waar de module over dezelfde fysieke beheerverbinding gaat, verwijdert het uitschakelen van de poort de enige link van de module — u hebt dan een routeringsprobleem omgezet in een dood apparaat. Geef de voorkeur aan de wijziging die het eigendom van de beheerroutering herverdeelt, en bereid die voor met de netwerkeigenaar erbij.

Een tweede ondersteunde optie is het administratieve pad van de ASA een eigen segment te geven, zodat het beheersubnet van de module één eigenaar heeft. Dat kost één adres en wat documentatie, en het haalt de dubbelzinnigheid permanent weg. Welk pad u ook kiest, bevestig daarna dat de module nog steeds zowel FMC als zijn DNS- of NTP-bronnen kan bereiken.

Registreer pas als het pad coherent is

Als het retourpad schoon is, plan dan de beheerconnectiviteit en de registratieparameters volgens de bijbehorende releasehandleiding van FMC en module. Houd registratiegeheimen buiten gedeelde notities en tickets, en weersta de verleiding om opnieuw te registreren als diagnostische stap: een nieuwe sleutel op een gebroken pad levert alleen dezelfde storing met een nieuwere tijdstempel.

Accepteer het pad vanuit de eigen beheerstack van de module in plaats van vanuit een ping die van de ASA komt, want de bron van de test is precies datgene wat onder verdenking staat. Noteer de volgende hop van de module, de VPN-keuze van de ASA en de antwoordroute van FMC, en houd een onafhankelijke herstelmethode aan voor beide beheerrollen. Dat verslag is wat een gerepareerd transport van een geslaagde registratie scheidt.

Wanneer de module eindelijk in FMC verschijnt, voer dan dezelfde drie commando’s opnieuw uit en bewaar de uitvoer naast het diagram. De volgende persoon die dat beheersegment aanraakt, heeft precies die vergelijking nodig.