EIGRP छिमेकी कि DMVPN ट्रान्जिट? पहिले भूमिका जाँच्नुहोस्

छिमेक छैन, र बीचको राउटर स्पष्ट शंकास्पद देखिन्छ। यो निर्दोष पनि हुन सक्छ। बाहिरी टनेल प्याकेट अगाडि पठाउनु र overlay राउटिङ प्रोटोकलमा सहभागी हुनु दुई फरक काम हुन्, र उपकरणले दोस्रो नगरी पहिलो गर्न सक्छ। तलका पाँच जाँच क्रममा गर्नुहोस् र पहिलो असफल जाँचमा रोकिनुहोस्।

चरण 1: दुई भूमिका कोर्नुहोस्

इच्छित EIGRP छिमेकलाई दुई राउटरबीचको तार्किक जडानका रूपमा कोर्नुहोस्, त्यसपछि त्यसका टनेल प्याकेट बोक्ने underlay राउटर कोर्नुहोस्। एउटै उपकरण दुवै सूचीमा हुनुपर्ने छैन, र सूचीहरू मिसाउनु नै स्वस्थ ट्रान्जिट राउटरमाथि छिमेक बिगारेको आरोप लाग्ने सबैभन्दा सामान्य कारण हो।

ट्रान्जिट राउटरले आफ्नो सामान्य IP राउटिङ र नीतिबाट बाहिरी प्याकेट अगाडि पठाउँछ। सुरक्षित टनेलभित्र बोकिने प्रोटोकल चलाउनु आवश्यक छैन, र ती प्याकेट अगाडि पठाउन EIGRP प्रक्रिया पनि चाहिँदैन।

चरण 2: बीचको उपकरणले के अन्त्य गर्छ जाँच्नुहोस्

यदि बीचको राउटरले टनेल अन्त्य गर्छ र spoke सँग EIGRP छिमेक बनाउनुपर्ने हो भने उत्तर पूर्ण रूपमा बदलिन्छ। त्यो उपकरणलाई समर्थित overlay राउटिङ व्यवहार चाहिन्छ, र यसलाई ट्रान्जिट भन्नाले छिमेकीको सर्त हट्दैन। राउटिङ कन्फिगरेसनभन्दा पहिले टनेल कन्फिगरेसन पढ्नुहोस्। त्यही उत्तरले पछिका हरेक जाँच निर्धारण गर्छ।

त्यसैले पहिलो वास्तविक प्रश्न कुन प्रोटोकल ट्युन गर्ने होइन। प्रश्न यो हो कि त्यो बाकस hub हो, spoke हो, शुद्ध underlay हप हो, वा टोकाबीच फ्रेम बोक्ने Layer 2 सेवा हो।

चरण 3: छिमेकीको नियन्त्रण तल जाँच्नुहोस्

छिमेकी हुनुपर्ने हरेक उपकरणमा चार कुरा पुष्टि गर्नुहोस्: EIGRP इन्स्टेन्स र स्वायत्त प्रणाली नम्बर, प्रमाणीकरण प्यारामिटर, प्रक्रियामा सहभागी इन्टरफेस, र त्यो इन्टरफेस ढाक्ने नेटवर्क कथन। यीमध्ये कुनैमा बेमेल भए इन्टरफेस माथि र ping चलिरहँदा छिमेक तल रहन्छ।

RFC 7868 ले EIGRP लाई मल्टिकास्ट नियन्त्रण आदानप्रदानसहितको IP प्रोटोकल भनी वर्णन गर्छ, त्यसैले छिमेकी सम्बन्ध त्यस्तो कुरा होइन जसलाई मध्यस्थ राउटरले प्याकेट गन्तव्यतर्फ राउट गरेर प्रतिस्थापन गर्न सक्छ। या त नियन्त्रण आदानप्रदान साथीसम्म पुग्छ, या छिमेक बन्दैन।

चरण 4: यातायातले नियन्त्रण आदानप्रदान पुर्‍याउँछ कि जाँच्नुहोस्

अब, overlay ले इच्छित टोकाबीच नियन्त्रण ट्राफिक साँच्चै बोक्छ कि जाँच्नुहोस्। साथीको NHRP म्यापिङ र त्यहाँ पुग्ने बाहिरी मार्ग जाँच्नुहोस्, त्यसपछि टनेल इन्टरफेस माथि छ र ट्राफिक पास गर्छ भनी पुष्टि गर्नुहोस्। सफल underlay ping ले बाहिरी बाटो अवस्थित छ भनी प्रमाणित गर्छ; overlay नियन्त्रण आदानप्रदान पुग्यो भनी प्रमाणित गर्दैन।

पारदर्शी Layer 2 सेवा, बिन्दु-देखि-बिन्दु टनेल र बहु-बिन्दु DMVPN क्लाउडले मल्टिकास्ट फरक तरिकाले पुर्‍याउँछन्। तीनवटै उस्तै व्यवहार गर्छन् भनी मान्नुको सट्टा वास्तवमा तैनाथ भएकोका लागि समर्थित इन्टरफेस, NHRP र मल्टिकास्ट मोडेल पछ्याउनुहोस्।

चरण 5: सहभागी हुन नसक्ने भए सीमा पुनःडिजाइन गर्नुहोस्

यदि आवश्यक overlay उपकरणले प्रोटोकल चलाउन सक्दैन भने डिजाइन स्पष्ट रूपमा बदल्नुहोस्। त्यो सीमामा समर्थित प्रोटोकल वा आदानप्रदान मोडेल प्रयोग गर्नुहोस्, वा छिमेकीहरू साँच्चै एक-अर्कासँग बोल्ने टोका हुने गरी उपयुक्त टोका-देखि-टोका टनेल मिलाउनुहोस्। स्थिर मार्गले सहभागी नहुनेलाई हरेक नियन्त्रण प्याकेटका लागि रिले बनाउँछ भनी नमान्नुहोस्।

चित्रमा हरेक उपकरणको भूमिका लेख्नुहोस् र कन्फिगरेसनसँगै राख्नुहोस्। RFC 7868 ले प्रोटोकल आदानप्रदान परिभाषित गर्छ, र त्यही परिभाषा ट्रान्जिट फर्वार्डिङले छिमेकी सम्बन्ध अनुकरण गर्न नसकिने आधार हो।

पाँचै जाँचपछि पनि छिमेक बन्दैन भने बाँकी शंकास्पद प्लेटफर्म विशेषता हुन्, जस्तै टनेल इन्टरफेसमा मल्टिकास्ट ह्यान्डलिङ र 88 प्रोटोकल फिल्टर गर्ने नीति। यी ठोस, परीक्षणयोग्य कारण हुन् र बीचको राउटरलाई दोष दिने अर्को चरणभन्दा बढी मूल्यवान् छन्।