ASA FirePOWER-modulet har ingen administrationsrute til FMC

FMC viser modulet som utilgængeligt, registreringen står på afventende, og en ping indefra ASA’en fungerer upåklageligt. På en eksisterende ASA FirePOWER-udrulning er den kombination normal. Modulet har sin egen administrationsadresse, sin egen standardgateway og sine egne rutningsbeslutninger, og deling af en fysisk administrationsforbindelse med ASA’en på nogle platforme smelter ikke dette sammen til én netværksstak. To enheder svarer ud fra to forskellige synspunkter på samme ledning.

Det følgende gælder for moduler, der allerede er i drift. Fastlæg chassis model, modultype og understøttet softwareversion, før du anvender et hvilket som helst portdiagram fra en vejledning.

Tegn modulet som en separat vært

Start diagrammet med modulets administrations-IP, maske og standardgateway, den VLAN der faktisk bærer forbindelsen, og den FMC-adresse, den skal nå. Skriv derefter i en separat boks ASA’ens interfaceadresser og dens fulde rutningstabel. Hvis de to bokse ender med at dele et subnet med adresser ejet af forskellige sider, har du fundet den interessante del af problemet.

Vejledningen til ASA FirePOWER-modulet viser, hvordan portopstillinger varierer mellem platforme, inklusive delt administrationskabling hvor ASA’en og modulet har separate adresser på samme segment. Det hardwarediagram er et input til designet, ikke en fodnote.

Find hvor returvejen bryder sammen

Tag et kernestyret layout. Modulet sender FMC-trafik til en Layer 3-kerne, kernen videresender det fjerne administrationmål mod ASA’ens indvendige interface, og stedets VPN bærer det til den anden side. Det fjerne sted har derefter brug for en rute tilbage til modulets administrationssubnet. Hvert hop i den kæde kan være korrekt, mens den sidste rute mangler, og derfor ligner fejlen så ofte en brudt tunnel.

Læs ASA’ens eget syn, før du ændrer noget:

show interface ip brief
show route
show running-config interface

Den tredje kommando er vigtig, fordi en interfaceadresse, du har glemt, netop er det, der får returvejen til at lande på den forkerte enhed.

Kontroller, hvad ASA’en anser for forbundet

Hvis ASA’en har en adresse på modulets administrationssubnet, ejer dens forbundne rute det præfiks. En statisk rute mod kernen fortrænger ikke den forbundne rutes ejerskab, så pakken vender tilbage til ASA’en og stopper der. Registreringen fejler derefter på et punkt, der intet har med legitimationsoplysninger at gøre.

Konkludér ikke, at en bestemt anti-spoofing-kontrol har droppet pakken, medmindre du har enhedens egne observationer foran dig. Sammenlign i stedet det indgående interface, den valgte destinationsrute og den understøttede grænse mellem administration og data for den platform. Disse tre fakta afslører normalt topologikonflikten, før nogen begynder at nulstille registreringsnøgler.

Vælg en rettelse, der holder modulet forbundet

At fjerne ASA’ens adresse fra det segment og fysisk deaktivere en delt port er ikke ækvivalente handlinger. På platforme, hvor modulet kører over den samme fysiske administrationsforbindelse, fjerner deaktivering af porten modulets eneste forbindelse — du har gjort et rutningsproblem til en død enhed. Foretræk den ændring, der omfordeler ejerskabet af administrationsrutningen, og planlæg den med netværksejeren til stede.

En anden understøttet mulighed er at give ASA’ens administrative vej sit eget segment, så modulets administrationssubnet har én ejer. Det koster en adresse og lidt dokumentation og fjerner tvetydigheden permanent. Uanset hvilken vej du vælger, skal du bagefter bekræfte, at modulet stadig kan nå både FMC og sine DNS- eller NTP-kilder.

Registrer først, når ruten er sammenhængende

Når returvejen er ren, planlæg administrationsforbindelsen og registreringsparametrene ud fra den matchende versionsvejledning for FMC og modulet. Hold registreringshemmeligheder ude af delte noter og sager, og modstå fristelsen til at registrere igen som diagnostisk trin: en ny nøgle på en brudt vej giver blot den samme fejl med et nyere tidsstempel.

Accepter vejen fra modulets egen administrationsstak frem for fra en ping, der stammer fra ASA’en, fordi testens kilde er netop det, der er under mistanke. Noter modulets næste hop, ASA’ens VPN-valg og FMC’ens svar-rute, og behold en uafhængig gendannelsesmetode for begge administrationsroller. Den registrering er det, der adskiller en repareret transport fra en vellykket registrering.

Når modulet endelig dukker op i FMC, kør de samme tre kommandoer igen, og gem outputtet ved siden af diagrammet. Den næste person, der rører det administrationssegment, får præcis brug for den sammenligning.