BGP सत्र सुरू, ग्राहकाचा मार्ग तुटलेला: DMVPN वर MPLS

पीअरिंग आठवड्यांपासून सुरू आहे, प्रीफिक्सची संख्या बरोबर दिसते, तरीही एका ग्राहकाची रहदारी अजूनही लांबचा मार्ग घेते किंवा पोहोचतच नाही. एकाच निर्देशकाने दोन वेगळ्या गोष्टींचे मूल्यांकन होत आहे. BGP सत्र सांगते की दोन पीअर TCP जोडणीवर संदेशांची देवघेव करू शकतात; त्या विशिष्ट ग्राहकासाठी लेबल असलेले पॅकेट ओव्हरले वाहून नेऊ शकते का, याबद्दल ते काहीही सांगत नाही.

ही दरी MPLS-over-DMVPN रचनेत सर्वात सहज दिसते, जिथे हब मार्ग आणि थेट स्पोक मार्ग पीअरिंगशी काहीही संबंध नसलेल्या कारणांमुळे वेगळे वागू शकतात.

सत्र प्रत्यक्षात काय सिद्ध करते

BGP TCP वर चालते, म्हणून दुसरे काहीही घडण्यापूर्वी प्रत्येक पीअरला दुसऱ्या टोकाच्या पत्त्यापर्यंत मार्ग हवा. ते टोक म्हणून loopback निवडल्यास तुम्ही फॉर्वर्डिंगची हमी नाही, तर पोहोचण्याची अट तयार केली आहे. त्यानंतर सत्र अशा इंटरफेसवरून सुरू राहू शकते ज्याचा ग्राहकाची रहदारी कधीही वापर करणार नाही.

निष्कर्ष काढण्यापूर्वी दोन्ही टोकांवर चार तथ्ये नोंदवा: सत्राचा स्रोत पत्ता, गंतव्य पत्ता, ते ज्या राउटिंग संदर्भात आहे, आणि कर्नेल किंवा राउटर त्या जोडीसाठी कोणता इंटरफेस निवडेल. ही तथ्ये नियंत्रण स्तराचे वर्णन करतात. ग्राहकाचे पॅकेट त्यावर VRF, लेबल स्टॅक आणि ओव्हरले मॅपिंग जोडतात.

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

MPLS-over-DMVPN बद्दलचे Ciscoचे दस्तऐवज भाग स्पष्टपणे वेगळे करते. MP-BGP प्रदात्याच्या कडेच्या उपकरणांमध्ये ग्राहकाची ओव्हरले लेबल वितरित करते. MPLS ती लेबल पॅकेटचा फॉर्वर्डिंग संदर्भ निवडण्यासाठी वापरते. NHRP ओव्हरले पत्ता डायनॅमिक टनेलला लागणाऱ्या ट्रान्सपोर्ट टोकाशी मॅप करते. IPsec लागू होते तिथे पीअर मार्गाचे संरक्षण करते.

चारपैकी कोणतेही बरोबर असू शकते आणि दुसरे चूक, आणि रहदारी वाहून नेणारे हेच संयोजन असते. मार्गांची देवघेव पूर्ण होऊ शकते पण एका VRFचे लेबल बंधन नाही, NHRP मॅपिंग जुन्या ट्रान्सपोर्ट पत्त्याकडे दाखवत आहे, किंवा टनेल आहे पण कोणतेही धोरण आतील पॅकेटला परवानगी देत नाही. यापैकी कोणतीही स्थिती सत्र पाडत नाही.

हब मार्गाची शॉर्टकटशी तुलना करा, एका वेळी एक चल

स्रोत होस्ट, गंतव्य होस्ट आणि VRF स्थिर करा, मग तोच प्रवाह दोन वेळा पाठपुरावा करा. हब मार्गावर पुढील हॉप, दूरच्या ग्राहक संदर्भाची ओळख करणारे सेवा लेबल आणि वापरात असलेले ओव्हरले-ते-ट्रान्सपोर्ट मॅपिंग नोंदवा. इच्छित थेट मार्गावरही तेच तीन गोष्टी नोंदवा. दोन्ही याद्यांतील फरक हाच बिघाड, किंवा बिघाडाचा अभाव.

तुलना करताना प्रवाह स्थिर ठेवा. निरीक्षणांमधील स्रोत होस्ट, VRF किंवा गंतव्य बदलल्यास दोन असंबंधित कथा तयार होतात, आणि हा व्यायाम चुकण्याचा सर्वात सामान्य मार्ग हाच आहे.

loopback चाचण्या त्यांच्या स्वतःच्या कप्प्यात ठेवा

राउटरच्या loopbackवरून पाठवलेला ping उपयुक्त चाचणी आहे, आणि तो होस्टवरील प्रवाहापेक्षा वेगळी स्थिती तपासतो. स्रोत पत्ता राउटरचा असतो, त्याचा राउटिंग संदर्भ VRFऐवजी जागतिक असू शकतो, आणि उत्तराचा मार्ग ग्राहक प्रीफिक्स घेईल त्यापेक्षा वेगळा असू शकतो. म्हणून loopback उत्तर देणे आणि हे अनुप्रयोग शॉर्टकटवर चालणे या वेगळ्या निकाल आहेत, आणि फक्त दुसरा ग्राहकाचे वर्णन करतो.

दोन्ही तपासा, मग तुमच्या टिपांमध्ये ते वेगळे चिन्हांकित करा. ते जुळत नसल्यास, रचना कुठे भरकटते याबद्दल काहीतरी ठोस शिकलात, आणि एका हिरव्या खुणेने कधीही सांगू शकण्यापेक्षा ते जास्त आहे.

आवृत्ती आणि बिघाडाच्या दाव्यांना स्वतःचे पुरावे लागतात

क्षेत्र अहवाल कधीकधी होस्ट मास्क किंवा BGP स्रोत पत्ता बदलण्याची शिफारस करतात, आणि असे अहवाल ज्या बिघाडाबद्दल ते लिहिले गेले आणि ज्या आवृत्त्यांना त्याचा फटका बसला त्यांच्यासोबतच वाचण्यासारखे असतात. एका आवृत्तीचा उपाय म्हणजे प्रत्येक /32 प्रीफिक्स रचनेद्वारे असमर्थित आहे असे विधान नाही.

तुमच्या DMVPN टप्प्याशी, प्लॅटफॉर्मशी आणि आवृत्तीशी जुळणारे दस्तऐवज वापरा, आणि एका प्रकरणात FlexVPNसह अनेक मांडण्या येऊ शकतात हे लक्षात ठेवा. एका मांडणीचे उदाहरण दुसऱ्याकडे शांतपणे जात नाही. तुम्हाला खरोखर आवश्यक असलेल्या नियंत्रण-स्तर रचनेसाठी सत्राची टोके निवडा, मग ग्राहकाचा फॉर्वर्डिंग मार्ग वेगळा तपासा, कारण प्रत्येक loopback मास्क पुन्हा लिहिणे कोणते काम अयशस्वी झाले हे शोधण्याचा पर्याय नाही.