ASA FirePOWER-modulen har ingen administrasjonsrute til FMC

FMC viser modulen som utilgjengelig, registreringen står på vent, og en ping fra innsiden av ASA-en fungerer feilfritt. På en eksisterende ASA FirePOWER-utrulling er den kombinasjonen normal. Modulen har sin egen administrasjonsadresse, sin egen standardgateway og sine egne rutingsbeslutninger, og å dele en fysisk administrasjonsforbindelse med ASA-en på enkelte plattformer smelter ikke dette sammen til én nettverksstakk. To enheter svarer fra to forskjellige synspunkter på samme ledning.

Det følgende gjelder moduler som allerede er i drift. Fastslå chassis-modell, modultype og støttet programvareversjon før du bruker et hvilket som helst portdiagram fra en veiledning.

Tegn modulen som en separat vert

Start diagrammet med modulens administrasjons-IP, maske og standardgateway, VLAN-et som faktisk bærer forbindelsen, og FMC-adressen den må nå. Skriv deretter i en egen boks ASA-ens grensesnittadresser og dens fullstendige rutetabell. Hvis de to boksene ender med å dele et subnett med adresser eid av forskjellige parter, har du funnet den interessante delen av problemet.

Veiledningen for ASA FirePOWER-modulen viser hvordan portoppsett varierer mellom plattformer, inkludert delt administrasjonskabling der ASA-en og modulen har separate adresser på samme segment. Det hardwarediagrammet er et innspill til designet, ikke en fotnote.

Finn hvor returveien bryter sammen

Ta et kjernebasert oppsett. Modulen sender FMC-trafikk til en Layer 3-kjerne, kjernen videresender det eksterne administrasjonsmålet mot ASA-ens indre grensesnitt, og nettstedets VPN bærer det til den andre siden. Det eksterne nettstedet trenger da en rute tilbake til modulens administrasjonssubnett. Hvert hopp i den kjeden kan være riktig mens den siste ruten mangler, og derfor ser feilen så ofte ut som en brutt tunnel.

Les ASA-ens eget syn før du endrer noe:

show interface ip brief
show route
show running-config interface

Den tredje kommandoen er viktig fordi en grensesnittadresse du har glemt, er nettopp det som får returveien til å lande på feil enhet.

Kontroller hva ASA-en anser som tilkoblet

Hvis ASA-en har en adresse på modulens administrasjonssubnett, eier dens tilkoblede rute det prefikset. En statisk rute mot kjernen fortrenger ikke eierskapet til den tilkoblede ruten, så pakken kommer tilbake til ASA-en og stopper der. Registreringen feiler da på et punkt som ikke har noe med påloggingsinformasjon å gjøre.

Ikke konkluder med at en bestemt anti-spoofing-kontroll droppet pakken med mindre du har enhetens egne observasjoner foran deg. Sammenlign i stedet det inngående grensesnittet, den valgte destinasjonsruten og den støttede grensen mellom administrasjon og data for den plattformen. Disse tre fakta avslører vanligvis topologikonflikten før noen begynner å tilbakestille registreringsnøkler.

Velg en rettelse som holder modulen tilkoblet

Å fjerne ASA-ens adresse fra det segmentet og fysisk deaktivere en delt port er ikke likeverdige handlinger. På plattformer der modulen går over den samme fysiske administrasjonsforbindelsen, fjerner deaktivering av porten modulens eneste lenke — du har gjort et rutingsproblem om til en død enhet. Foretrekk endringen som omfordeler eierskapet til administrasjonsrutingen, og planlegg den med nettverkseieren til stede.

Et andre støttet alternativ er å gi ASA-ens administrative vei sitt eget segment slik at modulens administrasjonssubnett har én eier. Det koster én adresse og litt dokumentasjon, og fjerner tvetydigheten permanent. Uansett hvilken vei du velger, må du etterpå bekrefte at modulen fortsatt når både FMC og sine DNS- eller NTP-kilder.

Registrer først når ruten er sammenhengende

Når returveien er ren, planlegg administrasjonstilkoblingen og registreringsparametrene fra den samsvarende versjonsveiledningen for FMC og modulen. Hold registreringshemmeligheter unna delte notater og saker, og motstå fristelsen til å registrere på nytt som et diagnostisk trinn: en ny nøkkel på en brutt vei gir bare den samme feilen med et nyere tidsstempel.

Godta veien fra modulens egen administrasjonsstakk i stedet for fra en ping som kommer fra ASA-en, fordi kilden til testen er nettopp det som er under mistanke. Noter modulens neste hopp, ASA-ens VPN-valg og FMCs svar-rute, og behold en uavhengig gjenopprettingsmetode for begge administrasjonsrollene. Den registreringen er det som skiller en reparert transport fra en vellykket registrering.

Når modulen endelig dukker opp i FMC, kjør de samme tre kommandoene på nytt og lagre utdataene ved siden av diagrammet. Den neste personen som rører det administrasjonssegmentet, trenger nøyaktig den sammenligningen.