LLTR Частина 0: Автоматичне визначення топології мережі і некеровані комутатори. Місія нездійсненна?

Як побудувати топологію мережі на канальному рівні, якщо потрібної підмережі використовуються тільки некеровані світчі? У статті я постараюся відповісти на це питання.

Почну з причини виникнення LLTR (Link Layer Topology Reveal).

У мене був один “велосипед” – синхронізатор великих файлів “на повній швидкості мережі”, здатний за 3 години цілком залити 120 GiB файл Fast Ethernet (100 Мбіт/с; 100BASE‑TX; дуплекс) на 1, 10, 30, або 200 ПК. Це був дуже корисний “велосипед”, т. як. швидкість синхронізації файлу майже не залежала від кількості ПК, на які потрібно залити файл. Все б добре, але він вимагає знання топології мережі для своєї роботи.

Докладніше в статті про нього:

“RingSync: синхронізуємо на повній швидкості мережі”.
(див. P. P. P. S.)

Гаразд, а навіщо знадобилося “ганяти” 120 GiB файл по мережі на таку кількість ПК?

Цим файлом був VHD з операційною системою, програмами, і т. п. Файл створювався на майстер‑системі, а потім поширювався на всі інші ПК. VHD був не лише способом доставки системи на кінцеві ПК, але й давав можливість відновлення початкового стану системи при перезавантаженні ПК.

Можна продовжити ланцюжок далі, але на цьому я прервусь.

Існуючі протоколи виявлення топології канального рівня (LLDP, LLTD, CDP, …) для своєї роботи вимагають відповідної підтримки їх з боку всіх проміжних вузлів мережі. Тобто вони вимагають як мінімум керованих світчів, які б підтримували відповідний протокол. На Хабре вже була стаття, як використовуючи ці протоколи, “визначити топологію мережі на рівнях 2/3 моделі OSI”.

Але що ж робити, якщо проміжні вузли – прості некеровані світчі?

Якщо цікаво як це можна зробити, то ласкаво просимо під кат. Обіцяю наявність безлічі ілюстрацій та прикладів.

{ обсяг зображень: 924 KiB; тексту: 69 KiB; смайликів: 9 шт. }

Трохи UserCSS перед прочитанням

Note: спочатку цей спойлер розміщувався до ката.

Напевно всі, хто хотів налаштувати стилі під себе, вже зробили це. Тим не менш, ось частина мого UserCSS. Основні зміни:

 

  • видно кінець розкритого спойлера (корисно, коли спойлер великий, і різницю у відступі між основним текстом і текстом в спойлері не відразу помічаєш), точніше повернув колишню рамку і фон спойлера;
  • цитата повернув свій колишній вигляд (я показував кільком людям, які не розуміють російської мови, і не читають хабр, нові “жовті цитати”, і вони говорили, що це вставки контекстної реклами…);
  • основний шрифт, його розмір, міжрядковий інтервал, також повернулися назад (IMHO, з ними довгий текст сприймається легше);
  • прибраний рейтинг публікації і кількість переглядів, але залишено кількість додавань в закладки.

Загалом, повернув (з невеликими модифікаціями) знайомий вид основних елементів статті. З таким оформленням вже було прочитано велика кількість хороших статей (спливають приємні спогади).

 

@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.9 em; margin-top: 0.9 em; }
/* 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.jpeg" 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.5 em !important; }
.post__text h3 { font-size:1.375 em !important; }
.post__text h4, .post__text h5, .post__text h6 { font-family: Verdana,sans-serif !important; font-size:1.125 em !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 ul ol 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 ul ol, .post__text ol ol { margin-left:35px !important; }
.post__text ul ul, .post__text ul ol, .post__text ul ol, .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.25 em !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.5 em 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.2 em 0.5 em 0.3 em !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:1px 0px 0px #FFF !important; }

.post__text blockquote,
.comment__message blockquote, .comment-form__preview blockquote { background:inherit !important; border-left:0.25 em 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.5 em 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; }

UPDATE: UserJS – Anti-quotes-hell і <code> (див. докладніше в цьому коментарі):

 

// ==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);
}

Основні стилі взяв з попередніх версій Матриці Хабра:

 

  • 2012-06 (UserCSS) – основний шрифт Verdana 13px, міжрядковий інтервал 160%
  • 2012-06 – перша поява спойлера + блок з кодом
  • 2012-04 – таблиця заголовки
  • 2012-05 – більше заголовків
  • 2012-05 – просто хороша стаття
  • 2011-05 — міжрядковий інтервал 1.54 em (у вузькій колонці, з порожнім простором ліворуч і праворуч, текст читається гірше, ніж при інтервалі 160%), блоки з кодом змінили колір фону і втратили обведення, (що ще: змінилася “шапка” хаби [одна стаття може бути в багатьох хабах] стали блогами [одна стаття може бути тільки в одному блозі])
  • 2011-01 – вміст розтягується на всю ширину екрану (у такому форматі текст з зменшеним міжрядковим інтервалом виглядає оптимально, IMHO), IMHO: широка права колонка (при ширині екрану 1600px) створює відчуття затишку, а так само тут краще, ніж в інших версіях виглядають коментар (підібрані вдалі розміри відступів)
  • 2010-08, 2009-12, 2009-05, 2009-03 – зміни на прикладі однієї і тієї ж статті
  • 2010-02, 2009-06 – статті з більш щільним текстом (більш довгі абзаци)
  • 2010-03, 2010-02, 2009-06, 2008-12 – позитивні спогади про Opera
  • 2007-12 – Хабразачистка :)і хмара тегів у правій колонці
  • 2007-04 – міжрядковий інтервал ще менше
Читайте також  Несподівана зустріч. Глава 18 [остання глава, вихід на краудфандінг]

Про LLTR я збираюся написати цикл статей з загальною тематикою “як створити протокол”. Це стаття – нульова.

 

# Аналогія з фізичного світу – пневмотранспорт

Уявімо, що у нас є 2 пневмо-труби…

Одна труба для вхідних посилок (червоні контейнери), і одна для вихідних (сині контейнери).

У нас є кілька знайомих, які підключені до цієї системи пневмотранспорту. Ми можемо посилати їм контейнери, і вони нам можуть надсилати контейнери. Адреса доставки контейнера наноситься на сам контейнер (наприклад, у RFID або bar‑code).

У якийсь момент всім захотілося дізнатися маршрут, за яким кожен день проходять їх посилки, і дізнатися, до яких свитчам (комутаційних центрів) підключені їх пневмо‑труби, тобто дізнатися топологію пневмо‑мережі.

Все, що можемо робити ми і наші друзі – це посилати і приймати контейнери з певним вмістом.

Пропоную подумати, як в такому випадку можна побудувати топологію мережі. Кілька варіантів знаходяться під спойлером:

спойлер

1. Якщо труби прозорі, як у пневмотранспорту в Футурамі (КДПВ), то можна просто відправити відеокамеру, яка зніме весь шлях руху контейнера.

2. Можна розташувати в контейнері датчики, гіроскоп, компас, акселерометр, …), і побудувати карту переміщень по зібраним ними даними.

3. Можна обійтися і без датчиків, відправляючи спеціальним чином контейнери, наповнені повітрям. Нижче розглядається саме цей варіант, оскільки він застосовний до звичайних дротових Ethernet‑мереж.

 

# LLTR Basic

Повертаючись до дротових Ethernet‑мереж, нагадаю про проблему, завдяки якій LLTR був створений. Проблема докладно описана в розділі “PC підключені до різних switch” статті про RingSync – це проблема зниження швидкості при неправильному побудові ланцюжка бенкетів в мережі з декількома свитчами. Для правильної побудови ланцюжка бенкетів потрібна інформація про топологію мережі.

Невеликий приклад (проблеми немає):

У нас є 2 світча (з’єднаних одним “проводом”), 4 хоста (бенкету), всі з’єднання дуплексні, і швидкість усіх сполук однакова. Стрілками показано шлях руху даних. В даному випадку проблеми немає – дані передаються на максимальній швидкості мережі.

Інший приклад (проблема є):

У цьому прикладі ланцюжок бенкетів побудувалася менш вдало (т. к. нам не відома топологія мережі), що призвело до утворення “пляшкового горлечка” (два односпрямованих потоку даних в одному з’єднанні) і падіння загальної швидкості передачі даних.

В даному випадку рішення проблеми (визначення топології мережі) криється в причини необхідності її розв’язання – в освіті “пляшкового горлечка”. Цілком ланцюжок проблем виглядає наступним чином: треба позбутися “темно-зелених шийок” → треба побудувати “правильний” ланцюжок → потрібно визначити топологію мережі. До речі, ми не будемо перебирати всі можливі комбінацій ланцюжка, у пошуках ланцюжка без “темно-зелених шийок” – це занадто довго, замість цього зробимо розумніші/хитріше:

Заповнимо мережа трафіком – виділимо один з хостів під роль джерела broadcast трафіку. На всіх інших хостах запустимо збір статистики по прийнятому broadcast трафік. Далі виберемо будь-2 не broadcast хоста, і почнемо посилати з першого хоста unicast трафік на другий хост. За збирається на хостах статистикою broadcast трафіку в цей момент, буде видно, що на деяких хостах впала швидкість отримання broadcast трафіку – ці хости, в даному випадку, були підключені до правого перемикач. А на всіх хостах, підключених до лівого перемикач, швидкість отримання broadcast трафіку не змінилася.

Зв’язок між двома світчами стала “пляшковим горлечком”, і дозволила виділити всі хости, підключені до правого перемикача в окремий кластер.

Note: У звичайних випадках прийнято всіма силами боротися з broadcast, особливо з тим, який “утилізує всю пропускну здатність”, але ми маємо справу з мережею на некерованих свитчах, яка можливо не раз страждала від broadcast‑шторму/флуду, і хоч раз в житті хочеться, щоб такий broadcast приніс користь. До речі, цілком можливо замінити broadcast на unicast, тільки таке сканування займе більше часу. Для пневмотранспорту теж доведеться використовувати unicast, поки не випустять установку, клонуючу матерію, і не встановлять її в кожен комутаційний центр :).

Для побудови коректної топології мережі, залишилося повторити те ж саме для всіх можливих комбінації орієнтованих пар не broadcast хостів. Що значить “орієнтованих пар” – треба посилати спочатку unicast трафік з першого хоста на другий, і зібрати статистику, а потім поміняти напрям (трафік з другого в перший), і зібрати окрему статистику по цьому варіанту.

Кількість комбінацій, які потрібно перевірити, можна порахувати за формулою n×(n−1) {кожному (n) потрібно “привітатися” з усіма іншими (n−1), навіть якщо з ним раніше вони вже віталися}, де n – кількість всіх хостів мінус один (broadcast хост).

У підсумку, вся зібрана статистика подається на вхід спеціальним алгоритмом (про нього докладніше в одній з наступних статей), який і будує топологію мережі (точніше він робить більше – відразу будує правильний ланцюжок бенкетів для RingSync).

До речі, мінімальна конфігурація мережі, яку доцільно сканувати складається з двох світчів, до кожного з яких підключено два хоста. Що стосується швидкості broadcast і unicast, broadcast трафік можна тримати в діапазоні 75% – 100% від “чистої швидкості передачі даних” (net bitrate; пошук по “Ethernet 100Base-TX”), а unicast в діапазоні 80% – 100%.

А що буде, якщо прибрати один з хостів?

Вийде мережа, в якій один світч, до якого підключені 3 хоста, і в розріз між одним з хостів і світчем підключено ще один світч. Тобто, в мережі знаходиться всього лише один світч (вставлений в розріз перетворився в “перемичку” – його не рахуємо), а це ідеальний випадок для RingSync “бутилочної шийки” нізвідки взятися. Раз немає проблеми чого усувати :)

 

# LLTR Advanced

НЛОприлетілоіоставилоцейпробілтут? Нагадує одну з картинок тесту IQ

Як вище було написано, при використанні LLTR Basic потрібно n×(n−1) раз сканувати мережу, що приводить нас до O(n2). Для невеликої кількості хостів – це не проблема:

 

  • 4 хоста, n=3 ⇒ 6 сканувань;
  • 30 хостів, n=29 ⇒ 812 сканувань.

Але якщо у нас 200 хостів, n=199 ⇒ 39 402 сканування. Далі ще гірше…

Подивимося, як можна поліпшити ситуацію. Грокнем два простих варіанти топології дерево:

 

  • зірка з світчів;
  • послідовне з’єднання світчів.

 

# Топологія: зірка з світчів”

Нижче покроково пояснюється зображене на малюнку дійство.

У нас є 5 світчів і 12 хостів. Хости позначаються колами [●] всередині світча, до якого вони підключені. Повністю чорний світч – це “кореневої” світч.

Один з хостів виділимо під роль джерела broadcast трафіку (на схемі зображений окружністю [○]).

Якщо використовувати LLTR Basic, то для 12 хостів, n=11 ⇒ потрібно 110 сканувань (ітерацій).

Ітерація 1. Виберемо один з хостів (позначений синім ) в якості джерела (src) unicast трафіку, і один хост (позначений синім ●) в якості одержувача (dst) unicast трафіку. Запустимо, у певний проміжок часу, сканування і збір статистики.

Зібрана статистика показала падіння швидкості broadcast трафіку на 9‑й хостах. Для наочності, падіння швидкості на всіх хостах, підключених до перемикач, позначається як .

Виходячи з виявленого падіння швидкості, можна розподілити хости з двох кластерів:

 

  • жовтий (початковий) – хости на яких швидкість broadcast залишалася близькою до максимуму;
  • зелений – хости, на яких було зафіксовано значне падіння швидкості broadcast.

Ітерація 2. Виберемо інші unicast src і dst хости, і знову запустимо сканування і збір статистики.

Падіння швидкості зафіксовано на 3‑х машин. Зараз вони знаходяться в зеленому кластері, т. к. в попередній ітерації на цих машин теж було зафіксовано падіння швидкості. Перемістимо ці 3 хоста з зеленого кластера в новий червоний кластер.

Ітерація 3. Знову виберемо інші unicast src і dst хости, і знову запустимо сканування і збір статистики.

Падіння швидкості зафіксовано на інших 3‑х машин. Зараз вони знаходяться в зеленому кластері. Перемістимо ці 3 хоста з зеленого кластера в новий фіолетовий кластер.

Читайте також  Пошук пошкодженого об'єкта за номером пошкодженої сторінки в MS SQL Server 2005

Підсумок: вже після трьох ітерацій з 110, всі хости були розбиті по кластерам, відповідним їх свитчам. У решти 107 ітераціях нових кластерів утворено не буде.

Це був ідеальний випадок – ми знали топологію мережі, або нам дуже пощастило.

 

# Цікаво, які можуть бути варіанти першої ітерації?

Варіант 1: “unicast on broadcast sw”. Unicast src розташований на тому ж світчі, що і broadcast src (також, як і в наведеному вище прикладі на малюнку в ітерації 1). Unicast dst розташовується на будь-якому іншому (не broadcast src) світчі.

У всіх випадках реакція мережі на сканування однакова – падіння швидкості на всіх “не broadcast src” свитчах. Це зрозуміло — unicast src вливається в той же початок каналу, що і broadcast src – звідси падіння швидкості на всіх інших свитчах, і неважливо на якому з них знаходиться unicast dst.

Варіант 2: “unicast general”. Unicast src розташовується на будь-якому “не broadcast src” світчі. Unicast dst розташовується на будь-якому іншому (“не broadcast src” і “не unicast src”) світчі.

У всіх випадках падіння швидкості відбувається на тому з світчів, на якому був розташований unicast dst. Це ж поведінка мережі було на ітерації 2 і 3 (див. рисунок) з прикладу на початку розділу.

Варіант 3: “unicast to broadcast sw”. Unicast src розташовується на будь-якому “не broadcast src” світчі (також як і у варіанті 2). Unicast dst розташований на тому ж світчі, що і broadcast src.

В цих випадках реакція мережі на сканування відсутня. Якщо в попередніх варіантах (1 і 2) створювався новий кластер, то в цьому варіанті нові кластери не створюються. Почасти це погано – ми не отримуємо нової інформації про топологію мережі (насправді в деяких випадках, і якщо ця ітерація не перша, то можна отримати трохи інформації про місцезнаходження unicast dst).

Варіант 4: “unicast in sw”. Unicast src і dst розташовані на одному і тому ж світчі.

Тут також мережа ніяк не реагує на сканування, і відповідно немає нових кластерів.

Підсумок. Варіанти 1 і 2 – хороші, на них мережа реагує, і дає нам нову інформацію про свою топології. А на основі цієї інформації створюються нові кластери.

Варіанти 3 і 4 можуть сказати тільки те, що unicast dst знаходиться або на одному світчі з broadcast src, або на одному світчі з unicast src. Причому, дати повну інформацію за одну ітерацію про точне місцезнаходження unicast dst вони самі не можуть – завжди буде або поруч з broadcast src, або з unicast src. Точне місце розташування можна отримати, тільки об’єднавши отриману інформацію з інформацією з інших ітерацій.

 

# А чи був вибір unicast src і dst у прикладі випадковим?

Може вибір був не випадковим, і в ньому є схована закономірність?

Добре, ми щойно подивилися, як мережа реагує на різні варіанти сканування. Пам’ятаєте приклад з початку розділу, можливо, настав час подивитися на нього під новим кутом”, і відповісти на питання: чи випадково я вибирав unicast src і dst, або схитрував?

Ця картинка аналогічна картинці з початку розділу, відмінність в тому, що до кожної ітерації додалися альтернативні варіанти вибору unicast src, і дещо праворуч…

Цим “щось” є підрахунок імовірності утворення нового кластера (кількість варіантів, при яких новий кластер створиться, поділена на кількість варіантів при яких новий кластер створиться + кількість варіантів, не приводять до створення нового кластера). Варіанти підраховувалися щодо зафіксованого unicast src, і вільного unicast dst. Unicast dst “вільний” – це означає, що розглядалися всі можливі варіанти його розташування.

Тобто, в прикладі я спеціально вибирав ті варіанти, в яких була найбільша ймовірність утворення нового кластера. На жаль, в реальності такою оцінкою (ймовірностей) ми не зможемо скористатися. Не дарма в кінці я написав:

Це був ідеальний випадок – ми знали топологію мережі, або нам дуже пощастило.

Однак здатність оцінювати ймовірність утворення нового кластера знадобиться нам нижче.

 

# Сканувати всередині кластера, або використовувати міжкластерне сканування – ось в чому питання…

На прикладі вище в останній (3‑й) ітерації використовувалося сканування між кластерами. Так чи воно добре, адже спочатку використовували сканування всередині кластера?

Note: Якщо unicast src і dst знаходяться в одному і тому ж кластері – це сканування всередині кластера. Якщо unicast src знаходиться в одному кластері, а unicast dst в іншому – це межкластерное сканування.

Якщо подивитися на ймовірності у 3‑й ітерації, то у міжкластерної сканування буде 0.60 проти 0.30 у сканування всередині кластера. Ймовірність немов говорить нам “використовуй міжкластерне сканування, бро.”, але варто сліпо слідувати її порад?

Note: Використання тільки одного типу сканування (або всередині кластера, або межкластерное) – дозволить значно скоротити кількість ітерацій.

Якщо в наведеному вище прикладі, починаючи з 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‑й ітерації (в цей момент існує тільки 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 знаходиться не в жовтому кластері, а в зеленому! Цього просто не може бути.

Читайте також  Фахівці з кібербезпеки створили детектор скімерів — SkimReaper

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]
  2. Алгоритм визначення топології мережі по зібраної статистики
  3. OMNeT++ продовження
  4. Математика
  5. OMNeT++ продовження 2
  6. Реалізація
  7. Експеримент (назва‑спойлер: “в кінці Джон помре”)

Про помилки та інші поліпшення…

Якщо в тексті знайшлися помилки, то можете написати про них в ПМ/ЛЗ.

Якщо можете допомогти з зменшенням кількості тексту до ката, зберігши при цьому всю вкладену в текст інформацію та зручність читання, то варіанти приймаю в той же ПМ/ЛЗ.

Якщо ви вважаєте що в тексті краще використовувати синонім одного з слів, то теж можна писати в ПМ/ЛЗ.

P. S. Розділ про пневмотранспорт вставлений не випадково:

(з “Вартових Галактики” вставити сцени з “Ракетою” (~енотом~), коли він просить принести ногу‑протез для плану втечі (і йому приносять ногу), і коли він просить дати для очей плану атаки в кінці фільму (він каже: “дуже важлива частина плану”))

P. S. на картинках мітки стоять неспроста (; зверни увагу на хеш в URI картинок )

P. P. S. у зображеннях можуть бути заховані пасхалки, надають їм глибокий сенс ;)

P. P. P. S. У світлі цього приховав посилання на зовнішній ресурс, де я раніше викладав статті під спойлери, у всіх місцях, крім одного – там де вказується на конкретний розділ статті. Якщо такі посилання (статті) можна, то напишіть в ПМ/ЛЗ, приберу з під спойлера – стане зручніше читачам :)

P. P. P. P. S. Відповіді на коментарі зможу написати лише невеликий проміжок часу, ввечері за Всесвітнім координованим часом.

Степан Лютий

Обожнюю технології в сучасному світі. Хоча частенько і замислююся над тим, як далеко вони нас заведуть. Не те, щоб я прям і знаюся на ядрах, пікселях, коллайдерах і інших парсеках. Просто приходжу в захват від того, що може в творчому пориві вигадати людський розум.

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *