ASA FirePOWER-modulen har ingen administrasjonsrute til FMC

FMC viser modulen som utilgjengeleg, registreringa står på vent, og ein ping frå innsida av ASA-en fungerer feilfritt. På ein eksisterande ASA FirePOWER-utrulling er den kombinasjonen normal. Modulen har si eiga administrasjonsadresse, sin eigen standardgateway og sine eigne rutingsavgjerder, og å dela ei fysisk administrasjonskopling med ASA-en på enkelte plattformer smeltar ikkje dette saman til ein nettverksstakk. To einingar svarar frå to ulike synspunkt på same leidning.

Det følgjande gjeld modular som allereie er i drift. Fastset chassis-modell, modultype og støtta programvareversjon før du brukar eit kva som helst portdiagram frå ein rettleiar.

Teikn modulen som ein separat vert

Start diagrammet med administrasjons-IP-en til modulen, maske og standardgateway, VLAN-et som faktisk ber koplinga, og FMC-adressa han må nå. Skriv deretter i ein eigen boks grensesnittadressene til ASA-en og den fullstendige rutetabellen hans. Viss dei to boksane endar med å dela eit subnett med adresser åtte av ulike partar, har du funne den interessante delen av problemet.

Rettleiaren for ASA FirePOWER-modulen viser korleis portoppsett varierer mellom plattformer, inkludert delt administrasjonskabling der ASA-en og modulen har separate adresser på same segment. Det maskinvardiagrammet er eit innspel til designet, ikkje ein fotnote.

Finn kvar returvegen bryt saman

Ta eit kjernebasert oppsett. Modulen sender FMC-trafikk til ein Layer 3-kjerne, kjernen videresender det eksterne administrasjonsmålet mot det indre grensesnittet til ASA-en, og VPN-et på staden ber det til den andre sida. Den eksterne staden treng då ei rute tilbake til administrasjonssubnettet til modulen. Kvart hopp i den kjeda kan vere riktig medan den siste ruta manglar, og difor ser feilen så ofte ut som ein broten tunnel.

Les det eige synet til ASA-en før du endrar noko:

show interface ip brief
show route
show running-config interface

Den tredje kommandoen er viktig fordi ei grensesnittadresse du har gløymt, er nettopp det som får returvegen til å lande på feil eining.

Kontroller kva ASA-en reknar som tilkopla

Viss ASA-en har ei adresse på administrasjonssubnettet til modulen, eig den tilkopla ruta det prefikset. Ei statisk rute mot kjernen fortrengjer ikkje eigarskapet til den tilkopla ruta, så pakken kjem tilbake til ASA-en og stoppar der. Registreringa feilar då på eit punkt som ikkje har noko med påloggingsinformasjon å gjere.

Ikkje konkluder med at ein bestemt anti-spoofing-kontroll slapp pakken med mindre du har eininga sine eigne observasjonar framfor deg. Samanlikn i staden det inngåande grensesnittet, den valde destinasjonsruta og den støtta grensa mellom administrasjon og data for den plattforma. Desse tre fakta avdekkjer vanlegvis topologikonflikten før nokon byrjar å nullstille registreringsnøklar.

Vel ei retting som held modulen tilkopla

Å fjerna adressa til ASA-en frå det segmentet og fysisk deaktivere ein delt port er ikkje likeverdige handlingar. På plattformer der modulen går over same fysiske administrasjonskopling, fjernar deaktivering av porten den einaste lenkja til modulen — du har gjort eit rutingsproblem om til ei daud eining. Føretrekk endringa som omfordeler eigarskapet til administrasjonsrutinga, og planlegg ho med netverks-eigaren til stades.

Eit andre støtta alternativ er å gje den administrative vegen til ASA-en sitt eige segment slik at administrasjonssubnettet til modulen har éin eigar. Det kostar éi adresse og litt dokumentasjon, og fjernar tvitydigheita permanent. Kva veg du enn vel, stadfest etterpå at modulen framleis når både FMC og DNS- eller NTP-kjeldene sine.

Registrer først når vegen er samanhengande

Når returvegen er rein, planlegg administrasjonstilkoplinga og registreringsparametrane frå den samsvarande versjonsrettleiaren for FMC og modulen. Hald registreringsløyndomar unna delte notat og saker, og motstå freistinga til å registrere på nytt som eit diagnostisk steg: ein ny nøkkel på ein broten veg gjev berre same feilen med eit nyare tidsstempel.

Godta vegen frå den eigne administrasjonsstakken til modulen i staden for frå ein ping som kjem frå ASA-en, fordi kjelda til testen er nettopp det som er under mistanke. Noter neste hopp til modulen, VPN-valet til ASA-en og svar-ruta til FMC, og hald ein uavhengig attopprettingsmetode for begge administrasjonsrollene. Den registreringa er det som skil ein reparert transport frå ei vellukka registrering.

Når modulen endeleg dukkar opp i FMC, køyr dei same tre kommandoane på nytt og lagre utdataene ved sida av diagrammet. Den neste personen som rører det administrasjonssegmentet, treng nøyaktig den samanlikninga.