Att räkna aktiva FTD-plats-VPN: vilket tal menar du?

Innan du skriver Ansible-uppgiften, svara på en mindre fråga: vad är det som räknas? En konfigurerad peer, en IKE-session, en IPsec-säkerhetsassociation och en övervakad tunnelstatuspost är fyra olika enheter, och nyckelbyte eller flera skyddade nätverk gör att deras summor divergerar. Om instrumentpanelen och playbooken inte är överens räknar de vanligtvis olika saker, inte att en av dem har fel.

Fyra saker som folk kallar aktiva

En konfigurerad peer är ett topologiobjekt: den finns eftersom någon definierade den. En IKE-session är en relation på kontrollplanet som kan vara uppe medan ingen trafik flyter. En IPsec-SA är dataplansassociationen för ett visst selektorpar, och en tunnel kan bära flera. En övervakad tunnelstatus är plattformens egen operativa bedömning, oftast närmast det en operatör menar med att tunneln är uppe.

Bara den sista är en rimlig grund för en operativ räkning. Den första är en konfigurationsinventering, och att rapportera den som aktiv är hur en instrumentpanel visar grönt för en peer som varit nere sedan tisdag. Bestäm vilken enhet mottagaren av talet behöver, och namnge sedan mätvärdet med den enheten i dess eget namn.

Första beslutet: vilken hanteringsplan?

Om enheten hanteras av FDM är FTD REST API den relevanta ytan. Om den hanteras av FMC är det API:et inte en utbytbar ersättning, och objekten ligger bakom FMC:s eget API. Bekräfta detta innan du skriver en enda förfrågan, eftersom fel plan returnerar ett trovärdigt fel som ser ut som ett behörighetsproblem.

För en flotta avgör svaret också var räkningen hör hemma: per enhet via FDM, eller per domän via FMC. Det är olika omfattningar och de ger olika tal för samma flotta.

Andra beslutet: vilken resurs svarar?

För ett versionsbundet exempel dokumenterar FMC 7.3 API-objektreferensen GET-resurser under health-sökvägen:

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

Tunnelstatusresursen stöder enhets- och statusfilter, inklusive TUNNEL_UP. Det ger dig en verklig operativ resurs att inspektera för den versionen, i stället för en gissning om ett fältnamn.

Bekräfta tillgänglighet, behörigheter, förfrågningsparametrar och resursschemat i den installerade FMC:ns API Explorer innan du implementerar en parser. Dokumentation för en version är en utgångspunkt, inte ett kontrakt för den du kör.

Skriv räkningskontraktet

Ange mätvärdet i en mening: unika operativa tunnelposter för en avsedd enhet och domän vars rapporterade tillstånd är TUNNEL_UP. Dokumentera sedan hur redundanta enheter och flera poster för en logisk plats representeras, eftersom dessa två fall avgör om ditt tal stämmer med det i mötet.

Ändra inte enheten tyst från tunnelpost till fjärrplats. Om verksamheten vill ha platser, mappa posterna uttryckligen till platser och publicera mappningen. En räkning som tyst omdefinierar sig själv är sämre än ingen räkning, eftersom ingen kan säga när den ändrades.

Behandla sammanfattningsresursen som en bekvämlighet först efter att du bekräftat vad den sammanfattar. Den kan aggregera exakt det du behöver, eller svara på en subtilt annan fråga. Läs dess schema en gång, skriv ned skillnaden och använd statusresursen om sammanfattningen inte kan förklaras. En sammanfattning du inte förstår är ett tal du inte kan försvara i en granskning.

Låt arbetsflödet bevara osäkerheten

Använd den godkända HTTPS API:n, validera certifikatet, håll tokens utanför uppgiftens utdata och hämta omfattningen med filtret och sidindelningen som versionen stöder. Validera sedan schemat innan du beräknar något.

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

Detta är pseudokod för ett arbetsflöde, inte en testad playbook. Ta de faktiska fältnamnen från det installerade API:et i stället för att hitta på en JSON-nyckel som heter active.

Den viktiga regeln är beteende vid fel: ett auktoriseringsfel, en resurs som inte stöds, ett inaktuellt urval eller en ofullständig siduppsättning måste ge unknown eller error, aldrig en lyckad nolla. En nolla som betyder att jag inte kunde fråga är den dyraste typen av fel.

Validera mot plattformens egen vy

Jämför det första resultatet med versionens VPN-övervakningsvy för samma enhet och ögonblick. När de skiljer sig, ta reda på vilken enhet var och en använder innan du ändrar playbooken.

Behåll icke-hemlig kontext för varje körning: omfattning, tidsstämpel, mätvärdets enhet och antal poster. FMC 7.3 API-objektreferensen är källan till resursvägarna ovan, och API Explorer i din egen distribution är källan till allt annat.