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 डिजाइन हो। केही बदल्नुअघि पाँचमध्ये कुन जाँच असफल भयो लेख्नुहोस्, त्यसपछि त्यही तह मात्र बदल्नुहोस्।