Nomita kontraŭ numera DMVPN-habo: kion ŝanĝas la FQDN
Haba FQDN lokas la NBMA-finpunkton, ne la tunelan adreson. Komparu, kion malkovro, registriĝo kaj DNS-kaŝmemoro ŝanĝas kiam habo renomiĝas.
DMVPN-spoke povas trovi sian habon per gastigantnomo sur platformoj, kiuj subtenas tiun funkcion, kaj la unua tento estas legi tiun gastigantnomon kiel alian manieron skribi la tunelan adreson de la habo. Ĝi ne estas tio. La nomo solviĝas al transporta finpunkto, dum la haba protokoladreso identigas la sekvan salteton ene de la overlay, kaj ambaŭ roloj restas en ĉiu agorda formo. Tiu distingo decidas, kion renomigo povas kaj ne povas ripari.
Du adresoj, du taskoj
En deklarita ekzemplo, hub.example.net diras al la spoke kien sendi transportan trafikon, kaj 10.90.0.1 identigas la NHS ene de la tunelo. Malkovro funkcias sur la unua; registriĝo kaj enkursigado funkcias sur la dua. Ŝanĝo de la nomo efikas al la vojo al la finpunkto, dum ŝanĝo de la protokoladreso efikas al la overlay-rilato mem.
Apartigo de la roloj estas tio, kio faras la nomitan formon sencimigebla. Kiam spoke malsukcesas registriĝi, vi povas starigi du malsamajn demandojn: ĉu la nomo solviĝis al la adreso, kiun mi atendis, kaj ĉu tiu adreso kongruis kun la protokoladreso, kiun la agordo asertas? Neniu respondo implicas la alian.
Komparu la du agordajn formojn
Unu formo agordas la NHS-protokoladreson eksplicite apud la nomo. La alia lasas la spoke lerni tiun protokoladreson el la registriĝa respondo. Ambaŭ estas dokumentitaj, kaj ambaŭ finiĝas per la sama speco de NHS-rilato, kiam ili sukcesas.
La eksplicita formo portas limigon indan je memoro: solvita transporta adreso, kiu ne mapiĝas al la agordita protokoladreso, malhelpas registriĝon. Tio ne estas DNS-malsukceso, kvankam la simptomo aperas tuj post DNS-ŝanĝo. La nomo solviĝis ĝuste kaj la rezulto estis malakceptita pro alia kialo. Legu la solvitan adreson kaj la agorditan protokoladreson unu apud la alia.
La lerna formo forigas unu manan paŝon kaj unu fonton de drivo, kontraŭ la kosto dependi de la respondo por establi la mapadon. Elektu la eksplicitan formon, kiam la haba adreso estas stabila kaj vi volas, ke la malkongruo laŭte malsukcesu. Elektu la lernan formon, kiam la haba protokoladreso povas ŝanĝiĝi kaj vi prefere volas, ke la spoke sekvu ĝin. Ĉiuokaze notu, kiun formon la dezajno uzas.
Komparu DNS-kaŝmemoron kun senmova habo
Senmova haba adreso ŝanĝiĝas, kiam iu redaktas la agordon. Nomita habo ŝanĝiĝas, kiam DNS ŝanĝiĝas, kaj DNS-respondoj kaŝmemoriĝas por sia vivdaŭro. La dokumentaro notas, ke kaŝmemorita informo restas uzebla ĝis ĝi eksvalidiĝas, kaj posta demando tiam povas redoni la novan adreson.
Tiu diferenco estas tempo-diferenco, ne tuja migrado. Longa kaŝmemora vivdaŭro prokrastas la adoptadon de renomita finpunkto, kaj la prokrasto estas nevidebla, se vi observas nur la DNS-rikteton. Planu renomigon ĉirkaŭ la kaŝmemora vivdaŭro kaj la registriĝa konduto de la instalita eldono, anstataŭ supozi, ke ĉiu tunelo moviĝas samtempe.
La senmova formo havas, kompreneble, sian propran prokraston: nenio ŝanĝiĝas, ĝis ĉiu spoke estas redaktita. La komparo estas inter kunordigita agorda puŝo kaj kaŝmemorita malkovra refreŝigo, ne inter malrapida kaj tuja.
Komparu, kio restas la sama
Pera aŭtentikigo ne moviĝas. Gastigantnomo, kiu lokas la transportan finpunkton, ne anstataŭigas la agorditan IKE-identecon nek la aŭtentikigan politikon, kiu validigas la peron. Se la identeco estas malĝusta, sukcesa DNS-solvo nur kondukas vin pli rapide al malakceptita tunelo.
Protektita trafiko ankaŭ ne ŝanĝiĝis. Respondanta NHS ne pruvas, ke la klienta vojo ekzistas aŭ ke la aplikaĵa fluo estas permesita. Registriĝo, enkursigado kaj politiko estas tri kontroloj, kaj la nomo efikas nur al la unua paŝo, kiu nutras ilin.
Komparo, kiun vi povas kontroli
Cisco dokumentas apartajn observojn por la sesio kaj la NHS-rilato. Uzu show dmvpn por legi la peran kaj sesian staton, kaj show ip nhrp nhs por legi la NHS-registriĝan vidon. Komparu la solvitan transportan adreson, la overlay-peron kaj la registriĝan staton en tiu ordo.
La ĉapitro IOS XE FQDN-DMVPN dokumentas la malkovran, kaŝmemoran kaj limigan konduton malantaŭ ĉi tiu komparo. Legu ĝin kontraŭ via instalita eldono antaŭ ol trakti renomitan habon kiel rektan anstataŭaĵon por numera.