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 मार्गदर्शिका त्यसको छेउमा राख्नुहोस्।