Pagbilang ng aktibong FTD site VPN: aling numero ang ibig mong sabihin?

Bago isulat ang Ansible task, sagutin ang isang mas maliit na tanong: ano ang binibilang? Ang naka-configure na peer, isang IKE session, isang IPsec security association at isang naitalang estado ng minomonitor na tunnel ay apat na magkakaibang unit, at ang muling pagbuo ng key o maraming protektadong network ay nagpapalihis sa kanilang mga kabuuan. Kung hindi magkasundo ang dashboard at ang playbook, karaniwang magkaibang bagay ang binibilang nila, hindi na mali ang isa sa kanila.

Apat na bagay na tinatawag na aktibo ng mga tao

Ang naka-configure na peer ay isang topology object: umiiral ito dahil may nagtukoy nito. Ang IKE session ay isang ugnayan sa control plane na maaaring nakaupo habang walang trapikong dumadaloy. Ang IPsec SA ay ang data plane association para sa isang partikular na pares ng selector, at ang isang tunnel ay maaaring magdala ng marami. Ang minomonitor na estado ng tunnel ay ang sariling operasyonal na hatol ng platform, na karaniwang pinakamalapit sa ibig sabihin ng operator kapag sinabi niyang nakataas ang tunnel.

Tanging ang huli ang makatwirang batayan para sa operasyonal na bilang. Ang una ay imbentaryo ng configuration, at ang iulat ito bilang aktibo ay kung paano nagpapakita ng berde ang dashboard para sa peer na down mula Martes. Magpasya kung aling unit ang kailangan ng gumagamit ng numero, pagkatapos ay lagyan ng label ang metric ng unit na iyon sa sarili nitong pangalan.

Unang desisyon: aling management plane?

Kung ang device ay pinamamahalaan ng FDM, ang kaugnay na surface ay ang FTD REST API. Kung pinamamahalaan ito ng FMC, ang API na iyon ay hindi mapagpapalit na kapalit, at ang mga object ay nasa likod ng sariling API ng FMC. Kumpirmahin ito bago sumulat ng isang kahilingan, dahil ang maling plane ay nagbabalik ng makatwirang error na mukhang problema sa pahintulot.

Para sa isang fleet, ang sagot ay nagpapasya rin kung saan nabibilang ang bilang: bawat device sa pamamagitan ng FDM, o bawat domain sa pamamagitan ng FMC. Magkaibang saklaw ang mga ito at nagbibigay sila ng magkakaibang numero para sa parehong fleet.

Ikalawang desisyon: aling resource ang sumasagot?

Para sa halimbawang nakatali sa bersyon, idinodokumento ng FMC 7.3 API object reference ang mga GET resource sa ilalim ng health path:

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

Sinusuportahan ng tunnel status resource ang mga filter ng device at status, kabilang ang TUNNEL_UP. Nagbibigay ito sa iyo ng tunay na operasyonal na resource na susuriin para sa bersyong iyon, hindi isang haka-haka tungkol sa pangalan ng field.

Kumpirmahin ang availability, mga pahintulot, mga parameter ng kahilingan at ang schema ng tugon sa API Explorer ng naka-deploy na FMC bago magpatupad ng parser. Ang dokumentasyon ng isang bersyon ay panimulang punto, hindi kontrata para sa bersyong pinapatakbo mo.

Isulat ang kontrata ng pagbilang

Sabihin ang metric sa isang pangungusap: natatanging operasyonal na talaan ng tunnel para sa isang nilalayong device at domain na ang iniulat na estado ay TUNNEL_UP. Pagkatapos ay idokumento kung paano kinakatawan ang mga redundant na device at maraming talaan para sa isang lohikal na site, dahil ang dalawang kasong iyon ang nagpapasya kung tumutugma ang numero mo sa nasa pulong.

Huwag baguhin nang tahimik ang unit mula sa talaan ng tunnel patungo sa malayong site. Kung gusto ng negosyo ng mga site, tahasang i-map ang mga talaan sa mga site at i-publish ang mapping. Ang bilang na tahimik na muling naglalarawan sa sarili nito ay mas masama kaysa walang bilang, dahil walang makapagsasabi kung kailan ito nagbago.

Tratuhin ang summary resource bilang kaginhawahan lamang pagkatapos kumpirmahin kung ano ang isinasama nito. Maaaring isama nito nang eksakto ang kailangan mo, o sumagot sa isang bahagyang naiibang tanong. Basahin ang schema nito nang isang beses, isulat ang pagkakaiba, at gamitin ang status resource kung hindi maipaliwanag ang summary. Ang summary na hindi mo naiintindihan ay isang numerong hindi mo maipagtatanggol sa isang review.

Hayaang pangalagaan ng workflow ang kawalan ng katiyakan

Gamitin ang aprubadong HTTPS API, i-validate ang certificate, ilayo ang mga token sa output ng task, at kunin ang saklaw gamit ang filter at pagination na sinusuportahan ng bersyon. Pagkatapos ay i-validate ang schema bago magkalkula ng kahit ano.

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

Ito ay pseudocode ng workflow, hindi isang nasubok na playbook. Kunin ang aktwal na mga pangalan ng field mula sa naka-install na API sa halip na mag-imbento ng JSON key na tinatawag na active.

Ang mahalagang tuntunin ay pag-uugali sa pagkabigo: ang error sa awtorisasyon, hindi sinusuportahang resource, lumang sample o hindi kumpletong set ng pahina ay dapat magbigay ng unknown o error, hindi kailanman isang matagumpay na zero. Ang zero na ibig sabihin ay hindi ako makapagtanong ang pinakamahal na uri ng pagkakamali.

I-validate laban sa sariling pananaw ng platform

Ihambing ang unang resulta sa view ng VPN monitoring ng bersyon para sa parehong device at sandali. Kapag magkaiba sila, alamin kung aling unit ang ginagamit ng bawat isa bago baguhin ang playbook.

Panatilihin ang hindi-sekretong konteksto para sa bawat pagpapatakbo: saklaw, timestamp, unit ng metric at bilang ng talaan. Ang FMC 7.3 API object reference ay ang pinagmulan ng mga path ng resource sa itaas, at ang API Explorer sa sarili mong deployment ang pinagmulan ng lahat ng iba pa.