Прозорі мости (TB) були вперше розроблені Digital Equipment Corporation на початку 1980 рр. Digital представила свою роботу в IEEE, який включив її в стандарт IEEE 802.1. TB дуже популярні в мережах Ethernet / IEEE 802.3.
ТВ успішно ізолює внутрішньосегментний трафік, тим самим скорочуючи трафік, видимий в кожному окремому сегменті. Це зазвичай покращує час реакції мережі, видиме користувачеві. Ступінь скорочення трафіку і поліпшення часу реакції залежать від об'ема межсегментного трафіку щодо загального трафіку, а також від об'ема широковещательного і багатопунктовий трафіку.
Без протоколу взаємодії між мостами алгоритм ТВ відмовляє, коли між двома будь-якими LAN единенной мережі є кілька трактів, що включають в себе мости і локальні мережі. Освіта петлі при єднання за допомогою мостів показано на Рис. 29-2 "Неправильне просування пакетів і впізнавання інформації в середовищах прозорого об'единения".
Припустимо, що Хост А відправляє блок даних в Хост В. Обидва мости приймають цей блок даних і і роблять правильний висновок про те, що машина А знаходиться в мережі 2. На жаль, після того, як машина В прийме два примірника блоку даних машини А , обидва мости знову отримують цей же блок даних на свої інтерфейси з Мережею 1, тому що всі хости приймають всі повідомлення широкомовних LAN. У деяких випадках мости потім змінюють свої внутрішні таблиці, щоб вказати, що машина А знаходиться в Мережі 1. У цьому випадку при відповіді машини В на блок даних машини А обидва мости візьмуть, а потім проігнорують ці відповіді, тому що їх таблиці вкажуть, що даний пункт призначення (машина А) знаходиться в тому ж сегменті мережі, що і джерело цього блоку даних.
Крім основних проблем зв'язності, подібних описаної вище, потенційно серйозною проблемою є розмноження широкомовних повідомлень в мережах з петлями. Звернувшись знову до Рис. 29-2, припустимо, що початковий блок даних машини А є широкомовною. Обидва мости будуть нескінченно просувати цей блок даних, використовуючи всю доступну ширину смуги мережі і блокуючи передачу інших пакетів в обох сегментах.
Топологія з петлями, подібними зображеної на Рис. 29-2, може бути корисною, але також і потенційно шкідливої. Петля має на увазі існування декількох трактів через об'едіненнную мережу. У мережі з декількома трактами від джерела до пункту призначення загальна стійкість може збільшитися завдяки поліпшеній топологічної гнучкості.
STA передбачає вільне від петель підмножина топології мережі шляхом розміщення таких мостів, які, якщо вони включені, то утворюють петлі в резервному (блокирующем) стані. Порти блокуючого моста можуть бути активовані в разі відмови основного каналу, забезпечуючи новий тракт через единенную мережу.
Першим кроком при обчисленні сполучного дерева є вибір кореневого моста (root bridge), який являє собою міст з найменшим значенням ідентифікатора моста. На Рис. 29-3 кореневих мостом є Міст 1. Далі визначається кореневої порт (root port) у всіх інших мостах. Кореневої порт моста - це порт, через який можна потрапити в кореневій міст з найменшими комбінованими витратами тракту. Ця величина (тобто найменші комбіновані витрати тракту до кореневого моста) називається витратами кореневого тракту (root path cost).
І нарешті, визначаються призначені мости (designated bridges) і їх призначені порти (designated ports). Призначений міст - це той міст кожної локальної мережі, який забезпечує мінімальні витрати кореневого тракту. Призначений міст локальної мережі є єдиним мостом, який дозволяє просувати блоки даних в ту локальну мережу (і з неї), для якої цей міст є призначеним. Призначений порт локальної мережі - це той порт, який з'єднує її з призначеним мостом.
У деяких випадках два або більше мостів можуть мати однакові витрати кореневого тракту. Наприклад, на Рис. 29-3 як Міст 4, так і Міст 5 можуть досягти Міст 1 (кореневої міст) з витратами тракту 10. У цьому випадку знову використовуються ідентифікатори моста, на цей раз для визначення призначення мостів. При виборі перевагу віддано порту LAN V Моста 4 перед портом LAN V Моста 5.
При використанні цього процесу усуваються всі мости, безпосередньо з'єднані з кожної LAN, крім одного; таким чином, видаляються всі петлі між двома LAN. STA також усуває петлі, які мають більше двох LAN, в той же час зберігаючи зв'язність. На Рис. 29-4 "Мережа ТВ після прогону STA" показані результати дії STA в мережі, зображеної на Рис. 29-3. На Рис. 29-4 чіткіше показана топологія дерева. Порівняння цього малюнка з малюнком мережі до прогону STA показує, що STA перевів в режим резерву як порти Моста 3 в LAN V, так і порти Moста 5 в LAN V.
Розрахунок сполучного дерева має місце при подачі живлення на міст і в усіх випадках виявлення зміни топології. Для розрахунку необхідна зв'язок між мостами сполучного дерева, яка здійснюється через повідомлення конфігурації (іноді звані протокольними інформаційними одиницями моста - bridge protocol data units. Або BPDU). Повідомлення конфігурації містять інформацію, що ідентифікує той міст, який вважається кореневим (тобто ідентифікатор кореневого моста), і відстань від моста-відправника до кореневого моста (витрати кореневого тракту). Установок Вам також містять ідентифікатори моста і порту моста-відправника, а також вік інформації, що міститься в повідомленні конфігурації.
Мости обмінюються повідомленнями конфігурації через регулярні інтервали часу (зазвичай 1-4 сек.). Якщо який-небудь міст відмовляє (викликаючи зміну в топології), то сусідні мости незабаром виявляють відсутність повідомлень конфігурації і ініціюють перерахунок сполучного дерева.
Мости ТВ обмінюються повідомленнями конфігурації (configuration messages) і повідомленнями про зміну в топології (topology change). Мости обмінюються повідомленнями конфігурації для встановлення топології мережі. Повідомлення про зміну топології відправляються після виявлення якого-небудь зміни в топології для вказівки того, що повинен бути проведений повторний прогін STA.
Формат повідомлення конфігурації IEEE 802.1d представлений на Рис. 29-5.
Першим полем установок Вам ТВ є поле ідентифікатора протоколу (protocol identifier), яке містить нульове значення.
Другим полем у вигляді повідомлення настройки ТВ є поле версії (version), яке містить нульове значення.
Третім полем в повідомленні ТВ є поле типу повідомлення (message type), яке містить нульове значення.
Четвертим полем у вигляді повідомлення настройки ТВ є однобайтовое поле прапорів (flags). Біт ТС сигналізує про зміну в топології. Біт ТСА встановлюється для підтвердження прийому повідомлення конфігурації з встановленим бітом ТС. Інші шість бітів цього байта не використовуються.
Наступним полем у вигляді повідомлення настройки ТВ є поле ідентифікатора кореневого моста (root ID). Це 8-байтовое поле ідентифікує кореневої міст шляхом перерахування його 2-байтового пріоритету, за яким слід його 6-байтовий ID.
За полем ID кореневого моста йде поле витрат кореневого тракту (root path cost), яке містить витрати тракту від моста, який відправляє конфигурационное повідомлення, до кореневого моста.
Далі йде поле ідентифікатора моста (bridge ID), яке ідентифікує пріоритет і ID моста, що відправляє повідомлення.
Поле ідентифікатора порту (port ID) ідентифікує порт, з якого відправлено конфигурационное сообщшеніе. Це поле дозволяє виявляти і усувати петлі, утворені декількома підключеними мостами.
Поле віку повідомлення (message age) визначає проміжок часу, що пройшов з моменту відправки кореневих мостом конфігураційного повідомлення, на якому базується поточний конфигурационное повідомлення.
Поле максимального віку (maximum age) вказує, коли поточний конфигурационное повідомлення повинно бути стерто.
Поле часу вітання (hello time) забезпечує період часу між конфігураційними повідомленнями кореневого моста.
І нарешті, поле затримки просування (forward delay) забезпечує проміжок часу, протягом якого мости повинні вичікувати, перш ніж перейти в новий стан після зміни в топології. Якщо переходи якогось моста відбуваються занадто швидко, то не всі канали мережі можуть виявитися готовими для зміни їх станів, в результаті чого можуть з'явитися петлі.
Повідомлення про топологічних змінах складаються всього з 4 байтів. Вони включають в себе поле ідентифікатора протоколу (protocol identifier), яке містить нульове значення, поле версії (version), яке містить нульове значення і поле типу повідомлення (message type), яке містить значення 128.
Версія: 0.1
Даний документ підготовлений для HTML версії Володимиром Плешаковим.
Vladimir Pleshakov. [email protected]. Малюнки Володимир Чепик.
Vladimir Chepikov. [email protected].