DMVPN टप्पा 3: शॉर्टकट दोन्ही दिशांनी वाचणे
एक सरळ ping DMVPN टप्पा 3 शॉर्टकट सिद्ध करत नाही. पुढे आणि परतचे मार्ग चाला, नंतर NHRP, रूट आणि IPsec स्थिती वेगवेगळी वाचा.
तुम्ही एक ping spoke ते spoke जाताना पाहता, तो hub मार्गे लांबचा रस्ता घेतो, आणि दुसरा सरळ जातो. त्या क्षणी शॉर्टकट काम करतोय असे जाहीर करणे मोहक वाटते. तो निष्कर्ष अर्धा बरोबर आहे. पुढचा मार्ग शॉर्टकट असू शकतो, तर परतीचा मार्ग अजूनही hub मार्गे जात असतो, आणि प्रत्येक दिशा सिद्ध करणारी स्थिती वेगळी स्थिती आहे. दोन्ही दिशा चाला आणि रचना निरोगी मानण्यापूर्वी तीन तक्ते वाचा.
तुम्ही प्रत्यक्षात पाहू शकता त्या पॅकेट मार्गापासून सुरुवात करा
सरळ असाव्या अशा गंतव्यस्थानासह spoke वर सुरुवात करा. पहिले पॅकेट ट्रेस करा: ते spoke च्या रूटने hub कडे जाते, कारण अजून शॉर्टकट नाही. hub ते पुढे पाठवते आणि टप्पा 3 रचनेत स्रोताकडे चांगला मार्ग आहे असे सांगणारे रीडायरेक्टही पाठवते.
तो रीडायरेक्ट ट्रिगर आहे, पुरावा नाही. तो सांगतो की hub ने अशी रहदारी पाहिली जी अनुकूल करता येईल. स्रोताने शॉर्टकट बांधला, गंतव्यस्थानाने रिझोल्यूशनला उत्तर दिले, किंवा परतीचा मार्ग तो वापरतो असे तो सांगत नाही.
म्हणून पहिले उपयुक्त निरीक्षण म्हणजे आधी आणि नंतर: hub मार्गे पहिला प्रवाह, नंतरचा प्रवाह सरळ.
एकच बोगदा वाटणाऱ्या तीन स्थिती
शॉर्टकट तीन स्थिती-भागांवर अवलंबून आहे, आणि प्रत्येकाचे स्वतःचे आयुष्य आणि स्वतःचा आदेश आहे.
| State | What it answers | Where to read it |
|---|---|---|
| NHRP cache | Which transport address maps to this overlay address | show ip nhrp |
| Route or shortcut | Where one specific inner prefix is forwarded | show ip route 10.10.20.5 |
| IPsec association | Which peer traffic is protected, and by which SA | show crypto ipsec sa peer 203.0.113.5 |
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 मार्गदर्शक त्याच्या शेजारी ठेवा.