ASA FirePOWER-modulen har ingen administrationsrutt till FMC

FMC visar modulen som oåtkomlig, registreringen står på väntande, och en ping inifrån ASA:n fungerar felfritt. I en befintlig ASA FirePOWER-distribution är den kombinationen normal. Modulen har sin egen administrationsadress, sin egen standardgateway och sina egna routningsbeslut, och att dela en fysisk administrationsanslutning med ASA:n på vissa plattformar smälter inte samman detta till en enda nätverksstack. Två enheter svarar från två olika synvinklar på samma ledning.

Följande gäller moduler som redan är i drift. Fastställ chassimodell, modultyp och programvaruversion som stöds innan du tillämpar något portdiagram från en guide.

Rita modulen som en separat värd

Börja diagrammet med modulens administrations-IP, mask och standardgateway, det VLAN som faktiskt bär anslutningen, och den FMC-adress som måste nås. Skriv sedan i en separat ruta ASA:ns gränssnittsadresser och dess fullständiga routingtabell. Om de två rutorna till slut delar ett subnät med adresser som ägs av olika parter har du hittat den intressanta delen av problemet.

Guiden för ASA FirePOWER-modulen visar hur portarrangemang skiljer sig mellan plattformar, inklusive delad administrationskablage där ASA:n och modulen har separata adresser i samma segment. Det hårdvarudiagrammet är en indata till designen, inte en fotnot.

Hitta var returvägen bryts

Ta en kärnroutad layout. Modulen skickar FMC-trafik till en Layer 3-kärna, kärnan vidarebefordrar det fjärranslutna administrationsmålet mot ASA:ns insida gränssnitt, och platsens VPN bär det till andra sidan. Fjärrplatsen behöver sedan en rutt tillbaka till modulens administrationssubnät. Varje hopp i kedjan kan vara korrekt medan den sista rutten saknas, och därför ser felet så ofta ut som en bruten tunnel.

Läs ASA:ns egen bild innan du ändrar något:

show interface ip brief
show route
show running-config interface

Det tredje kommandot spelar roll eftersom en gränssnittsadress du glömt är precis det som får returvägen att landa på fel enhet.

Kontrollera vad ASA:n anser vara anslutet

Om ASA:n har en adress i modulens administrationssubnät äger dess anslutna rutt det prefixet. En statisk rutt mot kärnan tränger inte undan ägarskapet för den anslutna rutten, så paketet återvänder till ASA:n och stannar där. Registreringen misslyckas då vid en punkt som inte har något med inloggningsuppgifter att göra.

Dra inte slutsatsen att en viss anti-spoofing-kontroll släppte paketet om du inte har enhetens egna observationer framför dig. Jämför i stället det inkommande gränssnittet, den valda destinationsrutten och den gräns för vidarebefordran mellan administration och data som stöds för plattformen. Dessa tre fakta brukar avslöja topologikonflikten innan någon börjar återställa registreringsnycklar.

Välj en rättelse som håller modulen ansluten

Att ta bort ASA:ns adress från segmentet och att fysiskt inaktivera en delad port är inte likvärdiga åtgärder. På plattformar där modulen går över samma fysiska administrationsanslutning tar inaktiveringen av porten bort modulens enda länk — du har förvandlat ett routningsproblem till en död enhet. Föredra den ändring som omfördelar ägarskapet för administrationsroutningen, och förbered den med nätverksägaren närvarande.

Ett andra stödd alternativ är att ge ASA:ns administrativa väg ett eget segment så att modulens administrationssubnät har en enda ägare. Det kostar en adress och lite dokumentation, och tar bort otydligheten permanent. Vilken väg du än väljer, bekräfta efteråt att modulen fortfarande når både FMC och sina DNS- eller NTP-källor.

Registrera först när vägen är sammanhängande

När returvägen är ren, planera administrationanslutningen och registreringsparametrarna enligt motsvarande versionsguide för FMC och modulen. Håll registreringshemligheter utanför delade anteckningar och ärenden, och motstå frestelsen att registrera om som ett diagnostiskt steg: en ny nyckel på en bruten väg ger bara samma fel med en nyare tidsstämpel.

Acceptera vägen från modulens egen administrationsstack i stället för från en ping som ASA:n startar, eftersom testets källa är just det som är under misstanke. Notera modulens nästa hopp, ASA:ns VPN-val och FMC:ns svarsrutt, och behåll en oberoende återställningsmetod för båda administrationsrollerna. Det är den anteckningen som skiljer en reparerad transport från en lyckad registrering.

När modulen till slut dyker upp i FMC, kör samma tre kommandon igen och spara utdata bredvid diagrammet. Nästa person som rör det administrationssegmentet behöver exakt den jämförelsen.