Benoemde teenoor genommerde DMVPN-hub: wat die FQDN verander

’n DMVPN-spoke kan sy hub per gasheernaam vind op platforms wat dié funksie ondersteun, en die eerste versoeking is om dié gasheernaam te lees as nog ’n manier om die hub se tonneladres te skryf. Dit is nie. Die naam los op na ’n vervoereindpunt, terwyl die hub se protokoladres die volgende sprong binne die overlay aandui, en dié twee rolle bly deur elke konfigurasievorm behoue. Daardie onderskeid bepaal wat ’n hernoeming kan regmaak en wat nie.

Twee adresse, twee take

In ’n verklaarde voorbeeld sê hub.example.net vir die spoke waarheen om vervoerverkeer te stuur, en 10.90.0.1 dui die NHS binne die tonnel aan. Ontdekking werk op die eerste; registrasie en roetering werk op die tweede. ’n Verandering aan die naam raak die pad na die eindpunt, terwyl ’n verandering aan die protokoladres die overlay-verhouding self raak.

Dit is die skeiding van die rolle wat die benoemde vorm ontfoutbaar maak. Wanneer ’n spoke nie kan registreer nie, kan jy twee verskillende vrae vra: het die naam na die adres opgelos wat ek verwag het, en het daardie adres by die protokoladres gepas wat die konfigurasie beweer? Geen van die twee antwoorde impliseer die ander nie.

Vergelyk die twee konfigurasievorms

Een vorm konfigureer die NHS-protokoladres uitdruklik saam met die naam. Die ander laat die spoke daardie protokoladres uit die registrasieantwoord leer. Albei is gedokumenteer, en albei eindig met dieselfde soort NHS-verhouding wanneer hulle slaag.

Die uitdruklike vorm het ’n beperking wat die moeite werd is om te onthou: ’n opgeloste vervoeradres wat nie na die gekonfigureerde protokoladres karteer nie, verhoed registrasie. Dit is nie ’n DNS-fout nie, al verskyn die simptoom reg ná ’n DNS-verandering. Die naam het korrek opgelos en die resultaat is om ’n ander rede verwerp. Lees die opgeloste adres en die gekonfigureerde protokoladres langs mekaar.

Die lerende vorm verwyder een handmatige stap en een bron van drywing, teen die koste daarvan dat dit op die antwoord staatmaak om die kartering te vestig. Kies die uitdruklike vorm wanneer die hub-adres stabiel is en jy wil hê die wanverhouding moet hardop misluk. Kies die lerende vorm wanneer die hub se protokoladres kan verander en jy liever wil hê die spoke moet dit volg. Skryf in elk geval neer watter vorm die ontwerp gebruik.

Vergelyk DNS-kas met ’n statiese hub

’n Statiese hub-adres verander wanneer iemand die konfigurasie wysig. ’n Benoemde hub verander wanneer DNS verander, en DNS-antwoorde word vir hul leeftyd gekas. Die dokumentasie noem dat gekaste inligting bruikbaar bly totdat dit verval, en ’n latere navraag kan dan die nuwe adres teruggee.

Daardie verskil is ’n tydsverskil, nie ’n oombliklike migrasie nie. ’n Lang kasleeftyd vertraag die aanvaarding van ’n hernoemde eindpunt, en die vertraging is onsigbaar as jy net die DNS-rekord dophou. Beplan ’n hernoeming rondom die kasleeftyd en die registrasiegedrag van die geïnstalleerde weergawe eerder as om te aanvaar elke tonnel skuif gelyktydig.

Die statiese vorm het natuurlik sy eie vertraging: niks verander totdat elke spoke gewysig is nie. Die vergelyking is tussen ’n gekoördineerde konfigurasie-stoot en ’n gekaste ontdekkingsverfrissing, nie tussen stadig en onmiddellik nie.

Vergelyk wat dieselfde bly

Portuur-verifikasie beweeg nie. ’n Gasheernaam wat die vervoereindpunt vind, vervang nie die gekonfigureerde IKE-identiteit of die verifikasiestelsel wat die portuur valideer nie. As die identiteit verkeerd is, kry ’n suksesvolle DNS-oplossing jou net vinniger by ’n verworpe tonnel.

Beskermde verkeer is ook onveranderd. ’n Reagerende NHS bewys nie dat die kliëntroete bestaan of dat die toepassingvloei toegelaat word nie. Registrasie, roetering en beleid is drie kontroles, en die naam raak net die eerste stap wat hulle voed.

’n Vergelyking wat jy kan verifieer

Cisco dokumenteer afsonderlike waarnemings vir die sessie en die NHS-verhouding. Gebruik show dmvpn om portuur- en sessietoestand te lees, en show ip nhrp nhs om die NHS-registrasieaansig te lees. Vergelyk die opgeloste vervoeradres, die overlay-portuur en die registrasietoestand in dié volgorde.

Die IOS XE FQDN-DMVPN-hoofstuk dokumenteer die ontdekking-, kas- en beperkingsgedrag agter hierdie vergelyking. Lees dit teen jou geïnstalleerde weergawe voordat jy ’n hernoemde hub as ’n direkte plaasvervanger vir ’n genommerde een beskou.