नाम भएको र नम्बर भएको DMVPN हब: FQDN ले के बदल्छ
हबको FQDN ले NBMA अन्त्य बिन्दु पत्ता लगाउँछ, टनेल ठेगाना होइन। हबको नाम बदल्दा डिस्कभरी, दर्ता र DNS क्यासले के बदल्छ भन्ने तुलना गर्नुहोस्।
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 अध्याय ले यो तुलनापछिको डिस्कभरी, क्यासिङ र सीमा व्यवहार अभिलेख गर्छ। नाम बदलिएको हबलाई नम्बर भएको हबको सीधा प्रतिस्थापन मान्नुअघि यसलाई तपाईंको स्थापित रिलिजसँग तुलना गरी पढ्नुहोस्।