राउटर में igmp क्या है। राउटर के लिए iptv का चरण-दर-चरण कॉन्फ़िगरेशन


प्रदाता से आईपीटीवी सेवा

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

पारंपरिक स्थलीय टीवी पर आईपीटीवी के लाभ

  • आपके पीसी पर टीवी ट्यूनर स्थापित करने की कोई आवश्यकता नहीं है।
  • एक विशिष्ट समय के लिए किसी चैनल के प्लेबैक को रोकने की क्षमता।
  • आईपीटीवी वीडियो ऑन डिमांड (वीओडी) जैसी अतिरिक्त सेवाएं प्रदान कर सकता है।

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

आईपीटीवी प्लेबैक के लिए सॉफ्टवेयर प्लेयर:वीएलसी, आईपीटीवी प्लेयर, पीसी प्लेयर, आदि।

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

ध्यान! IPTV सपोर्ट वाले राउटर की सूचीआप अपने प्रदाता को कॉल करके या आधिकारिक वेबसाइट देखकर पता लगा सकते हैं। या इसका इस्तेमाल करें।

आईपीटीवी के लिए राउटर: 54 एमबीपीएस वायरलेस राउटर (जी सीरीज), 150 एमबीपीएस वायरलेस राउटर (एन सीरीज), 300 एमबीपीएस वायरलेस राउटर (एन सीरीज) और बाद में।

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

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

यूडीपी-टू-एचटीटीपी प्रॉक्सीकनवर्ट करने के लिए डिज़ाइन किया गया यूडीपी मल्टीकास्टटीसीपी-यूनिकास्ट (विशेष रूप से http) यातायात के लिए आईपीटीवी यातायात। यह आराम से देखने के लिए उपयोगी है। वाई-फाई पर आईपीटीवी, NAT, PDA, उपभोक्ता खिलाड़ी और गेम कंसोल पर।

राउटर के माध्यम से आईपीटीवी

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

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

ध्यान! सक्रिय मल्टीकास्टराउटर के कुछ मॉडलों में, यह अक्सर स्थानीय नेटवर्क, विशेष रूप से वाई-फाई को "क्लॉज" करता है।

सेट-टॉप बॉक्स के माध्यम से आईपीटीवी

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

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

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

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

आईपीटीवी कैसे सेट करें

उदाहरण के लिए, आईपीटीवी सेटअपडी-लिंक डीआईआर-300 राउटर और इसी तरह के मॉडल पर, यह "मल्टीकास्ट स्ट्रीम सक्षम करें" आइटम में केवल एक चेकबॉक्स सेट करने के लिए नीचे आता है:

मेरे लिए व्यक्तिगत रूप से, आईपी ​​टेलीविजन स्थापित करनाएक वायर्ड कनेक्शन पर, यह कई चरणों में उबलता है (उदाहरण के लिए, Asus 520GU राउटर):

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

ASUS राउटर पर IPTV सेट करना

अब मैं वर्णन करूंगा RT-G32 B राउटर के माध्यम से IPTV को कॉन्फ़िगर करने के 2 तरीके

ध्यान! IPTV की स्थापना के लिए वर्णित निर्देश स्पष्टता के लिए Asus राउटर के अन्य मॉडलों पर उपयोग किए जा सकते हैं, न कि केवल व्यावहारिक और सैद्धांतिक अनुप्रयोग में Asus।

1 रास्ता... अनुभाग पर जाएँ लैन -> रूटऔर "मल्टीकास्ट रूटिंग सक्षम करें" - "हां" बॉक्स को चेक करें। सहेजें - "लागू करें"।

इस मामले में, वीएलसी प्लेयर के लिए मल्टीकास्ट स्ट्रीम बिना किसी बदलाव के स्थानीय नेटवर्क पर प्रसारित की जाएगी।

इस विधि के फायदे:
1. आपको वीएलसी प्लेयर के लिए कोई अतिरिक्त सेटिंग करने की आवश्यकता नहीं है।

नुकसान:
1. केवल एक मुड़ जोड़ी (ईथरनेट केबल) के माध्यम से आईपीटीवी देखने के लिए कंप्यूटर को जोड़ने की क्षमता।
2. आईपीटीवी प्लेबैक के समय, स्थानीय नेटवर्क में अन्य कंप्यूटरों पर इंटरनेट कनेक्शन की गति में गिरावट।
3. राउटर पर भारी भार।
4. नेटवर्क के भीतर अत्यधिक मल्टीकास्ट ट्रैफिक।

2 रास्ते... "आईपीटीवी यूडीपी मल्टीकास्ट से HTTP प्रॉक्सी" फ़ंक्शन को कॉन्फ़िगर करना आवश्यक है। अनुभाग पर जाएँ लैन -> मार्गऔर "मल्टीकास्ट रूटिंग सक्षम करें" - "हां", और "आईपीटीवी यूडीपी" में एक चेकमार्क लगाएं
HTTP प्रॉक्सी के लिए मल्टीकास्ट ”एक मनमाना पोर्ट चुनें। उदाहरण के लिए, 2323. परिवर्तन सहेजें - "लागू करें"।

इस विधि के फायदे:

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

नुकसान:

  1. आप जिस मीडिया प्लेयर का उपयोग कर रहे हैं, उसके लिए आपको प्लेलिस्ट बदलनी होगी।

"आईपीटीवी यूडीपी मल्टीकास्ट टू एचटीटीपी प्रॉक्सी" फ़ंक्शन का उपयोग करते समय वीएलसी प्लेलिस्ट में किए जाने वाले संपादन:

टेक्स्ट एडिटर में प्लेलिस्ट खोलें।
इस तरह की लाइनें खोजें - यूडीपी: // @ 239.23.0.200:1234/ और उस भाग को हटा दें जिसे मैंने बोल्ड में हाइलाइट किया है। सब कुछ बदलने की जरूरत है।
हटाए गए भाग के स्थान पर यूडीपी: // @ सम्मिलित करें - http://192.168.1.1:2323/udp/, कहां 192.168.1.1 - आपके वाई-फाई राउटर का आईपी पता, और 2323 - आपके द्वारा चुना गया प्रॉक्सी पोर्ट।
परिणाम रेखा होगी - http://192.168.1.1:2323/udp/239.23.0.200:1234/

आईपीटीवी कनेक्ट करते समय क्या देखना है :

IPTV सेट-टॉप बॉक्स का उपयोग करना:

विकल्प सक्रियण चुननाज़र्दपुलबंदरगाहतथा एक या अधिक का चयन IPTV सेट-टॉप बॉक्स को जोड़ने के लिए राउटर के LAN पोर्ट।

आईपीटीवी पीसी देखने के लिए उपयोग करें (वायर्ड और वायरलेस कनेक्शन)

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

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

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

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

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

एक अनुस्मारक के रूप में, IGMP IPv6 के लिए काम नहीं करता है। वहां एमएलडी प्रोटोकॉल मौजूद है।

चलो फिर दोहराते हैं

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


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

एक बार फिर

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

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

पीआईएम

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

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

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

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

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

पीआईएम सघन मोड

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

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

यह लूपलेस है और गंतव्य से स्रोत तक सबसे छोटा रास्ता अपनाता है। वास्तव में, यह एसटीपी में फैले हुए वृक्ष के समान है, जहां जड़ स्रोत है।

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

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

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

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

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

R2 वही करता है, यानी यह R3 की ओर ट्रैफिक भेजता है। R3 यह निर्धारित नहीं कर सकता कि यह वही ट्रैफ़िक है जो इसे R1 से पहले ही प्राप्त हो चुका है, इसलिए यह इसे अपने सभी इंटरफेस पर अग्रेषित करता है। R1 को R3 से ट्रैफ़िक की एक प्रति प्राप्त होगी, और इसी तरह। यहाँ यह है - लूप।

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

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

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

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

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

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

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

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


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

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

R1 (कॉन्फ़िगरेशन) #ip मल्टीकास्ट-रूटिंग R1 (कॉन्फ़िगरेशन) #int fa0 / 0 R1 (कॉन्फ़िगर-अगर) #ip pim sparse-mode R1 (config-if) #int fa1 / 0 R1 (config-if) #ip pim विरल मोड

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

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


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

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

आइए इस संक्षिप्त निष्कर्ष पर एक नजर डालते हैं।

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

रिकॉर्डिंग (172.16.0.5, 225.0.1.1) बुलाया, / पढ़ा एस्कोमाडज़ी/ और इंगित करता है कि स्रोत ज्ञात है। हमारे मामले में, 172.16.0.5 पते वाला स्रोत 224.2.2.4 समूह के लिए ट्रैफ़िक प्रसारित करता है। मल्टीकास्ट ट्रैफ़िक FE0 / 1 इंटरफ़ेस पर आता है - यह है आरोही (नदी के ऊपर) इंटरफेस।

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

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

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

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

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

यह समझने के लिए कि पीआईएम क्या है, आइए अधिक जटिल नेटवर्क की ओर मुड़ें।


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

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

तो, समय का क्षण 0 है।

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

RX (कॉन्फ़िगरेशन) #ip मल्टीकास्ट-रूटिंग
पीआईएम सभी राउटर के सभी इंटरफेस पर सीधे सक्षम होता है (सोर्स सर्वर और क्लाइंट की ओर इंटरफेस सहित):

RX (कॉन्फ़िगरेशन) #int FEX / X RX (config-if) #ip pim sparse-mode

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

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

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

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

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

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

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

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

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

अभी के लिए R2 को RP की भूमिका निभाने दें।
विश्वसनीयता बढ़ाने के लिए, आमतौर पर लूपबैक इंटरफ़ेस का पता चुना जाता है। इसीलिए सभी के लिएराउटर कमांड चलाते हैं:
RX (कॉन्फ़िगरेशन) #ip pim आरपी-एड्रेस 2.2.2.2
स्वाभाविक रूप से, यह पता सभी बिंदुओं से रूटिंग तालिका में उपलब्ध होना चाहिए।
ठीक है, चूंकि पता 2.2.2.2 इंटरफ़ेस पर RP है लूपबैक 0 R2 पर भी PIM को सक्रिय करना वांछनीय है।

R2 (कॉन्फ़िगरेशन) #इंटरफ़ेस लूपबैक 0 RX (कॉन्फ़िगर-अगर) #ip pim sparse-mode

उसके तुरंत बाद, R4 को समूह 224.2.2.4 के ट्रैफ़िक स्रोत के बारे में पता चलता है:

और यहां तक ​​​​कि यातायात भी प्रसारित करता है:

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

हमने जो कुछ किया:
मल्टीकास्ट ट्रैफ़िक को रूट करने की क्षमता सक्षम ( आईपी ​​मल्टीकास्ट-रूटिंग)
इंटरफेस पर सक्रिय पीआईएम ( आईपी ​​पिम विरल मोड)
आरपी पता निर्दिष्ट ( आईपी ​​पिम आरपी-एड्रेस X.X.X.X )

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

डीब्रीफिंग

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

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

1) क्लाइंट 1 समूह 224.2.2.4 के लिए IGMP रिपोर्ट भेजता है

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

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

R4 को कहा जाता है - LHR (लास्ट हॉप राउटर) - मल्टीकास्ट ट्रैफ़िक के पथ में अंतिम राउटर, यदि आप स्रोत से गिनते हैं। दूसरे शब्दों में, यह प्राप्तकर्ता के निकटतम राउटर है। के लिये ग्राहक1 R4 है, के लिए ग्राहक 2 R5 है।

3) चूंकि अभी तक R4 पर कोई मल्टीकास्ट स्ट्रीम नहीं है (इसने पहले इसका अनुरोध नहीं किया है), यह एक पीआईएम जॉइन संदेश उत्पन्न करता है और इसे आरपी (2.2.2.2) की ओर भेजता है।

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

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

इस तरह से RP को पता चलता है कि ग्राहक कहाँ हैं।

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

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

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

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

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

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

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

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

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

यह ट्रैफ़िक क्लाइंट 1 और 2 को डिलीवर करने की आवश्यकता है:
क्लाइंट 1 मल्टीकास्ट ट्रैफिक के रूप में समूह पता 239.9.9.9 के साथ।
और क्लाइंट सेगमेंट 2 में, 255.255.255.255.255.255.255.255 के पते पर प्रसारण पैकेट के रूप में।

टोपोलॉजी नोट: इस कार्य में, हमारे नेटवर्क व्यवस्थापकों द्वारा केवल राउटर 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 का यातायात बिना किसी समस्या के प्रसारित किया जाना चाहिए।

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

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

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

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

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

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

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

आरपी चयन

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

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

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

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

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

तो, मान लीजिए कि हमारे नेटवर्क में हम चाहते हैं कि R3 R2 की विफलता के मामले में RP फ़ंक्शन को उठाए।
R2 और R3 को RP उम्मीदवारों के रूप में पहचाना जाता है - यही उन्हें कहा जाता है सी-आरपी... इन राउटर पर हम कॉन्फ़िगर करते हैं:
RX (कॉन्फ़िगरेशन) इंटरफ़ेस लूपबैक 0 RX (कॉन्फ़िगर-अगर) आईपी पिम विरल-मोड RX (कॉन्फ़िगर-अगर) बाहर निकलें RX (कॉन्फ़िगरेशन) #ip pim आरपी-उम्मीदवार लूपबैक 0

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

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

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

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

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

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

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

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

पीआईएम एसएम के अध्याय को समाप्त करने के लिए, आइए एक बार फिर सबसे महत्वपूर्ण बिंदुओं पर प्रकाश डालें

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

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

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

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

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

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

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

आज, पीआईएम को सरल बनाने के लिए दो पूरी तरह से विरोधी दृष्टिकोण हैं: एसएसएम और बीआईडीआईआर पीआईएम।

एसएसएम

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

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

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

राउटर (कॉन्फ़िगरेशन) # आईपी पिम एसएसएम

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

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

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

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


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

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

उदाहरण के लिए:

स्रोत1समूह 224.2.2.4 से एक साथ नेटवर्क पर यातायात संचारित करना शुरू किया स्रोत 2... उनमें से धाराएँ सिर्फ आरपी की ओर प्रवाहित हुईं। कुछ क्लाइंट जो आस-पास हैं, उन्हें तुरंत ट्रैफ़िक मिलना शुरू हो गया, क्योंकि राउटर में एक प्रविष्टि (*, G) है (क्लाइंट हैं)। दूसरा हिस्सा RP से Shared Tree पर ट्रैफिक प्राप्त करता है। इसके अलावा, वे एक ही समय में दोनों स्रोतों से ट्रैफ़िक प्राप्त करते हैं।
यही है, अगर हम, उदाहरण के लिए, एक सट्टा नेटवर्क गेम लेते हैं, स्रोत1शॉट लेने वाले पहले शूटर खिलाड़ी हैं और स्रोत 2- यह एक और खिलाड़ी है जिसने एक कदम आगे बढ़ाया। इन दोनों घटनाओं की जानकारी पूरे नेटवर्क में फैल गई। तथा प्रत्येकएक अन्य खिलाड़ी ( प्राप्तकर्ता) इन दोनों घटनाओं के बारे में पता होना चाहिए।

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

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

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

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

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

नियम काफी पारदर्शी हैं:

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

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

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

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

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

लिंक परत मल्टीकास्ट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IGMP स्नूपिंग

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

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

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

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

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

सर्वर 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 समूह में शामिल हो सका।

अंत में, एक गैर-तुच्छ मल्टीकास्ट समस्या (लेखक हम नहीं हैं, उत्तर में मूल के लिए एक लिंक होगा)।

सबसे सरल योजना:

एक ओर, स्रोत सर्वर, चाप के साथ, एक कंप्यूटर है जो यातायात प्राप्त करने के लिए तैयार है।

आप मल्टीकास्ट स्ट्रीम का पता स्वयं सेट कर सकते हैं।

और तदनुसार, दो प्रश्न:
1. मल्टीकास्ट रूटिंग का सहारा लिए बिना कंप्यूटर को स्ट्रीम प्राप्त करने के लिए क्या करने की आवश्यकता है?
2. मान लीजिए कि आप बिल्कुल नहीं जानते हैं कि मल्टीकास्ट क्या है और इसे कॉन्फ़िगर नहीं कर सकते हैं, सर्वर से कंप्यूटर पर स्ट्रीम कैसे संचारित करें?

खोज इंजन में समस्या आसानी से खोजी जाती है, लेकिन इसे स्वयं हल करने का प्रयास करें।

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

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

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

टैग:

  • छोटों के लिए नेटवर्क
  • बहुस्त्र्पीय
  • पीआईएम
  • आईजीएमपी
  • एसएसएम
टैग लगा दो

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

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

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

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

इस घटना में कि आप इन सेटिंग्स का उपयोग करके आईपीटीवी देखने का आनंद नहीं ले सकते हैं, राउटर के माध्यम से आईपीटीवी स्थापित करने के लिए निम्नलिखित तकनीकी सुझाव दिए गए हैं।

फर्मवेयर बदलने की विधि

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

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

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

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

एक एसस राउटर के माध्यम से आईपीटीवी की स्थापना

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

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

सामान्य तौर पर, राउटर के माध्यम से आईपीटीवी स्थापित करना एक सामान्य उपयोगकर्ता के लिए एक कठिन काम है, लेकिन यदि आप पेशेवरों से संपर्क नहीं कर सकते हैं, तो मुझे लगता है कि इस प्रकार की सेटिंग्स आपको एक कठिन परिस्थिति में मदद करेंगी।

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

IGMP स्नूपिंग फ़ंक्शन का उपयोग आपको कुछ इंटरफेस पर ट्रैफ़िक प्रसारण के बारे में निर्णय लेने की अनुमति देता है। उपभोक्ताओं (होस्ट) से प्रदाताओं (मल्टीकास्ट राउटर) के लिए IGMP अनुरोधों को स्नूपिंग करने की प्रक्रिया।

IGMP स्नूपिंग अवधारणा और उद्देश्य

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

अधिकांश संचारकों में, IGMP स्नूपिंग फ़ंक्शन उपलब्ध है, लेकिन इसे पहले सक्षम किया जाना चाहिए।

नेटवर्क ट्रैफ़िक की निगरानी क्यों करें?

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

यदि संचारक अपने सभी बंदरगाहों पर मल्टीकास्ट ट्रैफिक का प्रसारण शुरू कर देता है, तो:

  • यह प्रक्रिया बेकार है;
  • अंतिम प्राप्तकर्ता (नेटवर्क डिवाइस) के संचालन में समस्याएं उत्पन्न हो सकती हैं, जो अनावश्यक डेटा की एक बड़ी धारा को संसाधित करने के लिए मजबूर होती है।

ऐसी स्थितियों को खत्म करने के लिए, IGMP स्नूपिंग फ़ंक्शन है, जो पूरे नेटवर्क के संचालन में काफी सुधार करता है। यह नेटवर्क (तीसरी) परत की जरूरतों को ध्यान में रखता है और इस प्रकार डेटा लिंक (दूसरी) परत का अनुकूलन करता है।

वायरटैप फ़ंक्शन को सक्षम करना

मल्टीकास्ट ट्रैफ़िक की निगरानी के लिए, आपको पहले IGMP स्नूपिंग को सक्षम करना होगा और इसे स्वयं कॉन्फ़िगर करना होगा। आइए विचार करें कि मल्टीकास्ट डेटा ट्रांसमिशन योजना को लागू करते समय डी-लिंक संचारकों पर इसे कैसे किया जाए। वायरटैपिंग को सक्रिय करने के लिए कमांड:

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

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

आईजीएमपी ईव्सड्रॉपिंग के प्रकार

IGMP स्नूपिंग निष्क्रिय या सक्रिय हो सकती है। इसे कैसे दिखाया जाता है?

  1. पैसिव ट्रैफिक को फिल्टर नहीं करता है, यह सिर्फ इसकी निगरानी करता है।
  2. सक्रिय - मल्टीकास्ट राउटर पर लोड को कम करने के लिए डेटा पैकेट को सुनता है और फ़िल्टर करता है।

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

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