નામવાળું વિરુદ્ધ ક્રમાંકિત DMVPN હબ: FQDN શું બદલે છે

DMVPN સ્પોક આ સુવિધા ધરાવતા પ્લેટફોર્મ પર હોસ્ટનામ દ્વારા પોતાનું હબ શોધી શકે છે, અને પ્રથમ લાલચ એ છે કે તે હોસ્ટનામને હબ ટનલ સરનામું લખવાની બીજી રીત તરીકે વાંચવું. એમ નથી. નામ ટ્રાન્સપોર્ટ એન્ડપોઇન્ટમાં ઉકેલાય છે, જ્યારે હબ પ્રોટોકોલ સરનામું ઓવરલેની અંદરનું આગલું હોપ ઓળખે છે, અને બંને ભૂમિકાઓ દરેક રૂપરેખાંકન સ્વરૂપમાં ટકી રહે છે. એ ભેદ નક્કી કરે છે કે નામ બદલવાથી શું સુધરી શકે છે અને શું નહીં.

બે સરનામાં, બે કામ

એક ઘોષિત ઉદાહરણમાં, hub.example.net સ્પોકને કહે છે કે ટ્રાન્સપોર્ટ ટ્રાફિક ક્યાં મોકલવો, અને 10.90.0.1 ટનલની અંદરનું NHS ઓળખે છે. ડિસ્કવરી પ્રથમ પર કાર્ય કરે છે; નોંધણી અને રૂટિંગ બીજા પર કાર્ય કરે છે. નામમાં ફેરફાર એન્ડપોઇન્ટ સુધીના માર્ગને અસર કરે છે, જ્યારે પ્રોટોકોલ સરનામામાં ફેરફાર ઓવરલે સંબંધને જ અસર કરે છે.

ભૂમિકાઓને અલગ રાખવી એ જ નામવાળા સ્વરૂપને ડિબગ કરી શકાય તેવું બનાવે છે. જ્યારે સ્પોક નોંધણી કરી શકતું ન હોય, ત્યારે તમે બે અલગ પ્રશ્નો પૂછી શકો છો: શું નામ મારી અપેક્ષિત સરનામામાં ઉકેલાયું, અને શું તે સરનામું રૂપરેખાંકન જે પ્રોટોકોલ સરનામાનો દાવો કરે છે તેની સાથે મેળ ખાતું હતું? કોઈ પણ જવાબ બીજાને સૂચવતો નથી.

બે રૂપરેખાંકન સ્વરૂપોની સરખામણી કરો

એક સ્વરૂપ નામની સાથે NHS પ્રોટોકોલ સરનામું સ્પષ્ટ રીતે રૂપરેખાંકિત કરે છે. બીજું સ્પોકને નોંધણી જવાબમાંથી તે પ્રોટોકોલ સરનામું શીખવા દે છે. બંને દસ્તાવેજીકૃત છે, અને સફળ થાય ત્યારે બંને સમાન પ્રકારના NHS સંબંધ સાથે પૂર્ણ થાય છે.

સ્પષ્ટ સ્વરૂપમાં એક મર્યાદા છે જે યાદ રાખવા જેવી છે: ઉકેલાયેલું ટ્રાન્સપોર્ટ સરનામું જે રૂપરેખાંકિત પ્રોટોકોલ સરનામા પર મેપ ન થાય તો નોંધણી અટકે છે. આ DNS નિષ્ફળતા નથી, છતાં લક્ષણ DNS ફેરફાર પછી તરત જ દેખાય છે. નામ યોગ્ય રીતે ઉકેલાયું અને પરિણામ બીજા કારણસર નકારવામાં આવ્યું. ઉકેલાયેલું સરનામું અને રૂપરેખાંકિત પ્રોટોકોલ સરનામું સાથે સાથે વાંચો.

શીખવાનું સ્વરૂપ એક હાથે કરવાનું પગલું અને ડ્રિફ્ટનો એક સ્રોત દૂર કરે છે, તેના બદલામાં મેપિંગ સ્થાપિત કરવા જવાબ પર આધાર રાખે છે. જ્યારે હબ સરનામું સ્થિર હોય અને તમે ઇચ્છો કે અસંગતિ મોટેથી નિષ્ફળ થાય, ત્યારે સ્પષ્ટ સ્વરૂપ પસંદ કરો. જ્યારે હબ પ્રોટોકોલ સરનામું બદલાઈ શકે અને તમે પસંદ કરો કે સ્પોક તેને અનુસરે, ત્યારે શીખવાનું સ્વરૂપ પસંદ કરો. કોઈ પણ રીતે, ડિઝાઇન કયું સ્વરૂપ વાપરે છે તે નોંધો.

સ્થિર હબ સાથે DNS કેશની સરખામણી કરો

કોઈ રૂપરેખાંકન સંપાદિત કરે ત્યારે સ્થિર હબ સરનામું બદલાય છે. નામવાળું હબ DNS બદલાય ત્યારે બદલાય છે, અને DNS જવાબો તેમના આયુષ્ય માટે કેશમાં રાખવામાં આવે છે. દસ્તાવેજીકરણ નોંધે છે કે કેશ કરેલી માહિતી સમાપ્ત થાય ત્યાં સુધી વાપરી શકાય તેવી રહે છે, અને પછીની ક્વેરી નવું સરનામું પાછું આપી શકે છે.

એ ભેદ સમયનો ભેદ છે, તાત્કાલિક સ્થળાંતર નહીં. લાંબું કેશ આયુષ્ય નામ બદલાયેલા એન્ડપોઇન્ટને અપનાવવામાં વિલંબ કરે છે, અને જો તમે ફક્ત DNS રેકોર્ડ જુઓ તો વિલંબ અદૃશ્ય હોય છે. દરેક ટનલ એકસાથે ખસે છે એમ ધારવાને બદલે કેશ આયુષ્ય અને સ્થાપિત રિલીઝના નોંધણી વર્તનની આસપાસ નામ બદલવાની યોજના કરો.

સ્થિર સ્વરૂપનો પોતાનો વિલંબ ચોક્કસ છે: દરેક સ્પોક સંપાદિત ન થાય ત્યાં સુધી કંઈ બદલાતું નથી. સરખામણી સંકલિત રૂપરેખાંકન ધક્કા અને કેશ કરેલા ડિસ્કવરી રિફ્રેશ વચ્ચે છે, ધીમા અને તાત્કાલિક વચ્ચે નહીં.

શું સમાન રહે છે તેની સરખામણી કરો

પીઅર પ્રમાણીકરણ ખસતું નથી. ટ્રાન્સપોર્ટ એન્ડપોઇન્ટ શોધતું હોસ્ટનામ રૂપરેખાંકિત IKE ઓળખ કે પીઅરને ચકાસતી પ્રમાણીકરણ નીતિને બદલતું નથી. ઓળખ ખોટી હોય તો સફળ DNS રિઝોલ્યુશન તમને ફક્ત નકારેલી ટનલ સુધી ઝડપથી પહોંચાડે છે.

સુરક્ષિત ટ્રાફિક પણ અપરિવર્તિત છે. જવાબ આપતું NHS એ સાબિત કરતું નથી કે ગ્રાહક રૂટ અસ્તિત્વમાં છે અથવા એપ્લિકેશન પ્રવાહને મંજૂરી છે. નોંધણી, રૂટિંગ અને નીતિ ત્રણ તપાસ છે, અને નામ ફક્ત તેમને પોષતા પ્રથમ પગલા પર અસર કરે છે.

તમે ચકાસી શકો તેવી સરખામણી

Cisco સત્ર અને NHS સંબંધ માટે અલગ અવલોકનોનું દસ્તાવેજીકરણ કરે છે. પીઅર અને સત્ર સ્થિતિ વાંચવા માટે show dmvpn વાપરો, અને NHS નોંધણી દૃશ્ય વાંચવા માટે show ip nhrp nhs વાપરો. ઉકેલાયેલું ટ્રાન્સપોર્ટ સરનામું, ઓવરલે પીઅર અને નોંધણી સ્થિતિ તે ક્રમમાં સરખાવો.

IOS XE FQDN-DMVPN પ્રકરણ આ સરખામણી પાછળનું ડિસ્કવરી, કેશિંગ અને મર્યાદા વર્તનનું દસ્તાવેજીકરણ કરે છે. નામ બદલાયેલા હબને ક્રમાંકિત હબના સીધા વિકલ્પ તરીકે ગણતા પહેલાં તમારા સ્થાપિત રિલીઝ સામે તેને વાંચો.