Die ASA FirePOWER-module het geen bestuursroete na FMC nie

FMC wys die module as onbereikbaar, registrasie bly op hangende staan, en ’n ping van binne die ASA werk foutloos. Op ’n bestaande ASA FirePOWER-ontplooiing is daardie kombinasie normaal. Die module het sy eie bestuursadres, sy eie verstekpoort en sy eie roetebesluite, en om op sommige platforms ’n fisiese bestuursverbinding met die ASA te deel, smelt dit nie in een netwerkstapel saam nie. Twee toestelle antwoord twee verskillende standpunte op dieselfde draad.

Wat volg, geld vir modules wat reeds in diens is. Bepaal die onderstelmodel, modulettipe en ondersteunde sagtewarevrystelling voordat jy enige poortdiagram uit ’n gids toepas.

Teken die module as ’n aparte gasheer

Begin die diagram met die module se bestuurs-IP, masker en verstekpoort, die VLAN wat daardie verbinding werklik dra, en die FMC-adres wat dit moet bereik. Skryf dan, in ’n aparte blokkie, die ASA se koppelvlakadresse en sy volledige roetetabel. As die twee blokkies uiteindelik ’n subnet deel met adresse wat deur verskillende blokkies besit word, het jy die interessante deel van die probleem gevind.

Die ASA FirePOWER-modulegids wys hoe poortreëlings tussen platforms verskil, insluitend gedeelde bestuursbedrading waar die ASA en die module aparte adresse op dieselfde segment het. Daardie hardewarediagram is ’n inset vir die ontwerp, nie ’n voetnoot nie.

Vind waar die terugpad breek

Neem ’n uitleg met kernroetering. Die module stuur FMC-gerigte verkeer na ’n Layer 3-kern, die kern stuur die remote bestuursbestemming na die ASA se binnekant-koppelvlak, en die werf-VPN dra dit na die ander kant. Die remote werf het dan ’n roete terug na die module se bestuursubnet nodig. Elke hop in daardie ketting kan korrek wees terwyl daardie laaste roete ontbreek, en daarom lyk die fout so dikwels soos ’n stukkende tonnel.

Lees die ASA se eie siening voordat jy enigiets verander:

show interface ip brief
show route
show running-config interface

Die derde opdrag maak saak, want ’n koppelvlakadres wat jy vergeet het, is presies wat die terugpad op die verkeerde toestel laat beland.

Kyk wat die ASA dink is gekoppel

As die ASA ’n adres op die module se bestuursubnet het, besit sy gekoppelde roete daardie voorvoegsel. ’n Statiese roete na die kern verskuif nie die eienaarskap van die gekoppelde roete nie, so die pakkie kom terug na die ASA en stop daar. Die registrasie misluk dan op ’n punt wat niks met geloofsbriewe te doen het nie.

Moenie aflei dat ’n spesifieke anti-spoofing-kontrole die pakkie laat val het nie, tensy jy die toestel se eie waarnemings voor jou het. Vergelyk eerder die inkomende koppelvlak, die gekose bestemmingsroete en die ondersteunde bestuurs-teenoor-data-aansturende grens vir daardie platform. Daardie drie feite ontbloot gewoonlik die topologiekonflik voordat enigiemand registrasiesleutels begin herstel.

Kies ’n regstelling wat die module verbind hou

Om die ASA se adres van daardie segment te verwyder en om ’n gedeelde poort fisies te deaktiveer, is nie gelykwaardige aksies nie. Op platforms waar die module op dieselfde fisiese bestuursverbinding ry, verwyder die deaktivering van die poort die module se enigste skakel — jy het ’n roeteprobleem in ’n dooie toestel omskep. Verkies die verandering wat eienaarskap van bestuursroetering herbepaal, en beplan dit met die netwerkeienaar teenwoordig.

’n Tweede ondersteunde opsie is om die ASA se administratiewe pad sy eie segment te gee sodat die module se bestuursubnet een eienaar het. Dit kos ’n adres en ’n bietjie dokumentasie, en dit verwyder die onduidelikheid permanent. Watter pad jy ook al kies, bevestig daarna dat die module steeds beide FMC en sy DNS- of NTP-bronne kan bereik.

Registreer eers wanneer die pad samehangend is

Sodra die terugpad skoon is, beplan die bestuurskonnektiwiteit en registrasieparameters uit die ooreenstemmende FMC- en module-vrystellingsgids. Hou registrasiegeheime uit gedeelde notas en kaartjies, en weerstaan die versoeking om weer te registreer as ’n diagnostiese stap: ’n nuwe sleutel op ’n stukkende pad lewer net dieselfde fout met ’n nuwer tydstempel.

Aanvaar die pad vanaf die module se eie bestuursstapel eerder as vanaf ’n ping wat die ASA begin het, want die bron van die toets is juis die ding wat verdink word. Teken die module se volgende hop, die ASA se VPN-keuse en FMC se antwoordroete aan, en hou ’n onafhanklike herstelmetode vir beide bestuursrolle. Daardie rekord is wat ’n herstelde vervoer van ’n suksesvolle registrasie skei.

Wanneer die module uiteindelik in FMC verskyn, voer dieselfde drie opdragte weer uit en stoor die uitset langs die diagram. Die volgende persoon wat daardie bestuurssegment aanraak, sal presies daardie vergelyking nodig hê.