नामित बनाम क्रमांकित 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 अध्याय इस तुलना के पीछे की डिस्कवरी, कैशिंग और सीमा व्यवहार को प्रलेखित करता है। नाम बदले गए हब को क्रमांकित हब का सीधा प्रतिस्थापन मानने से पहले इसे अपने स्थापित रिलीज़ के सामने पढ़ें।