BGP सत्र चालू, ग्राहक का रास्ता टूटा: DMVPN पर MPLS

पीयरिंग हफ़्तों से चालू है, प्रीफ़िक्स की गिनती सही दिखती है, और फिर भी एक ग्राहक का ट्रैफ़िक अब भी लंबा रास्ता लेता है या पहुँचता ही नहीं। एक ही संकेतक से दो अलग बातों का मूल्यांकन हो रहा है. BGP सत्र बताता है कि दो पीयर TCP कनेक्शन पर संदेशों का आदान-प्रदान कर सकते हैं; यह इस बारे में कुछ नहीं कहता कि ओवरले उस विशेष ग्राहक के लिए लेबल वाला पैकेट ले जा सकता है या नहीं।

यह अंतराल MPLS-over-DMVPN डिज़ाइन में सबसे आसानी से दिखता है, जहाँ हब पथ और सीधा स्पोक पथ ऐसे कारणों से अलग व्यवहार कर सकते हैं जिनका पीयरिंग से कोई संबंध नहीं है।

सत्र वास्तव में क्या साबित करता है

BGP TCP पर चलता है, इसलिए किसी भी अन्य चीज़ से पहले हर पीयर को दूसरे छोर के पते तक एक मार्ग चाहिए। यदि उस छोर के रूप में लूपबैक चुनें, तो आपने फ़ॉरवर्डिंग की गारंटी नहीं, बल्कि पहुँच की शर्त बनाई है। इसके बाद सत्र ऐसे इंटरफ़ेस से भी चालू रह सकता है जिसका ग्राहक का ट्रैफ़िक कभी उपयोग नहीं करेगा।

निष्कर्ष निकालने से पहले दोनों सिरों पर चार तथ्य लिखें: सत्र का स्रोत पता, गंतव्य पता, वह राउटिंग संदर्भ जिसमें वह बैठा है, और कर्नेल या राउटर उस जोड़ी के लिए कौन-सा इंटरफ़ेस चुनेगा। ये तथ्य नियंत्रण तल का वर्णन करते हैं। ग्राहक के पैकेट इनके ऊपर VRF, लेबल स्टैक और ओवरले मैपिंग जोड़ते हैं।

चार तंत्र, एक नहीं

MPLS-over-DMVPN पर Cisco का दस्तावेज़ भागों को स्पष्ट रूप से अलग करता है। MP-BGP प्रदाता के किनारे के उपकरणों के बीच ग्राहक के ओवरले लेबल वितरित करता है। MPLS उन लेबलों का उपयोग पैकेट के फ़ॉरवर्डिंग संदर्भ को चुनने के लिए करता है। NHRP ओवरले पते को उस ट्रांसपोर्ट छोर पर मैप करता है जिसकी गतिशील टनल को आवश्यकता होती है। IPsec जहाँ लागू हो वहाँ पीयर पथ की रक्षा करता है।

इनमें से कोई भी सही हो सकता है जबकि दूसरा ग़लत हो, और यही संयोजन ट्रैफ़िक ले जाता है। मार्गों का आदान-प्रदान पूरा हो सकता है जबकि एक VRF के लिए लेबल बाइंडिंग अनुपस्थित हो, जबकि NHRP मैपिंग पुराने ट्रांसपोर्ट पते की ओर इशारा कर रही हो, या जबकि टनल मौजूद हो पर कोई नीति भीतरी पैकेट की अनुमति न दे। इनमें से कोई भी स्थिति सत्र को नहीं गिराती।

हब पथ की तुलना शॉर्टकट से करें, एक बार में एक चर

स्रोत होस्ट, गंतव्य होस्ट और VRF को स्थिर रखें, फिर उसी प्रवाह को दो बार देखें। हब पथ पर अगला हॉप, दूरस्थ ग्राहक संदर्भ की पहचान करने वाला सेवा लेबल, और प्रयुक्त ओवरले-से-ट्रांसपोर्ट मैपिंग लिखें। इच्छित सीधे पथ पर वही तीन बातें लिखें। दोनों सूचियों के बीच का अंतर ही ख़राबी है, या उसका अभाव।

तुलना के दौरान प्रवाह को स्थिर रखें। अवलोकनों के बीच स्रोत होस्ट, VRF या गंतव्य बदलने से दो असंबंधित कहानियाँ बनती हैं, और यही इस अभ्यास के बिगड़ने का सबसे सामान्य तरीका है।

लूपबैक परीक्षणों को उनके अलग डिब्बे में रखें

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

दोनों की जाँच करें, फिर अपने नोट्स में उन्हें अलग-अलग चिह्नित करें। जब वे मेल नहीं खाते, तब आपने इस बारे में कुछ ठोस सीखा है कि डिज़ाइन कहाँ भटकता है, और यह एक हरी टिक के कभी बताए जाने से अधिक है।

संस्करण और ख़राबी के दावों को अपने सबूत चाहिए

फ़ील्ड रिपोर्टें कभी-कभी होस्ट मास्क या BGP स्रोत पता बदलने की सलाह देती हैं, और ऐसी रिपोर्टें केवल उस ख़राबी और उन रिलीज़ों के साथ पढ़ने योग्य हैं जिनके बारे में वे लिखी गईं। एक रिलीज़ का वर्कअराउंड यह कथन नहीं है कि आर्किटेक्चर हर /32 प्रीफ़िक्स का समर्थन नहीं करता।

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