Протокол STP дозволяє фізично надлишкові топології в деревовидні топології без петель. Найбільша проблема протоколу STP полягає в тому, що деякі відмови устаткування можуть викликати збій цього протоколу. Такий збій призводить до утворення петель пересилання (або петель STP). Петлі STP викликають серйозні перебої в роботі мережі.
В даному документі описана функція захисту від петель STP, призначена для підвищення стабільності мереж рівня 2 (L2). У ній також наведено функція виявлення втрати BPDU. Функція виявлення втрати BPDU є засіб діагностики, яке створює повідомлення системного журналу, якщо пакети BPDU не отримані в належний термін.
Цей документ не має жорсткої прив'язки до яких-небудь конкретних версій програмного забезпечення і устаткування.
Функція захисту від петель STP була вперше реалізована в CatOS версії 6.2.1 програми Catalyst для платформ Catalyst 4000 і Catalyst 5000 і в версії 6.2.2 для платформи Catalyst 6000.
Функція виявлення втрати BPDU вперше реалізована в CatOS версії 6.2.1 програми Catalyst для платформ Catalyst 4000 і Catalyst 5000 і в версії 6.2.2 для платформи Catalyst 6000.
Функція захисту від петель STP вперше реалізована в ПО Cisco IOS випуску 12.1 (12c) EW для комутаторів Catalyst 4500 і в ПО Cisco IOS випуску 12.1 (11b) EX для Catalyst 6500.
Функція виявлення втрати BPDU не підтримує комутаторами Catalyst з системним ПО Cisco IOS.
Для внутрішніх цілей протокол STP кожному порту моста (або комутатора) призначає роль на основі конфігурації, топології, відносного положення порту в топології та інших факторів. Роль порту визначає поведінку порту з точки зору протоколу STP. Залежно від призначеної ролі порт або відправляє, або приймає пакети BPDU протоколу STP і пересилає або блокує трафік даних. У наступному списку наведено короткий опис кожної ролі порту STP:
Призначений. Для кожного з'єднання (сегмента) вибирається один призначений порт. Призначений порт - це порт, найближчий до кореневого мосту. Цей порт відправляє пакети BPDU по цьому з'єднанню (сегменту) і пересилає трафік на кореневої міст. У мережі з топологією збіжності STP всі призначені порти знаходяться в стані пересилання STP.
Кореневої. Біля мосту може бути тільки один кореневий порт. Кореневої порт - це порт, що веде до кореневого мосту. У мережі з топологією збіжності STP кореневої порт знаходиться в стані пересилання STP.
Альтернативний. Альтернативні порти ведуть до кореневого мосту, але не є кореневими портами. Альтернативні порти підтримують стан блокування STP.
Резервний. Це особливий випадок, коли два або більше портів одного моста (комутатора) пов'язані між собою безпосередньо або через загальний носій. У цьому випадку один порт є призначеним, а інші порти блокуються. Такий порт має роль резервного.
Функція захисту від петель STP забезпечує додатковий захист від петель пересилання на рівні 2 (петель STP). Петля STP утворюється, коли заблокований порт STP в надлишкової топології помилково переходить в стан пересилки. Зазвичай причина цього в тому, що один з портів фізично надлишкової топології (не обов'язково заблокований порт STP) перестає отримувати пакети BPDU протоколу STP. Робота протоколу STP залежить від безперервного прийому і передачі пакетів BPDU на основі ролі порту. Призначений порт передає пакети BPDU, а непризначений порт отримує пакети BPDU.
Коли один з портів в фізично надлишкової топології перестає приймати пакети BPDU, протокол STP вважає таку топологію як топологію без петель. В результаті заблокований порт з альтернативного або резервного порту перетворюється в призначений і переходить в стан пересилки. У такій ситуації утворюється петля.
Функція захисту від петель виконує додаткові перевірки. Якщо пакети BPDU більше не приймаються непризначеним портом, а захист від петель включена, то такий порт переводиться в стан блокування внаслідок можливості петлі STP, а не в стан прослуховування, самонавчання (learning) або пересилання. Без функції захисту від петель порт приймає роль призначеного порту. Порт переходить в стан пересилання STP і формує петлю.
Коли захист від петель блокує неузгоджений порт, в журналі реєструється наступне повідомлення:
Коли пакет BPDU приймається портом в стані блокування внаслідок можливості петлі STP, цей порт переходить в інший стан STP. Відповідно до отриманої блоку BPDU це означає, що відновлення виконано автоматично і втручання не потрібно. Після відновлення в журналі реєструється наступне повідомлення:
Щоб проілюструвати це поведінка, розглянемо наступний приклад:
Комутатор A є кореневим комутатором. Комутатор C не отримує пакети BPDU від комутатора B через збій односпрямованого з'єднання між комутатором B і комутатором C.
Без захисту від петель заблокований порт STP на комутаторі C переходить в стан прослуховування STP після закінчення часу, що задається таймером max_age, а потім переходить в стан пересилання через проміжок, рівний подвоєному значенню forward_delay. У такій ситуації утворюється петля.
Коли функція захисту від петель включена, після обнулення таймера max_age заблокований порт на комутаторі C переходить в стан блокування внаслідок можливості петлі STP. Порт в стані блокування внаслідок можливості петлі STP не зрадив користувача трафік, тому петля не утворюється. (Стан блокування внаслідок можливості петлі фактично еквівалентно станом блокування.).)
Функція захисту від петель включається для кожного порту окремо. Однак оскільки функція захисту від петель блокує порт на рівні STP, вона блокує неузгоджені порти для кожної VLAN окремо (оскільки протокол STP налаштований окремо для кожної VLAN). Значить, якщо пакети BPDU не приймаються на магістральному порту тільки однієї окремої VLAN, то блокується тільки ця VLAN (переводиться в стан блокування внаслідок можливості петлі STP). З цієї ж причини, якщо ця функція включена в інтерфейсі EtherChannel, блокується весь канал окремої VLAN, а не тільки одне з'єднання (так як EtherChannel з точки зору протоколу STP є одним логічним портом).
На яких портах повинна бути включена захист від петель? Найбільш очевидна відповідь: на заблокованих портах. Однак це не зовсім вірно. Захист від петель повинна бути включена на непризначених портах (точніше, на кореневих і альтернативних портах) для всіх можливих комбінацій активних топологій. Оскільки захист від петель не встановлюється для кожної VLAN окремо, один і той же (магістральний) порт може бути призначеним в одній мережі VLAN (VLAN) і непризначеним в інший. Слід також враховувати можливі сценарії переходу на інший ресурс при збої.
Розглянемо наступний приклад:
За замовчуванням захист від петель відключена. Для включення захисту від петель використовується наступна команда:
Починаючи з версії 7.1 (1) ПО Catalyst (CatOS), захист від петель може включатися глобально на всіх портах. Фактично захист від петель включається на всіх з'єднаннях "точка-точка". З'єднання "точка-точка" визначається станом дуплексной передачі з'єднання. Якщо налаштований повнодуплексний режим, з'єднання вважається з'єднанням "точка-точка". Ще можна налаштувати або перевизначити глобальні настройки для кожного порту окремо.
Щоб включити захист від петель глобально, виконайте наступну команду:
Щоб відключити захист від петель, виконайте наступну команду:
Залежно від конкретних особливостей проекту можна вибрати функцію UDLD або захист від петель. Відносно протоколу STP найбільш помітна різниця між цими двома функціями полягає в відсутності у UDLD захисту від збоїв STP, викликаних проблемами ПО. В результаті виділений комутатор не надсилає пакети BPDU. Однак збої такого типу відбуваються (у десятки разів) рідше, ніж збої, викликані односпрямованим сполуками. У свою чергу, функція UDLD може бути більш гнучкою в разі односпрямованих з'єднань в EtherChannel. В цьому випадку UDLD відключає тільки несправні з'єднання, а канал зберігає працездатність за рахунок решти сполук. При такому збої захист від петель переводить порт в стані блокування внаслідок можливості петлі, щоб блокувати весь канал.
Крім того, захист від петель не діє на спільно використовуваних з'єднаннях і в ситуаціях, коли з моменту з'єднання з'єднання є односпрямованим. В останньому випадку порт ніколи не отримує блоки BPDU і стає призначеним. Так як така поведінка може бути нормальним, цей випадок не охоплюється захистом від петель. Захист від такого сценарію надає UDLD.
Як уже відзначено, найвищий рівень захисту забезпечується, коли включені функції UDLD і захисту від петель.
Захист кореня дерева STP
Функції захисту кореня дерева STP і захисту від петель є взаємовиключними. Захист кореня дерева STP використовується на призначених портах і не дозволяє порту змінювати стан. Захист від петель діє на непризначених портах і дозволяє порту ставати призначеним після закінчення терміну max_age. Захист кореня дерева STP можна включити для порту, на якому включена захист від петель. Коли для порту включається захист від петель, вона відключає налаштовану на цьому порте захист кореня дерева STP.
Функції uplink fast і backbone fast
Функції uplink fast і backbone fast прозорі для захисту від петель. Коли під час повторної конвергенції функція backbone fast пропускає max_age, це не викликає спрацьовування захисту від петель. Додаткову інформацію про функції uplink fast і backbone fast см. В наступних документах:
PortFast і захист BPDU і динамічна віртуальна ЛЗ
Захист від петель не можна включити для портів, на яких включена функція PortFast. Так як захист BPDU діє на портах з активним з'єднанням portfast, до захисту BPDU застосовуються деякі обмеження. Захист від петель не можна включити на портах динамічної віртуальної мережі, так як на таких портах вже включена функція portfast.
Спільно використовувані з'єднання
Захист від петель не слід включати на спільно використовуваних з'єднаннях. Якщо захист від петель включити на спільно використовуваних з'єднаннях, то трафік від вузлів, підключених до загальних сегментам, може блокуватися.
Множинні сполучні дерева (MST)
Захист від петель правильно функціонує в середовищі MST.
Виявлення втрати BPDU
Функція захисту від петель повинна правильно взаємодіяти з функцією виявлення втрати BPDU.
Робота протоколу STP сильно залежить від своєчасного отримання пакетів BPDU. При кожному повідомленні hello_time message (за замовчуванням кожні 2 секунди) кореневої міст відправляє пакети BPDU. Некореневі мости не створюють пакети BPDU заново для кожного повідомлення hello_time, а приймають пакети BPDU, що ретранслюють від кореневого моста. Тому кожен некорневой міст повинен отримувати пакети BPDU в кожної VLAN для кожного повідомлення hello_time. У деяких випадках губляться BPDU або CPU моста занадто зайнятий, щоб передавати BPDU своєчасно. Такі або інші проблеми можуть викликати запізнення пакетів BPDU (якщо вони взагалі виходять). Ця проблема може порушити стабільність топології STP.
Виявлення втрати BPDU дозволяє комутатора відстежувати запізнілі пакети BPDU і повідомляти адміністратора за допомогою повідомлень системного журналу. Для кожного порту, для якого будь-коли було зафіксовано запізнення (або спотворення) пакета BPDU, функція виявлення затримки повідомить про самої останньої затримки із зазначенням її тривалості. Вона також вказує максимальну тривалість затримки блоку BPDU для цього конкретного порту.
Щоб захистити ЦП моста від перевантаження, повідомлення системного журналу створюється не за будь-якої затримки пакета BPDU. Частота створення повідомлень обмежується одним повідомленням кожні 60 секунд. Однак якщо затримка BPDU перевищує значення max_age, поділене на 2 (що за замовчуванням дорівнює 10 с), повідомлення друкується негайно.
Примітка: Виявлення втрати BPDU - це функція діагностики. При виявленні затримки пакетів BPDU вона відправляє повідомлення системного журналу. Функція виявлення втрати BPDU не виконує ніяких інших коригувальних дій.
Приклад повідомлення системного журналу, створеного функцією виявлення втрати BPDU:
Виявлення втрати BPDU налаштовується для кожного комутатора окремо. За замовчуванням ця функція відключена. Щоб увімкнути визначення втрати BPDU, виконайте наступну команду: