एलएलटीआर भाग 0: स्वचालित नेटवर्क टोपोलॉजी का पता लगाने और अप्रबंधित स्विच। मिशन असंभव?

डेटा लिंक लेयर पर नेटवर्क टोपोलॉजी का निर्माण कैसे करें यदि वांछित सबनेट में केवल अप्रबंधित स्विच का उपयोग किया जाता है? लेख में मैं इस प्रश्न का उत्तर देने का प्रयास करूंगा।

मैं LLTR ( लिंक लेयर टोपोलॉजी रिवील ) के कारण के साथ शुरुआत करूँगा।

मेरे पास एक "बाइक" थी - एक बड़ी फाइल सिंक्रोनाइज़र "फुल नेटवर्क स्पीड पर", फास्ट ईथरनेट ( 100 एमबीपीएस ; 100BASE - TX; डुप्लेक्स) पर 1, 10, 30, या 3 घंटे से अधिक पूरी तरह से 120 GiB फाइल अपलोड करने में सक्षम; > 200 पीसी । यह एक बहुत उपयोगी "बाइक" था क्योंकि फ़ाइल सिंक्रनाइज़ेशन की गति लगभग पीसी की संख्या से स्वतंत्र थी, जिस पर फ़ाइल को अपलोड करना था। सब कुछ ठीक होगा, लेकिन इसके काम के लिए नेटवर्क टोपोलॉजी का ज्ञान होना आवश्यक है।

आप श्रृंखला को आगे जारी रख सकते हैं, लेकिन इस पर मैं टूट जाऊंगा।

मौजूदा डेटा लिंक लेयर टोपोलॉजी डिस्कवरी प्रोटोकॉल ( LLDP , LLTD , CDP , ...) को उनके संचालन के लिए सभी मध्यवर्ती नेटवर्क नोड्स से उचित समर्थन की आवश्यकता होती है। यही है, उन्हें कम से कम प्रबंधित स्विच की आवश्यकता होती है जो उपयुक्त प्रोटोकॉल का समर्थन करते हैं। हैरे पर पहले से ही एक लेख था कि इन प्रोटोकॉल का उपयोग कैसे करें " ओएसआई मॉडल के 2/3 स्तरों पर नेटवर्क टोपोलॉजी का निर्धारण करें "।

लेकिन क्या होगा यदि मध्यवर्ती नोड सरल अप्रबंधित स्विच हैं?

यदि आप रुचि रखते हैं कि यह कैसे किया जा सकता है, तो बिल्ली का स्वागत करें। मैं कई दृष्टांतों और उदाहरणों की उपलब्धता का वादा करता हूं।

{छवि का आकार: 924 KiB; पाठ: 69 कीबी; इमोटिकॉन्स: 9 पीसी। }

@charset "utf-8"; body { font-family: Verdana,sans-serif !important; } .nav-links__item-link { font-family: Helvetica,Arial,sans-serif !important; } .comment__message, .comment-form__preview { font-family:Arial !important; } .post__text { font-size:13px !important; line-height:1.60 !important; } .post__title-text, .post__title_link { font-family: Tahoma,sans-serif !important; line-height:118% !important; } .post__title-text { font-size:30px !important; } .post__title_link { font-size:26px !important; } /* .post__text-html p > br:first-child, .post__text p+br { display:none !important; } .post__text p { margin-bottom: 0.9em; margin-top: 0.9em; } /* for test: https://habr.com/post/315186 :（ */ .post__text br { line-height:normal !important; } /* or 1 ; https://habr.com/company/pt/blog/337450 */ .post__text img { -o-object-fit:contain; object-fit:scale-down; } /* https://stackoverflow.com/questions/787839/resize-image-proportionally-with-css and don't use "height:auto; width:auto;" (example: <img src="img32x32_2x.png" width="16" height="16">)*/ .post__text h1, .post__text h2, .post__text h3 { font-family: Helvetica,Arial,sans-serif !important; } .post__text h2 { font-size:1.5em !important; } .post__text h3 { font-size:1.375em !important; } .post__text h4, .post__text h5, .post__text h6 { font-family: Verdana,sans-serif !important; font-size:1.125em !important; font-weight:bold !important; } .post__text h5 { color:#3D3D3D !important; } .post__text h6 { color:#5C5C5C !important; } .post__text ul li, .post__text ul ul li, .post__text ul ol li, .post__text ol li, .post__text ol ul li, .post__text ol ol li { line-height:inherit !important; padding:0 !important; } .post__text ul, .post__text ul ul, .post__text ul ol, .post__text ol, .post__text ol ul, .post__text ol ol { margin-left:35px !important; } .post__text ul ul, .post__text ul ol, .post__text ol ul, .post__text ol ol { margin-bottom:9px !important; } .post__text .spoiler .spoiler_title { color:#6DA3BD !important; font-size:inherit !important; font-weight:400 !important; } .post__text .spoiler::before { margin-top:2px !important; } .post__text .spoiler .spoiler_text { color:#666 !important; background:#F9F9F9 !important; border:1px solid #EEE !important; } .post__text .spoiler .spoiler_text hr:first-child, .post__text .spoiler .spoiler_text hr:last-child { display:none !important; } .post__text code { font-size:13px !important; /*background-color:#F8F8F8 !important;*/ border:1px solid #F2F2F2 !important; border-radius:3px !important; padding:0 0.25em !important; white-space:pre-wrap !important; } .post__text strong > code { font-weight: normal !important; background-color: #F8F8F8 !important; } .post__text pre code { line-height:1.5 !important; background-color:#F8F8F8 !important; border-color:#DDD !important; padding:0.5em 1em !important; white-space:pre !important; overflow-x:auto !important; } .hljs-comment, .hljs-quote { color:#808080 !important; font-style:inherit !important; } .hljs-doctag,.hljs-keyword,.hljs-formula, .hljs-section,.hljs-name,.hljs-selector-tag,.hljs-deletion,.hljs-subst { color:#4d7386 !important; } .hljs-literal{ color:#7296a3 !important; } .hljs-string,.hljs-regexp,.hljs-addition,.hljs-meta-string{ color:#390 !important; } .hljs-built_in,.hljs-class .hljs-title{ color:#968e5b !important; } .hljs-attr,.hljs-attribute,.hljs-variable,.hljs-template-variable,.hljs-type,.hljs-selector-class,.hljs-selector-attr,.hljs-selector-pseudo,.hljs-number{ color:#2f98ff !important; } .hljs-symbol,.hljs-bullet,.hljs-link,.hljs-meta,.hljs-selector-id,.hljs-title{ color:#968e5b !important; } .post__text kbd { display:inline-block !important; padding:0.2em 0.5em 0.3em !important; vertical-align:middle !important; background-color:#FCFCFB !important; border:1px solid #D9D9D9 !important; border-radius:3px !important; border-bottom-color:#C6CBD1 !important; box-shadow:inset 0px -1px 0px #C6CBD1 !important; font:11px/10px Tahoma, sans-serif !important; color:#575757 !important; text-shadow:0px 1px 0px #FFF !important; } .post__text blockquote, .comment__message blockquote, .comment-form__preview blockquote { background:inherit !important; border-left:0.25em solid #DFE2E5 !important; color:#70767D !important; padding:0 1em !important; } .post__text .user_link { display:inline-block !important; padding-left:14px !important; color:#666 !important; font:92.4%/1.5em Arial !important; background:url("https://hsto.org/storage/habrastock/i/bg-user2.gif") 0px 60% no-repeat !important; } .post__text .user_link::before { content:'@' !important; color:transparent !important; position:absolute !important; left:0 !important; }/*for copy-paste (for Opera Presto)*/ .voting-wjt_post>.voting-wjt__counter, .post-stats__item_views { display:none !important; } 

 // ==UserScript== // @version    1.0.0 // @namespace  https://habr.com/users/ZiroKyl/ // @homepageURL https://habr.com/post/414799/ // @name       Anti-quotes-hell for Habr // @include    https://habr.com/post/* // @include    https://habr.com/company/*/blog/* // ==/UserScript== // Enable opera:config#UserPrefs|UserJavaScriptonHTTPS if(self == top){   window.opera.addEventListener("BeforeEvent.DOMContentLoaded", function(){ "use strict";       var code = document.querySelectorAll(".post__text :not(pre) > code");       var unQuote = function(el){           var aN = null, a = "",              bN = null, b = "";           if((aN = el.previousSibling) && (bN = el.nextSibling) &&              aN.nodeType == 3        && bN.nodeType == 3    ){               a = aN.data; a = a.charCodeAt(a.length-1);               b = bN.data; b = b.charCodeAt(0);               // a != " " && ( a+1 == b && (a == "“" || a == "'" ) || (a == "«" && b == "»") || a == b && (a == "'" || a == "`" || a == '"') )               if(a != 32 && ( a+1 == b && (a == 8220 || a == 8216) || (a == 171 && b == 187) || a == b && (a == 39 || a == 96 || a == 34 ) )){                   aN.data = aN.data.slice(0,-1);                   bN.data = bN.data.slice(1);                   return true;               }           }           return false;       };       var aN = null, bN = null, pElTagName = "";       for(var i=code.length;i--;){           // “<code>...</code>” -> <code>...</code>           if(!unQuote(code[i])                                                                 &&               ( code[i].previousElementSibling == null && code[i].nextElementSibling == null &&                (pElTagName = code[i].parentElement.tagName)                                &&                (pElTagName == "A" || pElTagName == "STRONG")                                ) &&               ( (!(aN = code[i].previousSibling) || aN.data.trim().length == 0) &&                (!(bN = code[i].nextSibling)    || bN.data.trim().length == 0) )             ){               // “<a><code>...</code></a>”    -> <a><code>...</code></a>               // “<a> <code>...</code> </a>”  -> <a> <code>...</code> </a>               // “<a><code>...</code>...</a>” -X               unQuote(code[i].parentElement);           }       }   }, false); } 

LLTR के बारे में, मैं एक सामान्य विषय "प्रोटोकॉल कैसे बनाऊं" के साथ कई लेख लिखने जा रहा हूं। यह लेख शून्य है।

# भौतिक दुनिया से एक समानता - वायवीय परिवहन

कल्पना कीजिए कि हमारे पास 2 वायु पाइप हैं ...

आने वाले पार्सल (लाल कंटेनर) के लिए एक पाइप, और आउटगोइंग पार्सल (नीले कंटेनर) के लिए एक।

हमारे कई मित्र हैं जो समान वायवीय परिवहन प्रणाली से जुड़े हैं। हम उन्हें कंटेनर भेज सकते हैं, और वे हमारे लिए कंटेनर भेज सकते हैं। कंटेनर वितरण पता कंटेनर पर ही चिह्नित किया जाता है (उदाहरण के लिए, RFID या बार-कोड में)।

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

हम और हमारे मित्र जो कुछ भी कर सकते हैं, वह कुछ सामग्री के साथ कंटेनर भेजना और प्राप्त करना है।

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

# एलएलटीआर बेसिक

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

एक छोटा उदाहरण (कोई समस्या नहीं):

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

एक और उदाहरण (एक समस्या है):

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

इस मामले में, समस्या का समाधान (नेटवर्क टोपोलॉजी का निर्धारण) इसे हल करने की आवश्यकता के कारण होता है - एक "अड़चन" के गठन में। समस्याओं की पूरी श्रृंखला इस प्रकार है: आपको "बाधाओं" से छुटकारा पाने की आवश्यकता है → आपको "सही" श्रृंखला बनाने की आवश्यकता है → आपको नेटवर्क टोपोलॉजी निर्धारित करने की आवश्यकता है। वैसे, हम "अड़चनों" के बिना किसी श्रृंखला की तलाश में, श्रृंखला के सभी संभावित संयोजनों से नहीं गुज़रेंगे - यह बहुत लंबा है, इसके बजाय हम अधिक चालाक / चालाक करेंगे:

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

दो स्विच के बीच कनेक्शन एक "अड़चन" बन गया, और एक अलग क्लस्टर में सही स्विच से जुड़े सभी होस्ट का चयन करने की अनुमति दी।

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

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

जिन संयोजनों की जाँच करने की आवश्यकता है, उनकी गणना सूत्र n × (n - 1) {प्रत्येक (n) को अन्य (n - 1) को "नमस्ते" करने की आवश्यकता है, भले ही वे पहले से ही उसे अभिवादन कर रहे हों}, जहाँ n की संख्या है, की गणना की जा सकती है। सभी मेजबान माइनस एक (प्रसारण मेजबान)।

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

वैसे, न्यूनतम नेटवर्क कॉन्फ़िगरेशन को स्कैन किया जाना चाहिए जिसमें दो स्विच होते हैं, जिनमें से प्रत्येक में दो होस्ट जुड़े होते हैं। प्रसारण और यूनिकस्ट की गति के लिए, प्रसारण ट्रैफ़िक को 75% - " नेट डेटा दर " (नेट बिटरेट; "ईथरनेट 100Base-TX" पर खोज) की सीमा में रखा जा सकता है, और 80% - 100% की सीमा में यूनिकस्ट।

# LLTR उन्नत

^{यूएफओ} _{ने उड़ान भरी} और _इस ^{अंतर को} _यहां ^छोड़ _दिया ? आईक्यू टेस्ट की तस्वीरों में से एक की याद दिलाता है

जैसा कि ऊपर लिखा गया था, LLTR बेसिक का उपयोग करते समय, हमें नेटवर्क n × (n - 1) बार स्कैन करने की आवश्यकता होती है, जो हमें O (n ² ) की ओर ले जाती है। मेजबानों की एक छोटी संख्या के लिए, यह एक समस्या नहीं है:

• 4 होस्ट, एन = 3 ⇒ 6 स्कैन;
• 30 होस्ट, एन = 29 ⇒ 812 स्कैन।

लेकिन अगर हमारे पास 200 होस्ट हैं, तो n = 199 ⇒ 39,402 स्कैन। इससे भी बदतर ...

आइए देखें कि हम स्थिति को कैसे सुधार सकते हैं। टोपोलोजी ट्री के लिए ग्रैकनोम दो सरल विकल्प:

• स्विच से एक सितारा;
• स्विच का सीरियल कनेक्शन।

# टोपोलॉजी: "स्विच से स्टार"

नीचे, इस चित्र में दर्शाए गए क्रिया को चरण दर चरण समझाया गया है।

हमारे पास 5 स्विच और 12 होस्ट हैं। होस्ट्स को उस स्विच के अंदर हलकों [●] द्वारा इंगित किया जाता है जिससे वे जुड़े हुए हैं। एक पूरी तरह से ब्लैक स्विच "रूट" स्विच है।

हम प्रसारण ट्रैफ़िक के स्रोत की भूमिका के लिए मेजबानों में से एक का चयन करते हैं (चित्र में एक चक्र [)] के रूप में दिखाया गया है)।

यदि आप LLTR बेसिक का उपयोग करते हैं, तो 12 होस्ट्स के लिए, n = 11 ⇒ आपको 110 स्कैन (पुनरावृत्तियों) की आवश्यकता है।

Iteration 1 । मेजबानों में से किसी एक को चुनें (नीले द्वारा दर्शाया गया ) यूनिकास्ट ट्रैफ़िक के स्रोत (src) के रूप में, और एक होस्ट (नीला ● द्वारा दर्शाया गया) (dst) यूनिकस्ट ट्रैफ़िक के प्राप्तकर्ता के रूप में। चलो, समय की एक निश्चित अवधि में, स्कैन करना और आंकड़े एकत्र करना शुरू करते हैं।

एकत्र किए गए आँकड़ों में 9 मेजबानों पर प्रसारण यातायात की गति में कमी देखी गई। स्पष्टता के लिए, स्विच से जुड़े सभी होस्ट पर गति में गिरावट को चिह्नित किया जाता है ।

गति में पता चला ड्रॉप के आधार पर, आप दो समूहों में मेजबान वितरित कर सकते हैं:

• पीला (प्रारंभिक) - मेजबान जिस पर प्रसारण की गति अधिकतम के करीब रही;
• हरा - मेजबान जिस पर प्रसारण की गति में एक महत्वपूर्ण गिरावट दर्ज की गई थी।

Iteration 2 । हम अन्य यूनिकस्ट src और dst होस्ट्स का चयन करेंगे, और फिर से स्कैन करना और आंकड़े एकत्र करना शुरू करेंगे।

स्पीड ड्रॉप 3 मेजबानों पर तय किया गया है। अब वे ग्रीन क्लस्टर में हैं, क्योंकि पिछली यात्रा में, इन यजमानों पर गति में गिरावट भी दर्ज की गई थी। इन 3 मेजबानों को हरे रंग के क्लस्टर से नए लाल क्लस्टर में स्थानांतरित करें।

Iteration 3 । फिर से, अन्य यूनिकैस्ट src और dst होस्ट्स का चयन करें, और फिर से आँकड़े स्कैन और संग्रह करना शुरू करें।

अन्य 3 मेजबानों पर स्पीड ड्रॉप दर्ज की गई है। अब वे ग्रीन क्लस्टर में हैं। इन 3 मेजबानों को हरे रंग के क्लस्टर से नए बैंगनी क्लस्टर में स्थानांतरित करें।

नीचे पंक्ति : 110 में से तीन पुनरावृत्तियों के बाद, सभी मेजबान अपने स्विच के अनुरूप क्लस्टर में विभाजित थे। शेष 107 पुनरावृत्तियों में, कोई नया समूह नहीं बनाया जाएगा।

यह एक आदर्श मामला था - हम या तो नेटवर्क टोपोलॉजी जानते थे, या हम बहुत भाग्यशाली थे।

# मुझे आश्चर्य है कि पहले पुनरावृत्ति के लिए क्या विकल्प हो सकते हैं?

विकल्प 1: "ब्रॉडकास्ट स्विक पर यूनिकास्ट" । यूनिकस्ट src प्रसारण src के रूप में एक ही स्विच पर स्थित है (साथ ही साथ 1 पुनरावृति में आंकड़ा में ऊपर के उदाहरण में)। Unicast dst किसी अन्य (प्रसारण src नहीं) स्विच पर स्थित है।

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

विकल्प 2: "यूनिकैस्ट जनरल" । यूनिकास्ट src किसी भी "गैर प्रसारण src" स्विच पर स्थित है। Unicast dst किसी अन्य ("ब्रॉडकास्ट src" और "unicast src") स्विच पर स्थित नहीं है।

सभी मामलों में, गति में गिरावट उन स्विचों पर होती है, जिन पर यूनीकास्ट डीएसटी स्थित था। अनुभाग की शुरुआत में उदाहरण से समान नेटवर्क व्यवहार पुनरावृत्ति 2 और 3 (आंकड़ा देखें) पर था।

विकल्प 3: "स्विक प्रसारित करने के लिए यूनिकस्ट" । यूनिकास्ट src किसी भी "गैर प्रसारण src" स्विच (साथ ही विकल्प 2 में) पर स्थित है। Unicast dst प्रसारण src के समान स्विच पर स्थित है।

इन मामलों में, स्कैन के लिए कोई नेटवर्क प्रतिक्रिया नहीं है। यदि पिछले संस्करणों (1 और 2) में एक नया क्लस्टर बनाया गया था, तो इस संस्करण में नए क्लस्टर नहीं बनाए गए हैं। यह आंशिक रूप से खराब है - हमें नेटवर्क टोपोलॉजी के बारे में नई जानकारी नहीं मिलती है (वास्तव में, कुछ मामलों में, और यदि यह पुनरावृत्ति पहले नहीं है, तो आप यूनिकस्ट डीएसटी के स्थान के बारे में कुछ जानकारी प्राप्त कर सकते हैं)।

विकल्प 4: "स्विक में यूनिकास्ट" । यूनिकस्ट src और dst एक ही स्विच पर स्थित हैं।

यहां, नेटवर्क स्कैनिंग के लिए बिल्कुल भी प्रतिक्रिया नहीं देता है, और तदनुसार कोई नया क्लस्टर नहीं है।

परिणाम । विकल्प 1 और 2 अच्छे हैं, नेटवर्क उनका जवाब देता है, और हमें इसकी टोपोलॉजी के बारे में नई जानकारी देता है। और इस जानकारी के आधार पर, नए क्लस्टर बनाए जाते हैं।

विकल्प 3 और 4 केवल यह कह सकते हैं कि यूनिकस्ट dst या तो प्रसारण src के साथ एक ही स्विच पर है, या unicast src के साथ एक ही स्विच पर है। इसके अलावा, वे यूनिकास्ट dst के सटीक स्थान के बारे में एक पुनरावृत्ति में पूरी जानकारी नहीं दे सकते हैं - वे हमेशा src या unicast src के प्रसारण के बगल में होंगे। अन्य पुनरावृत्तियों की जानकारी के साथ प्राप्त जानकारी को मिलाकर ही सटीक स्थान प्राप्त किया जा सकता है।

# यूनिकैस्ट src और dst का चुनाव यादृच्छिक था?

शायद चुनाव यादृच्छिक नहीं था, और इसमें एक छिपा हुआ पैटर्न है?

ठीक है, हमने अभी देखा कि नेटवर्क विभिन्न स्कैनिंग विकल्पों पर कैसे प्रतिक्रिया देता है। अनुभाग की शुरुआत से उदाहरण याद रखें, शायद यह "नए कोण" से देखने और सवाल का जवाब देने का समय है: क्या मैंने गलती से यूनिकैस्ट src और dst, या धोखा दिया?

यह तस्वीर अनुभाग की शुरुआत से चित्र के समान है, अंतर यह है कि प्रत्येक पुनरावृत्ति में यूनिकस्ट src के वैकल्पिक विकल्प जोड़े गए थे, और दाईं ओर कुछ ...

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

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

यह एक आदर्श मामला था - हम या तो नेटवर्क टोपोलॉजी जानते थे, या हम बहुत भाग्यशाली थे।

हालांकि, नए क्लस्टर के गठन की संभावना का मूल्यांकन करने की क्षमता हमारे लिए उपयोगी है।

# क्लस्टर के अंदर स्कैन करें, या क्रॉस-क्लस्टर स्कैनिंग का उपयोग करें - यह सवाल है ...

ऊपर के उदाहरण में, अंतिम (तीसरे) पुनरावृत्ति में, क्लस्टर के बीच स्कैनिंग का उपयोग किया गया था। क्या यह इतना अच्छा है, क्योंकि पहले वे क्लस्टर के अंदर स्कैनिंग का इस्तेमाल करते थे?

नोट : यदि यूनिकस्ट src और dst एक ही क्लस्टर में हैं, तो यह क्लस्टर के अंदर एक स्कैन है । यदि यूनिकैस्ट src एक क्लस्टर में है, और एक दूसरे में unicast dst - यह इंटरक्लस्टर स्कैनिंग है ।

यदि आप तीसरी पुनरावृत्ति में संभावनाओं को देखते हैं, तो इंटरक्लस्टर स्कैन में क्लस्टर के अंदर स्कैन के लिए 0.60 बनाम 0.30 होगा। संभावना हमें बताने के लिए लगता है "इंटरक्लस्टर स्कैनिंग, भाई का उपयोग करें।", लेकिन क्या यह उसकी सलाह का आँख बंद करके पालन करने के लिए लायक है?

नोट : केवल एक प्रकार के स्कैन (या तो क्लस्टर या इंटरक्लस्टर के भीतर) का उपयोग करने से पुनरावृत्तियों की संख्या में काफी कमी आएगी।

यदि ऊपर के उदाहरण में, 4 पुनरावृति से शुरू होकर, हम केवल क्लस्टर के अंदर स्कैन करना शुरू करते हैं, तो यह 20 पुनरावृत्तियों (3 × 2 + 3 × 2 + 2 × 1 + 3 × 2) ले जाएगा , कुल 23 पुनरावृत्तियों 110 के बजाय प्राप्त होगी (जैसा था) खंड की शुरुआत में गणना की गई)। यदि, एक ही 4 पुनरावृति से शुरू होकर, केवल इंटरक्लस्टर स्कैनिंग शुरू की जाती है , तो यह 87 पुनरावृत्तियों (3 × (3 + 2 + 3) + 3 × (3 + 2 + 3) + 2 × (3 + 3 + 3) ले जाएगा + 3 × (3 + 3 + 2) - 3) , कुल 90 पुनरावृत्तियों में बदल जाएगा।

इंटरक्लस्टर स्कैनिंग काफ़ी हद तक खो जाती है, इसके अलावा, इसे 1 पुनरावृत्ति पर इस्तेमाल नहीं किया जा सकता है (इस समय केवल एक क्लस्टर है)। यदि हम ऊपर दिए गए उदाहरण से 2 पुनरावृत्ति पर ध्यान देते हैं, तो हम देख सकते हैं कि अंतिम वैकल्पिक स्कैन विकल्प में 0.00 का एक नया क्लस्टर बनाने की संभावना है। मेरा मानना ​​है कि प्रश्न का उत्तर: "इस विकल्प के पास किस प्रकार की स्कैनिंग है?" पहले से ही स्पष्ट है।

# समानांतर स्कैनिंग का आनंद

यदि, एक क्लस्टर के अंदर स्कैनिंग का उपयोग करते हुए, एक साथ सभी समूहों में एक साथ स्कैन चलाना संभव है, तो अतिरिक्त 20 पुनरावृत्तियों (3 × 2 + 3 × 2 + 2 × 1 + 3 × 2) को 6 पुनरावृत्तियों (3 × 2) में घटा दिया जाएगा। इंटरलास्टर स्कैनिंग भी समानांतर स्कैनिंग से लाभ उठा सकती है।

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

Note : ( ), – , ?

: – ; , 2‑ — .

– 6‑ . , unicast src dst , 2 . , 2‑ : “ 0.00”.

“ ”, . , ‑ …

, , . 2‑ (“ unicast on broadcast sw ”: unicast src , broadcast src) (“unicast in sw”: unicast src dst ).

“ unicast on broadcast sw ” , “unicast in sw”, . , “unicast in sw” , unicast src ( – ), 2 .

. , ( , ), . “” , broadcast src. , , broadcast src , ! .

Note : , unicast src , , ( ), .

: .

IQ …

# : “ ”

.

unicast ( ) broadcast ( ) , broadcast ( ). 5‑ , “” , – . , , , (↼), ( ) – (⇁), .. (⇋).

.

5 15 . LLTR Basic, 15 , n=14 ⇒ 182 .

. 1‑ , , unicast src , broadcast src, unicast dst broadcast src . Unicast ( ) broadcast broadcast src . ( ). 2‑ , , unicast dst broadcast src .

. ( ).

3 . broadcast unicast – .

4 . broadcast unicast – .

5 . Unicast src dst broadcast src – , unicast dst ( ). , 2‑ , , “ ”.

, , (2 ):

, . 4‑ ( , , ), 1‑ .

30 ((4) + (3×2 + 3×2 + 3×2 + 2×1 + 3×2)) , 182 LLTR Basic.

?

, ‑ . 3‑ , unicast (↼), broadcast , unicast src . , unicast src ( ), , . unicast src , . , , “ ” .

, , , ? “ ” …

( ), :

(2 ), ( ).

, – , 1 . – / .

, 1 , ( , ), , 1 , ? ?

: ( ), () . , , 4 (1 + 3 ):

:

: “ , ?” – , .

? . … ；）

# TL;DR

, …

, , :

• 2 / , – ;
• / , , ( ‑ ).

xkcd, , （：

# / To be continued…

1. OMNeT++ INET [ tutorial ]
3. OMNeT++
5. OMNeT++ 2
7. (‑: “ ”)

: GitHub Pages ;

PS （； URI )

PPS , ；）

PPPS , , – . ( ) , / , – ：）

PPPPS , .