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 प्रोटोकॉल फिल्टर करणारे धोरण. ही ठोस, तपासण्यायोग्य कारणे आहेत आणि मधल्या राउटरला दोष देण्याच्या अजून एका फेरीपेक्षा जास्त मोलाची आहेत.