हमारा सट्टा प्रदाता लिंकमेप बढ़ता है और चुपचाप साधारण दूरसंचार ऑपरेटरों की सभी सेवाओं के साथ बढ़ जाता है। अब हम आईपीटीवी की तरफ बढ़ गए हैं।
इसका मतलब यह है कि मल्टीकास्ट रूटिंग को कॉन्फ़िगर करने की आवश्यकता है और सबसे पहले, मल्टीकास्ट सामान्य रूप से क्या है की समझ।
यह आईपी-नेटवर्क के सामान्य सिद्धांतों से पहला विचलन है। फिर भी, मल्टीकास्ट प्रतिमान गर्म ट्यूब यूनिकस्ट से मौलिक रूप से अलग है।
आप इसे कुछ हद तक यह भी कह सकते हैं कि नए दृष्टिकोण को समझने में आपके दिमाग के लचीलेपन को चुनौती देता है।

यह लेख निम्नलिखित पर ध्यान केंद्रित करेगा:

• मल्टीकास्ट की सामान्य समझ
• IGMP प्रोटोकॉल
• PIM प्रोटोकॉल
• >>> PIM Dense Mode
• >>> Pim विरल मोड
• >>> एसपीटी स्विचओवर - आरपीटी-एसपीटी स्विचिंग
• >>> डीआर, एसर, फारवर्डर
• >>> स्वचालित आरपी चयन
• >>> एसएसएम
• >>> BIDIR PIM
• चैनल स्तर पर मल्टीकास्ट
• >>> IGMP- स्नूपिंग
• >>> एमवीआर

पारंपरिक वीडियो ट्यूटोरियल:

एक इंजीनियर के रूप में मेरे गठन के भोर में, मल्टीकास्ट के विषय ने मुझे अविश्वसनीय रूप से डरा दिया, और मैंने इसे अपने पहले अनुभव के मनोवैज्ञानिक आघात के लिए जिम्मेदार ठहराया।
" तो, मराट, तत्काल, दोपहर से पहले हमें शहर के केंद्र में हमारे नए भवन में वीडियो स्ट्रीम को स्ट्रीम करने की आवश्यकता है - प्रदाता हमें यहां दूसरी मंजिल पर देगा, " मैंने एक अद्भुत सुबह सुनी। उस समय मैं मल्टीकास्ट के बारे में जो कुछ भी जानता था वह यह था कि केवल एक प्रेषक था, कई प्राप्तकर्ता थे, और ऐसा लगता है कि आईजीएमपी प्रोटोकॉल किसी तरह वहां शामिल है।

नतीजतन, दोपहर से पहले, हमने पूरी बात शुरू करने की कोशिश की - मैंने प्रवेश बिंदु से निकास बिंदु तक सबसे आम वीएलएएन को आगे बढ़ाया। लेकिन संकेत अस्थिर था - चित्र फ्रिज़, अलग हो गया, बाधित हो गया। मैं यह सोचकर दहशत में था कि सामान्य रूप से IGMP के साथ क्या किया जा सकता है, स्नूप्ड, स्नूप्ड, मल्टीकास्ट रूटिंग चालू, IGMP-स्नूपिंग, चेक देरी और नुकसान एक हजार बार, कुछ भी मदद नहीं की। और फिर यह सब काम किया। बेशक, स्थिर, विश्वसनीय।

यह मल्टीकास्ट के खिलाफ एक वैक्सीन के रूप में कार्य करता था, और लंबे समय तक मैंने उसमें कोई दिलचस्पी नहीं दिखाई।

पहले से ही बहुत बाद में, मैं निम्नलिखित नियम पर आया:

और अब, जिन मामलों को मैंने लिया है, उनकी ऊंचाई से, मैं समझता हूं कि नेटवर्क भाग की स्थापना के साथ कोई समस्या नहीं हो सकती थी - अंत उपकरण छोटी गाड़ी थी।

शांत रहो और मुझ पर भरोसा रखो। इस लेख के बाद ऐसी बातें आपको डराएंगी नहीं।

मल्टीकास्ट की सामान्य समझ

जैसा कि आप जानते हैं, निम्न प्रकार के यातायात मौजूद हैं:
यूनिकास्ट - यूनिकस्ट - एक प्रेषक, एक प्राप्तकर्ता। ( उदाहरण: WEB सर्वर से HTTP पृष्ठ का अनुरोध करना )।
प्रसारण - प्रसारण - एक प्रेषक, प्राप्तकर्ता - प्रसारण खंड में सभी डिवाइस। ( उदाहरण: एआरपी अनुरोध )।
मल्टीकास्ट - मल्टीकास्ट - एक प्रेषक, कई प्राप्तकर्ता। ( उदाहरण: आईपीटीवी )।
एनीकास्ट - निकटतम मेजबान के लिए यूनिकास्ट - एक प्रेषक, कई प्राप्तकर्ता हैं, लेकिन वास्तव में डेटा केवल एक को भेजा जाता है। ( उदाहरण: एनीकास्ट डीएनएस )।

---

चूंकि हमने मल्टीकास्ट के बारे में बात करने का फैसला किया है, हम शायद इस पैराग्राफ को इस सवाल से शुरू करेंगे कि इसका उपयोग कहां और कैसे किया जाता है।

पहली बात जो दिमाग में आती है वह है टेलीविज़न (आईपीटीवी) - एक स्रोत सर्वर ट्रैफ़िक भेजता है जो एक साथ कई क्लाइंट प्राप्त करना चाहता है। यह वह है जो शब्द को परिभाषित करता है - मल्टीकास्ट - मल्टीकास्ट प्रसारण। यही है, अगर ब्रॉडकास्ट आपको पहले से ज्ञात है तो इसका मतलब है कि हर किसी के लिए प्रसारण, मल्टीकास्ट का मतलब है एक निश्चित समूह के लिए प्रसारण।

दूसरा अनुप्रयोग, उदाहरण के लिए, एक साथ कई कंप्यूटरों के लिए ऑपरेटिंग सिस्टम की प्रतिकृति है। इसका अर्थ है एक सर्वर से बड़ी मात्रा में डेटा डाउनलोड करना।

संभावित परिदृश्य: ऑडियो और वीडियो कॉन्फ्रेंसिंग (हर कोई सुनता है), ई-कॉमर्स, नीलामी, एक्सचेंज। लेकिन यह सिद्धांत रूप में है, और व्यवहार में, मल्टीकास्ट का उपयोग शायद ही कभी यहां किया जाता है।

एक अन्य अनुप्रयोग प्रोटोकॉल ओवरहेड है। उदाहरण के लिए, अपने प्रसारण डोमेन में OSPF 224.0.0.5 और 224.0.0.6 पते पर अपने संदेश भेजता है। और केवल वे नोड्स जो ओएसपीएफ चलाते हैं, उन्हें प्रोसेस करेंगे।

हम मल्टीकास्ट मेलिंग के दो बुनियादी सिद्धांतों को तैयार करते हैं:

1. प्राप्तकर्ता की संख्या की परवाह किए बिना, प्रेषक केवल ट्रैफ़िक की एक प्रति भेजता है।
2. यातायात केवल उन लोगों द्वारा प्राप्त किया जाता है जो वास्तव में इसमें रुचि रखते हैं।

---

अभ्यास के लिए इस लेख में, हम आईपीटीवी को सबसे अधिक उदाहरण के रूप में लेंगे।

उदाहरण I

चलो सबसे सरल मामले से शुरू करते हैं:



समूह 224.2.2.4 पर प्रसारित स्रोत सर्वर पर कॉन्फ़िगर किया गया है - इसका मतलब है कि सर्वर आईपी पते 224.2.2.4 पर ट्रैफ़िक भेजता है। क्लाइंट पर, वीडियो प्लेयर समूह 224.2.2.4 स्ट्रीम को स्वीकार करने के लिए कॉन्फ़िगर किया गया है।

उसी समय, ध्यान दें कि क्लाइंट और सर्वर के पास एक ही सबनेट से पते नहीं होते हैं और एक दूसरे को पिंग करते हैं - यह पर्याप्त है कि वे एक ही प्रसारण डोमेन में हैं।

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

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



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

मल्टीकास्ट और यूनिकस्ट के बीच अंतर क्या है? मुझे लगता है कि आपके पास पहले से ही एक धारणा है। और आप शायद सही हैं।

सामान्य स्थिति में, हमारे पास 1 प्राप्तकर्ता और 1 प्रेषक है - उनमें से प्रत्येक के पास एक अद्वितीय आईपी पता है। प्रेषक को पता है कि पैकेट को कहां भेजा जाए और इस पते को आईपी हेडर में रखा जाए। प्रत्येक मध्यवर्ती नोड, इसकी रूटिंग टेबल के लिए धन्यवाद, ठीक से जानता है कि पैकेट को आगे कहां करना है। नेटवर्क के माध्यम से दो नोड्स के बीच यूनिकस्ट ट्रैफिक मूल रूप से बहता है। लेकिन समस्या यह है कि एक नियमित पैकेट में केवल एक प्राप्तकर्ता आईपी पता इंगित किया जाता है।
क्या होगा यदि एक ही ट्रैफ़िक में कई प्राप्तकर्ता हों? सिद्धांत रूप में, आप ऐसी स्थिति के लिए यूनिकास्ट दृष्टिकोण का विस्तार कर सकते हैं - प्रत्येक ग्राहक को पैकेज की एक प्रति भेजें। ग्राहक अंतर को नोटिस नहीं करेंगे - भले ही एक हो, भले ही एक हजार हों, अंतर आपके डेटा ट्रांसमिशन चैनलों पर स्पष्ट रूप से दिखाई देगा।

मान लीजिए हम एक मल्टीकास्ट सर्वर से एक एसडी चैनल को स्थानांतरित कर रहे हैं। इसे 2 एमबी / एस का उपयोग करने दें। ऐसे 30 चैनल हैं, और प्रत्येक चैनल एक बार में 20 लोगों को देख रहा है। कुल 2 एमबी / एस * 30 चैनल * 20 लोग = 1200 एमबी / एस या 1.2 जीबी / एस केवल टीवी पर अनैस्ट डिस्ट्रीब्यूशन के मामले में। लेकिन अभी भी एचडी चैनल हैं जहां आप सुरक्षित रूप से इस आंकड़े को 2 से गुणा कर सकते हैं। और टोरेंट्स के लिए जगह कहां है?

यही कारण है कि IPv4 : 224.0.0.0/4 (224.0.0.0-239.255.255.255) में क्लास डी एड्रेस ब्लॉक को नीचे रखा गया था। इस श्रेणी के पते मल्टीकास्ट समूह को निर्धारित करते हैं। एक पता - यह एक समूह है, आमतौर पर इसे " जी " अक्षर द्वारा इंगित किया जाता है।
यह कहते हुए कि ग्राहक 224.2.2.4 समूह से जुड़ा है, हमारा मतलब है कि यह गंतव्य पते 224.2.2.4 के साथ बहुस्त्र्पीय यातायात प्राप्त करता है।

उदाहरण II

सर्किट में एक स्विच और कुछ और ग्राहक जोड़ें:



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

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

कृपया ध्यान दें कि इस स्थिति में, स्विच की ट्रैफ़िक की केवल एक प्रतिलिपि स्रोत सर्वर से आती है, न कि प्रत्येक क्लाइंट के लिए एक अलग प्रतिलिपि। और एसडी चैनलों के साथ हमारे उदाहरण में, स्रोत और स्विच के बीच का पोर्ट लोडिंग 1.2 Gb / s नहीं होगा, बल्कि केवल 60 Mb / s (2 Mb / s * 30 चैनल) होगा।

तथ्य की बात के रूप में, इस सभी विशाल रेंज (224.0.0.0-239.255.255.255) का उपयोग किया जा सकता है।
खैर, लगभग सभी - पहले पते (रेंज 224.0.0.0/23) अभी भी प्रसिद्ध प्रोटोकॉल के लिए आरक्षित हैं।


रेंज 224.0.0.0/24 लिंक-स्थानीय संचार के लिए आरक्षित है। ऐसे गंतव्य पते वाले मल्टीकास्ट पैकेट एक प्रसारण खंड की सीमाओं से परे नहीं जा सकते।
रेंज 224.0.1.0/24 प्रोटोकॉल के लिए आरक्षित है जिसे पूरे नेटवर्क पर मल्टीकास्ट को प्रसारित करने की आवश्यकता होती है, अर्थात, राउटर से गुजरती हैं।

---

यहां, वास्तव में, मल्टीकास्ट के बारे में सबसे बुनियादी चीजें।
हमने एक साधारण स्थिति पर विचार किया जब स्रोत और रिसीवर एक ही नेटवर्क सेगमेंट में होते हैं। स्विच द्वारा प्राप्त ट्रैफ़िक को इसके द्वारा सभी बंदरगाहों तक भेजा जाता है - कोई जादू नहीं।

लेकिन जब यह पूरी तरह से समझ से बाहर है कि सर्वर से ट्रैफ़िक ग्राहकों तक कैसे पहुंचे, जब उनके बीच लिंकमैप का एक विशाल प्रदाता है? और वास्तव में, यह कैसे पता चलेगा कि ग्राहक कौन है? हम मैन्युअल रूप से मार्गों को पंजीकृत नहीं कर सकते, बस क्योंकि हम नहीं जानते कि ग्राहक कहां हो सकते हैं। पारंपरिक रूटिंग प्रोटोकॉल इस प्रश्न का उत्तर नहीं देंगे। इसलिए हमें समझ में आता है कि मल्टीकास्ट डिलीवरी हमारे लिए पूरी तरह से नया है।

सामान्य तौर पर, मल्टीकास्ट को स्रोत से गंतव्य तक पहुंचाने के कई प्रोटोकॉल हैं - IGMP / MLD, PIM, MSDP, MBGP, MOSPF, DVMRP।
हम उनमें से दो पर ध्यान केंद्रित करेंगे जो वर्तमान में उपयोग किए जाते हैं: पीआईएम और आईजीएमपी।
IGMP के साथ, अंतिम गंतव्य क्लाइंट निकटतम रूटर्स को बताते हैं कि वे ट्रैफ़िक प्राप्त करना चाहते हैं। और पीआईएम स्रोत से प्राप्तकर्ताओं के लिए राउटर के माध्यम से मल्टीकास्ट ट्रैफिक का मार्ग बनाता है।

---

IGMP

चलो फिर से डंप पर वापस जाएं। इस शीर्ष पैकेट को देखें जिसके बाद मल्टीकास्ट स्ट्रीम डाला गया है?



यह IGMP प्रोटोकॉल संदेश है जिसे क्लाइंट ने प्ले पर क्लिक करने पर भेजा है। इस तरह वह रिपोर्ट करता है कि वह 224.2.2.4 समूह के लिए यातायात प्राप्त करना चाहता है।
IGMP - इंटरनेट ग्रुप मैनेजमेंट प्रोटोकॉल - मल्टीकास्ट ट्रैफिक क्लाइंट्स की बातचीत और उनके सबसे करीब के राउटर के लिए एक नेटवर्क प्रोटोकॉल है।

IPv6 IGMP के बजाय MLD (मल्टिकास्ट लिसनर डिस्कवरी) का उपयोग करता है। वे ठीक उसी तरह से काम करते हैं, इसलिए आप हर जगह IGMP को MLD और IP को IPv6 में सुरक्षित रूप से बदल सकते हैं।

IGMP कैसे काम करता है?
शायद आपको इस तथ्य से शुरू करने की आवश्यकता है कि प्रोटोकॉल में अब तीन संस्करण हैं: IGMPv1, IGMPv2, IGMPv3। सबसे अधिक इस्तेमाल किया जाने वाला दूसरा है, पहला लगभग भूल गया है, इसलिए हम इसके बारे में बात नहीं करेंगे, तीसरा दूसरे के समान है।

हम अब तक दूसरे पर ध्यान केंद्रित करते हैं, जैसा कि सबसे अधिक संकेत देने वाला है, और समूह से कनेक्ट होने तक क्लाइंट से सभी घटनाओं पर विचार करें जब तक वह समूह को छोड़ नहीं देता।
ग्राहक वीएलसी प्लेयर के माध्यम से समूह 224.2.2.4 का भी अनुरोध करेगा।

IGMP की भूमिका बहुत सरल है: यदि कोई ग्राहक नहीं हैं, तो आपको मल्टीकास्ट ट्रैफ़िक को सेगमेंट में स्थानांतरित करने की आवश्यकता नहीं है। यदि कोई ग्राहक आता है, तो वह IGMP के माध्यम से राउटर को सूचित करता है कि वह ट्रैफ़िक प्राप्त करना चाहता है।

यह समझने के लिए कि सब कुछ कैसे होता है, निम्न नेटवर्क लें:



मान लीजिए कि राउटर मल्टीकास्ट ट्रैफ़िक प्राप्त करने और संसाधित करने के लिए पहले से ही कॉन्फ़िगर है।


1. जैसे ही हम क्लाइंट पर एप्लिकेशन चलाते हैं और समूह को 224.2.2.4 पर सेट करते हैं, IGMP सदस्यता रिपोर्ट पैकेज नेटवर्क को भेजा जाएगा - नोड "रिपोर्ट" जो यह इस समूह से ट्रैफ़िक प्राप्त करना चाहता है।



IGMPv2 में रिपोर्ट वांछित समूह के पते पर भेजी जाती है, और समानांतर में इसे पैकेज में भी इंगित किया जाता है। इन संदेशों को केवल अपने सेगमेंट के भीतर रहना चाहिए और कहीं भी राउटर्स द्वारा अग्रेषित नहीं किया जाना चाहिए, इसलिए उनके पास TTL 1 भी है।

अक्सर साहित्य में आप IGMP Join का उल्लेख कर सकते हैं। चिंतित न हों - यह IGMP सदस्यता रिपोर्ट के लिए एक वैकल्पिक नाम है।

2. राउटर IGMP- रिपोर्ट प्राप्त करता है और, यह महसूस करते हुए कि इस इंटरफ़ेस के पीछे अब ग्राहक हैं, जानकारी को अपनी तालिकाओं में दर्ज करता है



यह IGMP जानकारी का आउटपुट है। पहले समूह को ग्राहक द्वारा अनुरोध किया जाता है। तीसरा और चौथा विंडोज में निर्मित एसएसडीपी प्रोटोकॉल के सेवा समूह हैं। दूसरा एक विशेष समूह है जो हमेशा सिस्को राउटर पर मौजूद होता है - इसका उपयोग ऑटो-आरपी प्रोटोकॉल के लिए किया जाता है, जो राउटर पर डिफ़ॉल्ट रूप से सक्रिय होता है।
FE0 / 0 इंटरफ़ेस समूह 224.2.2.4 के ट्रैफ़िक के लिए डाउनस्ट्रीम हो जाता है - प्राप्त ट्रैफ़िक को इसे भेजने की आवश्यकता होगी।

सामान्य यूनिकास्ट राउटिंग टेबल के साथ, एक मल्टीकास्ट भी है:



ग्राहकों की उपस्थिति को पहली प्रविष्टि (*, 224.2.2.4) से संकेत मिलता है। एक रिकॉर्ड (172.16.0.5, 224.2.2.4) का अर्थ है कि राउटर इस समूह के मल्टीकास्ट स्ट्रीम के स्रोत के बारे में जानता है।
यह आउटपुट से देखा जा सकता है कि समूह 224.2.2.4 के लिए यातायात FE0 / 1 के माध्यम से आता है, और इसे FE0 / 0 को पोर्ट करना होगा।
जिन इंटरफेसों को ट्रैफ़िक प्रेषित किया जाना चाहिए, वे डाउनस्ट्रीम इंटरफेस की सूची में शामिल हैं - OIL - आउटबाउंड इंटरफ़ेस सूची ।
हम बाद में और अधिक विस्तार से शो आईपी mroute कमांड के आउटपुट की जांच करेंगे।

डंप में ऊपर, आप देखते हैं कि जैसे ही ग्राहक ने आईजीएमपी-रिपोर्ट भेजी, यूडीपी ने इसके ठीक बाद उड़ान भरी - यह एक वीडियो स्ट्रीम है।


3. क्लाइंट को ट्रैफ़िक मिलना शुरू हुआ। अब राउटर को कभी-कभी यह देखना चाहिए कि उसके पास अभी भी प्राप्तकर्ता हैं ताकि यह व्यर्थ में प्रसारित न हो अगर अचानक कोई क्लाइंट नहीं बचा है। ऐसा करने के लिए, यह समय-समय पर अपने सभी डाउनस्ट्रीम इंटरफेसों को एक IGMP क्वेरी अनुरोध भेजता है।

* IGMP * द्वारा फ़िल्टर किया गया डंप ।


डिफ़ॉल्ट रूप से, यह हर 60 सेकंड में होता है। ऐसे पैकेटों का TTL भी 1 के बराबर होता है। वे 224.0.0.1 पते पर भेजे जाते हैं - इस सेगमेंट के सभी नोड - एक विशिष्ट समूह को निर्दिष्ट किए बिना। ऐसे क्वेरी संदेशों को जनरल क्वेरी - जनरल कहा जाता है। इस प्रकार, राउटर पूछता है: "दोस्तों, कौन और क्या प्राप्त करना चाहता है?"।

IGMP जनरल क्वेरी प्राप्त करने के बाद, किसी भी समूह को सुनने वाले किसी भी होस्ट को IGMP रिपोर्ट भेजनी चाहिए, जैसा कि कनेक्ट करते समय किया था। रिपोर्ट में, निश्चित रूप से, ब्याज के समूह के पते को इंगित किया जाना चाहिए।

* IGMP * द्वारा फ़िल्टर किया गया डंप ।


यदि क्वेरी के जवाब में एक समूह के लिए कम से कम एक रिपोर्ट राउटर के पास आई, तो अधिक ग्राहक हैं, यह उस इंटरफ़ेस पर प्रसारित करना जारी रखता है जहां से यह रिपोर्ट आई थी, इस समूह का ट्रैफ़िक।
यदि लगातार 3 क्वेरी के लिए किसी भी समूह के लिए इंटरफ़ेस से कोई जवाब नहीं था, तो राउटर इस समूह के लिए अपनी मल्टीकास्ट रूटिंग टेबल से इस इंटरफ़ेस को हटा देता है - यह वहां ट्रैफ़िक भेजना बंद कर देता है।

अपनी पहल पर, ग्राहक आमतौर पर रिपोर्ट तभी भेजता है जब वह कनेक्ट होता है, तो यह केवल राउटर से क्वेरी का जवाब देता है।

ग्राहक के व्यवहार में एक दिलचस्प विवरण: क्वेरी प्राप्त करने के बाद, वह तुरंत रिपोर्ट के साथ जवाब देने के लिए जल्दी में नहीं है। नोड 0 से अधिकतम प्रतिक्रिया समय तक एक समयबाह्य लेता है, जो कि आए प्रश्न में निर्दिष्ट है:



डिबगिंग या डंप में, वैसे, आप देख सकते हैं कि विभिन्न रिपोर्ट प्राप्त करने के बीच कई सेकंड बीत सकते हैं।
ऐसा इसलिए किया जाता है ताकि जनरल क्वैरी प्राप्त करने वाले सैकड़ों ग्राहकों ने अपने रिपोर्ट पैकेजों के साथ नेटवर्क में बाढ़ न आए। इसके अलावा, केवल एक ग्राहक आमतौर पर रिपोर्ट भेजता है।
तथ्य यह है कि रिपोर्ट समूह पते पर भेजी जाती है, और इसलिए यह सभी ग्राहकों तक पहुंचती है। उसी समूह के लिए किसी अन्य ग्राहक से रिपोर्ट प्राप्त करने के बाद, नोड अपना स्वयं का भेज नहीं देगा। तर्क सरल है: राउटर ने पहले ही यह रिपोर्ट प्राप्त कर ली है और जानता है कि ग्राहक हैं, इसे अब इसकी आवश्यकता नहीं है।
इस तंत्र को रिपोर्ट दमन कहा जाता है।

बाद में लेख में हम इस बारे में बात करेंगे कि यह तंत्र वास्तव में शायद ही कभी काम करता है ।

4. यह सदियों तक जारी रहता है जब तक ग्राहक समूह को छोड़ना नहीं चाहता (उदाहरण के लिए, खिलाड़ी / टीवी बंद करें)। इस स्थिति में, यह समूह पते पर IGMP अवकाश भेजता है।



राउटर इसे प्राप्त करता है और सिद्धांत में डिस्कनेक्ट होना चाहिए। लेकिन वह एक विशिष्ट ग्राहक को डिस्कनेक्ट नहीं कर सकता है - राउटर उनके बीच अंतर नहीं करता है - उसके पास केवल डाउनस्ट्रीम इंटरफ़ेस है। और इंटरफ़ेस के पीछे कई क्लाइंट हो सकते हैं। यही है, यदि राउटर इस समूह के लिए अपने ओआईएल (आउटगोइंग इंटरफेस लिस्ट) से इस इंटरफ़ेस को हटा देता है, तो वीडियो सभी के लिए बंद हो जाएगा।
लेकिन इसे हटाना बिल्कुल भी असंभव नहीं है - अचानक यह अंतिम ग्राहक था - फिर व्यर्थ में प्रसारण क्यों?

यदि आप डंप में देखते हैं, तो आप देखेंगे कि लीव प्राप्त करने के बाद, राउटर कुछ समय के लिए स्ट्रीम भेजना जारी रखता है। तथ्य यह है कि लीव के जवाब में राउटर एक IGMP क्वेरी को उस समूह के पते पर भेजता है जिसके लिए यह लीव उस इंटरफेस में आया था जहां से वह आया था। इस तरह के पैकेज को ग्रुप स्पेसिफिक क्वेरी कहा जाता है।केवल वे ग्राहक जो इस विशेष समूह से जुड़े हैं, वे इसका जवाब देते हैं ।



यदि राउटर को समूह के लिए एक प्रतिक्रिया रिपोर्ट मिली, तो यह इंटरफ़ेस पर प्रसारित करना जारी रखता है, यदि ऐसा नहीं होता है, तो टाइमर के समाप्त होने के बाद इसे हटा देता है।

कुल मिलाकर, अवकाश प्राप्त करने के बाद, दो समूह विशिष्ट प्रश्न भेजे जाते हैं - एक अनिवार्य, दूसरा नियंत्रण।

* IGMP * द्वारा फ़िल्टर किया गया डंप ।


अगला, राउटर प्रवाह को रोक देता है।

---

Querier

थोड़ा और जटिल मामले पर विचार करें:



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

चुनाव काफी सरल और सहज हैं।
आइए रूटर्स आर 1 और आर 2 के समावेश के क्षण से एक स्थिति पर विचार करें।
1) इंटरफेस पर सक्रिय IGMP।
2) सबसे पहले, डिफ़ॉल्ट रूप से, उनमें से प्रत्येक खुद को क्वियर मानते हैं।
3) प्रत्येक नेटवर्क को IGMP जनरल क्वेरी भेजता है। मुख्य लक्ष्य यह पता लगाना है कि क्या ग्राहक हैं, और एक ही समय में खंड में अन्य राउटर को बताने के लिए, यदि कोई हो, तो चुनाव में भाग लेने की उनकी इच्छा।
4) जनरल क्वेरी सेगमेंट के सभी उपकरणों को प्राप्त करता है, जिसमें अन्य IGMP राउटर भी शामिल हैं।
5) पड़ोसी से ऐसा संदेश मिलने पर, प्रत्येक राउटर मूल्यांकन करता है कि कौन योग्य है।
6) कम आईपी जीत (आईजीएमपी क्वेरी पैकेट के स्रोत आईपी क्षेत्र में संकेत ) के साथ राउटर। वह क्वियर बन जाता है, अन्य सभी गैर-क्वियरियर बन जाते हैं।
7) नॉन-क्वियरियर एक टाइमर शुरू करता है जो हर बार कम आईपी पते के साथ एक क्वेरी को रीसेट करता है। यदि, टाइमर समाप्त होने से पहले (100 सेकंड से अधिक: 105-107), राउटर को कम पते वाला क्वेरी प्राप्त नहीं होता है, तो यह खुद को क्वियर घोषित करता है और सभी प्रासंगिक कार्यों को लेता है।
) यदि क्वियरियर को निम्न पते वाला प्रश्न प्राप्त होता है, तो वह इन कर्तव्यों से इस्तीफा दे देता है। क्वियर एक और राउटर बन जाता है जिसमें आईपी कम होता है।

वह दुर्लभ मामला, जब मापा जाता है, किसके पास कम है।

क्वियर चुनना एक बहुत ही महत्वपूर्ण मल्टीकास्ट प्रक्रिया है, लेकिन कुछ कपटी निर्माता जो आरएफसी का पालन नहीं करते हैं वे पहियों में एक मजबूत छड़ी डाल सकते हैं। मैं 0.0.0.0 के स्रोत पते के साथ IGMP क्वेरी के बारे में बात कर रहा हूं, जिसे स्विच द्वारा उत्पन्न किया जा सकता है। इस तरह के संदेशों को क्वियर की पसंद में भाग नहीं लेना चाहिए, लेकिन आपको हर चीज के लिए तैयार रहना चाहिए। यहां एक बहुत ही जटिल लंबे समय तक चलने वाली समस्या का एक उदाहरण है।

---

IGMP के अन्य संस्करणों के बारे में कुछ शब्द

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

संस्करण 3 IGMPv2 का समर्थन करने वाली हर चीज का समर्थन करता है, लेकिन इसमें कई बदलाव हैं। सबसे पहले, रिपोर्ट अब समूह पते पर नहीं भेजी जाती है, लेकिन मल्टीकास्ट सेवा पते 224.0.0.22 पर । और अनुरोधित समूह का पता केवल पैकेज के अंदर इंगित किया गया है। यह IGMP स्नूपिंग के काम को आसान बनाने के लिए किया जाता है, जिसके बारे में हम बाद में बात करेंगे।

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



तो, IGMP क्लाइंट और राउटर के बीच बातचीत के लिए बनाया गया है। इसलिए, उदाहरण II पर लौटते हुए, जहां कोई राउटर नहीं है, हम आधिकारिक तौर पर घोषित कर सकते हैं कि IGMP औपचारिकता से ज्यादा कुछ नहीं है। कोई राउटर नहीं है, और क्लाइंट के पास मल्टीकास्ट स्ट्रीम से अनुरोध करने के लिए कोई नहीं है। और वीडियो सरल कारण के लिए काम करेगा कि प्रवाह पहले से ही स्विच से डालना है - आपको इसे लेने की आवश्यकता है।

याद रखें कि IGMP IPv6 के लिए काम नहीं करता है। MLD प्रोटोकॉल मौजूद है।

---

फिर से दोहराएं

* IGMP * द्वारा फ़िल्टर किया गया डंप ।

1. सबसे पहले, राउटर ने IGMP जनरल क्वेरी को अपने इंटरफेस पर IGMP को इनेबल करने के बाद यह पता लगाने के लिए भेजा कि क्या कोई प्राप्तकर्ता हैं और क्वियर होने की अपनी इच्छा की घोषणा करते हैं। उस समय, कोई भी इस समूह में नहीं था।
2. फिर एक ग्राहक दिखाई दिया जो 224.2.2.4 समूह से यातायात प्राप्त करना चाहता था और उसने अपनी IGMP रिपोर्ट भेजी। उसके बाद, ट्रैफ़िक इसमें चला गया, लेकिन इसे डंप से फ़िल्टर किया गया।
3. फिर राउटर ने किसी कारण से जांच करने का निर्णय लिया कि क्या कोई और ग्राहक थे और आईजीएमपी जनरल क्वेरी को फिर से भेजा, जिसके लिए ग्राहक को जवाब देने के लिए मजबूर किया गया था ( 4 )।
5. समय-समय पर (एक मिनट में), राउटर जाँच करता है कि IGMP जनरल क्वेरी का उपयोग करने वाले अभी भी प्राप्तकर्ता हैं, और नोड IGMP रिपोर्ट का उपयोग करके इसकी पुष्टि करता है।
6. फिर उसने अपना विचार बदल दिया और IGMP लीव भेजकर ग्रुप को छोड़ दिया।
7. राउटर ने लीव प्राप्त किया और यह सुनिश्चित करने के लिए कि कोई अन्य प्राप्तकर्ता नहीं हैं, IGMP ग्रुप स्पेसिफिक क्वेरी ... दो बार भेजता है। और टाइमर के समाप्त होने के बाद, यह यहां ट्रैफिक को प्रसारित करना बंद कर देता है।
8. हालाँकि, यह नेटवर्क पर IGMP क्वेरी को प्रसारित करना जारी रखता है। उदाहरण के लिए, यदि आपने खिलाड़ी को डिस्कनेक्ट नहीं किया है, लेकिन कनेक्शन समस्या से बस कहीं है। फिर कनेक्शन बहाल हो जाता है, लेकिन रिपोर्ट क्लाइंट खुद से नहीं भेजता है। लेकिन क्वेरी का जवाब। इस प्रकार, मानव हस्तक्षेप के बिना प्रवाह को बहाल किया जा सकता है।

---

और एक बार और

IGMP एक प्रोटोकॉल है जिसके द्वारा एक राउटर मल्टीकास्ट ट्रैफ़िक प्राप्तकर्ताओं की उपस्थिति और उनके वियोग के बारे में सीखता है।
IGMP रिपोर्ट - कनेक्शन द्वारा और IGMP क्वेरी के जवाब में ग्राहक द्वारा भेजी जाती है। इसका मतलब है कि ग्राहक एक विशिष्ट समूह का ट्रैफ़िक प्राप्त करना चाहता है।
IGMP जनरल क्वेरी - राउटर द्वारा समय-समय पर यह जांचने के लिए भेजा जाता है कि वर्तमान में किन समूहों की जरूरत है। प्राप्तकर्ता का पता 224.0.0.1 है।
IGMP Group Sepcific Query - राउटर द्वारा छुट्टी के संदेश के जवाब में राउटर द्वारा भेजा गया ताकि यह पता लगाया जा सके कि इस समूह में अन्य प्राप्तकर्ता हैं या नहीं। मल्टीकास्ट समूह के पते को प्राप्तकर्ता पते के रूप में दर्शाया गया है।
IGMP छुट्टी - ग्राहक द्वारा भेजा जाता है जब वह समूह को छोड़ना चाहता है।
Querier - यदि कई राउटर हैं जो एक प्रसारण खंड में प्रसारित कर सकते हैं, तो उनमें से एक मुख्य का चयन किया जाता है - Querier। वह समय-समय पर क्वेरी भेजेगा और ट्रैफ़िक प्रेषित करेगा।

सभी IGMP शर्तों का विस्तृत विवरण।

---

पीआईएम

इसलिए, हमें पता चला कि ग्राहक अपने इरादों के निकटतम राउटर को कैसे सूचित करते हैं। अब स्रोत से प्राप्तकर्ता को बड़े नेटवर्क के माध्यम से ट्रैफ़िक स्थानांतरित करना अच्छा होगा।

यदि आप इसके बारे में सोचते हैं, तो हम एक कठिन समस्या का सामना कर रहे हैं - स्रोत केवल समूह को प्रसारित करता है, यह कुछ भी नहीं जानता है कि प्राप्तकर्ता कहां हैं और कितने हैं।
प्राप्तकर्ता और उनके निकटतम राउटर केवल यह जानते हैं कि उन्हें एक विशिष्ट समूह के ट्रैफ़िक की आवश्यकता है, लेकिन उन्हें कोई पता नहीं है कि स्रोत कहाँ है और इसका पता क्या है।
इस स्थिति में यातायात कैसे वितरित करें?

मल्टीकास्ट ट्रैफ़िक को रूट करने के लिए कई प्रोटोकॉल हैं: DVMRP , MOSPF , CBT - ये सभी अलग-अलग तरीकों से इस समस्या का समाधान करते हैं। लेकिन वास्तविक तथ्य मानक पीआईएम - प्रोटोकॉल इंडिपेंडेंट मल्टीकास्ट बन गया है।
अन्य दृष्टिकोण इतने अस्थिर हैं कि कभी-कभी उनके डेवलपर्स भी व्यावहारिक रूप से इसे पहचानते हैं। यहाँ, उदाहरण के लिए, CBT RFC प्रोटोकॉल का एक अंश है:
CBT संस्करण 2, और पीछे 1 संस्करण के साथ संगत होने का इरादा नहीं था; हम उम्मीद नहीं करते हैं कि यह व्यापक संगतता समस्याओं का कारण बन सकता है क्योंकि हमें विश्वास नहीं है कि सीबीटी इस स्तर पर व्यापक रूप से तैनात है।


पीआईएम के दो संस्करण हैं, जिन्हें दो अलग-अलग प्रोटोकॉल भी कहा जा सकता है, सिद्धांत रूप में, वे बहुत अलग हैं:

• PIM डेंस मोड (DM)
• PIM विरल मोड (SM)

यह स्वतंत्र है क्योंकि यह किसी विशेष यूनिकस्ट ट्रैफिक रूटिंग प्रोटोकॉल से बंधा नहीं है, और आप देखेंगे कि बाद में क्यों।

PIM Dense Mode

पीआईएम डीएम माथे पर मल्टी-एक्ट पहुंचाने की समस्या को हल करने की कोशिश कर रहे हैं। वह स्पष्ट रूप से मानता है कि नेटवर्क के सभी कोनों में हर जगह प्राप्तकर्ता हैं। इसलिए, शुरू में यह मल्टीकास्ट ट्रैफिक के साथ पूरे नेटवर्क को बाढ़ कर देता है, अर्थात यह सभी बंदरगाहों को भेजता है, सिवाय इसके कि यह कहां से आया है। यदि बाद में यह पता चला कि कहीं इसकी आवश्यकता नहीं है, तो यह शाखा एक विशेष पीआईएम प्रून संदेश का उपयोग करके "कट ऑफ" है - ट्रैफ़िक अब वहां नहीं भेजा जाता है।

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

यह छोरों से रहित है और प्राप्तकर्ता से स्रोत तक के सबसे छोटे रास्ते का उपयोग करता है। वास्तव में, यह एसटीपी में स्पैनिंग ट्री के समान है, जहां स्रोत जड़ है।

एसपीटी एक विशिष्ट प्रकार का पेड़ है - सबसे छोटा रास्ता पेड़। सामान्य तौर पर, किसी भी मल्टीकास्ट ट्री को एमडीटी - मल्टीकास्ट डिस्ट्रीब्यूशन ट्री कहा जाता है।

यह माना जाता है कि पीआईएम डीएम का उपयोग नेटवर्क में मल्टीकास्ट क्लाइंट के उच्च घनत्व के साथ किया जाना चाहिए, जो इसके नाम (डेंस) की व्याख्या करता है। लेकिन वास्तविकता यह है कि यह स्थिति एक अपवाद नहीं है, और अक्सर पीआईएम डीएम व्यावहारिक नहीं है।

अब हमारे लिए जो महत्वपूर्ण है वह है लूप अवॉइडेंस मैकेनिज्म।
इस तरह से एक नेटवर्क की कल्पना करें:



एक स्रोत, एक प्राप्तकर्ता और उनके बीच सबसे सरल आईपी नेटवर्क। सभी राउटर PIM DM चला रहे हैं।

यदि कोई विशेष लूप परिहार तंत्र नहीं होता तो क्या होता?
स्रोत मल्टीकास्ट ट्रैफ़िक भेजता है। R1 इसे प्राप्त करता है और, PIM के सिद्धांतों के अनुसार, DM इसे सभी इंटरफेस को भेजता है, सिवाय इसके कि यह कहां से आया है - यानी R2 और R3 तक।

आर 2 बिल्कुल वैसा ही करता है, अर्थात आर 3 के पक्ष में ट्रैफ़िक भेजता है। R3 यह निर्धारित नहीं कर सकता है कि यह वही ट्रैफ़िक है जो इसे पहले ही R1 से प्राप्त हो चुका है, इसलिए यह इसके सभी इंटरफेस को आगे बढ़ाता है। आर 1 को आर 3 और इतने पर से ट्रैफ़िक की एक प्रति प्राप्त होगी। यहाँ यह है - एक पाश।

इस स्थिति में पीआईएम क्या प्रदान करता है? आरपीएफ - रिवर्स पथ अग्रेषण । यह पीआईएम (किसी भी प्रकार: डीएम और एसएम दोनों) के लिए मल्टीकास्ट ट्रैफ़िक को प्रसारित करने का मुख्य सिद्धांत है - स्रोत से ट्रैफ़िक को सबसे कम रास्ते में आना चाहिए।
यही है, प्रत्येक प्राप्त मल्टिकास्ट पैकेट के लिए, राउटिंग टेबल के आधार पर एक चेक बनाया जाता है, चाहे वह वहां से आया हो।

1) राउटर मल्टीकास्ट पैकेट के स्रोत पते को देखता है।
2) राउटिंग टेबल की जांच करता है कि स्रोत का पता किस इंटरफेस से उपलब्ध है।
3) इंटरफ़ेस की जांच करता है जिसके माध्यम से मल्टीकास्ट पैकेट आया था।
4) यदि इंटरफेस मैच करता है - सब कुछ ठीक है, तो मल्टीकास्ट पैकेट छोड़ दिया जाता है, अगर डेटा दूसरे इंटरफ़ेस से आता है - तो उन्हें छोड़ दिया जाएगा।
हमारे उदाहरण में, आर 3 जानता है कि स्रोत का सबसे छोटा रास्ता आर 1 (स्थिर या गतिशील मार्ग) के माध्यम से है। इसलिए, आर 1 से आने वाले मल्टीकास्ट पैकेटों को आर 3 द्वारा जांचा और स्वीकार किया जाता है, और जो आर 2 से आते हैं उन्हें छोड़ दिया जाता है।



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

हम यहां नहीं रुकेंगे और पीआईएम डीएम के संचालन की विस्तार से जांच करेंगे - यह एक पुराना प्रोटोकॉल है जिसमें बहुत सारी खामियां हैं (अच्छी तरह से, आरआईपी की तरह)।

हालाँकि, कुछ मामलों में PIM DM का उपयोग किया जा सकता है। उदाहरण के लिए, बहुत छोटे नेटवर्क में जहां मल्टीकास्ट स्ट्रीम छोटा है।

---

पीआईएम विरल मोड

एक पूरी तरह से अलग दृष्टिकोण पीआईएम एसएम लेता है । नाम (विरल मोड) के बावजूद, यह किसी भी नेटवर्क में पीआईएम डीएम की तुलना में कम से कम खराब दक्षता के साथ सफलतापूर्वक उपयोग किया जा सकता है।
यहां उन्होंने मल्टीकास्ट नेटवर्क के साथ बिना शर्त बाढ़ के विचार को छोड़ दिया। इच्छुक नोड्स स्वतंत्र रूप से पीआईएम में शामिल संदेश का उपयोग करके पेड़ से एक कनेक्शन का अनुरोध करते हैं।
यदि राउटर ने Join नहीं भेजा है, तो उसे ट्रैफ़िक नहीं भेजा जाएगा।

यह समझने के लिए कि पीआईएम कैसे काम करता है, हम एक पीआईएम राउटर के साथ परिचित सरल नेटवर्क से शुरू करते हैं:

R1 पर सेटिंग्स से, आपको मल्टीकास्ट, पीआईएम एसएम को दो इंटरफेस (स्रोत की ओर और क्लाइंट की ओर) और आईजीएमपी को क्लाइंट की ओर करने की क्षमता सक्षम करनी चाहिए। अन्य बुनियादी सेटिंग्स में, बेशक (आईपी, आईजीपी)।

अब से, आप GNS को उजागर कर सकते हैं और एक प्रयोगशाला का निर्माण कर सकते हैं। इस लेख में मैंने जिस मल्टीकास्ट के बारे में बात की है, उसके बारे में विस्तार से बात करूँ।

R1(config)#ip multicast-routing R1(config)#int fa0/0 R1(config-if)#ip pim sparse-mode R1(config-if)#int fa1/0 R1(config-if)#ip pim sparse-mode 

यहां हमेशा की तरह, सिस्को अपने विशेष दृष्टिकोण में भिन्न होता है: जब पीआईएम इंटरफ़ेस पर सक्रिय होता है, तो IGMP भी स्वचालित रूप से सक्रिय हो जाता है। सभी इंटरफेस पर जहां पीआईएम सक्रिय है, आईजीएमपी भी काम करता है।
इसी समय, अन्य निर्माताओं से दो अलग-अलग प्रोटोकॉल दो अलग-अलग कमांड द्वारा सक्षम होते हैं: अलग से आईजीएमपी, अलग से पीआईएम।
माफ कर दो सिस्को इस विषमता? बाकी सबके साथ?

साथ ही, आपको आरपी पता ( आईपी ​​पीआईएम आरपी-पता 172.16.0.1 , उदाहरण के लिए) कॉन्फ़िगर करने की आवश्यकता हो सकती है। इसके बारे में अधिक बाद में, अभी के लिए, इसे स्वीकृत और सामंजस्य के लिए लें।

समूह 224.2.2.4 के लिए मल्टीकास्ट रूटिंग टेबल की वर्तमान स्थिति की जाँच करें:



जब आप स्रोत पर प्रसारण शुरू करते हैं, तो आपको तालिका को फिर से जांचना होगा।



आइए इस लेकोनिक निष्कर्ष को देखें।

फॉर्म का एक रिकॉर्ड (*, 225.0.1.1) कहा जाता है (*, G) , / स्टारकॉम द्वारा पढ़ा जाता है / और हमें प्राप्तकर्ताओं के बारे में बताता है। और यह आवश्यक नहीं है कि हम एक क्लाइंट-कंप्यूटर के बारे में बात कर रहे हैं, सामान्य तौर पर यह हो सकता है, उदाहरण के लिए, एक और पीआईएम-राउटर। महत्वपूर्ण बात यह है कि यातायात को स्थानांतरित करने के लिए आपको कौन से इंटरफेस की आवश्यकता है।
यदि डाउनस्ट्रीम इंटरफेस (OIL) की सूची रिक्त है - अशक्त है , तो कोई प्राप्तकर्ता नहीं हैं - और हमने उन्हें अभी तक शुरू नहीं किया है।

रिकॉर्ड (172.16.0.5, 225.0.1.1) को (S, G) कहा जाता है, या इसे eskomadzhi पढ़ा जाता है और कहते हैं कि स्रोत ज्ञात है। हमारे मामले में, 172.16.0.5 पते के साथ स्रोत 224.2.2.4 समूह के लिए यातायात को प्रसारित करता है। मल्टिकास्ट ट्रैफ़िक FE0 / 1 इंटरफ़ेस पर आता है - यह एक अपस्ट्रीम इंटरफ़ेस है।

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



एक डाउनवर्ड इंटरफ़ेस दिखाई दिया: FE0 / 0, जो काफी अपेक्षित है। इसके अलावा, वह दोनों (*, G) और (S, G) में दिखाई दिए। डाउनस्ट्रीम इंटरफेस की सूची को ओआईएल - आउटगोइंग इंटरफेस लिस्ट कहा जाता है।

FE1 / 0 इंटरफ़ेस में एक और क्लाइंट जोड़ें:



यदि हम निष्कर्ष शब्द पढ़ते हैं, तो हमारे पास है:
(*, G): FE0 / 0, FE1 / 0 इंटरफेस के पीछे समूह 224.2.2.4 के लिए मल्टीकास्ट ट्रैफ़िक प्राप्तकर्ता हैं। और इससे कोई फर्क नहीं पड़ता कि प्रेषक कौन है, जो "*" संकेत कहता है।

(एस, जी): जब स्रोत 172.16.0.5 से गंतव्य पते के साथ मल्टीकास्ट ट्रैफ़िक FE0 / 1 पर आता है, तो प्रतियां FE0 / 0 और FE1 / 0 पर भेजी जानी चाहिए।

लेकिन यह एक बहुत ही सरल उदाहरण था - एक राउटर को स्रोत का पता और प्राप्तकर्ता कहां हैं, यह तुरंत पता चल जाता है। वास्तव में, यहाँ भी कोई पेड़ नहीं है - शायद पतित को छोड़कर। लेकिन इससे हमें यह समझने में मदद मिली कि पीआईएम और आईजीएमपी कैसे बातचीत करते हैं।

---

यह समझने के लिए कि पीआईएम क्या है, चलो नेटवर्क को और अधिक जटिल बनाते हैं

मान लें कि सभी आईपी पते पहले से ही योजना के अनुसार कॉन्फ़िगर किए गए हैं। आईजीपी सामान्य यूनिकैस्ट मार्ग के लिए नेटवर्क पर चल रहा है।
क्लाइंट 1 , उदाहरण के लिए, स्रोत सर्वर को पिंग कर सकता है।



लेकिन जब तक पीआईएम, आईजीएमपी शुरू नहीं किया जाता है, तब तक ग्राहक चैनलों का अनुरोध नहीं करते हैं।

प्रारंभिक कॉन्फ़िगरेशन फ़ाइल ।


तो, समय में बिंदु 0 है।

हम सभी पांच राउटर्स पर मल्टिकास्ट राउटिंग को सक्षम करते हैं:

  RX(config)#ip multicast-routing 

PIM को सभी राउटर के सभी इंटरफेस (सोर्स सर्वर और क्लाइंट्स के इंटरफ़ेस पर सहित) पर सीधे सक्षम किया जाता है:

  RX(config)#int FEX/X RX(config-if)#ip pim sparse-mode 

आईजीएमपी, सिद्धांत रूप में, ग्राहकों की दिशा में इंटरफेस पर सक्षम होना चाहिए, लेकिन, जैसा कि हमने पहले ही ऊपर उल्लेख किया है, सिस्को उपकरण पर यह स्वचालित रूप से पीआईएम के साथ सक्षम है।

---

पहली बात यह है कि PIM एक पड़ोस स्थापित करता है। इसके लिए PIM हैलो मैसेज का इस्तेमाल किया जाता है। जब पीआईएम इंटरफ़ेस पर सक्रिय होता है, तो पीआईएम हैलो को पते से 224.0.0.13 पर 1. टीटीएल के साथ भेजा जाता है। इसका मतलब है कि एक ही प्रसारण डोमेन में केवल राउटर पड़ोसी हो सकते हैं।



जैसे ही पड़ोसियों को एक-दूसरे से बधाई मिली:



अब वे मल्टीकास्ट समूहों के लिए आवेदन स्वीकार करने के लिए तैयार हैं।

यदि हम अब एक तरफ एवियरी में क्लाइंट लॉन्च करते हैं और दूसरी तरफ सर्वर से मल्टीकास्ट स्ट्रीम को सक्षम करते हैं, तो आर 1 को एक ट्रैफ़िक स्ट्रीम प्राप्त होगी, और क्लाइंट को कनेक्ट करने का प्रयास करते समय आर 4 एक आईजीएमपी रिपोर्ट प्राप्त करेगा। नतीजतन, आर 1 प्राप्तकर्ताओं के बारे में कुछ भी पता नहीं होगा, और स्रोत के बारे में आर 4।





यह अच्छा होगा यदि स्रोत के बारे में और समूह के ग्राहकों के बारे में जानकारी एक ही जगह पर एकत्र की गई थी। लेकिन किसमें?

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

MDT ट्री बनाने के लिए, एक निश्चित केंद्रीय बिंदु को नेटवर्क में RP के रूप में चुना जाता है, जो,

1. स्रोत का अध्ययन करने के लिए जिम्मेदार,
2. सभी रुचि के संदेशों में शामिल होने के आकर्षण का बिंदु है।

RP को निर्दिष्ट करने के दो तरीके हैं: स्थिर और गतिशील। हम इस लेख में दोनों को देखेंगे, लेकिन स्टेटिक के साथ शुरू करते हैं, क्योंकि स्टैटिक्स की तुलना में इतना सरल क्या है?

आर 2 आरपी की भूमिका को पूरा करेगा।
विश्वसनीयता बढ़ाने के लिए, लूपबैक इंटरफ़ेस का पता आमतौर पर चुना जाता है। इसलिए, सभी राउटर पर कमांड निष्पादित होती है:

  RX(config)#ip pim rp-address 2.2.2.2 

स्वाभाविक रूप से, यह पता सभी बिंदुओं से रूटिंग टेबल से सुलभ होना चाहिए।
खैर, चूंकि पता 2.2.2.2 आरपी है, इसलिए पीआईएम को लूपबैक 0 इंटरफेस पर आर 2 पर भी सक्रिय करना उचित है।

  R2(config)#interface Loopback 0 RX(config-if)#ip pim sparse-mode 

इसके तुरंत बाद, R4 समूह 224.2.2.4 के लिए यातायात स्रोत के बारे में सीखता है:



और यहां तक ​​कि यातायात भी पहुंचाता है:



362000 बीपीएस FE0 / 1 इंटरफ़ेस के लिए आता है, और वे FE0 / 0 इंटरफ़ेस के माध्यम से प्रेषित होते हैं।

हम सब किया है:
मल्टीकास्ट ट्रैफ़िक को रूट करने की क्षमता सक्षम ( आईपी ​​मल्टिकास्ट-रूटिंग )
इंटरफेस पर सक्रिय पीआईएम ( आईपी ​​पीएम विरल-मोड )
निर्दिष्ट RP पता ( IP pim rp-adress XXXX )

सब कुछ, यह पहले से ही एक कार्यशील कॉन्फ़िगरेशन है और आप विश्लेषण के साथ आगे बढ़ सकते हैं, क्योंकि मंच पर देखे जा सकने वाले दृश्यों के पीछे बहुत कुछ छिपा हुआ है।
PIM के साथ पूर्ण कॉन्फ़िगरेशन।

---

डीब्रीफिंग

खैर, और अंत में सब कुछ कैसे काम करता है? आरपी कैसे जानता है कि स्रोत कहां है, ग्राहक कहां हैं और उनके बीच एक कनेक्शन प्रदान करता है?

चूंकि हमारे प्रिय ग्राहकों की खातिर सब कुछ शुरू किया गया है, फिर उनके साथ शुरू करते हुए, हम पूरी प्रक्रिया पर विस्तार से विचार करेंगे।

1) क्लाइंट 1, ग्रुप 224.2.2.4 को IGMP रिपोर्ट भेजता है





2) R4 यह अनुरोध प्राप्त करता है, समझता है कि FE0 / 0 इंटरफ़ेस के पीछे एक ग्राहक है, इस इंटरफ़ेस को OIL में जोड़ता है, और एक रिकॉर्ड (*, G) बनाता है।

अपस्ट्रीम FE0 / 1 इंटरफ़ेस यहाँ दिखाई दे रहा है, लेकिन इसका मतलब यह नहीं है कि R4 समूह 224.2.2.4 के लिए ट्रैफ़िक प्राप्त करता है। यह केवल यह कहता है कि अब तक वह एकमात्र स्थान FE0 / 1 से प्राप्त कर सकता है, क्योंकि जहाँ आरपी स्थित है। वैसे, आरपीएफ-चेक - आर 2: 10.0.2.24 पास करने वाले पड़ोसी को भी यहां संकेत दिया गया है। उम्मीद।

आर 4 को कहा जाता है - एलएचआर (लास्ट हॉप राउटर) - मल्टीकास्ट ट्रैफिक के रास्ते पर अंतिम राउटर, यदि आप स्रोत से गणना करते हैं। दूसरे शब्दों में, यह प्राप्तकर्ता के निकटतम राउटर है। Client1 के लिए , यह R4 है, Client2 के लिए , यह R5 है।



3) चूँकि R4 पर अभी तक कोई मल्टीकास्ट स्ट्रीम नहीं है (उसने पहले यह अनुरोध नहीं किया था), वह एक PIM Join संदेश बनाता है और RP (2.2.2.2) को भेजता है।



PIM Join को मल्टीकास्ट द्वारा 224.0.0.13 पते पर भेजा जाता है। "आरपीओआरडी आरपी" का अर्थ उस इंटरफ़ेस के माध्यम से है जो रूटिंग टेबल में निर्दिष्ट है, पैकेट के अंदर निर्दिष्ट पते के लिए आउटबाउंड के रूप में। हमारे मामले में, यह 2.2.2.2 है - आरपी का पता। इस जॉइन को जॉइन (*, G) भी कहा जाता है और कहते हैं: "इससे कोई फर्क नहीं पड़ता कि स्रोत कौन है, मुझे समूह 224.2.2.4 से ट्रैफ़िक की आवश्यकता है।"
यही है, रास्ते में प्रत्येक राउटर को इस तरह के जॉइन को संसाधित करना होगा और यदि आवश्यक हो, तो आरपी की तरफ एक नया जॉइन भेजें। (यह समझना महत्वपूर्ण है कि यदि यह समूह पहले से ही राउटर पर मौजूद है, तो यह Join को ऊपर नहीं भेजेगा - यह केवल उस इंटरफ़ेस को जोड़ेगा जिसमें से Join OIL में आया था और ट्रैफिक भेजना शुरू किया था।
हमारे मामले में, Join FE0 / 1 में गया:





4) R2, प्राप्त होने के बाद, एक रिकॉर्ड (*, G) बनाता है और FE0 / 0 इंटरफ़ेस को OIL में जोड़ता है। लेकिन ज्वाइन करने के लिए कहीं नहीं भेजा गया है - वह खुद पहले से ही एक आरपी है, लेकिन स्रोत के बारे में अभी तक कुछ भी नहीं पता है।



इस तरह, आरपी सीखता है कि ग्राहक कहां हैं।

यदि क्लाइंट 2 भी एक ही समूह के लिए मल्टीकास्ट ट्रैफ़िक प्राप्त करना चाहता है, तो R5 FE0 / 1 पर PIM Join को भेजेगा, क्योंकि यह RP, R3 से पीछे है, इसे प्राप्त करने के बाद, एक नया PIM Join करता है और इसे FE1 / 1 में भेजता है, जहाँ RP स्थित है। ।
यही है, जब तक यह समूह आरपी या किसी अन्य राउटर तक नहीं पहुंच जाता है, जहां तक ​​इस समूह के ग्राहक पहले से ही हैं, तब तक नोड से यात्रा करें।



तो, आर 2 - हमारे आरपी - अब जानते हैं कि FE0 / 0 और FE1 / 0 के लिए उसके पास समूह 224.2.2.4 के प्राप्तकर्ता हैं।
और कोई फर्क नहीं पड़ता कि कितने हैं - प्रत्येक इंटरफ़ेस के बाद एक या एक सौ - ट्रैफ़िक प्रवाह अभी भी प्रति इंटरफ़ेस एक होगा।

यदि आप ग्राफिक रूप से दर्शाते हैं कि हमें क्या मिला, तो यह इस तरह दिखाई देगा:



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



5) अब हम सर्वर को काटते हैं। जैसा कि हमने ऊपर चर्चा की, वह पीआईएम, आरपी, आईजीएमपी के बारे में चिंता नहीं करता है - वह सिर्फ प्रसारण करता है। और R1 इस स्ट्रीम को प्राप्त करता है। उनका काम मल्टीकास्ट को आरपी तक पहुंचाना है।
PIM में एक विशेष प्रकार का संदेश होता है - रजिस्टर । आरपी पर मल्टीकास्ट के स्रोत को पंजीकृत करने के लिए यह आवश्यक है।
तो, R1 समूह 224.2.2.4 की बहुस्त्र्पीय धारा प्राप्त करता है:





आर 1 एफएचआर (फर्स्ट हॉप राउटर) है - मल्टीकास्ट ट्रैफिक के रास्ते पर पहला राउटर या स्रोत के सबसे करीब।



6) फिर यह स्रोत से प्राप्त प्रत्येक मल्टीकास्ट पैकेट को यूनिकस्ट पीआईएम रजिस्टर में इनकैप करता है और सीधे आरपी को भेजता है।



प्रोटोकॉल स्टैक पर ध्यान दें। यूनिकस्ट आईपी और पीआईएम हेडर के शीर्ष पर मूल मल्टीकास्ट आईपी, यूडीपी और डेटा आता है।
अब, PIM संदेशों के लिए अब तक ज्ञात अन्य सभी के विपरीत, प्राप्तकर्ता पते में 2.2.2.2 है, और एक बहुस्त्र्पीय पता नहीं है।

इस तरह के पैकेट को मानक यूनिकैस्ट रूटिंग नियमों के अनुसार आरपी को वितरित किया जाता है और प्रारंभिक मल्टीकास्ट पैकेट को वहन किया जाता है, अर्थात ... यह टनलिंग है!

=====================
टास्क नंबर 1

योजना और प्रारंभिक विन्यास ।



एक सर्वर 172.16.0.5 सर्वर पर चल रहा है जो केवल गंतव्य पोर्ट यूडीपी 10999 के साथ पैकेट को प्रसारण पते 255.255.255.255 पर प्रसारित कर सकता है।

यह ट्रैफ़िक क्लाइंट 1 और 2 को दिया जाना चाहिए:
239.9.9.9 समूह के पते के साथ मल्टीकास्ट ट्रैफ़िक के रूप में क्लाइंट 1।
और क्लाइंट सेगमेंट 2 में, 255.255.255.255 पते पर प्रसारण पैकेट के रूप में।

कार्य का विवरण यहां दिया गया है ।
=====================

7) आरपी पीआईएम रजिस्टर प्राप्त करता है, इसे अनपैक करता है और समूह 224.2.2.4 के लिए आवरण के नीचे यातायात का पता लगाता है।
वह तुरंत अपनी मल्टीकास्ट रूटिंग टेबल में इस बारे में जानकारी डालता है:



प्रविष्टि (एस, जी) - (172.16.0.5, 224.2.2.4) दिखाई दी।
अनपेक्षित आरपी पैकेट को फिर RP0 को FE0 / 0 और FE1 / 0 इंटरफेस पर भेजा जाता है, जिसके माध्यम से ट्रैफ़िक ग्राहकों तक पहुँचता है।

सिद्धांत रूप में, यह रोका जा सकता था। सब कुछ काम करता है - ग्राहकों को ट्रैफ़िक मिलता है। लेकिन दो समस्याएं हैं:

1. एनकैप्सुलेशन और डिकैप्सुलेशन प्रक्रिया राउटर के लिए महंगा संचालन हैं। इसके अलावा, अतिरिक्त हेडर पैकेट के आकार को बढ़ाते हैं, और यह केवल मध्यवर्ती नोड पर कहीं भी MTU में रेंगना नहीं हो सकता है (सभी सुरंगों की समस्याओं को याद रखें)।
2. अगर अचानक स्रोत और आरपी के बीच कहीं समूह के लिए अभी भी प्राप्तकर्ता हैं, तो मल्टीकास्ट ट्रैफ़िक को दो बार एक ही रास्ते से जाना होगा।

उदाहरण के लिए निम्न टोपोलॉजी लें:



रजिस्टर संदेशों में ट्रैफ़िक पहले R1-R42-R2 लाइन के साथ RP तक पहुंचेगा, फिर शुद्ध मल्टीकास्ट R2-R42 लाइन के साथ वापस आ जाएगा। इस प्रकार, एक ही ट्रैफ़िक की दो प्रतियां विपरीत दिशाओं में, R42-R2 लाइन पर चलेंगी।



इसलिए, शुद्ध मल्टीकास्ट को स्रोत से आरपी में स्थानांतरित करना बेहतर है, और इसके लिए आपको एक पेड़ बनाने की आवश्यकता है - स्रोत ट्री ।



8) इसलिए, आरपी R1 में एक PIM Join संदेश भेजता है। लेकिन अब यह पहले से ही समूह को आरपी के पते के लिए इंगित करता है, लेकिन रजिस्टर संदेश से सीखा स्रोत का। इस संदेश को Join (S, G) - Source Specific Join कहा जाता है ।


उसका लक्ष्य ठीक उसी तरह है जैसे पीआईएम जॉइन (*, जी) - एक पेड़ बनाने के लिए, केवल इस बार स्रोत से आरपी तक।
जॉइन (एस, जी) भी नोड द्वारा नोड को बढ़ाता है, नियमित जॉइन की तरह (*, जी)। केवल Join (*, G) RP को जाता है, और Join (S, G) को S - स्रोत। प्राप्तकर्ता का पता सेवा का पता 224.0.0.13 और TTL = 1 भी है।

यदि मध्यवर्ती नोड्स मौजूद हैं, उदाहरण के लिए, R42, तो वे एक रिकॉर्ड (S, G) बनाते हैं और इस समूह के लिए डाउनस्ट्रीम इंटरफेस की एक सूची बनाते हैं और स्रोत में आगे जुड़ें।

आरपी से स्रोत तक जुड़ने वाला मार्ग एक स्रोत ट्री में बदल जाता है - स्रोत से एक पेड़। लेकिन अधिक सामान्य नाम एसपीटी - सबसे छोटा पथ ट्री है - क्योंकि स्रोत से आरपी तक का यातायात सबसे छोटे रास्ते से जाएगा।



9) R1 मिलाएं (S, G), FE1 / 0 इंटरफ़ेस को जोड़ता है, जहां पैकेट OIL डाउनस्ट्रीम इंटरफेस की सूची में आता है, और शुद्ध मल्टीकास्ट ट्रैफ़िक को प्रसारित करना शुरू कर देता है, जो कि एनकैप्सुलेशन द्वारा अस्पष्ट है। R1 पर रिकॉर्ड (S, G) पहले से ही था जैसे ही उसे सोर्स सर्वर से पहला मल्टीकास्ट पैकेट मिला।



निर्मित स्रोत ट्री के अनुसार, मल्टीकास्ट आरपी (और सभी मध्यवर्ती ग्राहकों को, यदि कोई हो, उदाहरण के लिए, R42) को प्रेषित किया जाता है।

लेकिन हमें यह ध्यान रखना चाहिए कि रजिस्टर संदेश इस समय सभी प्रेषित किए गए हैं और अभी भी प्रसारित किए जा रहे हैं। यही है, वास्तव में, आर 1 अब ट्रैफिक की दो प्रतियां भेजता है: एक शुद्ध एसपीटी मल्टीकास्ट है, दूसरा यूनिकैस्ट रजिस्टर में एनकैप्सुलेटेड है।

सबसे पहले, आर 1 रजिस्टर में एक मल्टीकास्ट भेजता है - पैकेट 231 । फिर R2 (RP) पेड़ से जुड़ना चाहता है, Join - पैकेट 232 भेजता है। R2 से अनुरोध को संसाधित करते समय कुछ समय के लिए R1, रजिस्टर करने के लिए एक मल्टीकास्ट ( 233 से 238 तक पैकेट ) भेजता है। इसके अलावा, जब R1 पर OIL में टॉप-डाउन इंटरफ़ेस जोड़ा जाता है, तो यह शुद्ध मल्टीकास्ट पैकेट 239 और 242 को प्रसारित करना शुरू कर देता है, लेकिन अभी तक रजिस्टर - पैकेट 241 और 243 को बंद नहीं किया है। और पैकेज 240 - यह आर 2 इसे बर्दाश्त नहीं कर सका और फिर से एक पेड़ बनाने के लिए कहा।

10) तो, एक बहुरंगी मल्टीकास्ट आरपी तक पहुंचता है। वह समझती है कि यह वही ट्रैफ़िक है जो रजिस्टर करने के लिए आता है, क्योंकि एक ही समूह का पता, एक ही स्रोत का पता और एक इंटरफ़ेस से। दो प्रतियाँ प्राप्त न करने के लिए, वह R1 को एक यूनिकस्ट PIM रजिस्टर-स्टॉप भेजता है।



रजिस्टर-स्टॉप का मतलब यह नहीं है कि आर 2 ट्रैफ़िक को मना करता है या इस स्रोत को अब पहचानता नहीं है, इसका मतलब केवल यह है कि एन्कैप्स ट्रैफ़िक भेजना बंद करना आवश्यक है।

फिर एक भयंकर संघर्ष होता है - R1 बफर में संचित यातायात को संचारित करना जारी रखता है, जबकि यह रजिस्टर-स्टॉप को सामान्य मल्टीकास्ट और अंदर के रजिस्टर संदेशों के साथ संसाधित करता है:



लेकिन, जल्द या बाद में, आर 1 केवल शुद्ध मल्टीकास्ट ट्रैफिक को प्रसारित करना शुरू कर देता है।

तैयारी में, मेरे पास, जैसा कि यह मेरे लिए एक तार्किक प्रश्न था: ठीक है, इन सभी सुरंगों, पीआईएम रजिस्टर क्यों? मल्टीकास्ट ट्रैफ़िक के साथ क्यों नहीं, जैसा कि पीआईएम के साथ होता है - आरटी की ओर टीटीएल = 1 के साथ हॉप-बाय-हॉप भेजना - क्या यह जल्द या बाद में आएगा? तो पेड़ बिना अनावश्यक इशारों के एक ही समय में बनाया जाएगा।
यहाँ कई बारीकियाँ हैं।
सबसे पहले, पीआईएम एसएम के मुख्य सिद्धांत का उल्लंघन किया जाता है - केवल उस स्थान पर यातायात भेजने के लिए जहां से यह अनुरोध किया गया था। नो जॉइन - नो ट्री !
दूसरे, यदि इस समूह के लिए कोई ग्राहक नहीं हैं, तो एफएचआर को इसके बारे में नहीं पता होगा और अपने स्वयं के पेड़ पर यातायात भेजना जारी रखेगा। बैंडविड्थ का बेकार उपयोग क्या है? संचार की दुनिया में, इस तरह के एक प्रोटोकॉल केवल जीवित नहीं होगा, जैसे कि पीआईएम डीएम या डीवीएमआरपी नहीं बची थी।

इस प्रकार, हमारे पास स्रोत सर्वर से क्लाइंट 1 और क्लाइंट 2 तक समूह 224.2.2.4 के लिए एक बड़ा एमडीटी पेड़ है। और यह एमडीटी दो टुकड़ों से बना है जो एक-दूसरे से स्वतंत्र रूप से निर्मित हैं: स्रोत ट्री स्रोत से आरपी और आरपीटी आरपी से क्लाइंट तक। यहां एमडीटी और आरपीटी और एसपीटी के बीच अंतर है। MDT एक सामान्य सामान्य शब्द है जिसका अर्थ है मल्टीकास्ट ट्रांसमिशन ट्री सामान्य तौर पर, जबकि RPT / SPT इसका विशिष्ट स्वरूप है।

लेकिन क्या होगा यदि सर्वर पहले से ही प्रसारण कर रहा है, लेकिन कोई क्लाइंट नहीं है? क्या मल्टीकास्ट प्रेषक और आरपी के बीच के क्षेत्र को रोक देगा?
नहीं, इस मामले में पीआईएम रजिस्टर-स्टॉप भी मदद करेगा। यदि कुछ समूह के लिए आरपी पर रजिस्टर संदेश आने लगे हैं, लेकिन इसके लिए कोई प्राप्तकर्ता नहीं हैं, तो आरपी को इस ट्रैफ़िक को प्राप्त करने में कोई दिलचस्पी नहीं है, इसलिए, पीआईएम जॉइन (एस, जी) को भेजे बिना , आरपी तुरंत रजिस्टर-स्टॉप को आर 1 पर भेजता है।
R1, रजिस्टर-स्टॉप प्राप्त किया और यह देखते हुए कि इस समूह के लिए कोई पेड़ अभी तक नहीं है (कोई क्लाइंट नहीं हैं), सर्वर से मल्टीकास्ट ट्रैफ़िक को छोड़ना शुरू कर देता है।
यही है, सर्वर स्वयं इस बारे में पूरी तरह से चिंतित नहीं है और स्ट्रीम भेजना जारी रखता है, लेकिन जब यह राउटर इंटरफ़ेस तक पहुंच जाता है, तो स्ट्रीम को छोड़ दिया जाएगा।
इस मामले में, आरपी रिकॉर्ड (एस, जी) को संग्रहीत करना जारी रखता है। यही है, यह ट्रैफ़िक प्राप्त नहीं करता है, लेकिन जानता है कि समूह के लिए स्रोत कहाँ स्थित है। यदि प्राप्तकर्ता समूह में दिखाई देते हैं, तो RP उनके बारे में सीखता है और उन्हें Join (S, G) स्रोत पर भेजता है, जो पेड़ बनाता है।

इसके अलावा, हर 3 मिनट में, आर 1 आरपी पर स्रोत को फिर से पंजीकृत करने की कोशिश करेगा, अर्थात, रजिस्टर पैकेट भेजें। आरपी को सूचित करने के लिए यह आवश्यक है कि यह स्रोत अभी भी जीवित है।

विशेष रूप से जिज्ञासु पाठकों को एक प्रश्न पूछना चाहिए - आरपीएफ के बारे में क्या? यह तंत्र, आखिरकार, मल्टीकास्ट पैकेट के प्रेषक पते की जांच करता है, और यदि ट्रैफ़िक सही इंटरफ़ेस से नहीं आता है, तो इसे छोड़ दिया जाएगा। इस मामले में, आरपी और स्रोत विभिन्न इंटरफेस पर स्थित हो सकते हैं। तो R3 RP के लिए हमारे उदाहरण में - FE1 / 1 के लिए, और FE1 / 0 के लिए स्रोत।
उत्तर अनुमानित है - इस मामले में, यह स्रोत का पता नहीं है जिसे चेक किया गया है, लेकिन आरपी। यही है, ट्रैफ़िक को इंटरफ़ेस से RP की ओर आना चाहिए।
लेकिन, जैसा कि आप बाद में देखेंगे, यह भी एक अविनाशी नियम नहीं है।

यह समझना महत्वपूर्ण है कि आरपी एक सार्वभौमिक चुंबक नहीं है - प्रत्येक समूह का अपना आरपी हो सकता है। यही है, नेटवर्क में दो, तीन और एक सौ हो सकते हैं - एक आरपी एक समूह के समूह के लिए जिम्मेदार है, दूसरे के लिए दूसरा। इसके अलावा, एनीकास्ट आरपी जैसी कोई चीज है , और फिर अलग-अलग आरपी एक ही समूह की सेवा कर सकते हैं।

=====================
टास्क नंबर 2

योजना और प्रारंभिक विन्यास ।



टोपोलॉजी पर एक नोट : इस कार्य में, हमारे नेटवर्क के प्रशासकों द्वारा केवल R1, R2, R3 को रूट किया जाता है। यही है, कॉन्फ़िगरेशन केवल उन पर बदला जा सकता है।

सर्वर 172.16.0.5 समूहों को 239.1.1.1 और 239.2.2.2 को मल्टीकास्ट ट्रैफ़िक भेजता है।

नेटवर्क को कॉन्फ़िगर करें ताकि समूह 239.1.1.1 का ट्रैफ़िक R3 और R5 के बीच और R5 से नीचे के सभी सेगमेंट में न जाए।
लेकिन एक ही समय में, समूह 239.2.2.2 का यातायात समस्याओं के बिना प्रसारित किया जाना चाहिए।

कार्य का विवरण यहां दिया गया है ।
=====================

---

व्यापम का उस्तरा या अनावश्यक शाखाओं को निष्क्रिय करना

सेगमेंट में अंतिम क्लाइंट के अनसब्सक्राइब हो जाने के बाद, PIM को अतिरिक्त RPT शाखा को काट देना चाहिए।
मान लीजिए, उदाहरण के लिए, R4 पर एकमात्र क्लाइंट ने कंप्यूटर बंद कर दिया। IGMP छोड़ संदेश द्वारा राउटर या तीन अनुत्तरित IGMP क्वेरी के बाद समझता है कि FE0 / 0 के पीछे कोई और क्लाइंट नहीं है, और RP पक्ष को PIM Prune संदेश भेजता है । प्रारूप में, यह बिल्कुल Join के समान है, लेकिन विपरीत कार्य करता है।
गंतव्य का पता भी 224.0.0.13 है, और TTL 1. है।



लेकिन PIM प्रून प्राप्त करने वाला राउटर सदस्यता को हटाने से पहले थोड़ी देर इंतजार करता है (आमतौर पर 3 सेकंड - Delay Timer में शामिल हों)।
यह इस स्थिति के लिए किया जाता है:

एक प्रसारण डोमेन में 3 राउटर होते हैं। उनमें से एक अधिक है, और यह वह है जो खंड में मल्टीकास्ट ट्रैफ़िक स्थानांतरित करता है। यह R1 है। दोनों राउटर (R2 और R3) के लिए, इसके OIL में केवल एक प्रविष्टि है।

अगर अब R2 पीआईएम प्रून को डिस्कनेक्ट करने और भेजने का फैसला करता है, तो वह अपने सहयोगी आर 3 को प्रतिस्थापित कर सकता है - आर 1 इंटरफ़ेस पर प्रसारण बंद कर देगा।
तो, ऐसा होने से रोकने के लिए, आर 1 3 सेकंड का समय देता है। इस समय के दौरान, आर 3 को प्रतिक्रिया करने का समय होना चाहिए। नेटवर्क के प्रसारण को देखते हुए, यह R2 से Prune भी प्राप्त करेगा और इसलिए, यदि यह ट्रैफ़िक प्राप्त करना जारी रखना चाहता है, तो यह तुरंत एक नियमित PIM सेगमेंट में भेजता है, R1 को सूचित करता है कि इंटरफ़ेस को निकालना आवश्यक नहीं है।

इस प्रक्रिया को कहा जाता है - प्रून ओवरराइड। R2, जैसा कि यह था, आर 1 से आगे निकल गया, पहल को जब्त कर लिया।

---

एसपीटी स्विचओवर - आरपीटी-एसपीटी स्विचिंग

अब तक, हमने मुख्य रूप से केवल क्लाइंट 1 पर विचार किया है । अब ग्राहक 2 की ओर मुड़ें ।
सबसे पहले, उसके लिए सब कुछ क्लाइंट 1 के समान है - वह आरपी से आरपीटी का उपयोग करता है, जिसकी हमने पहले जांच की थी। वैसे, चूंकि दोनों - क्लाइंट 1 और क्लाइंट 2 - एक ही पेड़ का उपयोग करते हैं, ऐसे पेड़ को साझा पेड़ कहा जाता है - यह एक उचित नाम है। साझा पेड़ = आरपीटी।

यहाँ R5 पर मल्टीकास्ट रूटिंग टेबल क्या है जो पेड़ के निर्माण के ठीक बाद की शुरुआत में दिखती है:



कोई प्रविष्टि (S, G) नहीं है, लेकिन इसका मतलब यह नहीं है कि मल्टीकास्ट ट्रैफ़िक संचारित नहीं है। R5 सिर्फ परवाह नहीं करता है कि प्रेषक कौन है।

ध्यान दें कि इस मामले में ट्रैफ़िक किस मार्ग पर जाना चाहिए - R1-R2-R3-R5। यद्यपि मार्ग R1-R3-R5 छोटा है।



और अगर नेटवर्क अधिक जटिल है?



किसी तरह मैला।

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



कोई व्यक्ति स्वयं को स्रोत की ओर क्यों नहीं भेजता और मार्ग का अनुकूलन कैसे करता है?

जड़ को देखो। ऐसा स्विच LHR (लास्ट हॉप राउटर) शुरू कर सकता है- आर 5। R3 से पहला मल्टीकास्ट पैकेट प्राप्त करने के बाद, R5 FE0 / 1 इंटरफ़ेस के लिए पहले से ज्ञात स्रोत विशिष्ट जॉइन (S, G) को भेजता है, जो कि इसके रूटिंग टेबल में नेटवर्क 172.16.0.0-24 के लिए आउटगोइंग के रूप में इंगित किया गया है।


इस तरह के Join को प्राप्त करने के बाद, R3 इसे RP को नहीं भेजता है, जैसा कि यह सामान्य Join (*, G) के साथ किया था, लेकिन स्रोत की तरफ (रूटिंग टेबल के अनुसार इंटरफेस के माध्यम से)।
यही है, इस मामले में, आर 3 एफई 1/0 इंटरफेस में जॉइन (172.16.0.5, 224.2.2.4) भेजता है।



अगला, यह जॉइन R1 को मिलता है। और आर 1, बाय और बड़े, कोई फर्क नहीं पड़ता कि किसने इसे भेजा है - आरपी या कोई और - यह ग्रुप 224.2.2.4 के लिए अपने ओआईएल में FE1 / 1 जोड़ता है।



इस बिंदु पर, स्रोत और रिसीवर के बीच दो रास्ते हैं और R3 को दो धाराएँ मिलती हैं।



अतिरिक्त ट्रिम करने के लिए एक विकल्प बनाने का समय। इसके अलावा, यह आर 3 है जो इसे बनाता है, क्योंकि आर 5 अब इन दो धाराओं के बीच अंतर करने में सक्षम नहीं होगा - वे दोनों एक ही इंटरफ़ेस के माध्यम से आएंगे।
जैसे ही R3 ने अलग-अलग इंटरफेस से दो समान प्रवाह तय किए हैं, यह रूटिंग टेबल के अनुसार पसंदीदा एक का चयन करता है। इस मामले में, प्रत्यक्ष, आरपी के माध्यम से बेहतर है। इस बिंदु पर, आर 3 आरपीटी शाखा को काटकर आरपीयू पक्ष को प्रून (एस, जी) भेजता है। और उस क्षण से केवल एक धारा सीधे स्रोत से बची रहती है।



इस प्रकार पीआईएम ने एसपीटी - शॉर्ट पाथ ट्री का निर्माण किया। यह वही सोर्स ट्री है। यह क्लाइंट से सोर्स तक का सबसे छोटा रास्ता है। वैसे, स्रोत से आरपी तक का पेड़, जिसे हमने पहले ही ऊपर चर्चा की है, अनिवार्य रूप से ठीक उसी एसपीटी है।
यह अंकन (एस, जी) की विशेषता है। यदि राउटर में ऐसी प्रविष्टि है, तो यह जानता है कि एस समूह जी के लिए स्रोत है और एसपीटी पेड़ बनाया गया है।

एसपीटी पेड़ की जड़ स्रोत है और मैं वास्तव में " स्रोत से ग्राहक के लिए सबसे छोटा रास्ता" कहना चाहता हूं । लेकिन यह तकनीकी रूप से गलत है, क्योंकि स्रोत से क्लाइंट तक और क्लाइंट से स्रोत तक के रास्ते अलग-अलग हो सकते हैं। अर्थात्, क्लाइंट से एक ट्री ब्रांच बननी शुरू होती है: राउटर PIM जॉइन को सोर्स / RP साइड में भेजता है और RPF ट्रैफिक प्राप्त करने के लिए इंटरफेस की जांच करता है।

आपको याद है कि R5 पर इस खंड की शुरुआत में केवल एक रिकॉर्ड (*, G) था, अब इन सभी घटनाओं के बाद उनमें से दो होंगे: (*, G) और (S, G) ।

---

वैसे, यदि आप R3 मल्टीकास्ट राउटिंग टेबल को उसी सेकंड में देखते हैं, जिसे आपने VLC में Play पर क्लिक किया था, तो आप देखेंगे कि यह पहले से ही R1 से सीधे ट्रैफ़िक प्राप्त कर रहा है, जैसा कि रिकॉर्ड (S, G) की उपस्थिति से संकेत मिलता है।
यही है, एसपीटी स्विचओवर पहले से ही हुआ है - यह कई निर्माताओं के उपकरणों पर डिफ़ॉल्ट कार्रवाई है - पहला मल्टीकास्ट पैकेट प्राप्त करने के बाद स्विच शुरू करने के लिए।

सामान्यतया, ऐसे स्विच कई मामलों में हो सकते हैं:

• कभी भी ऐसा न हो ( ip pim spt-threshold infinity कमांड )।
• एक निश्चित बैंडविड्थ उपयोग ( आईपी ​​पिम स्पेस-थ्रेशोल्ड एक्स कमांड ) तक पहुंचने पर ।
• बेशक - पहला पैकेट प्राप्त करने के तुरंत बाद (डिफ़ॉल्ट कार्रवाई या कोई आईपी पिम स्पेस-थ्रेशोल्ड एक्स )

एक नियम के रूप में, निर्णय कि "समय" एलएचआर द्वारा किया जाता है।

इस मामले में, आरपीएफ के संचालन का नियम दूसरी बार बदलता है - यह फिर से स्रोत के स्थान की जांच करता है। यही है, मल्टीकास्ट की दो धाराओं से - आरपी से और स्रोत से - स्रोत से ट्रैफ़िक को प्राथमिकता दी जाती है।

---

डीआर, एसर, फारवर्डर

पीआईएम पर विचार करते समय कुछ और महत्वपूर्ण बिंदु।

डीआर - नामित राउटर ।
यह एक समर्पित राउटर है जो आरपी को सर्विस पैकेट भेजने के लिए जिम्मेदार है।
स्रोत DR - सीधे स्रोत से मल्टीकास्ट पैकेट प्राप्त करने और आरपी के साथ इसे पंजीकृत करने के लिए जिम्मेदार है।
यहाँ एक टोपोलॉजी का उदाहरण दिया गया है:



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



उच्च मूल्य, उच्च प्राथमिकता। यदि वे समान हैं, तो उच्चतम आईपी पते वाले नोड का चयन किया जाता है (हैलो संदेश से भी)।



यदि किसी अन्य राउटर (DR नहीं) को होल्डटाइम के दौरान (डिफ़ॉल्ट 105 s) पड़ोसी से हैलो प्राप्त नहीं हुआ, तो यह स्वचालित रूप से DR की भूमिका निभाता है।

संक्षेप में, सोर्स डीआर एक एफएचआर है - पहला हॉप राउटर ।

प्राप्तकर्ता DR , स्रोत DR के समान है, केवल मल्टीकास्ट ट्रैफ़िक प्राप्त करने वालों के लिए - LHR (लास्ट हॉप राउटर) ।
टोपोलॉजी उदाहरण:



आरपी पीआईएम जॉइन में भेजने के लिए रिसीवर डीआर जिम्मेदार है। उपरोक्त टोपोलॉजी में, यदि दोनों राउटर जॉइन भेजते हैं, तो दोनों को मल्टीकास्ट ट्रैफ़िक प्राप्त होगा, लेकिन यह आवश्यक नहीं है। केवल DR Join भेजता है। दूसरा बस DR उपलब्धता की निगरानी करता है।
चूंकि DR जॉइन भेजता है, इसलिए यह LAN को ट्रैफ़िक भी प्रसारित करेगा। लेकिन यहां एक तार्किक सवाल उठता है - क्या होगा अगर पीआईएम डीआर एक हो गया, और आईजीएमपी क्वियर एक और हो गया? और स्थिति काफी संभव है, क्योंकि क्वियर के लिए आईपी कम, बेहतर, लेकिन डीआर के लिए, इसके विपरीत।
इस स्थिति में, राउटर जो पहले से ही Querier है, DR द्वारा चुना गया है और यह समस्या उत्पन्न नहीं होती है।



रिसीवर DR को चुनने के नियम सोर्स DR के समान ही हैं।

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



यहां, तीन राउटर एक ही नेटवर्क सेगमेंट में हैं और तदनुसार, पीआईएम पड़ोसी हैं। R1 एक RP के रूप में कार्य करता है।
R4 PIM Join को RP की ओर भेजता है। चूंकि यह पैकेज मल्टीकास्ट है, यह R2 और R3 दोनों पर पड़ता है, और दोनों ही, इसे संसाधित करने के बाद, OIL में डाउनस्ट्रीम इंटरफ़ेस जोड़ते हैं।
यहां DR चयन तंत्र को काम करना चाहिए, लेकिन R2 और R3 पर इस समूह के अन्य ग्राहक हैं, और दोनों राउटर को वैसे भी PIM Join भेजना होगा।
जब मल्टीकास्ट ट्रैफ़िक आर 2 और आर 3 पर स्रोत से आता है, तो यह दोनों राउटर्स द्वारा सेगमेंट में प्रसारित होता है और वहां दोगुना हो जाता है। पीआईएम इस स्थिति को रोकने की कोशिश नहीं करता है - यहां यह एक निपुण अपराध के तथ्य पर काम करता है - जैसे ही राउटर को एक निश्चित समूह (ओआईएल सूची से) के लिए अपने डाउनस्ट्रीम इंटरफ़ेस में इस समूह के मल्टीकास्ट ट्रैफ़िक प्राप्त होता है, यह समझता है कि कुछ गलत है - पहले से ही एक अन्य प्रेषक है इस सेगमेंट में।



फिर राउटर एक विशेष PIM Assert संदेश भेजता है ।
यह संदेश PIM फ़ॉरवर्डर चुनने में मदद करता है- राउटर जो इस सेगमेंट में प्रसारण का हकदार है।



इसे पीआईएम डीआर के साथ भ्रमित न करें। सबसे पहले, PIM DR, PIM Join और Prune संदेश भेजने के लिए जिम्मेदार है, और PIM Forwarder ट्रैफिक भेजने के लिए जिम्मेदार है । दूसरा अंतर यह है कि PIM DR को हमेशा किसी भी नेटवर्क में तब चुना जाता है जब पड़ोस की स्थापना की जाती है, और PIM Forwrder केवल तभी आवश्यक होता है - जब OIL सूची से इंटरफ़ेस से मल्टीकास्ट ट्रैफ़िक प्राप्त होता है।

---

आरपी पसंद

ऊपर, सादगी के लिए, हमने आरपी को मैन्युअल रूप से आईपी ​​पिम आरपी-एड्रेस XXXX कमांड के साथ सेट किया है ।
और यह वही है जो शो आईपी पिम आरपी कमांड की तरह दिखता था :



लेकिन आइए एक ऐसी स्थिति की कल्पना करें जो आधुनिक नेटवर्क में पूरी तरह से असंभव है - आर 2 विफल। यह सब खत्म है। क्लाइंट 2 अभी भी काम करेगा, क्योंकि एक एसपीटी स्विचओवर था, लेकिन नया और आरपी के माध्यम से चला गया सब कुछ टूट जाएगा, भले ही कोई वैकल्पिक तरीका हो।
खैर, डोमेन व्यवस्थापक पर लोड। कल्पना करें: 50 राउटर पर, मैन्युअल रूप से कम से कम एक कमांड मारें (और विभिन्न समूहों के लिए अलग-अलग आरपी हो सकते हैं)।

आरपी का गतिशील चयन आपको मैनुअल काम से बचने और विश्वसनीयता सुनिश्चित करने की अनुमति देता है - यदि एक आरपी अनुपलब्ध हो जाता है, तो दूसरा तुरंत लड़ाई में प्रवेश करेगा।

फिलहाल, एक आम तौर पर मान्यता प्राप्त प्रोटोकॉल है जो आपको ऐसा करने की अनुमति देता है - बूटस्ट्रैप । पुराने दिनों में टिस्का ने कुछ हद तक अनाड़ी ऑटो-आरपी को बढ़ावा दिया था , लेकिन अब यह लगभग कभी भी उपयोग नहीं किया जाता है, हालांकि tsiska इसे मान्यता नहीं देता है, और शो आईपी mroute में हमारे पास समूह 224.0.1.40 के रूप में एक कष्टप्रद अशिष्टता है।

हमें वास्तव में ऑटो-आरपी प्रोटोकॉल के लिए श्रद्धांजलि अर्पित करनी चाहिए। पुराने दिनों में वह मोक्ष था। लेकिन खुले और लचीले बूटस्ट्रैप के आगमन के साथ, इसने स्वाभाविक रूप से रास्ता दिया।

तो, मान लीजिए कि हमारे नेटवर्क में हम चाहते हैं कि आर 3 आर 2 की विफलता की स्थिति में आरपी के कार्यों को उठाए।
R2 और R3 को RP की भूमिका के लिए उम्मीदवार के रूप में परिभाषित किया गया है - इसलिए उन्हें C-RP कहा जाता है । इन राउटर्स पर हम कॉन्फ़िगर करते हैं:

  RX(config)interface Loopback 0 RX(config-if)ip pim sparse-mode RX(config-if)exit RX(config)#ip pim rp-candidate loopback 0 

लेकिन जब तक कुछ नहीं होता है - उम्मीदवार अभी तक नहीं जानते कि सभी को अपने बारे में कैसे सूचित किया जाए।

मौजूदा आरपी के बारे में सभी मल्टीकास्ट डोमेन राउटर को सूचित करने के लिए, बीएसआर तंत्र , बूटस्ट्रैप राउटर पेश किया गया है । कई आवेदक हो सकते हैं, साथ ही सी-आरपी भी। उन्हें क्रमशः, सी-बीएसआर कहा जाता है । वे एक समान तरीके से कॉन्फ़िगर किए गए हैं।

हमारे पास एक बीएसआर है और परीक्षण के लिए (विशेष रूप से) यह आर 1 होगा।

 R1(config)interface Loopback 0 R1(config-if)ip pim sparse-mode R1(config-if)exit R1(config)#ip pim bsr-candidate loopback 0 

सबसे पहले, सभी सी-बीएसआर से, एक मुख्य बीएसआर का चयन किया जाता है, जो सब कुछ का प्रभारी होगा। ऐसा करने के लिए, प्रत्येक सी-बीएसआर 224.0.0.13 पते पर नेटवर्क पर एक मल्टीकास्ट बूटस्ट्रैप संदेश (बीएसएम) भेजता है - यह भी एक पीआईएम प्रोटोकॉल पैकेट है। इसे सभी मल्टीकास्ट राउटरों द्वारा स्वीकार और संसाधित किया जाना चाहिए और फिर उन सभी बंदरगाहों पर भेजा जाना चाहिए जहां पीआईएम सक्रिय है। पीआईएम जॉइन के विपरीत, लेकिन सभी दिशाओं में बीएसएम को कुछ (आरपी ​​या स्रोत) की दिशा में नहीं प्रेषित किया जाता है। यह प्रशंसक वितरण बीएसएम को सभी सी-बीएसआर और सभी सी-आरपी सहित नेटवर्क के सभी कोनों तक पहुंचने में मदद करता है। बीएसएम को अनिश्चित काल तक नेटवर्क के आसपास भटकने से रोकने के लिए, वही आरपीएफ तंत्र लागू किया जाता है - यदि बीएसएम इस संदेश को भेजने वाले के नेटवर्क के पीछे गलत इंटरफेस से आया है, तो यह संदेश छोड़ दिया जाता है।



इन बीएसएम की मदद से, सभी मल्टीकास्ट राउटर प्राथमिकताओं के आधार पर सबसे योग्य उम्मीदवार का निर्धारण करते हैं। जैसे ही सी-बीएसआर एक उच्च प्राथमिकता वाले दूसरे राउटर से बीएसएम प्राप्त करता है, वह अपने संदेश भेजना बंद कर देता है। नतीजतन, सभी को एक ही जानकारी है।



इस स्तर पर, जब बीएसआर का चयन किया जाता है, इस तथ्य के कारण कि उसके बीएसएम पहले से ही पूरे नेटवर्क में फैल चुके हैं, सी -आरपी को इसका पता पता है और यूनिकस्ट ने कैंडिडेट-आरपी-विज्ञापन संदेश इसमें भेजे हैं , जिसमें वे उन समूहों की सूची बनाते हैं जो सेवा करते हैं - यह जिसे ग्रुप-टू-आरपी मैपिंग कहा जाता है । बीएसआर इन सभी संदेशों को एकत्र करता है और आरपी-सेट बनाता है - एक सूचना तालिका: जो आरपी प्रत्येक समूह की सेवा करता है।



अगला, बीएसआर उसी फैन तरीके से बूटस्ट्रैप मैसेज भेजता है, जिसमें इस बार आरपी-सेट होता है। ये संदेश सफलतापूर्वक सभी मल्टीकास्ट राउटर तक पहुंचते हैं, जिनमें से प्रत्येक स्वतंत्र रूप से चुनता है कि प्रत्येक विशिष्ट समूह के लिए कौन सा आरपी का उपयोग करें।



बीएसआर समय-समय पर ऐसी मेलिंग करता है ताकि एक तरफ सभी को पता चले कि आरपी पर जानकारी अभी भी प्रासंगिक है, और दूसरी तरफ सी-बीएसआर को पता है कि मुख्य बीएसआर अभी भी जीवित है।
आरपी, वैसे, समय-समय पर अपने कैंडिडेट-आरपी-विज्ञापन की घोषणाएं भी बीएसआर को भेजते हैं।

वास्तव में, आप सभी को स्वचालित आरपी चयन को कॉन्फ़िगर करने की आवश्यकता है - सी-आरपी निर्दिष्ट करें और सी-बीएसआर निर्दिष्ट करें - बहुत काम नहीं है, पीआईएम आपके लिए बाकी काम करेगा।
हमेशा की तरह, विश्वसनीयता बढ़ाने के लिए, उम्मीदवारों के रूप में लूपबैक इंटरफेस को निर्दिष्ट करने की सिफारिश की गई है।

---

PIM SM पर अध्याय को छोड़कर, आइए हम एक बार फिर सबसे महत्वपूर्ण बिंदुओं को उजागर करें

1. आईजीपी या स्थिर मार्गों का उपयोग करके सामान्य यूनिकस्ट कनेक्टिविटी प्रदान की जानी चाहिए। यह आरपीएफ एल्गोरिदम का आधार है।
2. ग्राहक की उपस्थिति के बाद ही पेड़ का निर्माण किया जाता है। यह ग्राहक है जो पेड़ के निर्माण की पहल करता है। कोई ग्राहक नहीं - कोई पेड़ नहीं।
3. RPF छोरों से बचने में मदद करता है।
4. सभी राउटर को पता होना चाहिए कि आरपी कौन है - केवल इसकी मदद से एक पेड़ बनाया जा सकता है।
5. एक आरपी बिंदु को सांख्यिकीय रूप से निर्दिष्ट किया जा सकता है, या इसे बूटस्ट्रैप प्रोटोकॉल का उपयोग करके स्वचालित रूप से चुना जा सकता है।
6. RPT — RP — Source Tree — RP. RPT SPT — .

हम उन सभी प्रकार के पेड़ों और संदेशों को भी सूचीबद्ध करेंगे जिन्हें अब हम जानते हैं।

एमडीटी - मल्टीकास्ट डिस्ट्रीब्यूशन ट्री । एक सामान्य शब्द जो किसी भी मल्टीकास्ट ट्रांसमिशन ट्री का वर्णन करता है।
एसपीटी - सबसे छोटा पथ ट्री । ग्राहक या आरपी से स्रोत तक का सबसे छोटा रास्ता वाला पेड़। PIM DM में, केवल SPT है। पीआईएम एसएम में, एसपीटी स्रोत से आरपी तक या एसपीटी स्विचओवर होने के बाद स्रोत से गंतव्य तक हो सकता है। यह प्रविष्टि (एस, जी) द्वारा इंगित किया जाता है - समूह के लिए स्रोत ज्ञात है।
सोर्स ट्री एसपीटी के समान है।
आरपीटी - रेंडीज़्वस पॉइंट ट्री । आरपी से प्राप्तकर्ताओं को पेड़। केवल PIM SM में उपयोग किया जाता है। यह प्रविष्टि (*, जी) द्वारा इंगित किया गया है ।
साझा पेड़- आरपीटी के समान। इसे इसलिए कहा जाता है क्योंकि सभी ग्राहक आरपी में रूट के साथ एक ही साझा किए गए पेड़ से जुड़े होते हैं।

संदेश प्रकार PIM विरल मोड:
नमस्ते - एक पड़ोस की स्थापना और इस रिश्ते को बनाए रखने के लिए। साथ ही DR का चयन करने की आवश्यकता है।
ज्वाइन (*, G) - ग्रुप G ट्री से जुड़ने का अनुरोध। स्रोत चाहे कोई भी हो। आरपी की ओर भेजा गया। उनकी मदद से, एक RPT पेड़ बनाया गया है।
सम्मिलित हों (एस, जी) - स्रोत विशिष्ट जुड़ें। यह एक विशिष्ट स्रोत के साथ समूह जी के पेड़ से जुड़ने के लिए एक अनुरोध है - एस। इसे स्रोत की ओर भेजा जाता है - एस उनकी मदद से, एसपीटी पेड़ बनाया गया है।
प्रून (*, जी) - पेड़ से एक समूह जी को डिस्कनेक्ट करने का अनुरोध, जो भी इसके लिए स्रोत हैं। आरपी की ओर भेजा गया। यह आरपीटी शाखा को काटता है।
प्रून (एस, जी)- समूह जी के पेड़ से डिस्कनेक्ट करने का अनुरोध, जिसका मूल स्रोत एस है। इसे स्रोत की ओर भेजा जाता है। यह SPT शाखा को काटता है।
रजिस्टर - एक विशेष संदेश जिसके अंदर मल्टीटास्ट आरपी को प्रेषित किया जाता है जब तक कि एसपीटी स्रोत से आरपी तक नहीं बनाया जाता है। एफएचआर से आरपी तक यूनिकास्ट।
रजिस्टर-स्टॉप - आरपी से एफएचआर तक यूनिकस्ट द्वारा भेजा गया, रजिस्टर में मल्टीकास्ट ट्रैफिक को रोकने के लिए भेजने का आदेश।
बूटस्ट्रैप बीएसआर इंजन पैकेज हैं जो आपको बीएसआर भूमिका के लिए एक राउटर का चयन करने की अनुमति देते हैं, साथ ही मौजूदा आरपी और समूहों के बारे में जानकारी प्रसारित करते हैं।
जोर - एक संदेश PIM फ़ॉरवर्डर का चयन करने के लिए ताकि दो राउटर एक सेगमेंट में ट्रैफ़िक संचारित न करें।
उम्मीदवार-आरपी-विज्ञापन- एक संदेश जिसमें आरपी बीएसआर को सूचना भेजता है कि वह किन समूहों में कार्य करता है।
RP-Reachable - RP का एक संदेश, जिसके साथ वह अपनी उपलब्धता के बारे में सभी को सूचित करता है।
* पीआईएम में अन्य प्रकार के संदेश हैं, लेकिन ये विवरण हैं *

---

अब प्रोटोकॉल के विवरण को अनदेखा करने का प्रयास करते हैं? और तब इसकी जटिलता स्पष्ट हो जाती है।

1) आरपी की परिभाषा,
2) आरपी पर स्रोत का पंजीकरण,
3) एसपीटी पेड़ पर स्विच करना।

कई प्रोटोकॉल बताता है, मल्टीकास्ट रूटिंग टेबल में कई प्रविष्टियां। क्या आप इस बारे में कुछ कर सकते हैं?

आज, PIM को सरल बनाने के लिए दो विपरीत दृष्टिकोण हैं: SSM और BIDIR PIM।

एसएसएम

अब तक हमने जो भी वर्णन किया है वह सब ASM - कोई भी स्रोत मल्टीकास्ट है । इससे उन ग्राहकों को कोई फर्क नहीं पड़ता जो समूह के लिए यातायात के स्रोत हैं - मुख्य बात यह है कि वे इसे प्राप्त करते हैं। जैसा कि आपको याद है, IGMPv2 रिपोर्ट संदेश केवल समूह से कनेक्ट करने के लिए कहता है।
एसएसएम - स्रोत विशिष्ट मल्टीकास्ट - एक वैकल्पिक दृष्टिकोण। इस मामले में, क्लाइंट कनेक्ट करते समय समूह और स्रोत का संकेत देते हैं।
यह क्या देता है? न तो अधिक और न ही कम: आरपी से पूरी तरह से छुटकारा पाने की क्षमता। एलएचआर तुरंत स्रोत का पता जानता है - आरपी में शामिल होने के लिए भेजने की कोई आवश्यकता नहीं है, राउटर स्रोत की दिशा में तुरंत जॉइन (एस, जी) भेज सकता है और एसपीटी का निर्माण कर सकता है।
तो हम छूट जाते हैं

• आरपी (बूटस्ट्रैप और ऑटो-आरपी प्रोटोकॉल) खोजें,
• ( , )
• SPT.

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

इसके अलावा, सक्रिय मल्टीकास्ट रूटिंग के साथ एक नेटवर्क में एक संभावित हमला वेक्टर एक हमलावर है जो अपने स्रोत को जोड़ता है और बड़ी मात्रा में मल्टीकास्ट ट्रैफ़िक उत्पन्न करता है जो नेटवर्क को अधिभारित करेगा। एसएसएम में, यह व्यावहारिक रूप से असंभव है।

SSM के लिए IP पतों की एक विशेष श्रेणी आवंटित की गई है: 232.0.0.0/8।
राउटर पर, पीआईएम एसएसएम मोड एसएसएम का समर्थन करने में सक्षम है।

 Router(config)# ip pim ssm 

IGMPv3 और MLDv2 शुद्ध SSM का समर्थन करते हैं।
उनका उपयोग करते समय, ग्राहक हो सकता है

• स्रोतों को निर्दिष्ट किए बिना, केवल एक समूह से कनेक्शन का अनुरोध करें। यानी यह एक सामान्य ASM की तरह काम करता है।
• किसी विशिष्ट स्रोत वाले समूह से कनेक्शन का अनुरोध करें। आप कई स्रोतों को निर्दिष्ट कर सकते हैं - उनमें से प्रत्येक से पहले एक पेड़ बनाया जाएगा।
• समूह से कनेक्शन का अनुरोध करें और उन स्रोतों की सूची निर्दिष्ट करें जिनसे ग्राहक ट्रैफ़िक प्राप्त करना पसंद नहीं करेगा

IGMPv1 / v2, MLDv1 SSM का समर्थन नहीं करते हैं, लेकिन SSM मैपिंग जैसी कोई चीज है । क्लाइंट (LHR) के निकटतम राउटर पर, प्रत्येक समूह को एक स्रोत पता (या कई) सौंपा जाता है। इसलिए, यदि नेटवर्क पर ऐसे क्लाइंट हैं जो IGMPv3 / MLDv2 का समर्थन नहीं करते हैं, तो वे SPT भी बनाएंगे, RPT नहीं, क्योंकि स्रोत पता अभी भी ज्ञात है।
SSM मैपिंग को LHR पर स्थिर विन्यास और DNS सर्वर तक पहुँच के द्वारा कार्यान्वित किया जा सकता है।

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

---

BIDIR PIM

लेकिन क्या होगा अगर नेटवर्क पर स्रोत अनायास प्रकट हो सकते हैं और फिर, उसी समूहों में प्रसारित होते हैं, जल्दी से प्रसारण बंद कर देते हैं और गायब हो जाते हैं?
उदाहरण के लिए, यह स्थिति नेटवर्क गेम या डेटा सेंटर में संभव है, जहां विभिन्न सर्वरों के बीच डेटा को दोहराया जाता है। यह कई-से-कई अवधारणा है - कई स्रोत, कई ग्राहक।
एक नियमित पीआईएम एसएम इसे कैसे देखता है? यह स्पष्ट है कि निष्क्रिय पीआईएम एसएसएम यहां बिल्कुल उपयुक्त नहीं है?
जरा सोचो कि किस तरह की अराजकता शुरू हो जाएगी: स्रोतों का अंतहीन पंजीकरण, पेड़ों का पुनर्निर्माण, प्रोटोकॉल टाइमर के कारण कई मिनटों तक रहने वाले रिकॉर्ड (एस, जी) की एक बड़ी संख्या। द्विदिश PIM
( BIDIR PIM, BIDIR PIM) बचाव में आ रहा है)। एसएसएम के विपरीत, इसके विपरीत, यह एसपीटी और रिकॉर्ड (एस, जी) को पूरी तरह से खारिज कर देता है - आरपी में रूट के साथ केवल साझा पेड़ ही रहता है।
और अगर एक नियमित पीआईएम में, पेड़ एक तरफा है - ट्रैफिक हमेशा एसपीटी के नीचे स्रोत से और आरपीटी से आरपीटी से नीचे प्रेषित होता है - एक स्पष्ट विभाजन होता है, जहां स्रोत है जहां ग्राहक हैं, फिर स्रोत से आरपी तक द्विदिश ट्रैफिक में यह साझा पेड़ भी प्रेषित होता है - उसी कारण से ग्राहकों के लिए ट्रैफ़िक कम हो जाता है।

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

यहाँ एक उदाहरण है:



Istochnik1 समूह 224.2.2.4 के साथ एक साथ नेटवर्क यातायात का प्रसारण शुरू हुआ Istochnikom2 । उनमें से धाराएँ बस आरपी की ओर जाती हैं। कुछ क्लाइंट जो पास में हैं, उन्हें तुरंत ट्रैफ़िक मिलना शुरू हुआ, क्योंकि राउटर पर एक एंट्री (*, G) है (क्लाइंट्स हैं)। दूसरे भाग को RP से साझा ट्री ट्रैफ़िक प्राप्त होता है। इसके अलावा, वे दोनों स्रोतों से एक साथ यातायात प्राप्त करते हैं।
यही है, अगर हम उदाहरण के लिए एक सट्टा नेटवर्क गेम लेते हैं , तो Source1 शूटर में पहला खिलाड़ी है जिसने गोली मारी है, और Source2 दूसरा खिलाड़ी है जिसने पक्ष में कदम रखा। इन दो घटनाओं की जानकारी पूरे नेटवर्क में फैल गई। और हर दूसरे खिलाड़ी ( प्राप्तकर्ता) ) को इन दोनों घटनाओं के बारे में सीखना चाहिए।

, , RP — , , RP . ? : BIDIR PIM , , , , . RP .

ध्यान दें कि ऊपर की छवि में, R5 और R7 के बीच एक सीधी रेखा है, जो RP के माध्यम से पथ से बहुत छोटी है, लेकिन इसका उपयोग नहीं किया गया था, क्योंकि राउटिंग टेबल के अनुसार Join the RP की ओर जाएं, जिसमें यह पथ इष्टतम नहीं है।

यह बहुत आसान लग रहा है - आपको आरपी की दिशा में मल्टीकास्ट पैकेट भेजने की आवश्यकता है और यही है, लेकिन एक कैवेट है जो सब कुछ खराब कर देता है - आरपीएफ। RPT ट्री में, यह आवश्यक है कि ट्रैफिक RP से आए और अन्यथा नहीं। और यहां वह कहीं से भी आ सकता है। बेशक, हम RPF को नहीं ले सकते और मना नहीं कर सकते - यह एकमात्र तंत्र है जो लूप के गठन से बचा जाता है।

इसलिए, DF की अवधारणा को BIDIR PIM - नामित फारवर्डर में पेश किया गया है। प्रत्येक नेटवर्क सेगमेंट में, प्रत्येक पंक्ति पर, राउटर जिसका आरपी बेहतर है, इस भूमिका के लिए चुना जाता है।
इसमें शामिल हैं उन लाइनों पर जहां क्लाइंट सीधे जुड़े होते हैं। BIDIR PIM DF स्वतः DR है।



ओआईएल सूची केवल उन इंटरफेस से बनाई गई है, जिस पर राउटर को डीएफ भूमिका के लिए चुना गया था।

नियम बहुत पारदर्शी हैं:

• यदि इस खंड में DF के इंटरफ़ेस में PIM जॉइन / लीव रिक्वेस्ट आती है, तो इसे मानक नियमों के अनुसार RP पक्ष को भेजा जाता है।
  यहाँ, उदाहरण के लिए, R3 है। यदि अनुरोध डीएफ इंटरफेस में आए, जो एक लाल सर्कल के साथ चिह्नित हैं, तो यह उन्हें आरपी (आर 1 या आर 2 के माध्यम से, रूटिंग टेबल के आधार पर) भेजता है।
• PIM Join/Leave DF , .
  , , R1 R3, IGMP Report. R1 , DF ( ), . R3 , DF. R3 , , .
• DF , OIL RP.
  , 1 . R4 DF DF- — RP, — , RP . R3 — OIL — R5, - RPF, — RP.
• DF , OIL, RP.
  , 2 , RP RPT. R3 R1, R2 — R4 R5.

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

वैसे, अब Assert संदेशों की कोई आवश्यकता नहीं है, क्योंकि प्रत्येक खंड में DF का चयन किया जाता है। DR के विपरीत, वह केवल RP को Join भेजने के लिए ही नहीं, बल्कि सेगमेंट में ट्रैफ़िक भेजने के लिए भी ज़िम्मेदार है, यानी वह स्थिति जब दो राउटर एक ही सबनेट पर ट्रैफ़िक भेजते हैं, BIDIR PIM में शामिल नहीं है।

शायद द्विदिश पीआईएम के बारे में आखिरी बात यह है कि आरपी कैसे काम करता है। यदि पीआईएम एसएम आरपी ने स्रोत का एक बहुत ही विशिष्ट कार्य - पंजीकरण किया है, तो बीआईडीआईआर में पीआईएम आरपी एक बहुत ही सशर्त बिंदु है, जिस पर एक तरफ ट्रैफ़िक और दूसरी तरफ क्लाइंट से जुड़ना चाहता है। कोई भी विघटित नहीं होना चाहिए, एसपीटी पेड़ के निर्माण का अनुरोध करें। यह सिर्फ इतना है कि कुछ राउटर पर, स्रोतों से अचानक ट्रैफ़िक को साझा ट्री पर प्रेषित किया जाना शुरू हो जाता है। मैं "कुछ पर" क्यों कह रहा हूं? तथ्य यह है कि बीआईडीआईआर पीआईएम आरपी में एक अमूर्त बिंदु है, न कि एक विशिष्ट राउटर, सामान्य रूप से, एक गैर-मौजूद आईपी पता एक आरपी पते के रूप में कार्य कर सकता है - मुख्य बात यह है कि यह नियमित हो सकता है (ऐसे आरपी को प्रेत आरपी कहा जाता है )।

PIM से संबंधित सभी शब्द शब्दावली में पाए जा सकते हैं ।

---

चैनल स्तर पर मल्टीकास्ट

तो, नींद, प्रसंस्करण, परीक्षण की कमी के साथ एक लंबे कार्य सप्ताह के बाद - आपने सफलतापूर्वक मल्टीकास्ट और संतुष्ट ग्राहकों, निदेशकों और बिक्री विभाग को लागू किया है।
सृजन का सर्वेक्षण करने और अपने आप को एक सुखद विश्राम की अनुमति देने के लिए शुक्रवार बुरा दिन नहीं है।
लेकिन आपकी दोपहर की झपकी ने अचानक टेक सपोर्ट कॉल को परेशान कर दिया, फिर एक और एक और - कुछ भी नहीं काम करता है, सब कुछ टूट गया। जांच - नुकसान हैं, ब्रेक। सब कुछ एक स्विच के कई खंडों में परिवर्तित हो जाता है।

हमने SSH को उजागर किया, सीपीयू की जांच की, इंटरफेस के उपयोग और अंत में बालों की जांच की - एक ही वीएलएएन के सभी इंटरफेस पर लगभग 100% लोड हो रहा है। लूप! लेकिन अगर कोई काम नहीं हुआ तो वह कहां से आती है? परीक्षण के 10 मिनट और आपने देखा कि अपस्ट्रीम इंटरफ़ेस पर कर्नेल के लिए आपके पास बहुत अधिक आवक ट्रैफ़िक है, और क्लाइंट के सभी डाउनस्ट्रीम पर - आउटगोइंग। यह लूप की विशेषता भी है, लेकिन किसी तरह संदिग्ध: उन्होंने एक मल्टीकास्ट पेश किया, किसी भी स्विचिंग का काम नहीं किया, और छलांग केवल एक दिशा में थी।
हमने राउटर पर मल्टीकास्ट समूहों की सूची की जांच की - और सभी संभावित चैनलों और सभी एक पोर्ट के लिए एक सदस्यता है - स्वाभाविक रूप से, वह जो इस सेगमेंट में जाता है।
गहन जांच से पता चला कि ग्राहक का कंप्यूटर संक्रमित है और एक पंक्ति में सभी मल्टीकास्ट पते पर IGMP क्वेरी भेजता है।

पैकेट हानि शुरू हुई क्योंकि स्विच को भारी मात्रा में यातायात से गुजरना पड़ा। इससे इंटरफ़ेस बफ़र्स का अतिप्रवाह हुआ।

मुख्य सवाल यह है कि एक ग्राहक के ट्रैफ़िक को सभी बंदरगाहों पर कॉपी क्यों किया जाने लगा?

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

मल्टीकास्ट मैक पते

तो ऐसे पैकेट के ईथरनेट हैडर में प्राप्तकर्ता मैक पते क्या हैं? प्रसारण? नहीं।मैक पते की एक विशेष श्रृंखला है जो मल्टीकास्ट आईपी पते प्रदर्शित करती है।
ये विशेष पते इस तरह से शुरू होते हैं: 0x01005e और अगला 25 वां बिट 0 होना चाहिए ( इसका उत्तर देने की कोशिश करें कि ऐसा क्यों है )। शेष 23 बिट्स (याद करें, मैक पते 48 में सभी) आईपी पते से स्थानांतरित किए जाते हैं।

यहाँ कुछ गंभीर नहीं है, लेकिन एक समस्या है। मल्टीकास्ट पतों की सीमा 224.0.0.0/4 मुखौटा द्वारा निर्धारित की जाती है, जिसका अर्थ है कि पहले 4 बिट आरक्षित हैं: 1110, और शेष 28 बिट्स बदल सकते हैं। यही है, हमारे पास 2 ^ 28 मल्टीकास्ट आईपी पते हैं और केवल 2 ^ 23 मैक पते - 5 बिट्स 1 में 1 प्रदर्शित करने के लिए पर्याप्त नहीं हैं। इसलिए, आईपी पते के अंतिम 23 बिट्स को लिया जाता है और एक को मैक पते पर स्थानांतरित किया जाता है, शेष 5 को छोड़ दिया जाता है।



वास्तव में, इसका अर्थ है कि 2 ^ 5 = 32 आईपी पते एक मल्टीकास्ट मैक पते में प्रदर्शित किए जाएंगे। उदाहरण के लिए, समूह 224.0.0.1, 224.128.0.1, 225.0.0.1 और इतने पर 239.128.0.1 तक सभी को एक मैक पते 0100: 5e00: 0001 पर मैप किया जाएगा।

यदि हम एक स्ट्रीमिंग वीडियो डंप का उदाहरण लेते हैं, तो आप देख सकते हैं:



आईपी ​​पता - 224.2.2.4, मैक पता: 01: 00: 5E: 02: 02: 04।

अन्य मल्टीकास्ट मैक पते भी हैं जिनका आईपीवी 4 मल्टीकास्ट ( क्लिक ) से कोई लेना-देना नहीं है । वैसे, उन सभी को इस तथ्य की विशेषता है कि पहले ऑक्टेट का अंतिम बिट 1 है।

स्वाभाविक रूप से, ऐसे मैक पते को किसी भी नेटवर्क कार्ड पर कॉन्फ़िगर नहीं किया जा सकता है, इसलिए यह एक ईथरनेट फ्रेम के स्रोत मैक क्षेत्र में कभी नहीं होगा और कभी नहीं मिलेगा। मैक एड्रेस टेबल तो ऐसे फ्रेम को किसी भी तरह बाहर भेजा जाना चाहिएसभी वीएलएएन बंदरगाहों के लिए अज्ञात यूनिकास्ट ।

जो कुछ हमने पहले माना था, वह किसी भी मल्टीकास्ट ट्रैफ़िक को वीडियो स्ट्रीमिंग से लेकर स्टॉक कोट्स तक पूरा ट्रांसफर करने के लिए काफी है। लेकिन क्या हम वास्तव में अपनी लगभग संपूर्ण दुनिया में इस तरह के आक्रोश के साथ प्रसारण करने जा रहे हैं, जो चुनाव में पारित हो सकता है?
बिलकुल नहीं। विशेष रूप से पूर्णतावादियों के लिए, IGMP-Snooping तंत्र का आविष्कार किया गया था ।

---

IGMP-स्नूपिंग

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

यदि किसी समूह के लिए IGMP रिपोर्ट पोर्ट से आई है, तो इसका मतलब है कि कोई क्लाइंट है, स्विच इसे इस समूह के डाउनस्ट्रीम की सूची में जोड़ता है।
यदि एक समूह के लिए IGMP क्वेरी पोर्ट से आया है, तो एक राउटर है, स्विच इसे अपस्ट्रीम की सूची में जोड़ता है।

इस प्रकार, चैनल स्तर पर मल्टीकास्ट ट्रैफिक की एक ट्रांसमिशन टेबल बन जाती है।
नतीजतन, जब एक मल्टीकास्ट स्ट्रीम ऊपर से आती है, तो इसे केवल डाउनस्ट्रीम इंटरफेस में कॉपी किया जाता है। यदि 16-पोर्ट स्विच पर केवल दो क्लाइंट हैं, तो केवल वे ट्रैफ़िक प्राप्त करेंगे।



इस विचार की प्रतिभा तब समाप्त होती है जब हम इसकी प्रकृति के बारे में सोचते हैं। तंत्र मानता है कि स्विच को तीसरे स्तर पर यातायात के लिए सुनना चाहिए।

हालाँकि, नेटवर्क सहभागिता के सिद्धांतों की अनदेखी करने की अपनी डिग्री में NAT के साथ IGMP-Snooping की तुलना नहीं की जा सकती है। इसके अलावा, संसाधनों में बचत के अलावा, यह बहुत कम स्पष्ट विशेषताएं प्रदान करता है। और सामान्य तौर पर, आधुनिक दुनिया में, एक स्विच जो आईपी के अंदर देख सकता है वह एक असाधारण घटना नहीं है।

=====================
टास्क नंबर 3

.



172.16.0.5 239.1.1.1, 239.2.2.2 239.0.0.x.
, :
— 1 239.2.2.2. 239.0.0.x.
— 2 239.1.1.1. 239.0.0.x.

कार्य का विवरण यहां दिया गया है ।
=====================

---

IGMP Snooping Proxy

एक जिज्ञासु पाठक पूछ सकता है कि IGMP स्नूपिंग सभी क्लाइंट पोर्ट को कैसे पहचानता है, यह देखते हुए कि केवल सबसे तेज क्लाइंट में से एक IGMP क्वेरी का जवाब देता है, जैसा कि हमने ऊपर कहा था। और बहुत सरल: IGMP- स्नूपिंग रिपोर्ट संदेशों को ग्राहकों के बीच पारित करने की अनुमति नहीं देता है। वे केवल अपस्ट्रीम पोर्ट्स से रूटर्स तक भेजे जाते हैं। इस समूह के अन्य प्राप्तकर्ताओं की रिपोर्ट देखे बिना, ग्राहक को इस क्वेरी में निर्दिष्ट मैक्स रिस्पांस टाइम के भीतर क्वेरी का जवाब देना होगा।
नतीजतन, 1000 सेकंड के भीतर प्रति आईजीएमपी क्वेरी में 1000 नोड्स के नेटवर्क में, 1000 रिपोर्ट्स सामान्य मैक्सिमन रिस्पॉन्स टाइम के भीतर राउटर में आएंगे। यद्यपि यह उसके लिए और प्रत्येक समूह के लिए पर्याप्त होगा।
और यह हर मिनट होता है।

इस स्थिति में, आप IGMP अनुरोधों की प्रॉक्सी कॉन्फ़िगर कर सकते हैं। फिर स्विच पासिंग पैकेट के लिए "सुनो" नहीं है, यह उन्हें स्वीकार करता है।

IGMP- स्नूपिंग नीतियां निर्माता द्वारा भिन्न हो सकती हैं। इसलिए, हम उन्हें वैचारिक रूप से मानते हैं:

1) यदि समूह पर पहले रिपोर्ट का अनुरोध स्विच पर आता है, तो इसे राउटर तक भेजा जाता है, और इंटरफ़ेस को टॉप-डाउन सूची में सूचीबद्ध किया जाता है। यदि ऐसा समूह पहले से मौजूद है, तो इंटरफ़ेस को केवल अवरोही सूची में जोड़ा जाता है, और रिपोर्ट नष्ट हो जाती है।
2) यदि नवीनतम अवकाश स्विच पर आता है, अर्थात्, कोई अन्य क्लाइंट नहीं हैं, तो यह अवकाश राउटर को भेजा जाएगा, और इंटरफ़ेस को डाउनस्ट्रीम वालों की सूची से हटा दिया जाएगा। अन्यथा, इंटरफ़ेस बस हटा दिया जाता है, छुट्टी नष्ट हो जाती है।
3) यदि आईजीएमपी क्वेरी राउटर से आती है, तो स्विच इसे स्वीकार करता है, वर्तमान में प्राप्तकर्ता प्राप्त करने वाले सभी समूहों के जवाब में एक आईजीएमपी रिपोर्ट भेजता है।
और फिर, सेटिंग्स और निर्माता के आधार पर, या तो एक ही क्वेरी सभी क्लाइंट पोर्ट पर भेजी जाती है, या स्विच राउटर से अनुरोध को अवरुद्ध करता है और खुद एक क्वेरी के रूप में कार्य करता है, समय-समय पर सभी प्राप्तकर्ताओं को मतदान करता है।

इस प्रकार, नेटवर्क में अनावश्यक ओवरहेड ट्रैफ़िक का हिस्सा और राउटर पर लोड कम हो जाता है।

मल्टीकास्ट वीएलएएन प्रतिकृति

MVR के लिए लघु । यह उन प्रदाताओं के लिए एक तंत्र है जो उदाहरण के लिए VLAN-per-user का अभ्यास करते हैं ।
यहां एक नेटवर्क का एक विशिष्ट उदाहरण है जहां MVR महत्वपूर्ण है:



विभिन्न VLAN में 5 क्लाइंट, और हर कोई एक समूह 224.2.2.4 से मल्टीकास्ट ट्रैफ़िक प्राप्त करना चाहता है। इसी समय, ग्राहकों को एक दूसरे से अलग रहना चाहिए।

IGMP-Snooping, निश्चित रूप से, VLANs को ध्यान में रखता है। यदि विभिन्न वीएलएएन में पांच ग्राहक एक समूह का अनुरोध करते हैं, तो यह पांच अलग-अलग टेबल होंगे। तदनुसार, समूह से कनेक्ट करने के लिए 5 अनुरोध राउटर पर जाते हैं। और राउटर पर पांच उपप्रकारों में से प्रत्येक को अलग से ओआईएल में जोड़ा जाएगा। यही है, समूह 224.2.2.4 के लिए 1 स्ट्रीम प्राप्त करने के बाद, यह 5 प्रतियां भेजेगा, इस तथ्य के बावजूद कि वे सभी एक सेगमेंट में जाते हैं।



इस समस्या को हल करने के लिए, एक तंत्र मल्टीकास्ट वीएलएएन प्रतिकृति विकसित किया गया था।
एक अतिरिक्त वीएलएएन पेश किया गया है - मल्टीकास्ट वीएलएएन - इसमें, तदनुसार, एक मल्टीकास्ट स्ट्रीम प्रेषित किया जाएगा। यह सीधे अंतिम स्विच पर "अग्रेषित" किया जाता है, जहां से ट्रैफ़िक को उन सभी क्लाइंट इंटरफ़ेसों में कॉपी किया जाता है जो इस ट्रैफ़िक को प्राप्त करना चाहते हैं - यह प्रतिकृति है।
कार्यान्वयन के आधार पर, मल्टीकास्ट वीएलएएन से प्रतिकृति उपयोगकर्ता-वीएलएएन या कुछ भौतिक इंटरफेस में किया जा सकता है ।


IGMP संदेशों के बारे में क्या? राउटर से क्वेरी, निश्चित रूप से, मल्टीकास्ट वीएलएएन के माध्यम से आती है। स्विच उन्हें क्लाइंट पोर्ट पर भेजता है। जब रिपोर्ट या छुट्टी क्लाइंट से आती है, तो स्विच चेक करता है कि यह कहाँ से आता है (VLAN, इंटरफ़ेस) और, यदि आवश्यक हो, तो इसे मल्टीकास्ट VLAN में रीडायरेक्ट करता है।
इस प्रकार, सामान्य ट्रैफ़िक को अलग किया जाता है और फिर भी उपयोगकर्ता वीएलएएन में राउटर पर जाता है। और मल्टीकास्ट ट्रैफ़िक और IGMP पैकेट मल्टीकास्ट VLAN में प्रेषित होते हैं।

सिस्को उपकरण पर, एमवीआर और आईजीएमपी-स्नूपिंग स्वतंत्र रूप से कॉन्फ़िगर किए गए हैं। यही है, आप एक को अक्षम कर सकते हैं और दूसरा काम करेगा। सामान्य तौर पर, MVR IGMP-Snooping पर आधारित है, और MVR स्विच पर काम करने के लिए MVR के लिए IGMP-Snooping अनिवार्य हो सकता है।

इसके अलावा, IGMP- स्नूपिंग स्विच पर ट्रैफ़िक को फ़िल्टर करने की अनुमति देता है, उपयोगकर्ता के लिए उपलब्ध समूहों की संख्या को सीमित करता है, IGMP Querier को सक्षम करता है, अपस्ट्रीम पोर्ट्स का स्थिर कॉन्फ़िगरेशन, एक समूह के लिए स्थायी कनेक्शन (यह परिदृश्य साथ वीडियो में है , और टोपोलॉजी बदलने के लिए एक त्वरित प्रतिक्रिया है) अतिरिक्त क्वेरी भेजकर, IGMv2 के लिए एसएसएम-मैपिंग, आदि।

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

---

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

ये दोनों विधियां केवल कंप्यूटर पर स्ट्रीमिंग वीडियो देखना संभव बनाती हैं।

तीसरा विकल्प आपको टीवी का उपयोग करने की अनुमति देता है, और एक नियम के रूप में, कोई भी। ऐसा करने के लिए, तथाकथित सेट-टॉप-बॉक्स (एसटीबी) ग्राहक के घर में रखा जाता है - टीवी पर स्थापित एक बॉक्स। यह एक स्लॉट है, जो सब्सक्राइबर लाइन में शामिल है और ट्रैफ़िक को साझा करता है: यह सामान्य यूनिकस्ट को ईथरनेट या वाईफाई पर भेजता है ताकि ग्राहकों तक इंटरनेट की पहुंच हो, और मल्टीकास्ट स्ट्रीम केबल (डीवीआई, आरजीबी, एंटीना, आदि) के माध्यम से टीवी पर प्रसारित हो।
अक्सर, आप एक विज्ञापन देख सकते हैं जहां प्रदाता टेलीविजन को जोड़ने के लिए अपने सेट-टॉप बॉक्स प्रदान करता है - ये बहुत ही एसटीबी हैं

=====================
№ 4

( , ).

:



-, — , .

.

, :
1. , ?
2. , , , ?

, .

कार्य का विवरण यहां दिया गया है ।
=====================

---

मल्टीकास्ट ट्रैफ़िक ( MSDP , MBGP , BGMP ) का क्रॉस-डोमेन रूटिंग , RP ( Anycast RP ), PGM और मालिकाना प्रोटोकॉल के बीच लोड संतुलन अप्रभावित रहा । लेकिन, मुझे लगता है, इस लेख को एक शुरुआती बिंदु के रूप में रखते हुए, बाकी का पता लगाना मुश्किल नहीं होगा।
सभी मल्टीकास्ट शब्द लुकमेअप दूरसंचार शब्दावली में पाए जा सकते हैं ।

लेख तैयार करने में मदद के लिए धन्यवाद, JDima के
लिए धन्यवाद ... तकनीकी सहायता के लिए धन्यवाद , नताशा समोइलेन्को ।
केडीपीवी नीना डोलगोपोलोवा द्वारा बनाया गया है , जो एक अद्भुत कलाकार और परियोजना का मित्र है।

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

जैसा कि आप शायद पहले ही देख चुके हैं, लिंकमेप में एक नया प्रोजेक्ट है - लुकअप ग्लोरीरी (हाँ, यह हमारी कल्पना से बहुत दूर नहीं है)। हमें उम्मीद है कि यह शब्दावली संचार के क्षेत्र में शर्तों का सबसे व्यापक संदर्भ होगा, इसलिए हमें इसे भरने में किसी भी तरह की मदद करने में खुशी होगी। Info@linkmeup.ru पर हमें लिखें । हमारे

साथ बने रहें ।