Å telle aktive FTD-område-VPN-er: hvilket tall mener du?

Før du skriver Ansible-oppgaven, svar på et mindre spørsmål: hva er det som telles? En konfigurert peer, en IKE-økt, en IPsec-sikkerhetsassosiasjon og en overvåket tunnelstatuspost er fire forskjellige enheter, og nøkkelfornyelse eller flere beskyttede nettverk gjør at totalene deres divergerer. Hvis dashbordet og playbooken er uenige, teller de vanligvis forskjellige ting, ikke at en av dem tar feil.

Fire ting folk kaller aktive

En konfigurert peer er et topologiobjekt: den finnes fordi noen definerte den. En IKE-økt er en relasjon på kontrollplanet som kan være oppe mens ingen trafikk flyter. En IPsec-SA er dataplanassosiasjonen for et bestemt selektorpar, og én tunnel kan bære flere. En overvåket tunnelstatus er plattformens egen driftsmessige vurdering, som vanligvis er det nærmeste på det en operatør mener med at tunnelen er oppe.

Bare den siste er et rimelig grunnlag for en driftsmessig telling. Den første er en konfigurasjonsoversikt, og å rapportere den som aktiv er måten et dashbord viser grønt for en peer som har vært nede siden tirsdag. Bestem hvilken enhet forbrukeren av tallet trenger, og navngi deretter metrikken med den enheten i sitt eget navn.

Første beslutning: hvilket administrasjonsplan?

Hvis enheten administreres av FDM, er FTD REST API den relevante flaten. Hvis den administreres av FMC, er den API-en ikke en utskiftbar erstatning, og objektene ligger bak FMCs egen API. Bekreft dette før du skriver én eneste forespørsel, fordi feil plan returnerer en troverdig feil som ser ut som et tillatelsesproblem.

For en flåte avgjør svaret også hvor tellingen hører hjemme: per enhet via FDM, eller per domene via FMC. Dette er forskjellige omfang, og de gir forskjellige tall for samme flåte.

Andre beslutning: hvilken ressurs svarer?

For et versjonsbundet eksempel dokumenterer FMC 7.3 API-objektreferansen GET-ressurser under health-stien:

/api/fmc_config/v1/domain/{domainUUID}/health/tunnelstatuses
/api/fmc_config/v1/domain/{domainUUID}/health/tunnelsummaries

Tunnelstatus-ressursen støtter enhets- og statusfiltre, inkludert TUNNEL_UP. Det gir deg en reell driftsressurs å undersøke for den versjonen, i stedet for en gjetning om et feltnavn.

Bekreft tilgjengelighet, tillatelser, forespørselsparametere og responsskjemaet i den installerte FMCs API Explorer før du implementerer en parser. Dokumentasjon for én versjon er et utgangspunkt, ikke en kontrakt for den du kjører.

Skriv tellekontrakten

Angi metrikken i én setning: unike driftsmessige tunnelposter for én tiltenkt enhet og ett domene der rapportert tilstand er TUNNEL_UP. Dokumenter deretter hvordan redundante enheter og flere poster for ett logisk område representeres, fordi disse to tilfellene avgjør om tallet ditt stemmer med det i møtet.

Ikke endre enheten stille fra tunnelpost til eksternt område. Hvis forretningen vil ha områder, koble postene eksplisitt til områder og publiser koblingen. En telling som stille omdefinerer seg selv, er verre enn ingen telling, fordi ingen kan si når den endret seg.

Behandle sammendragsressursen som en bekvemmelighet først etter at du har bekreftet hva den oppsummerer. Den kan aggregere nøyaktig det du trenger, eller svare på et subtilt annerledes spørsmål. Les skjemaet én gang, skriv ned forskjellen, og bruk statusressursen hvis sammendraget ikke kan forklares. Et sammendrag du ikke forstår, er et tall du ikke kan forsvare i en gjennomgang.

La arbeidsflyten bevare usikkerheten

Bruk den godkjente HTTPS API-en, valider sertifikatet, hold tokens utenfor oppgaveutdata, og hent omfanget med filteret og pagineringen versjonen støtter. Valider deretter skjemaet før du beregner noe.

fetch intended domain/device runtime records
validate response, completeness and freshness
deduplicate by the documented tunnel identity
count records matching the approved up-state definition
report count with scope, timestamp and metric unit

Dette er pseudokode for en arbeidsflyt, ikke en testet playbook. Hent de faktiske feltnavnene fra den installerte API-en i stedet for å finne opp en JSON-nøkkel kalt active.

Den viktige regelen er oppførsel ved feil: en autorisasjonsfeil, en ikke-støttet ressurs, en utdatert prøve eller et ufullstendig sidesett må gi unknown eller error, aldri en vellykket null. En null som betyr at jeg ikke kunne spørre, er den dyreste typen feil.

Valider mot plattformens eget bilde

Sammenlign det første resultatet med versjonens VPN-overvåkingsvisning for samme enhet og øyeblikk. Når de avviker, finn ut hvilken enhet hver bruker før du endrer playbooken.

Behold ikke-hemmelig kontekst for hver kjøring: omfang, tidsstempel, metrikkenhet og antall poster. FMC 7.3 API-objektreferansen er kilden til ressursbanene ovenfor, og API Explorer på din egen utrulling er kilden til alt annet.