DMVPN चरण 3: शॉर्टकट को दोनों दिशाओं में पढ़ना

आप एक ping को spoke से spoke जाते देखते हैं, वह hub से होकर लंबा रास्ता लेता है, और दूसरा सीधा जाता है। उस क्षण शॉर्टकट को काम करता घोषित करना लुभावना है। यह निष्कर्ष आधा सही है। आगे का रास्ता शॉर्टकट हो सकता है जबकि वापसी का रास्ता अब भी hub से जाता हो, और हर दिशा को साबित करने वाली स्थिति अलग स्थिति है। डिज़ाइन को स्वस्थ मानने से पहले दोनों दिशाएँ चलें और तीन तालिकाएँ पढ़ें।

उस पैकेट पथ से शुरू करें जिसे आप वास्तव में देख सकते हैं

ऐसे spoke से शुरू करें जिसका गंतव्य सीधा होना चाहिए। पहले पैकेट को ट्रेस करें: वह spoke के रूट का अनुसरण hub की ओर करता है, क्योंकि अभी कोई शॉर्टकट नहीं है। hub उसे आगे भेजता है और चरण 3 डिज़ाइन में स्रोत को एक रीडायरेक्ट भी भेजता है कि बेहतर रास्ता मौजूद है।

वह रीडायरेक्ट ट्रिगर है, सबूत नहीं। वह कहता है कि hub ने ऐसा ट्रैफ़िक देखा जिसे अनुकूलित किया जा सकता है। वह नहीं कहता कि स्रोत ने शॉर्टकट बनाया, गंतव्य ने रिज़ॉल्यूशन का जवाब दिया, या वापसी पथ उसका उपयोग करता है।

इसलिए पहला उपयोगी अवलोकन पहले और बाद है: पहला फ़्लो hub से, बाद का फ़्लो सीधा।

तीन स्थितियाँ जो एक ही टनल जैसी दिखती हैं

शॉर्टकट तीन स्थिति-भागों पर निर्भर करता है, और हर एक का अपना जीवनकाल और अपना कमांड है।

NHRP कैश प्रविष्टि overlay पते को NBMA ट्रांसपोर्ट पते से मैप करती है। रूट या शॉर्टकट तय करता है कि एक आंतरिक गंतव्य कहाँ फ़ॉरवर्ड होगा। IPsec एसोसिएशन उससे बनने वाले ट्रैफ़िक की रक्षा करता है। गायब जवाब तीनों में से किसी से भी आ सकता है, और कमांड बताते हैं कि कौन गायब है।

उन्हें उसी क्रम में पढ़ें, क्योंकि गायब मैपिंग बाकी दोनों को रोचक नहीं रहने देती।

अनुरोध और जवाब अलग-अलग चलें

spoke A से रिज़ॉल्यूशन माँगें और देखें क्या लौटता है। अनुरोध समर्थित NHRP फ़ॉरवर्डिंग पथ से जाता है, और गंतव्य hub से नहीं, सीधे जवाब दे सकता है। यह असमानता सामान्य है, और इसीलिए जवाब आदान-प्रदान का दिलचस्प आधा हिस्सा है।

अब भूमिकाएँ बदलें। B से A को भेजें और वही तीन पठन दोहराएँ। जो डिज़ाइन एक दिशा में शॉर्टकट करता है और दूसरी में नहीं, वह सममित नहीं है, और असमानता आमतौर पर एक तरफ गायब प्रीफ़िक्स या ऐसे रिज़ॉल्यूशन से आती है जिसे कभी जवाब नहीं मिला।

अनुरोध hub से गया इसलिए साथी के जवाब को hub पार करना ज़रूरी नहीं। इसे त्रुटि न पढ़ें और ऐसी रूटिंग खराबी के पीछे न दौड़ें जो मौजूद ही नहीं।

hub का रीडायरेक्ट पढ़ें, सिर्फ़ उसका रूट नहीं

hub की रूट तालिका बताती है कि hub पैकेट कहाँ भेजेगा। रीडायरेक्ट बताता है कि hub ने स्रोत से इस बारे में क्या करने को कहा। ये अलग तथ्य हैं, और सही रूट वाला पर बिना रीडायरेक्ट भेजने वाला hub हर फ़्लो को अनिश्चित काल तक लंबे पथ पर रखेगा। hub के NHRP ईवेंट जाँचें और पुष्टि करें कि आपके लिए महत्वपूर्ण ट्रैफ़िक के लिए रीडायरेक्ट बन रहे हैं।

चरण 3 सारांश के अर्थ को भी बदलता है। शॉर्टकट व्यवहार के साथ spokes को चरण 2 डिज़ाइन द्वारा अपेक्षित विशिष्ट दूरस्थ रूटों का पूरा सेट नहीं चाहिए, इसलिए spoke पर सारांशित रूट अपने आप गायब नेटवर्क नहीं है। सारांश को खराबी के रूप में पढ़ने से पहले चरण और रूटिंग नीति की पुष्टि करें।

यही एक गलतफहमी किसी भी और चीज़ से अधिक DMVPN टिकट बनाती है।

निष्कर्ष को गायब वस्तु के रूप में दर्ज करें

किसी अधिकृत एप्लिकेशन फ़्लो और उसके जवाब के साथ समाप्त करें, और हर दिशा के लिए नोट करें कि उसने सीधा पथ इस्तेमाल किया या नहीं। फिर निष्कर्ष को उस वस्तु के रूप में लिखें जो गायब थी: मैपिंग, फ़ॉरवर्डिंग शॉर्टकट, सुरक्षा एसोसिएशन या एप्लिकेशन प्रतिक्रिया।

रूटिंग सामीप्य और साझा सुरक्षा एसोसिएशन स्वास्थ्य के प्रमाण हैं, पथ के प्रमाण नहीं। दोनों परिपूर्ण हो सकते हैं जबकि हर पैकेट अब भी लंबा चक्कर लगाता है। पहले फ़ॉरवर्डिंग निर्णय जाँचें, फिर वह एसोसिएशन जो उसे ढोती है। क्रम मायने रखता है, क्योंकि एसोसिएशन किसी भी हाल में बनती है।

यह आदत अगली टिकट पर काम आती है। «टनल ऊपर है पर धीमी» «B के पास A के होस्ट के लिए शॉर्टकट नहीं है» बन जाता है, और दूसरा कथन पाँच मिनट का सुधार है। कमांड आउटपुट निष्कर्ष के साथ रखें, और विक्रेता की चरण 3 मार्गदर्शिका उसके बगल में रखें।