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 लेबल वाला काउंटर जो लगातार बढ़ता जा रहा है, वह टनल की ओर नहीं बल्कि पिछले अनुभाग की ओर इशारा करता है।

यदि पाँचों कमांड सही दिखते हैं और रिसीवर अब भी कुछ नहीं देखता, तो बचा हुआ संदिग्ध टनल की अपनी नीति है: ऐसा क्रिप्टो ACL या फ़ायरवॉल नियम जो यूनिकास्ट रूटिंग प्रोटोकॉल की अनुमति देता है पर PIM, IGMP या समूह ट्रैफ़िक की नहीं। नीति-आधारित IPsec टनल पर मल्टीकास्ट बिलकुल नहीं ढोया जाता, इसलिए उत्तर GRE या VTI डिज़ाइन है, न कि एक और फ़िल्टर अपवाद। कुछ भी बदलने से पहले लिखें कि पाँच जाँचों में से कौन विफल हुई, फिर केवल उसी परत को बदलें।