VPN वरून PIM-SM: BSR, RP मॅपिंग आणि RPF मार्ग तपासा

बोगदा सुरू आहे, युनिकास्ट पिंग त्यातून जातात, आणि तरीही प्राप्तकर्ता काळी स्क्रीन दाखवतो। PIM-SM तैनातीत हे लक्षण जवळजवळ नेहमीच सूचित करते की चार नियंत्रण मार्गांपैकी एक तुटलेला आहे, आणि डेटा मार्ग कधीही समस्या नव्हता। खालील यादी क्रमाने करा आणि अपयशी ठरणाऱ्या पहिल्या पायरीवर थांबा, कारण पुढील प्रत्येक पायरी आधीच्या पायरीवर अवलंबून असते। मी या पाच तपासण्या मसुदा फाइलमध्ये ठेवतो आणि मल्टिकास्ट तक्रार आल्यावर टर्मिनलमध्ये चिकटवतो, ज्यामुळे निदान अंदाजात बदलत नाही।

बोगद्यापासून नाही, प्राप्तकर्त्यापासून सुरुवात करा

ज्या प्राप्तकर्त्याने कधीही गटाची विनंती केली नाही तो कोणत्याही राउटरवर स्थिती निर्माण करत नाही, म्हणून दुसरे काहीही तपासण्यापूर्वी प्राप्तकर्त्याच्या बाजूच्या विभागात सहभाग अस्तित्वात असल्याची खात्री करा। Cisco शैलीच्या प्लॅटफॉर्मवर, शेवटच्या हॉपच्या राउटरवर show ip igmp groups सहभागी गट ते ऐकलेल्या इंटरफेसच्या शेजारी छापते। जेव्हा त्या आउटपुटमध्ये गट नसतो, तेव्हा बोगदा लक्ष विचलित करणारा असतो: विनंती प्रवेश स्विचवर, होस्ट सॉकेटवर किंवा querier नसलेल्या VLAN मध्ये मरण पावली।

मी पाहिलेल्या बहुतेक गहाळ सहभागांसाठी दोन सामान्य कारणे जबाबदार आहेत: होस्ट आणि राउटरमधील IGMP आवृत्तीची विसंगती, आणि राउटिंग न करणाऱ्या स्विचवर पडलेली querier निवड। तिसरे अधिक सूक्ष्म आहे: गटात सहभाग आहे पण चुकीच्या VLAN मध्ये, कारण होस्टमध्ये दोन नेटवर्क कार्ड आहेत आणि अनुप्रयोग चुकीच्या कार्डाला जोडला गेला। IPv6 प्राप्तकर्त्यांना MLD सह समान समस्या आहे, जिथे show ipv6 mld groups त्याच प्रश्नाचे उत्तर देते। यापैकी कोणतेही बोगद्याला स्पर्श करून सुधारत नाही, आणि म्हणूनच क्रम महत्त्वाचा आहे।

सहभाग दिसल्यावर, PIM प्राप्तकर्त्याच्या बाजूच्या इंटरफेसवर आणि भेटीच्या बिंदूकडे जाणाऱ्या इंटरफेसवर दोन्हीकडे सक्षम असल्याची खात्री करा। IGMP सदस्यत्व असूनही वरील इंटरफेसवर PIM नसलेला राउटर गट स्थानिक तक्त्यात ठेवेल आणि कुठेही काहीही पाठवणार नाही।

BSR संच दुसऱ्या बाजूला पोहोचतो का?

Bootstrap Router संदेश एका PIM डोमेनमध्ये हॉपमागून हॉप पुढे सरकतात, आणि बोगद्यातून तुटणारी दिशा तीच आहे। उमेदवार RP त्यांच्या घोषणा निवडलेल्या BSR ला युनिकास्टद्वारे पाठवतात, म्हणून RP ते BSR हा भाग कार्यरत बोगद्यात सहसा बदल न होता टिकतो। दुसऱ्या दिशेतील Bootstrap संदेशांचा ओघ प्रत्येक मध्यस्थ इंटरफेसवर PIM सक्षम असणे आणि सीमेवर संदेश थांबवणारे काहीही नसणे यावर अवलंबून असतो। RFC 5059 ते वितरण आणि ते लहान करण्यास परवानगी असलेल्या प्रशासकीय व्याप्तीच्या सीमा परिभाषित करते।

ip pim bsr-border विधान, प्रोटोकॉल 103 फिल्टर करणारा ACL, किंवा मल्टिकास्ट वाहून नेऊ शकणारा नसलेला धोरण-आधारित IPsec बोगदा, यापैकी प्रत्येक ओघ कापेल आणि युनिकास्ट अभंग राहील। हेच संयोजन अपयशाला RP समस्येसारखे दाखवते जेव्हा ते प्रत्यक्षात पोहोचण्याची समस्या असते, आणि म्हणूनच मी RP कॉन्फिगरेशनपूर्वी BSR स्थिती वाचतो।

दूरच्या बाजूच्या राउटरवर show ip pim bsr-router निवडलेला BSR आणि शिकलेला RP संच नावाने सांगते; आउटपुट रिकामे असल्यास, दूरची बाजू स्वतःच्या डोमेनमध्ये बसलेली असते आणि कोणतेही RP कॉन्फिगरेशन दोघांना जुळवून आणणार नाही। बोगद्याच्या दोन्ही बाजूंना show ip pim rp mapping मधील गट श्रेणी आणि RP पत्ते यांची तुलना करा। केवळ स्थानिक पातळीवर असलेले मॅपिंग चुकीच्या ठिकाणी संपणारे सामायिक वृक्ष तयार करते, आणि प्राप्तकर्ता कायमचा प्रतीक्षा करतो।

बोगद्याच्या दोन्ही बाजूंना RP मॅपिंग जुळवा

स्थिर RP, BSR आणि anycast-RP एकाच प्रश्नाची तीन उत्तरे आहेत, आणि ती बोगद्यातून मिसळणे हे कधीही एकत्र न येणारे डोमेन उभारण्याचा विश्वासार्ह मार्ग आहे। जर हेड एंड BSR वापरत असेल आणि शाखा दुसऱ्या पत्त्याकडे निर्देश करणारे स्थिर ip pim rp-address वापरत असेल, तर शाखा आपले सामायिक वृक्ष अशा RP कडे बांधते ज्याला प्राप्तकर्ता अस्तित्वात असल्याची कल्पनाही नाही। मॅपिंगने गट श्रेणी आणि पत्ता दोन्हीवर जुळले पाहिजे, कारण अधिक विशिष्ट श्रेणी विस्तृत श्रेणीवर जिंकते।

Anycast-RP दोन साइट्स एक RP पत्ता सामायिक करू शकावेत यासाठीच अस्तित्वात आहे, आणि ते येथे नमूद करणे योग्य आहे कारण ते «तेच RP» या अर्थाला बदलते। एक पत्ता जाहीर करणारे दोन RP रचनेनुसार सुसंगत आहेत; त्याच श्रेणीसाठी वेगवेगळे पत्ते जाहीर करणारे दोन RP तसे नाहीत, प्रत्येक साइट स्वतःच्या बळावर कितीही निरोगी दिसली तरी।

232.0.0.0/8 मधील स्रोत-विशिष्ट मल्टिकास्टसाठी RP ला कधीही विचारले जात नाही, म्हणून रिकामे RP मॅपिंग आपोआप दोष नाही। कधीही आवश्यक नसलेल्या RP मागे लागण्यापूर्वी अनुप्रयोग कोणते सेवा मॉडेल वापरतो ते ठरवा।

स्रोताकडे जाणारा RPF शोध वाचा

PIM युनिकास्ट मार्ग उलटून वृक्ष बांधतो, म्हणून महत्त्वाची तपासणी म्हणजे स्रोताकडे परत जाणारा मार्ग, किंवा सामायिक वृक्षासाठी RP कडे परत जाणारा मार्ग। राउटर वरील मानत नाही अशा इंटरफेसवर येणारा सहभाग टाकून दिला जातो, आणि कारण बोगदा अपयश म्हणून नाही तर RPF अपयश म्हणून नोंदवले जाते। बोगद्यावरील डीफॉल्ट मार्ग आणि WAN वरील अधिक विशिष्ट मार्ग असलेल्या शाखा राउटरवर, स्रोत फक्त बोगद्यातूनच पोहोचण्यासारखा असतानाही RPF इंटरफेस सहज WAN असू शकतो। सहभाग शांतपणे टाकून दिला जाण्याचे हे एकमेव सर्वात सामान्य कारण आहे।

show ip rpf 192.0.2.10 निवडलेला इंटरफेस, पुढील हॉप आणि निर्णय निर्माण करणारा मार्ग छापते, आणि सहसा विसंगती पाहण्यासाठी ते पुरेसे असते। ip mroute 192.0.2.0 255.255.255.0 tunnel0 सारखा स्थिर मल्टिकास्ट मार्ग त्या उपसर्गासाठी युनिकास्ट शोध मागे टाकतो, आणि जेव्हा मल्टिकास्ट टोपोलॉजी खरोखर युनिकास्ट टोपोलॉजीपेक्षा वेगळी असते तेव्हा ते कायदेशीर दुरुस्ती आहे। त्याकडे कागदपत्रांत नोंदवाव्या अशा कॉन्फिगरेशनसारखे पाहा, घटनेच्या वेळी लावून विसरलेल्या पॅचसारखे नाही।

पिंगने नाही, कमांडने सहभाग निश्चित करा

पिंग युनिकास्ट काम करते हे सिद्ध करते, जे तुम्हाला आधीच माहीत होते। टोकापासून टोकापर्यंतची पुष्टी हा असा क्रम आहे जो सहभाग, मॅपिंग, शेजारी आणि वृक्ष याच क्रमाने दाखवतो, आणि प्रत्येक कमांड वेगळ्या प्रश्नाचे उत्तर देते।

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

वास्तविक इनकमिंग इंटरफेस आणि रिकामी नसलेली आउटगोइंग यादी असलेली भरलेली (S,G) नोंद म्हणजे नियंत्रण स्तराने आपले काम पूर्ण केले आहे। ज्या नोंदीचा इनकमिंग इंटरफेस Null असा वाचला जातो, किंवा सतत वाढणारा RPF failed लेबलाचा काउंटर, तो बोगद्याकडे नाही तर मागील विभागाकडे निर्देश करतो।

पाचही कमांड बरोबर दिसत असूनही प्राप्तकर्त्याला काहीच दिसत नसेल, तर उर्वरित संशय हा बोगद्याचाच धोरण असतो: युनिकास्ट राउटिंग प्रोटोकॉलला परवानगी देणारा पण PIM, IGMP किंवा गट रहदारीला परवानगी न देणारा क्रिप्टो ACL किंवा फायरवॉल नियम। धोरण-आधारित IPsec बोगद्यात मल्टिकास्ट अजिबात वाहून नेले जात नाही, म्हणून उत्तर GRE किंवा VTI रचना आहे, अजून एक फिल्टर अपवाद नाही। काहीही बदलण्यापूर्वी पाचपैकी कोणती तपासणी अपयशी ठरली ते लिहा, आणि नंतर फक्त तो स्तर बदला।