Hub ng DMVPN na may pangalan kumpara sa may numero: ano ang binabago ng FQDN

Ang isang spoke ng DMVPN ay maaaring mahanap ang hub nito sa pamamagitan ng hostname sa mga platform na sumusuporta sa feature, at ang unang tukso ay basahin ang hostname na iyon bilang isa pang paraan ng pagsulat ng tunnel address ng hub. Hindi ganito. Ang pangalan ay niresolba sa isang transport endpoint, habang ang protocol address ng hub ay tumutukoy sa susunod na hop sa loob ng overlay, at nananatili ang dalawang papel sa bawat anyo ng configuration. Ang pagkakaibang iyon ang nagtatakda kung ano ang kayang at hindi kayang ayusin ng pagpapalit ng pangalan.

Dalawang address, dalawang tungkulin

Sa isang idineklarang halimbawa, sinasabi ng hub.example.net sa spoke kung saan ipapadala ang transport traffic, at tinutukoy ng 10.90.0.1 ang NHS sa loob ng tunnel. Gumagana ang discovery sa una; gumagana ang pagpaparehistro at routing sa pangalawa. Ang pagbabago ng pangalan ay nakakaapekto sa landas patungo sa endpoint, habang ang pagbabago ng protocol address ay nakakaapekto sa mismong ugnayan ng overlay.

Ang paghihiwalay ng mga papel ang gumagawa sa anyong may pangalan na madaling i-debug. Kapag nabigo ang isang spoke na magrehistro, maaari kang magtanong ng dalawang magkaibang tanong: niresolba ba ang pangalan sa address na inaasahan ko, at tumugma ba ang address na iyon sa protocol address na sinasabi ng configuration? Wala sa dalawang sagot ang nagpapahiwatig ng isa.

Ihambing ang dalawang anyo ng configuration

Ang isang anyo ay tahasang nagko-configure ng protocol address ng NHS kasama ng pangalan. Ang isa ay hinahayaan ang spoke na matutunan ang protocol address na iyon mula sa sagot ng pagpaparehistro. Pareho silang nakadokumento, at pareho silang nagtatapos sa parehong uri ng ugnayan sa NHS kapag nagtagumpay.

Ang tahasang anyo ay may limitasyong dapat tandaan: ang niresolbang transport address na hindi nagmamapa sa naka-configure na protocol address ay humahadlang sa pagpaparehistro. Hindi ito pagkabigo ng DNS, kahit lumilitaw ang sintomas kaagad pagkatapos ng pagbabago ng DNS. Niresolba nang tama ang pangalan at tinanggihan ang resulta dahil sa ibang dahilan. Basahin ang niresolbang address at ang naka-configure na protocol address nang magkatabi.

Tinatanggal ng anyo ng pagkatuto ang isang manu-manong hakbang at isang pinagmumulan ng drift, kapalit ng pag-asa sa sagot upang maitatag ang mapping. Piliin ang tahasang anyo kapag matatag ang address ng hub at gusto mong mabigo nang malakas ang hindi pagkakatugma. Piliin ang anyo ng pagkatuto kapag maaaring magbago ang protocol address ng hub at mas gusto mong sundan ito ng spoke. Sa alinmang kaso, itala kung aling anyo ang ginagamit ng disenyo.

Ihambing ang cache ng DNS sa isang statikong hub

Nagbabago ang statikong address ng hub kapag may nag-edit ng configuration. Nagbabago ang hub na may pangalan kapag nagbago ang DNS, at ang mga sagot ng DNS ay naka-cache sa buong buhay nila. Itinuturo ng dokumentasyon na nananatiling magagamit ang naka-cache na impormasyon hanggang sa mag-expire ito, at ang susunod na query ay maaaring magbalik ng bagong address.

Ang pagkakaibang iyon ay pagkakaiba sa oras, hindi agarang migrasyon. Ang mahabang buhay ng cache ay nagpapabagal sa pagtanggap ng endpoint na pinalitan ng pangalan, at hindi nakikita ang pagkaantala kung ang tinitingnan mo lamang ay ang rekord ng DNS. Planuhin ang pagpapalit ng pangalan sa paligid ng buhay ng cache at ng pag-uugali ng pagpaparehistro ng naka-install na release, sa halip na ipagpalagay na sabay na gumagalaw ang bawat tunnel.

Ang statikong anyo ay may sariling pagkaantala, siyempre: walang nagbabago hanggang sa ma-edit ang bawat spoke. Ang paghahambing ay sa pagitan ng coordinated na pagtulak ng configuration at ng naka-cache na pag-refresh ng discovery, hindi sa pagitan ng mabagal at agarang.

Ihambing ang hindi nagbabago

Hindi gumagalaw ang pagpapatunay ng peer. Ang hostname na naghahanap ng transport endpoint ay hindi pumapalit sa naka-configure na pagkakakilanlang IKE o sa patakaran ng pagpapatunay na nagva-validate sa peer. Kung mali ang pagkakakilanlan, ang matagumpay na resolusyon ng DNS ay mas mabilis ka lamang dalhin sa isang tinanggihang tunnel.

Hindi rin nagbabago ang protektadong trapiko. Ang NHS na tumutugon ay hindi nagpapatunay na umiiral ang ruta ng kliyente o pinapayagan ang daloy ng aplikasyon. Ang pagpaparehistro, routing at patakaran ay tatlong pagsusuri, at ang pangalan ay nakakaapekto lamang sa unang hakbang na nagpapakain sa kanila.

Isang paghahambing na maaari mong i-verify

Nakadokumento ang Cisco ng magkahiwalay na obserbasyon para sa session at sa ugnayan sa NHS. Gamitin ang show dmvpn upang basahin ang estado ng peer at session, at ang show ip nhrp nhs upang basahin ang view ng pagpaparehistro ng NHS. Ihambing ang niresolbang transport address, ang peer ng overlay at ang estado ng pagpaparehistro sa ganoong pagkakasunod-sunod.

Ang kabanata ng IOS XE FQDN-DMVPN ay nagdodokumento ng pag-uugali ng discovery, cache at paghihigpit sa likod ng paghahambing na ito. Basahin ito laban sa iyong naka-install na release bago ituring ang isang hub na pinalitan ng pangalan bilang direktang kapalit ng isang may numero.