Actieve FTD-site-VPN’s tellen: welk getal bedoelt u?

Voordat u de Ansible-taak schrijft, beantwoord een kleinere vraag: wat wordt er geteld? Een geconfigureerde peer, een IKE-sessie, een IPsec-beveiligingsassociatie en een bewaakt tunnelstatusrecord zijn vier verschillende eenheden, en sleutelvernieuwing of meerdere beschermde netwerken zorgen ervoor dat hun totalen uiteenlopen. Als het dashboard en de playbook het niet eens zijn, tellen ze meestal verschillende dingen in plaats van dat een van beide fout is.

Vier dingen die mensen actief noemen

Een geconfigureerde peer is een topologieobject: het bestaat omdat iemand het heeft gedefinieerd. Een IKE-sessie is een relatie op het controlevlak die omhoog kan zijn terwijl er geen verkeer stroomt. Een IPsec-SA is de datavlakassociatie voor een bepaald selectorpaar, en één tunnel kan er meerdere dragen. Een bewaakte tunnelstatus is het eigen operationele oordeel van het platform, meestal het dichtst bij wat een operator bedoelt als hij zegt dat de tunnel omhoog is.

Alleen de laatste is een redelijke basis voor een operationele telling. De eerste is een configuratie-inventaris, en die als actief rapporteren is hoe een dashboard groen toont voor een peer die sinds dinsdag platligt. Bepaal welke eenheid de gebruiker van het getal nodig heeft, en benoem de metriek vervolgens met die eenheid in de eigen naam.

Eerste beslissing: welk beheerpaneel?

Als het apparaat door FDM wordt beheerd, is de FTD REST API het relevante oppervlak. Als het door FMC wordt beheerd, is die API geen uitwisselbare vervanging, en de objecten leven achter de eigen API van FMC. Bevestig dit voordat u één verzoek schrijft, want het verkeerde vlak geeft een plausibele fout die op een rechtenprobleem lijkt.

Voor een vloot bepaalt het antwoord ook waar de telling thuishoort: per apparaat via FDM, of per domein via FMC. Dat zijn verschillende bereiken en ze leveren verschillende getallen voor dezelfde vloot.

Tweede beslissing: welke resource antwoordt?

Voor een versiegebonden voorbeeld documenteert de FMC 7.3 API-objectreferentie GET-resources onder het health-pad:

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

De tunnelstatus-resource ondersteunt apparaat- en statusfilters, waaronder TUNNEL_UP. Dat geeft u een echte operationele resource om voor die versie te inspecteren, in plaats van een gok over een veldnaam.

Bevestig beschikbaarheid, rechten, verzoekparameters en het responseschema in de API Explorer van de geïmplementeerde FMC voordat u een parser implementeert. Documentatie voor één versie is een startpunt, geen contract voor de versie die u draait.

Schrijf het telcontract

Formuleer de metriek in één zin: unieke operationele tunnelrecords voor één bedoeld apparaat en domein waarvan de gerapporteerde status TUNNEL_UP is. Documenteer daarna hoe redundante apparaten en meerdere records voor één logische locatie worden weergegeven, want die twee gevallen bepalen of uw getal overeenkomt met dat in de vergadering.

Wijzig de eenheid niet stilzwijgend van tunnelrecord naar externe locatie. Als het bedrijf locaties wil, koppel records dan expliciet aan locaties en publiceer de koppeling. Een telling die zichzelf stilzwijgend herdefinieert is erger dan geen telling, omdat niemand kan zien wanneer die veranderde.

Behandel de samenvattingsresource pas als gemak nadat u hebt bevestigd wat die samenvat. Het kan precies aggregeren wat u nodig hebt, of een subtiel andere vraag beantwoorden. Lees het schema één keer, noteer het verschil, en gebruik de statusresource als de samenvatting niet kan worden uitgelegd. Een samenvatting die u niet begrijpt is een getal dat u in een review niet kunt verdedigen.

Laat de workflow de onzekerheid bewaren

Gebruik de goedgekeurde HTTPS API, valideer het certificaat, houd tokens buiten de taakuitvoer en haal het bereik op met het filter en de paginering die de versie ondersteunt. Valideer daarna het schema voordat u iets berekent.

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

Dit is workflow-pseudocode, geen geteste playbook. Neem de werkelijke veldnamen uit de geïnstalleerde API in plaats van een JSON-sleutel met de naam active te verzinnen.

De belangrijke regel is faalgedrag: een autorisatiefout, een niet-ondersteunde resource, een verouderd monster of een onvolledige paginaset moeten unknown of error opleveren, nooit een geslaagde nul. Een nul die betekent dat ik het niet kon vragen is de duurste soort fout.

Valideer tegen de eigen weergave van het platform

Vergelijk het eerste resultaat met de VPN-monitoringweergave van de versie voor hetzelfde apparaat en moment. Als ze verschillen, zoek dan uit welke eenheid elk gebruikt voordat u de playbook wijzigt.

Bewaar niet-geheime context voor elke run: bereik, tijdstempel, eenheid van de metriek en aantal records. De FMC 7.3 API-objectreferentie is de bron voor de resourcepaden hierboven, en de API Explorer van uw eigen implementatie is de bron voor al het overige.