Протоколи маршрутизації RIP і OSPF

МОСКОВСЬКИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ ЗВ'ЯЗКУ ТА ІНФОРМАТИКИ

Курсова робота

з дисципліни «Локальні Обчислювальні Мережі»

на тему

«Внутрішні протоколи маршрутизації RIP і OSPF»

Москва 2009

Внутрішній протокол маршрутизації RIP (Routing Information Protocol)

Призначення

Протокол маршрутизації RIP (Routing Information Protocol) відноситься до алгоритмів класу «distance vector» (алгоритм Белмана-Форда). Цей алгоритм є одним з перших алгоритмів маршрутизації, які були використані в інформаційно - обчислювальних мережах взагалі та в мережі Internet - зокрема. Проте він до цих пір надзвичайно поширений в обчислювальних мережах. Крім версії RIP для мереж TCP / IP, існує також версія RIP для мереж IPX / SPX компанії Novell.

Цей протокол маршрутизації призначений для порівняно невеликих і щодо однорідних мереж. Протокол розроблений в університеті Каліфорнії (Берклі), базується на розробках фірми Ксерокс та реалізує ті ж принципи, що і програма маршрутизації routed, використовувана в ОC UNIX (4BSD). Маршрут тут характеризується вектором відстані до місця призначення. Передбачається, що кожен маршрутизатор є відправною точкою декількох маршрутів до мереж, з якими він пов'язаний. З 1988 року RIP був повсюдно прийнятий виробниками персональних комп'ютерів для використання в їх виробах передачі даних по мережі.

Рішення, знайдене за алгоритмом Белмана-Форда, є не оптимальним, а близьким до оптимального. Перевагою протоколу RIP є його обчислювальна простота і простота конфігурування, а недоліками - збільшення трафіку при періодичній розсилці широкомовних пакетів і неоптимальність знайденого маршруту.

У сучасних мережевих середовищах RIP - не найкраще рішення для вибору в якості протоколу маршрутизації, так як його можливості поступаються більш сучасним протоколів, таких як EIGRP, OSPF. Присутній обмеження на 15 хопов, яке не дає застосовувати його у великих мережах.

Архітектура

RIP працює на основі UDP протоколу і використовує порт 520. На кожному хості, що використовує RIP, повинно бути встановлено програмне забезпечення, обробляє RIP пакети. Налаштувати роботу протоколу на маршрутизаторі можна за допомогою того ж Hyper Terminal з робочої станції, що має на це право і доступ. Установки проводиться за допомогою команд відповідно з документацією до маршрутизатора.

Приклад коректної роботи протоколу

(На малюнку: маршрутизатори 1-6, сегменти мереж A .. F; наведена початкова інформація в маршрутизаторі 2 і інформація в ньому після двох ітерацій обміну маршрутними пакетами RIP; після певного числа ітерацій маршрутизатор буде знати про відстані до всіх сегментів, а також альтернативні маршрути)

Нехай мережею призначення є сегмент D. При необхідності відправити пакет у мережу D маршрутизатор переглядає свою базу даних маршрутів і вибирає порт, що має найменше відстані до мережі призначення (у даному випадку порт, що зв'язує його з маршрутизатором 3).

Для адаптації до зміни стану зв'язків та обладнання з кожним записом таблиці маршрутизації пов'язаний таймер. Якщо за час тайм-ауту не прийде нове повідомлення, яке підтверджує цей маршрут, то він видаляється з маршрутної таблиці.

Приклад нестійкої роботи по протоколу (відстеження змін в топології)

(На малюнку: маршрутизатори M 1 .. M 3; при працездатному стані в таблиці маршрутів кожного маршрутизатора є запис про мережі 1 та відповідний відстані до неї; далі розглянемо випадок обриву лінії зв'язку між мережею 1 і маршрутизатором M 1).

При обриві зв'язку з мережею 1 маршрутизатор М1 зазначає, що відстань до цієї мережі взяло значення 16. Проте отримавши через деякий час від маршрутизатора М2 маршрутне повідомлення про те, що від нього до мережі 1 відстань складає 2 хопу, маршрутизатор М1 нарощує це відстань на 1 і відзначає, що мережа 1 досяжна через маршрутизатор 2. У результаті пакет, призначений для мережі 1, буде циркулювати між маршрутизаторами М1 і М2 до тих пір, поки не закінчиться час зберігання запису про мережу 1 в маршрутизаторі 2, і він не передасть цю інформацію маршрутизатора М1.

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

Існують і інші, більш складні випадки нестабільного поведінки мереж, що використовують протокол RIP, при змінах в стані зв'язків або маршрутизаторів мережі.

Приклад нестійкої роботи по протоколу (виникнення циклічних маршрутів - процедура split horizon).

У вихідному стані всі канали передачі даних функціонують нормально і, тому, маршрути з вузлів D і C до мережі N лежать через маршрутизатор B і мають метрику 2.

Припустимо, що в деякий момент часу канал, який пов'язує маршрутизатори A і В, виходить з ладу. Маршрутизатор B в цьому випадку перестає приймати update для мережі N від маршрутизатора A і після закінчення встановленого інтервалу часу маршрутизатор B визначає мережу N в якості недосяжною і виключає її зі своїх масивів update.

Однак через те, що ці масиви передаються в мережі асинхронно цілком можливо, що незабаром після цього маршрутизатор C отримає масивів update від маршрутизатора D, який поки ще вважає, що маршрут з B до мережі N існує. Отримавши таку інформацію, маршрутизатор C включить в свою таблицю маршрутизації новий маршрут до мережі N - через маршрутизатор D з метрикою 3. Після того, як мине час існування вихідного маршруту в маршрутизаторі D, ця ситуація повториться абсолютно аналогічним чином.

У результаті маршрутизатор D скоректує свою таблицю маршрутизації і внесе до неї маршрут до мережі N через шлюз C з метрикою 4. Подібна ситуація буде таким чином поновлюватися знову і знову з періодом, який відповідає часу існування маршруту (3 T Update). Цей цикл, який називається «рахунок до безкінечності», буде тривати до тих пір, поки метрика циклічного маршруту не досягне значення 15, після чого він розірветься автоматично.

Правило split horizon (запобігання виникнення циклічних маршрутів)

Алгоритм split horizon є невід'ємною частиною протоколу маршрутизації RIP і призначений для запобігання появи циклічних маршрутів у мережі. Для запобігання виникнення подібних ситуацій досить використовувати наступне правило:

Маршрутизатор не повинен направляти update для маршрутів на адресу їхнього джерела.

За цим правилом закріпилася назва split horizon - розщеплений горизонт. Маршрутизатор, використовуючи дане правило, поділяє свої маршрути на стільки груп, скільки у нього є активних інтерфейсів. При використанні правила split horizon, оновлення для маршрутів, які були отримані через деякий інтерфейс, не повинні передаватися через цей же інтерфейс.

Правило split horizon with poisoned reverse

Правило split horizon може бути використано з незначною модифікацією. Правило split horizon with poisoned reverse «розщеплений горизонт з отруєним зворотним шляхом» - дозволяє передачу update для потенційно небезпечних, з точки зору виникнення циклів, маршрутів. У даному випадку для таких маршрутів установлюється метрика, яка відповідає нескінченності - 15.

Приклад нестійкої роботи по протоколу (процедура triggered update - керовані модифікації)

Використання процедури Split horizon дозволяє уникнути появи зацикленого маршруту у двох шлюзів. Однак можливе виникнення ситуації, коли в циклічному маршруті беруть участь три шлюзи.

На малюнку наведено приклад виникнення подібної ситуації. У наведеній мережі при виході з ладу каналу, який зв'язує вузол А з мережею N, маршрутизатор B може прийняти від маршрутизатора З неіснуючий маршрут до мережі N, який нібито проходить через вузол C. До того моменту, коли маршрутизатор C визначить, що він не має власного маршруту до мережі N, маршрутизатор B вже встигне передати інформацію про наявність у нього маршруту до цієї мережі марщрутізатору D.

Використання процедури Split horizon не зможе запобігти появі такої петлі, оскільки повідомлення про маршрут надходять не від того маршрутизатора, якому передаються повідомлення update. Отже, ця петля буде розірвана тільки тоді, коли метрика циклічного маршруту сягає безкінечності. Для того щоб зменшити час перехідних процесів в мережі, можна використовувати процедуру керованих модифікацій (triggered update).

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

Приклад нестійкої роботи по протоколу
(Лічильник часу timeout - timer)

Можливе виникнення ситуації, коли періодичне оновлення буде просто втрачено в мережі через виникнення короткостроковій перевантаження або тимчасової непрацездатності каналу передачі даних. Для того щоб у цій ситуації маршрути не були помилково видалені з таблиці маршрутизації, кожному маршруту ставиться у відповідність спеціальний лічильник часу, який називається timeout - timer. У той момент часу, коли даний маршрут включається в таблицю маршрутизації, або коли для нього приходить чергове оновлення значення лічильника timeout - timer встановлюється рівним T _{timeout max.} = 180 секунд і цей лічильник починає зворотний відлік часу. У тому випадку, якщо лічильник timeout - timer якого або маршруту досягне значення 0, цей маршрут повинен бути виключений з числа активних маршрутів.

Протокол RIP не забезпечує вирішення всіх можливих проблем, які можуть виникнути в процесі визначення маршруту в мережах передачі даних. Як вже згадувалося вище, в першу чергу він призначений для використання в якості IGP в гомогенних мережах невеликого розміру. Крім того, використання даного протоколу призводить до появи специфічних обмежень на параметри мережі, в якій він може бути використаний.

Обмеження максимальної довжини маршруту

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

Зациклення маршрутів

Використання протоколу RIP може в ряді випадків призвести до появи «зациклених маршрутів». Для запобігання виникнення подібних ситуацій повинні бути використані спеціальні заходи (poison reverse, split horizon).

Формат метрики

Для порівняння маршрутів протокол RIP використовує досить просту «метрику» - число переходів. Проте використання даного критерію в цілому ряді випадків не може забезпечити оптимальний вибір маршруту.

Специфікації

• RFC 1388. Протокол RIP 2 (1993 рік) є новою версією RIP, яка на додаток до широковещательному режиму підтримує мультікастінга; дозволяє працювати з масками субсетей.

• RFC 1582. Розширення до RIP за вимогами до хостів до підтримки певних параметрів.

• RFC 1721. Аналіз протоколу RIP версії 2.

• RFC 1722 (STD 0057). Протокол RIP версії 2, припис до застосування.

• RFC 1724. Протокол RIP версії 2, розширення по MIB (база керуючої інформації - management information base).

• RFC 2080. Специфікації протоколу RIP для IPv 6.

• RFC 2082. Протокол RIP версії 2, проблеми аутентифікації з використанням MD5 (Message Digest 5) - 128 бітний алгоритмом хешування, розроблений в 1991 році. MD 5 призначений для створення «відбитків» або «дайджестів» повідомлень довільної довжини.

• RFC 2092. Специфікація для автоматично запускається протоколу RIP (triggered RIP).

• RFC 2453 (STD 0056). Загальний опис протоколу другої версії.

Реалізація протоколу.

Існують дві версії протоколу RIP: RIP 1 і RIP 2. Версія 2 має деякі удосконалення, як то: можливість маршрутизації мереж за моделлю CIDR (крім адреси мережі передається і маска), підтримка мультікастінга, можливість використання аутентифікації RIP повідомлень і ін

Типи і формат повідомлень.

У протоколі RIP є два типи повідомлень, якими обмінюються маршрутизатори:

• відповідь (response) - розсилка вектора відстаней;

• запит (request) - маршрутизатор (наприклад, після своєї завантаження) запитує у сусідів їхні маршрутні таблиці або дані про певному маршруті.

Формат повідомлень обох типів однаковий:

Поля, помічені знаком *, ставляться до версії 2; в повідомленнях RIP 1 ці поля повинні бути обнулені.

Повідомлення RIP складається з 32 бітного слова, що визначає тип повідомлення і версію протоколу (плюс «Routing Domain» у версії 2), за яким йде набір з одного і більше елементів вектора відстаней. Кожен елемент вектора відстаней займає 5 слів (20 октетів) (від початку поля «Address Family Identifier» до кінця поля «Metric» включно). Максимальне число елементів вектора - 25, якщо вектор довше, він може розбиватися на декілька повідомлень.

• Поле «Command» визначає тип повідомлення: 1 - request, 2 - response; полі «Version» - версію протоколу (1 або 2).

• Поле «Address Family Identifier» містить значення 2, яке позначає сімейство адрес IP; інші значення не визначені. Поля «IP address» і «Metric» містять адресу мережі і відстань до неї.

Додатково до полів версії 1 у другій версії визначені наступні.

• «Routing Domain» - ідентифікатор RIP системи, до якої належить дане повідомлення, часто - номер автономної системи. Використовується, коли до одного фізичного каналу підключені маршрутизатори з кількох автономних систем, в кожній автономній системі підтримується своя таблиця маршрутів. Оскільки повідомлення RIP розсилаються всім маршрутизаторам, підключеним до мережі, потрібно розрізняти повідомлення, пов'язані з «своєї» і «чужий» автономних систем.

• «Route Tag» - використовується як мітка для зовнішніх маршрутів при роботі з протоколами зовнішньої маршрутизації.

• «Subnet Mask» - маска мережі, адреса якої міститься в полі IP address. RIP 1 працює тільки з класовою моделлю адрес.

• «Next Hop» - адреса наступного маршрутизатора для даного маршруту, якщо він відрізняється від адреси маршрутизатора, що послав дане повідомлення. Це поле використовується, коли до одного фізичного каналу підключені маршрутизатори з кількох автономних систем і, отже, деякі маршрутизатори «чужий» автономної системи фізично можуть бути досягнуті безпосередньо, минаючи прикордонний (логічно підключений до обох автономних систем) маршрутизатор. Про це прикордонний маршрутизатор і оголошує в полі «Next Hop».

Адреса 0.0.0.0 в повідомленні типу «відповідь» позначає маршрут, що веде за межі RIP системи. У повідомленні типу «запит» цю адресу означає запит інформації про всіх маршрутах (повного вектора відстаней). Вказівка ​​в повідомленні типу «запит» адреси конкретної мережі означає запит елемента вектора відстаней тільки для цієї мережі - такий режим використовується зазвичай тільки в налагоджувальних цілях.

Аутентифікація може проводитися протоколом RIP 2 для обробки тільки тих повідомлень, які містять правильний аутентифікаційні код. При роботі в такому режимі перший 20 октетний елемент вектора відстаней, наступний безпосередньо за першим 32 бітовим словом RIP повідомлення, є сегментом аутентифікації. Він визначається за значенням поля «Address Family Identifier», рівному в цьому випадку 0xFFFF. Наступні 2 октети цього елемента визначають тип аутентифікації, а решта 16 октетів містять аутентифікаційні код. Таким чином, в RIP повідомленні з аутентифікацією може передаватися не 25, а тільки 24 елемента вектора відстаней, які слідують за сегментом аутентифікації. До справжнього моменту надійного алгоритму аутентифікації для протоколу RIP не розроблено; стандартом визначена тільки аутентифікація за допомогою звичайного пароля (значення поля «Тип» дорівнює 2).

Робота протоколу RIP

Для кожного запису в таблиці маршрутів існує час життя, контрольоване таймером. Якщо для будь-якої конкретної мережі, внесеної в таблицю маршрутів, протягом 180 з не отримано вектор відстаней, що підтверджує або встановлює нове відстань до даної мережі, то мережа буде відзначена як недосяжна (відстань дорівнює нескінченності). Через певний час модуль RIP виробляє «збірку сміття» - видаляє з таблиці маршрутів всі мережі, відстань до яких нескінченно.

При отриманні повідомлення типу «відповідь» для кожного міститься в ньому елемента вектора відстаней модуль RIP виконує наступні дії:

• перевіряє коректність адреси мережі і маски, зазначених у повідомленні;

• перевіряє, чи не перевищує метрика (відстань до мережі) нескінченності;

• некоректний елемент ігнорується;

• якщо метрика менше нескінченності, вона збільшується на 1;

• проводиться пошук мережі, яка вказана в розглянутому елементі вектора відстаней, в таблиці маршрутів;

• якщо запис про таку мережі в таблиці маршрутів відсутня і метрика в отриманому елементі вектора менше нескінченності, мережа вноситься в таблицю маршрутів з зазначеної метрикою; в поле «Наступний маршрутизатор" заноситься адреса маршрутизатора, який надіслав повідомлення; запускається таймер для цього запису в таблиці;

• якщо шукана запис присутній в таблиці з метрикою більше, ніж оголошена в отриманому векторі, в таблицю вносяться нові метрика і, відповідно, адреса наступного маршрутизатора; таймер для цього запису перезапускається;

• якщо шукана запис присутній в таблиці і відправником отриманого вектора був маршрутизатор, зазначений у полі «Наступний маршрутизатор» цього запису, то таймер для цього запису перезапускається, більше того, якщо при цьому метрика в таблиці відрізняється від метрики в отриманому векторі відстаней, в таблицю вноситься значення метрики з отриманого вектора;

• у всіх інших випадках розглянутий елемент вектора відстаней ігнорується.

Повідомлення типу «відповідь» розсилаються модулем RIP кожні 30 сек. по широковещательному або мультікастінговому (тільки RIP 2) адресою; розсилка «відповіді» може відбуватися також поза графіком, якщо маршрутна таблиця була змінена (triggered response). Стандарт вимагає, щоб triggered response розсилався не негайно після зміни таблиці маршрутів, а через випадковий інтервал тривалістю від 1 до 5 с. Цей захід дозволяє дещо понизити навантаження на мережу.

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

У разі triggered response надсилається інформація тільки про тих мережах, записи про які були змінені.

Інформація про мережах з нескінченною метрикою посилається тільки в тому випадку, якщо вона була нещодавно змінена.

При отриманні повідомлення типу «запит» з адресою 0.0.0.0 маршрутизатор розсилає у відповідну мережу звичайне повідомлення типу відповідь. При отриманні запиту з будь-яким іншим значенням у полі (полях) «IP Address» посилається відповідь, що містить інформацію тільки про мережі, які вказані. Така відповідь надсилається на адресу запросила маршрутизатора (не широкомовно).

Налаштування протоколу RIP (логи)

<Quidway>

% May 12 16:08:13:801 2009 Quidway SHELL/5/LOGIN: Console login from con0

<Quidway> Vrbd

Routing Platform Software

Version AR28-10 8040V300R003B03D040 (COMWAREV300R002B60D021), RELEASE SOFTWARE

Compiled Apr квітня 2006 14:35:29 by Houming

<Quidway> Display rip

RIP is running

public net

Checkzero is on Default cost: 1

Summary is on Preference: 100

Validate-source-address is on

Traffic-share-across-interface is off

Period update timer: 30

Timeout timer: 180

Garbage-collection timer: 120

No peer router

Network:

192.168.1.0

<Quidway> Su

User privilege level is 3, and only those commands can be used

whose level is equal or less than this.

Privilege note: 0 VISIT, 1 MONITOR, 2 SYSTEM, 3 MANAGE

<Quidway> System-view

System View: return to User View with Ctrl + Z.

% May 12 16:24:58:322 2009 Quidway PHY/2/PHY: Ethernet0 / 0: change status to up

% May 12 16:24:58:322 2009 Quidway IFNET/5/UPDOWN: Line protocol on the interface

Ethernet0 / 0 is UP

[Quidway] interface Ethernet 0 / 0

[Quidway-Ethernet0 / 0] display ip interface

Aux0 current state: Administratively DOWN

Line protocol current state: DOWN

Internet Address is 172.16.0.2/24

Broadcast address: 172.16.0.255

The Maximum Transmit Unit: 1500 bytes

ip fast-forwarding incoming packets state is Disabled

ip fast-forwarding outgoing packets state is Disabled

ip multicast-fast-forwarding packets state is Disabled

IP packets input number: 0, bytes: 0, multicasts: 0

IP packets output number: 0, bytes: 0, multicasts: 0

TTL invalid packet number: 0

ICMP packet input number: 0

Echo reply: 0

Unreachable: 0

Source quench: 0

Routing redirect: 0

Echo request: 0

Router advert: 0

Router solicit: 0

Time exceed: 0

IP header bad: 0

Timestamp request: 0

Timestamp reply: 0

Information request: 0

Information reply: 0

Netmask request: 0

Netmask reply: 0

Unknown type: 0

Ethernet0 / 0 current state: UP

Line protocol current state: UP

Internet Address is 192.168.1.5/24

Broadcast address: 192.168.1.255

The Maximum Transmit Unit: 1500 bytes

ip fast-forwarding incoming packets state is Enabled

ip fast-forwarding outgoing packets state is Enabled

ip multicast-fast-forwarding packets state is Disabled

IP packets input number: 15, bytes: 4920, multicasts: 0

IP packets output number: 0, bytes: 0, multicasts: 0

ARP packets input number: 35

Request packet: 35

Reply packet: 0

Unknown packet: 0

TTL invalid packet number: 0

ICMP packet input number: 0

Echo reply: 0

Unreachable: 0

Source quench: 0

Routing redirect: 0

Echo request: 0

Router advert: 0

Router solicit: 0

Time exceed: 0

IP header bad: 0

Timestamp request: 0

Timestamp reply: 0

Information request: 0

Information reply: 0

Netmask request: 0

Netmask reply: 0

Unknown type: 0

DHCP packet

[Quidway] ping 192.168.1.10

PING 192.168.1.10: 56 data bytes, press CTRL_C to break

Reply from 192.168.1.10: bytes = 56 Sequence = 1 ttl = 64 time = 2 ms

Reply from 192.168.1.10: bytes = 56 Sequence = 2 ttl = 64 time = 1 ms

Reply from 192.168.1.10: bytes = 56 Sequence = 3 ttl = 64 time = 2 ms

Reply from 192.168.1.10: bytes = 56 Sequence = 4 ttl = 64 time = 1 ms

Reply from 192.168.1.10: bytes = 56 Sequence = 5 ttl = 64 time = 2 ms

- 192.168.1.10 ping statistics -

5 packet (s) transmitted

5 packet (s) received

0.00% packet loss

round-trip min / avg / max = 1/1/2 ms

deal mode: global

[Quidway] rip

[Quidway-rip] display rip

RIP is running

public net

Checkzero is on Default cost: 1

Summary is on Preference: 100

Validate-source-address is on

Traffic-share-across-interface is off

Period update timer: 30

Timeout timer: 180

Garbage-collection timer: 120

No peer router

[Quidway-rip] network 192.168.0.0

[Quidway-rip] display rip

RIP is running

public net

Checkzero is on Default cost: 1

Summary is on Preference: 100

Validate-source-address is on

Traffic-share-across-interface is off

Period update timer: 30

Timeout timer: 180

Garbage-collection timer: 120

No peer router

Network:

192.168.0.0

[Quidway-rip] peer 192.168.1.10

[Quidway-rip] display rip

RIP is running

public net

Checkzero is on Default cost: 1

Summary is on Preference: 100

Validate-source-address is on

Traffic-share-across-interface is off

Period update timer: 30

Timeout timer: 180

Garbage-collection timer: 120

Peer:

192.168.1.10

Network:

192.168.0.0

[Quidway-rip] undo peer 192.168.1.10

[Quidway-rip] display rip

RIP is running

public net

Checkzero is on Default cost: 1

Summary is on Preference: 100

Validate-source-address is on

Traffic-share-across-interface is off

Period update timer: 30

Timeout timer: 180

Garbage-collection timer: 120

No peer router

Network:

192.168.0.0

[Quidway-rip]

Quidway-rip] filter-policy gateway 192.168.1.10 import

The gateway does not exist, but the configuration is saved

[Quidway-rip] display rip

RIP is running

public net

Checkzero is on Default cost: 1

Checkzero is on Default cost: 1

Validate-source-address is on

Traffic-share-across-interface is off

Period update timer: 30

Timeout timer: 180

Garbage-collection timer: 120

No peer router

Network:

192.168.0.0

filter-policy gateway 192.168.1.10 import

[Quidway-rip] undo filter-policy gateway 192.168.1.10 import

[Quidway-rip] display rip

RIP is running

public net

Checkzero is on Default cost: 1

Summary is on Preference: 100

Validate-source-address is on

Traffic-share-across-interface is off

Period update timer: 30

Timeout timer: 180

Garbage-collection timer: 120

No peer router

Network:

192.168.0.0

[Quidway-rip] display rip

RIP is running

public net

Checkzero is on Default cost: 1

Host-route is off

Summary is on Preference: 100

Validate-source-address is on

Traffic-share-across-interface is off

Period update timer: 30

Timeout timer: 180

Garbage-collection timer: 120

No peer router

Network:

192.168.0.0

[Quidway-rip] host-route

[Quidway-rip] undo summary

[Quidway-rip] display rip

RIP is running

public net

Checkzero is on Default cost: 1

Summary is off Preference: 100

Validate-source-address is on

Traffic-share-across-interface is off

Period update timer: 30

Timeout timer: 180

Garbage-collection timer: 120

No peer router

Network:

192.168.0.0

[Quidway-rip] summary

[Quidway-rip] preference 150

[Quidway-rip] display rip

RIP is running

public net

Checkzero is on Default cost: 1

Summary is on Preference: 150

Validate-source-address is on

Traffic-share-across-interface is off

Period update timer: 30

Timeout timer: 180

Garbage-collection timer: 120

No peer router

Network:

192.168.0.0

[Quidway-rip] preference 100

[Quidway-rip] timers timeout 200

[Quidway-rip] display rip

RIP is running

public net

Checkzero is on Default cost: 1

Summary is on Preference: 100

Validate-source-address is on

Traffic-share-across-interface is off

Period update timer: 30

Timeout timer: 200

Garbage-collection timer: 120

No peer router

Network:

192.168.0.0

[Quidway-rip] timers timeout 180

[Quidway-rip] timers update 1005

[Quidway-rip] display rip

RIP is running

public net

Checkzero is on Default cost: 1

Summary is on Preference: 100

Validate-source-address is on

Traffic-share-across-interface is off

Period update timer: 1005

Timeout timer: 180

Garbage-collection timer: 4020

No peer router

Network:

192.168.0.0

[Quidway-rip] timers update 30

[Quidway-rip] display rip

RIP is running

public net

Checkzero is off Default cost: 1

Summary is on Preference: 100

Validate-source-address is on

Traffic-share-across-interface is off

Period update timer: 30

Timeout timer: 180

Garbage-collection timer: 120

No peer router

Network:

192.168.0.0

<Quidway>

Внутрішній протокол маршрутизації OSPF (Open Shortest Pass First)

Призначення.

Протокол OSPF (Open Shortest Pass First, алгоритми запропоновані Дейкстри) є альтернативою RIP в якості внутрішнього протоколу маршрутизації. OSPF являє собою протокол стану маршруту (в якості метрики використовується - коефіцієнт якості обслуговування). Кожен маршрутизатор має повну інформацію про стан всіх інтерфейсів всіх маршрутизаторів (перемикачів) автономної системи. Він був винайдений для позбавлення мереж, що використовують RIP від таких напастей, як:

1. Циклічні маршрути. Так як в протоколі немає механізмів виявлення замкнутих маршрутів, необхідно або сліпо вірити партнерам, або приймати заходи для блокування такої можливості.

2. Для придушення нестабільностей RIP повинен використовувати мале значення максимально можливого числа кроків (<16).

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

Протокол OSPF являє собою класичний протокол маршрутизації класу Link-State, який забезпечує:

• відсутність обмежень на розмір мережі

• підтримку позакласо мереж

• передачу оновлень маршрутів з використанням адрес типу multicast

• досить велику швидкість встановлення маршруту

• використання процедури authentication при передачі і отримання оновлень маршрутів

Архітектура

OSPF є ієрархічним протоколом маршрутизації з оголошенням стану про канал з'єднання (link-state). Він був спроектований як протокол роботи всередині мережевий області - AS (Autonomous System), яка представляє собою групу маршрутизаторів і мереж, об'єднаних за ієрархічним принципом і перебувають під єдиним управлінням і спільно використовують спільну стратегію маршрутизації. В якості транспортного протоколу для маршрутизації всередині AS OSPF використовує IP протокол.

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

Налаштування на маршрутизаторах проводиться аналогічним чином як при налаштуванні RIP.

Ієрархічна маршрутизація

Використання ієрархічної маршрутизації дозволяє істотно підвищити ефективність використання каналів передачі даних за рахунок скорочення частки переданого по ним службового трафіку.

Інформаційний обмін, який здійснюють маршрутизатори для визначення маршруту передачі даних всередині області, зображений на малюнку зеленими стрілками. Визначення маршруту і інформаційний обмін між областями в даному випадку проводиться через спеціальну центральну область - AREA 0.

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

Розподіл навантаження між паралельними каналами (Load balancing)

При використанні протоколу маршрутизації OSPF допускається існування декількох маршрутів у напрямку деякого вузла мережі. У тому випадку, якщо ці маршрути забезпечують однакову якість передачі даних, інформаційний потік на адресу даного сайту може бути направлений по всім цим каналах одночасно, що забезпечить істотне збільшення швидкості передачі даних. Динамічне перерозподіл трафіку між паралельними каналами, яке виконується пропорційно ступеню завантаженості цих каналів , називається Load balancing.

Ієрархія маршрутизації

На відміну від RIP, OSPF може працювати в межах деякої ієрархічної системи. Найбільшим об'єктом у цій ієрархії є автономна система (Autonomous System - AS) AS є набором мереж, які знаходяться під єдиним управлінням і спільно використовують загальну стратегію маршрутизації. OSPF є протоколом маршрутизації всередині AS, хоча він і здатний приймати маршрути з інших AS і відправляти маршрути в інші AS.

Будь-яка AS може бути розділена на ряд областей (area). Область - це група суміжних мереж і підключених до них хостів. Роутери, що мають кілька інтерфейсів, можуть брати участь в декількох областях. Такі роутери, які називаються роутерами межі областей (area border routers), підтримують окремі топологічні бази даних для кожної області.

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

Термін «домен» (domain) ісользуется для опису частини мережі, в якій всі роутера мають ідентичну топологічну базу даних. Термін «домен» часто використовується замість AS.

Топологія області є невидимою для об'єктів, що знаходяться поза цією областю. Шляхом зберігання топологій областей окремо, OSPF домагається меншого трафіку маршрутизації, ніж трафік для випадку, коли AS не розділена на області.

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

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

Маршрутизація між областями - коли вони знаходяться в різних областях.

Стрижнева частина OSPF (backbone) відповідає за розподіл маршрутної інформації між областями. Вона включає в себе всі роутери межі області, мережі, які не належать повністю якого-небудь з областей, і підключені до них роутери. На наступному малюнку представлений приклад об'єднаної мережі з декількома областями.

На цьому малюнку роутери 4, 5, 6, 10, 11 і 12 утворюють стрижень. Якщо хост Н1 Області 3 захоче відправити пакет хосту Н2 Області 2, то пакет відправляється в роутер 13, який просуває його в роутер 12, який у свою чергу відправляє його в роутер 11. Роутер 11 просуває пакет вздовж стрижня до роутера 10 межі області, який відправляє пакет через два внутрішніх роутера цій галузі (роутери 9 і 7) до тих пір, поки він не буде просунутий до хосту Н2.

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

Область може бути визначена таким чином, що стрижнева частина не буде суміжній з нею. У цьому випадку зв'язність стрижневою частини повинна бути відновлена ​​через віртуальні з'єднання. Віртуальні з'єднання формуються між будь-якими роутерами стрижневою області, які спільно використовують будь-який зв'язок з будь-якою з нестержневих областей; вони функціонують так, як якщо б вони були безпосередніми зв'язками.

Граничні роутери AS, що використовують OSPF, дізнаються про зовнішні роутерах через протоколи зовнішніх роутерів (EGPs), таких, як Exterior Gateway Protocol (EGP) або Border Gateway Protocol (BGP), або через інформацію про конфігурації.

Специфікації.

• RFC 1245. Аналіз протоколу OSPF.

• RFC 1246. Експериментальна частина роботи протоколу.

• RFC 1247 (оновлено 1349). Специфікації до протоколу OSPF версії 2.

• RFC 1248, RFC 1850. База керуючої інформації протоколу другої версії.

• RFC 1584. Доповнення до протоколу по широкомовлення.

• RFC 1585. Розширення протоколу по широкомовлення, аналіз та практичні додатки.

• RFC 1586. Інструкція з користування OSPF на мережах Frame Relay.

• RFC 1587. Опція протоколу для «не зовсім тупикової зони» (Not-so-stubby area).

• RFC 1793. Розширення до специфікаціям на вимогу до обладнання з підтримкою протоколу.

• RFC 2178. Чорновий варіант специфікацій.

• RFC 2328 (STD 0054). Чинний стандарт з OSPF.

Реалізація протоколу.

Метрики.

Метрика мережі, що оцінює пропускну здатність, визначається як кількість секунд, необхідний для передачі 100 Мбіт через фізичне середовище даної мережі. Наприклад, метрика мережі на базі 10Base-T Ethernet дорівнює 10, а метрика виділеної лінії 56 кбіт / с дорівнює 1785. Метрика каналу зі швидкістю передачі даних 100 Мбіт / с і вище дорівнює одиниці.

Порядок розрахунку метрик, що оцінюють надійність, затримку і вартість, не визначений. Адміністратор, який бажає підтримувати маршрутизацію за цими типами сервісів, повинен сам призначити розумні і узгоджені метрики за цими параметрами.

Якщо не потрібно маршрутизація з урахуванням типу сервісу (або маршрутизатор її не підтримує), використовується метрика за замовчуванням, рівна метриці по пропускній здатності.

База даних стану зв'язків

Для роботи алгоритму SPF на кожному маршрутизаторі будується база даних стану зв'язків, що представляє собою повний опис графа OSPF системи. При цьому вершинами графа є маршрутизатори, а ребрами - з'єднують їх зв'язку. Бази даних на всіх маршрутизаторах ідентичні.

За створення баз даних і підтримку їх взаємної синхронізації при змінах у структурі системи мереж відповідають інші алгоритми, що містяться в протоколі OSPF.

Підтримка множинних маршрутів.

Якщо між двома вузлами мережі існує декілька маршрутів з однаковими або близькими за значенням метриками, протокол OSPF дозволяє направляти частини трафіку за цими маршрутами в пропорції, що відповідає значенням метрик. Наприклад, якщо існує два альтернативні маршруту з метриками 1 і 2, то дві третини трафіку буде направлено за першою з них, а залишилася третина - за другим.

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

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

Зовнішні маршрути.

Для досягнення мереж, що не входять в OSPF систему (в автономну систему), використовуються прикордонні маршрутизатори автономної системи (autonomous system border router, ASBR), які мають зв'язки, що йдуть за межі системи.

ASBR вносять до бази даних стану зв'язків дані про мережі за межами системи, досяжних через той чи інший ASBR. Такі мережі, а також ведуть до них маршрути називаються зовнішніми (external).

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

Якщо в системі є декілька ASBR, то, можливо, внутрішнім маршрутизаторам системи доведеться вибирати, через який саме прикордонний маршрутизатор потрібно відправляти дейтаграми в ту або іншу зовнішню мережу. Це робиться на основі спеціальних записів, внесених ASBR в базу даних системи. Ці записи містять адресу і маску зовнішньої мережі і метрику відстані до неї, яка може бути, а може і не бути порівнянною з метриками, використовуваними в OSPF системі (див. також п. 5.5.12). Якщо можливо, адреси декількох зовнішніх мереж агрегуються в загальну адресу з коротшою маскою.

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

Мережі множинного доступу

Протокол OSPF особливим чином виділяє мережі множинного доступу, тобто мережі, де кожен вузол може безпосередньо зв'язатися з кожним. Такі мережі можуть також підтримувати широкомовну передачу і мультікастінга (broadcast networks, наприклад, Ethernet, FDDI) або не підтримувати такий (non-broadcast multi-access networks, NBMA, наприклад, Х.25, Frame Relay, ATM). Дотримуючись моделі роботи протоколів стану зв'язків, зв'язок кожної пари маршрутизаторів повинна розглядатися як зв'язок типу «точка-точка», що означає: кожен маршрутизатор повинен встановити суміжність з кожним, тобто всього N (N 1) / 2 відносин суміжності, по яких відбувається обмін всіма типами повідомлень.

Протокол OSPF зводить ситуацію тільки до N відносин суміжності, вибираючи серед всіх маршрутизаторів даної широкомовної мережі один виділений маршрутизатор (designated router, DR), з яким всі інші маршрутизатори встановлюють відносини суміжності.

Це означає, що кожен «невиділений» маршрутизатор підтримує синхронізацію бази даних стану зв'язків не з усіма сусідами, а тільки з виділеним маршрутизатором. При цьому протокол затоплення в подібній мережі працює наступним чином: «звичайний» маршрутизатор повідомляє про зміну стану своїх зв'язків виділеного маршрутизатора, а той затоплює мережу цим повідомленням і його отримують всі інші маршрутизатори мережі. Природно, що за своїм зовнішнім інтерфейсів, провідним до інших маршрутизаторів системи, що не знаходиться в даній мережі множинного доступу, кожен маршрутизатор відправляє повідомлення без участі виділеного маршрутизатора.

Протокол OSPF дозволяє також редукувати розмір бази даних стану зв'язків. Для цього в граф системи вводиться віртуальна вершина «транзитна мережа», що представляє собою мережу множинного доступу як таку. Кожен маршрутизатор, в тому числі й виділена, при такому підході має не набір двоточкових зв'язків з усіма іншими маршрутизаторами своєї мережі, а один зв'язок з вершиною «транзитна мережа».

Вибори виділеного маршрутизатора проводяться за допомогою протоколу Hello. Крім виділеного маршрутизатора вибирається також і запасний виділений маршрутизатор (backup designated router, BDR), інші маршрутизатори мережі встановлюють відносини суміжності як з DR, так і з BDR (отже, в попередньому пункті при описі відносин суміжності не вистачає BDR). Всі повідомлення для DR і BDR надсилаються на мультікастінговому адресою 224.0.0.6 «Усім виділеним OSPF маршрутизаторам».

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

NBMA-і point-to-multipoint мережі

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

Відмінність NBMA від широкомовних мереж полягає в тому, що адреси всіх сусідів повинні бути попередньо сконфігуровані на кожному маршрутизаторі, тому що можливості передавати мультікастінговие повідомлення немає.

Якщо маршрутизатор, підключений до нешіроковещательной мережі, може безпосередньо зв'язатися з кількома, але не з усіма маршрутизаторами цієї мережі (неповний множинний доступ), таке з'єднання конфігурується як point-to-multipoint і не розглядається протоколом OSPF як мережа множинного доступу з усіма вищеописаними наслідками. Маршрутизатор, підключений до з'єднання типу point-to-multipoint, встановлює Двоточкові зв'язку з кожним своїм сусідом по з'єднанню.

Можуть бути також причини, за якими адміністратор забажає конфігурувати мережу з повним множинним доступом як point-to-multipoint.

Ієрархічна маршрутизація (Розбиття на області)

Для спрощення обчислення маршрутів та зменшення розміру бази даних стану зв'язків OSPF система може бути розбита на окремі незалежні області (areas), що об'єднуються в єдину систему особливою областю, званої магістраллю (backbone). Області, які не є магістраллю, називаються периферійними.

Маршрути всередині кожної області обчислюються як в окремій системі: база даних стану зв'язків містить записи тільки про зв'язки маршрутизаторів всередині області, дію протоколу затоплення не поширюється за межі області.

Деякі маршрутизатори належать магістралі і однією або кількома периферійним областям. Такі маршрутизатори називаються обласними прикордонними маршрутизаторами (area border router, ABR). Кожна область повинна мати як мінімум один ABR, інакше вона буде повністю ізольована від решти.

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

Тим самим забезпечується передача маршрутної інформації та коннективність між областями. При цьому, за межі області передається не повна база даних стану зв'язків, а просто список мереж цієї області, досяжних ззовні області через даний ABR, разом з метриками відстані до цих мереж. Якщо можливо, адреси мереж агрегуються в загальну адресу з коротшою маскою. Подібну ж інформацію, але тільки про мережі, що лежать за межами OSPF системи, поширюють ASBR.

Тупикові й не зовсім тупикові області

Області, всередину яких не передається інформація про зовнішні маршрутах, називаються тупиковими областями (stub areas). Всі дейтаграми, що виходять з даної області і адресовані за межі автономної системи, відправляються за маршрутом за умовчанням (default) через певний ABR. Тупикова область може мати кілька ABR, але для кожного вузла всередині області встановлено маршрут за замовчуванням, що проходить тільки через один їх ABR.

Протокол OSPF визначає також поняття не зовсім тупикових областей (not so stubby area, NSSA). До таких областей відносяться тупикові області, в яких дозволено оголошувати деякі зовнішні маршрути.

OSPF заголовок

Протокол OSPF в стеку протоколів TCP / IP знаходиться безпосередньо над протоколом IP, код OSPF дорівнює 89. Тобто якщо значення поля «Protocol» IP дейтаграми дорівнює 89, то дані дейтаграми є повідомленням OSPF та передаються OSPF модулю для обробки. Відповідно розмір OSPF повідомлення обмежений максимальним розміром дейтаграми.

Всі повідомлення OSPF мають загальний заголовок (наступний у дейтаграми безпосередньо за IP заголовком):

Значення полів:

• Version (1 октет) - версія протоколу (= 2);

• Type (1 октет) - тип повідомлення:

1. Hello;

2. опис бази даних (Database Description);

3. запит стану зв'язків (Link State Request);

4. оновлення стану зв'язків (Link State Update);

5. підтвердження прийому повідомлення про стан зв'язків (Link State Acknowledgment).

• Packet length (2 октету) - довжина повідомлення в октетах, включаючи заголовок.

• Router ID (4 октету) - ідентифікатор маршрутизатора, що відправив повідомлення. Router ID дорівнює адресу одного з IP інтерфейсів маршрутизатора. У маршрутизаторів Cisco це найбільший з адрес локальних інтерфейсів, а якщо таких немає, то найбільший з адрес зовнішніх інтерфейсів.

• Area ID (4 октету) - номер області, до якої належить дане повідомлення; номер 0 зарезервований для магістралі. Часто номер області вважають рівними адресою IP мережі (однієї з IP мереж) цієї області.

• Checksum (2 октету) - контрольна сума, охоплює всі OSPF повідомлення, включаючи заголовок, але за винятком полі «Authentication»; обчислюється за тим же алгоритмом, що і в IP заголовку.

• Authentication Type (2 октету) - тип аутентифікації повідомлення. Стандарт визначає кілька можливих типів, найпростіші з них: 0 - немає аутентифікації, 1 - аутентифікація за допомогою пароля.

• Authentication (8 октетів) - аутентифікаційні дані; наприклад, восьмісімвольний пароль.

• Далі при розгляді формату повідомлень вищеописаний заголовок буде зображуватися у вигляді поля «OSPF заголовок», поміщеного в початок повідомлення.

Протокол Hello

Після ініціалізації модуля OSPF (наприклад, після подачі живлення на маршрутизатор) через всі інтерфейси, включені до OSPF систему, починають розсилатися Hello повідомлення. Завдання Hello протоколу - виявлення сусідів та встановлення з ними відносин суміжності.

Сусідами називаються OSPF маршрутизатори, підключені до однієї мережі (до однієї лінії зв'язку) і обмінюються Hello повідомленнями.

Суміжними називаються сусідні OSPF маршрутизатори, які прийняли рішення обмінюватися один з одним інформацією, необхідної для синхронізації бази даних стану зв'язків та побудови маршрутів. Не всі сусіди стають суміжними.

Інше завдання протоколу Hello - вибір виділеного маршрутизатора в мережі з множинним доступом, до якої підключено кілька маршрутизаторів.

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

У мережах з можливістю широкомовного розсилання (broadcast networks) Hello пакети розсилаються по мультікастінговому адресою 224.0.0.5 («Усім ОSPF маршрутизаторам»). В інших мережах всі можливі адреси сусідів повинні бути введені адміністратором.

Значення полів:

• Network Mask (4 октету) - маска IP мережі, в якій знаходиться інтерфейс маршрутизатора, що відправив повідомлення.

• Hello Interval (2 октету) - період посилки Hello повідомлень, в секундах.

• Options (1 октет) - визначено значення кількох біт:

• Біт Т встановлений, підтримується маршрутизація за типом сервісу (цей біт виключений з останньої версії стандарту OSPF, але може підтримуватися для сумісності з попередніми версіями).

• Біт Е встановлено, маршрутизатор може приймати і оголошувати зовнішні маршрути через даний інтерфейс; скинутий, даний інтерфейс маршрутизатора належить тупикової області.

• Біт MC встановлено, маршрутизатор підтримує маршрутизацію мультікастінгових дейтаграм (RFC 1584).

• Біт N / P встановлено, даний інтерфейс маршрутизатора належить не зовсім тупикової області (NSSA).

• Біт EA встановлено, маршрутизатор може отримувати і ретранслювати оголошення про «зовнішніх атрибутах» (на даний момент опис опції не розроблено).

• Біт DC встановлено, маршрутизатор підтримує роботу з сполуками, що встановлюються на вимогу (demand circuits, RFC 1793) - це, наприклад, означає, що записи про зв'язки, що встановлюються на вимогу, не втрачають актуальності.

• Поле «Options» використовується для узгодження можливостей маршрутизаторів-сусідів (маршрутизатор може перервати сусідські відносини, якщо якісь опції сусіда його не влаштовують) і для визначення того, яку інформацію про стан зв'язків не потрібно посилати маршрутизатора-сусіду, бо він все одно не зможе її обробити.

• Priority (1 октет) - пріоритет маршрутизатора; встановлюється адміністратором, використовується при виборах виділеного маршрутизатора; маршрутизатор з нульовим пріоритетом ніколи не буде обраний.

• Dead Interval (4 октету) - час у секундах, після закінчення якого маршрутизатор-сусід, не посилає повідомлення Hello, вважається відключеним.

• Designated Router (DR) (4 октету) - ідентифікатор виділеного маршрутизатора з точки зору маршрутизатора, що посилає повідомлення (0, якщо виділений маршрутизатор ще не вибрано).

• Backup Designated Router (BDR) (4 октету) - ідентіфіктор запасного виділеного маршрутизатора з точки зору маршрутизатора, що посилає повідомлення (0, якщо запасний виділений маршрутизатор ще не вибрано).

• Neighbor, ..., Neighbor - список ідентифікаторів сусідів, від яких отримано Hello повідомлення за останні Dead Interval секунд; число полів «Neighbor» визначається із загальної довжини повідомлення, зазначеної в OSPF заголовку. Довжина одного поля - 4 октету.

Після того, як пара маршрутизаторів починає обмінюватися Hello повідомленнями з якимось сусідом, цей процес проходить через декілька стадій:

• DOWN - сусід не виявлений або відключився;

• INIT - Надіслано Hello повідомлення або отримано від маршрутизатора, ще не зарахованого до списку сусідів;

• 2 WAY (двосторонній зв'язок) - отримано Hello повідомлення, в якому даний маршрутизатор-одержувач перераховано в списку сусідів, а відправник цього повідомлення також зарахований до списку сусідів даного маршрутизатора;

• WAIT - очікування протягом Dead Interval секунд для виявлення всіх сусідів, у цей час маршрутизатор передає Hello повідомлення, але не бере участь у виборах виділеного маршрутизатора і в синхронізувати баз даних;

• EXSTART - встановлення ролей головний / підпорядкований і ініціалізація структур даних для обміну описами баз даних (протокол обміну);

• EXCHANGE - обмін описами баз даних (протокол обміну);

• LOADING - синхронізація баз даних, пересилання повідомлень-запитів про стани зв'язків та відповідей на них (протокол обміну);

• FULL - бази даних синхронізовані.

Кожен маршрутизатор самостійно виробляє вибори виділеного та запасного виділеного маршрутизаторів на підставі наявних у нього даних про сусідів і про те, кого кожний з сусідів призначив на цю роль. Фактично процес виборів відбувається постійно, після отримання кожного Hello повідомлення, але алгоритм гарантує, що при стабільному стані мережі всіма маршрутизаторами будуть вибиратися одні й ті ж DR і BDR.

Кожен маршрутизатор може оголосити себе або виділеним, або запасним, помістивши свій ідентифікатор у відповідне поле своїх Hello повідомлень. Інакше він може помістити туди адреси інших маршрутизаторів, якщо він вважає їх займають відповідні ролі. Якщо маршрутизатор не визначився з вибором DR і (або) BDR (наприклад, після включення), він заповнює відповідні поля нулями.

Вибір проводиться тільки серед сусідів, з якими встановлено двосторонній зв'язок і пріоритет яких не дорівнює нулю; в цей список маршрутизатор включає і себе, якщо його пріоритет не нульовий.

Отже, після отримання чергового Hello повідомлення маршрутизатор приступає до вибору DR і BDR. Він пам'ятає думки своїх сусідів з приводу того, хто є DR і BDR, які він дізнався з одержуваних Hello повідомлень, а також свій власний попередній вибір.

Спочатку вибирається BDR, на цю посаду призначається маршрутизатор з найвищим пріоритетом з усіх, що оголосили себе в якості BDR, при цьому маршрутизатори, які оголосили себе як DR, не розглядаються. Якщо ніхто не оголосив себе як BDR, вибирається маршрутизатор з вищим пріоритетом з тих, хто не оголосив себе як DR. У разі рівних пріоритетів вибирається маршрутизатор з великим ідентифікатором.

На посаду DR вибирається маршрутизатор з найвищим пріоритетом з усіх, що оголосили себе в якості DR. У разі рівних пріоритетів вибирається маршрутизатор з великим ідентифікатором.

Якщо ніхто не запропонував себе як DR, в полі «Designated Router" заноситься ідентифікатор BDR.

Якщо маршрутизатор тільки що вибрав себе на роль DR або BDR або тільки що втратив статус DR або BDR, кроки 1-3 повторюються. Термін «щойно» означає «в результаті виконання безпосередньо передують кроків 1-3, а не попередніх ітерацій алгоритму».

Після вибору DR і BDR маршрутизатор повідомляє їх ідентифікатори в своїх Hello повідомленнях. Якщо в результаті процедури вибору DR або BDR змінилися в порівнянні з попереднім вибором даного маршрутизатора, він встановлює необхідні відносини суміжності, якщо вони ще не були встановлені, і розриває непотрібні більше відношення суміжності, якщо такі є.

Коли маршрутизатор підключається до мережі, спочатку він досягає стану 2 WAY з усіма своїми сусідами, а потім, перш ніж приступати до виборів, чекає час WAIT. Протягом цього часу він передає Hello повідомлення з обнуленням полями DR і BDR. Після закінчення періоду WAIT знову підключився маршрутизатор може пропонувати себе на роль BDR, виробляти вибори і формувати відносини суміжності.

Протокол обміну

Після встановлення відносин суміжності для кожної пари суміжних маршрутизаторів відбувається синхронізація їх баз даних. Ця ж операція відбувається при відновленні раніше розірваного з'єднання, оскільки в які утворилися після аварії двох ізольованих підсистемах бази даних розвивалися незалежно один від одного. Синхронізація баз даних відбувається за допомогою протоколу обміну (Exchange protocol).

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

Під час цього обміну кожен маршрутизатор формує список записів, вміст яких він повинен запросити (тобто ці записи в його базі даних застаріли або відсутні), і відповідно відправляє пакети запитів про стан зв'язків (Link State Request). У відповідь він отримує вміст останніх версій потрібних йому записів у пакетах типу «Оновлення стану зв'язків (Link State Update)».

Після синхронізації баз даних проводиться побудова маршрутів.

Повідомлення «Опис бази даних (Database Description)»

Значення полів:

• Options (1 октет) - те ж, що і в повідомленнях Hello.

• IMMS (3 біта) - останні 3 біти октету, наступного за полем «Options»: I - Initialize, біт 5; M - More, біт 6, MS - Master / Slave, біт 7. Використання цих біт буде описано нижче. Інша частина октету, де знаходяться ці біти, обнулено.

• DD Sequence number (DDSN) (4 октету) - порядковий номер даного повідомлення.

• LSA Header (20 октетів) - опис (набір ідентифікаторів) записи з бази даних стану зв'язків, що представляє собою заголовок «Оголошення про стан зв'язків». У повідомленні може бути присутнім кілька описів (полів «LSA Header»), наступних один за одним, їх число визначається із загальної довжини повідомлення, зазначеної в OSPF заголовку.

Обмін повідомленнями «Опис бази даних» відбувається при роботі протоколу обміну (Exchange protocol) між двома суміжними маршрутизаторами. Обмін починається зі з'ясування, хто з двох маршрутизаторів буде грати головну роль, а хто підлеглу.

Маршрутизатор, бажає почати обмін на правах головного, відправляє пусте повідомлення з встановленими бітами IMMS і довільним, але не використаних у недалекому минулому номером DDSN (пропонується використовувати час доби). Другий маршрутизатор підтверджує, що згоден грати підлеглу роль: він відправляє назад також пусте повідомлення з тим же DDSN, c встановленими бітами I і M і скинутим бітом MS.

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

Після того, як ролі розподілені, починається обмін описами бази даних. Головний відправляє підлеглому повідомлення з описами своєї бази даних; номери DDSN збільшуються з кожним повідомленням, біт I скинутий, біт МS встановлено, біт M встановлений в усіх повідомленнях, крім останнього.

Підлеглий відправляє підтвердження на кожне отримане від головного повідомлення. Ці підтвердження представляють собою повідомлення того ж типу, що містять опис бази даних підлеглого маршрутизатора. Номер DDSN рівний номеру підтверджуваного повідомлення, біти I і MS скинуті, біт М встановлений в усіх повідомленнях, крім останнього.

При неотриманні підтвердження від підлеглого протягом деякого тайм-ауту головний посилає повідомлення повторно. Якщо підлеглий отримує повідомлення з уже зустрічалися номером DDSN, він повинен повторити передачу відповідного підтвердження. Це стосується також і фази ініціалізації (розподілу ролей).

Якщо один з маршрутизаторів вже передав всі дані, він продовжує передавати порожні повідомлення зі скинутим бітом М, поки інша сторона також не закінчить передачу всіх даних і не передасть повідомлення (або підтвердження) зі скинутим бітом М.

На цьому процедура обміну описами бази даних закінчується.

Протокол затоплення (flooding)

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

Подпротокол OSPF, що виконує це завдання, називається протоколом затоплення (Flooding protocol). При роботі цього протоколу пересилаються повідомлення типу «Оновлення стану зв'язків (Link State Update)», отримання яких підтверджується повідомленнями типу «Link State Acknowledgment».

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

Маршрутизатор, відповідальний за запис про змінилася зв'язку, розсилає повідомлення "Оновлення стану зв'язку» за всіма інтерфейсів. Однак нові версії стану однієї і тієї ж зв'язку повинні з'являтися не частіше, ніж обумовлено певною константою.

Далі на всіх маршрутизаторах OSPF системи діє наступний алгоритм.

1. Отримати повідомлення. Знайти відповідний запис у базі даних.

2. Якщо запис не знайдений, додати її в базу даних, передати повідомлення по всіх інтерфейсів.

3. Якщо номер запису в базі даних менше номера прийшов повідомлення, замінити запис у базі даних, передати повідомлення по всіх інтерфейсів.

4. Якщо номер запису в базі даних більше номера прийшов повідомлення і цей запис не була нещодавно розіслано, розіслати вміст записи з бази даних через той інтерфейс, звідки прийшло повідомлення. Поняття «недавно» визначається значенням константи.

5. У разі рівних номерів повідомлення ігнорувати.

Протокол OSPF встановлює також таку характеристику запису в базі даних, як вік. Вік дорівнює нулю при створенні запису. При затопленні OSPF системи повідомленнями з даною записом кожен маршрутизатор, який ретранслює повідомлення, збільшує вік запису на певну величину. Крім цього, вік збільшується на одиницю кожну секунду. Через різницю в часі пересилання, в кількості проміжних маршрутизаторів і з інших причин вік однієї і тієї ж записи в базах даних на різних маршрутизаторах може трохи відрізнятися, це нормальне явище.

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

Оскільки бази даних на всіх маршрутизаторах системи повинні бути ідентичні, прострочена запис повинна бути вилучена з усіх копій бази даних на всіх маршрутизаторах. Це робиться з використанням протоколу затоплення: маршрутизатор затоплює систему повідомленням з простроченої записом. Відповідно, в описаний вище алгоритм обробки повідомлення вносяться доповнення, пов'язані з отриманням простроченого повідомлення і видаленням відповідного запису з бази даних.

Щоб запису в базі даних не старіли, маршрутизатори, відповідальні за них, повинні через кожні 30 хвилин затоплювати систему повідомленнями про оновлення записів, навіть якщо стан зв'язків не змінилося. Вміст записів у цих повідомленнях незмінно, але номер версії більше, а вік дорівнює нулю.

Вищеописані протоколи забезпечують актуальність інформації, що міститься в базі даних стану зв'язків, оперативне реагування на зміни в топології системи мереж і синхронізацію копій бази даних на всіх маршрутизаторах системи.

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

У протоколі OSPF може бути застосована аутентифікація повідомлень, наприклад, захист їх за допомогою пароля.

Повідомлення «Запит стану зв'язку (Link State Request)»

Повідомлення «Запит стану зв'язку» вирушає при роботі протоколу обміну після того, як був проведений обмін описами баз даних.

Повідомлення містить один або кілька ідентифікаторів записів, які маршрутизатор хоче отримати від свого сусіда. Кожен ідентифікатор запису складається з полів «Link State Type», «Link State ID» і «Advertising Router»; значення цих полів будуть розглянуті при обговоренні заголовків оголошень про стан зв'язків (LSA). Число ідентифікаторів (тобто число запитів) в одному повідомленні визначається із загальної довжини повідомлення, зазначеної в OSPF заголовку.

Підтвердженням прийому запиту є посилка повідомлення типу 4 «Оновлення стану зв'язку». При відсутності підтвердження протягом деякого тайм-ауту запит надсилається повторно. Якщо всі запити не можуть бути поміщені в одне повідомлення, вони розбиваються на декілька повідомлень, але кожне наступне повідомлення-запит надсилається тільки після отримання всіх записів, запитаних у попередньому.

Повідомлення «Оновлення стану зв'язків (Link State Update)»

Повідомлення «Оновлення стану зв'язків» власне і містить інформацію з бази даних стану зв'язків. Це повідомлення надсилається у відповідь на запит (тип 3) при роботі протоколу обміну, а також при роботі протоколу затоплення для поширення інформації про зміну стану зв'язків. В останньому випадку його отримання підтверджується повідомленнями типу 5 «Link State Acknowledgment», у разі відсутності підтвердження посилка повторюється.

Повідомлення типу 4 складається з одного або декількох оголошень про стан зв'язків (Link State Advertisement, LSA), наступних один за одним. Існує кілька типів LSA. Кожне LSA складається із заголовка і тіла.

Число оголошень LSA в повідомленні визначається першим 32 бітовим словом, наступним за OSPF заголовком. Довжина кожного LSA визначається відповідним полем у заголовку LSA. Якщо все LSA, який потрібно надіслати, не містяться в одне повідомлення, вони можуть бути розподілені на декількох повідомленнями.

Дейтаграмма з OSPF повідомленням типу 4, що несе 3 LSA, має таку загальну структуру:

Повідомлення «Підтвердження прийому повідомлення про стан зв'язків
(Link State Acknowledgment) »

Повідомлення типу 5 відправляються на підтвердження отримання повідомлень типу 4 при роботі протоколу затоплення. Повідомлення містить одне або кілька підтверджень, кожне підтвердження складається із заголовка LSA, отримання якого підтверджується.

Маршрутизатор може не посилати підтвердження на кожне повідомлення типу 4, а послати одне повідомлення типу 5 з підтвердженнями на отримання LSA, надісланих у кількох повідомленнях типу 4, але в будь-якому випадку затримка з посилкою підтверджень не повинна бути велика.

Число підтверджень в одному повідомленні типу 5 визначається із загальної довжини повідомлення, зазначеної в OSPF заголовку.

Типи Оголошень про стан зв'язків (LSA)

Тип 1. Router Links Advertisement - маршрутизатор оголошує про свої зв'язки з сусідніми маршрутизаторами, транзитними і тупиковими мережами; поширюється кожним маршрутизатором всередині області, до якої належать ці зв'язки.

Тип 2. Network Links Advertisement - містить список маршрутизаторів, підключених до мережі множинного доступу; поширюється виділеним маршрутизатором всередині області, до якої належить дана мережа. Фактично описує зв'язки, спрямовані в графі системи від вершини типу «транзитна мережа» до маршрутизаторів цієї мережі.

Тип 3. Summary Link Advertisement - описує відстань від даного обласного прикордонного маршрутизатора (ABR) до IP мережі, що знаходиться за межами даної області, але належить даній OSPF системі; поширюється цим ABR всередині області.

Тип 4. AS Boundary Router Summary Link Advertisement - описує відстань від даного ABR до даного прикордонного маршрутизатора системи (ASBR); поширюється цим ABR всередині області.

Тип 5. AS External Link Advertisement - описує відстань до мережі, що знаходиться за межами OSPF системи; поширюється ASBR і ретранслюється в усі області, крім тупикових, їх прикордонними маршрутизаторами.

Тип 7. AS External Link Advertisement (NSSA) - те ж, що тип 5, але поширюється всередині не зовсім тупикових областей (у них поширення LSA типу 5 заборонено); на кордоні NSSA і магістралі перетворюється на LSA типу 5 для подальшого розповсюдження в системі. Формат ідентичний формату LSA типу 5 за винятком номера типу.

Тема LSA

Всі оголошення про стан зв'язків (LSA) складаються із заголовка і тіла і пересилаються в повідомленнях OSPF типу 4, а заголовки окремо також пересилаються в повідомленнях типу 2 і 5. Тема LSA має однаковий формат для всіх типів LSA.

Значення полів:

• LS Age (2 октету) - вік зв'язку (зв'язків), що містяться в даному LSA.

• Options (1 октет) - вміст октету аналогічно такому ж октету в повідомленні Hello.

• LS Type (1 октет) - тип LSA.

• Link State ID (4 октету) - ідентифікатор зв'язку (зв'язків), які декларуються в даному LSA, інтерпретація цього поля залежить від типу LSA:

• Advertising Router (4 октету) - ідентифікатор маршрутизатора, відповідального за оголошення і підтримку зв'язку (зв'язків), що містяться в даному LSA.

• Link State sequence number (4 октету) - порядковий номер (версія) стану зв'язку (зв'язків), що містяться в даному LSA.

• LS Checksum (2 октету) - контрольна сума, обчислюється таким же методом, що і контрольна сума IP заголовка; захищає як заголовок, так і тіло LSA.

• length (2 октету) - довжина LSA в октетах, включаючи 20 октетів заголовка LSA.

Тіло LSA типу 1

Значення полів:

• VEB (3 біта) - перший октет обнулений за винятком трьох старших біт V (біт 5), E (біт 6) і B (біт 7). Встановлені значення цих біт говорять про те, що маршрутизатор, який оголосив дане LSA, є:

  • біт B - прикордонним маршрутизатором області (ABR);

  • біт Е - прикордонним маршрутизатором системи (ASBR);

  • біт V - оконечной точкою віртуального зв'язку.

• Число зв'язків (2 октету) - число зв'язків, оголошених у даному LSA.

• Оголошення про кожну зв'язку складається з полів «Link ID», «Link Data», «Type», «# TOS», «TOS 0 metric», за якими може слідувати 0 або більше 32 розрядних слів, що складаються з полів «TOS», нульового октету і «TOS metric». Кількість таких слів визначається полем «# TOS».

• Link ID (4 октету), Link Data (4 октету), Type (1 октет) - інтерпретація полів «Link ID» і «Link Data» залежить від значення поля «Type» (нижче в колонці «Link Data» під IP адресою розуміється IP адреса інтерфейсу оголошує маршрутизатора, підключеного до тому зв'язку, яку він оголошує):

# TOS (1 октет) - число метрик для маршрутизації за типом сервісу для даної зв'язку (0 - метрики для маршрутизації за типом сервісу не визначені).

• TOS 0 metric (2 октету) - метрика даної зв'язку для маршрутизації без урахування типу сервісу (метрика за замовчуванням).

• TOS (1 октет), TOS metric (2 октету) - метрика даної зв'язку («TOS metric») для вказаного типу сервісу («TOS»). Число таких метрик визначено полем «# TOS» і може дорівнювати нулю. Значення TOS визначається, як у заголовку IP дейтаграми. Незважаючи на те, що маршрутизація за типом сервісу виключена з останньої версії стандарту OSPF, ці поля підтримуються для сумісності з попередніми версіями.

Крім власне зв'язків з тупиковими мережами, наступні зв'язку оголошуються як зв'язку з тупиковими мережами:

• зв'язок з власним інтерфейсом (інтерфейсами) типу loopback (Link ID = IP адреса інтерфейсу, Link Data заповнюється одиницями);

• c в'язь з хостом, підключеним до маршрутизатора за двухточечной лінії (Link ID = IP адреса хоста, Link Data заповнюється одиницями);

• зв'язок з мережею, що представляє собою двухточечное з'єднання між маршрутизаторами (на додаток до власне двухточечной зв'язку між маршрутизаторами); у разі, якщо цієї мережі не присвоєні адресу і маска, Link ID дорівнює IP адресою інтерфейсу сусіднього маршрутизатора, Link Data заповнюється одиницями;

• зв'язок з власним інтерфейсом, підключеним до з'єднання типу point - to - multipoint (на додаток до двухточечним зв'язків з кожним із сусідів, підключеним до цього з'єднання); Link ID = IP адреса інтерфейсу, Link Data заповнюється одиницями.

Тіло LSA типу 2

Значення полів:

• Network Mask (4 октету) - маска мережі множинного доступу (адреса цієї мережі вказана в полі "Link State ID» заголовка LSA).

• Attached Router (4 октету) - ідентифікатор маршрутизатора, підключеного до мережі множинного доступу. Перераховуються всі маршрутизатори, які встановили відносини суміжності з виділеним маршрутизатором. Довжина списку маршрутизаторів визначається із загальної довжини LSA, зазначеної в заголовку LSA.

LSA цього типу описує зв'язки, спрямовані в графі системи від вершини типу «транзитна мережа» до маршрутизаторів цієї мережі. Метрика цих зв'язків не вказується, оскільки вона вважається рівною нулю.

Тіло LSA типів 3 і 4

LSA типу 3 або 4 містить оголошення про відстань тільки до однієї IP мережі, що лежить за межами області (до одного прикордонного маршрутизатора). Адреса мережі або ідентифікатор маршрутизатора вказана в полі "Link State ID »заголовка LSA.

Поле «Network Mask »(4 октету) містить значення маски мережі, якщо це LSA типу 3, або всі одиниці, якщо це LSA типу 4. Далі слід 32 бітне слово, два останні октету якого містять метрику відстані за замовчуванням (тип сервісу 0), після якого може слідувати 0 або більше 32 бітових слів, що оголошують метрики відстаней для маршрутизації за типами сервісу - аналогічно тому, як це зроблено в LSA типу 1. Незважаючи на те, що маршрутизація за типом сервісу виключена з останньої версії стандарту OSPF, ці поля підтримуються для сумісності з попередніми версіями.

Поле «# TOS» тут відсутній, тому що число оголошень метрик для типів сервісу можна обчислити із загальної довжини LSA, зазначеної в заголовку LSA.

LSA типу 3 та 4 поширюються обласними прикордонними маршрутизаторами як всередині периферійних областей, так і в магістралі. LSA, поширювані в периферійній області, містять інформацію про досяжності мереж і ASBR, що знаходяться в магістралі та інших периферійних областях. LSA, поширювані в магістралі, містять інформацію про досяжності мереж і ASBR, що знаходяться в периферійній області.

Якщо можливо, адреси декількох мереж агрегуються в загальну адресу з коротшою маскою, що зменшує кількість LSA і розмір бази даних.

Тіло LSA типу 5

Значення полів:

Network Mask (4 октету) - маска зовнішньої IP мережі. IP адресу цієї мережі вказана в полі "Link State ID »заголовка LSA.

Далі слід один чи більше записів із зазначенням метрики та інших характеристик маршруту до даної мережі для різних типів сервісу (поля «E TOS »,« TOS metric »,« Forwarding Address »,« External Route Tag »). Першими вказуються характеристики для TOS = 0 (тобто коли тип сервісу не враховується), ця частина присутня обов'язково. Число інших типів сервісу, представлених у LSA, визначається із загальної довжини LSA, зазначеної в заголовку LSA. Незважаючи на те, що маршрутизація за типом сервісу виключена з останньої версії стандарту OSPF, відповідні поля підтримуються для сумісності з попередніми версіями.

• E (E TOS) - молодший біт октету, що містить значення TOS (самим значенням TOS використовуються біти 3-6). Має наступні значення:

  • Е встановлений à метрика зовнішнього маршруту обчислюється в одиницях, не порівнянних з обчисленням метрик в OSPF (протоколи зовнішньої маршрутизації, що поставляють дані про зовнішніх маршрутах, не зобов'язані використовувати сумісні з OSPF значення метрик); в цьому випадку метрика, зазначена для відповідного TOS, повинна вважатися більше будь-якої метрики в OSPF системі;

  • Е скинутий à метрика зовнішнього маршруту може складатися з метриками внутрішніх маршрутів.

• TOS 0 metric (TOS metric) (2 октету) - метрика для відповідного значення TOS.

• Forwarding Address (4 октету) - адреса маршрутизатора, якому слід пересилати дейтаграми, адресовані в оголошується зовнішню мережу. Це поле використовується, коли ASBR вважає, що він сам - не кращий «наступний маршрутизатор» на шляху до цієї зовнішню мережу. Наприклад, в одній IP мережі з ASBR знаходиться маршрутизатор G, який не підтримує протокол OSPF (а підтримуючий, наприклад, BGP), причому через G лежать найкоротші маршрути до певних зовнішніх мереж. ASBR, який також підтримує і BGP, дізнається від G про ці маршрутах і оголошує їх в автономній системі, однак за допомогою «Forwarding Address» він тут же зазначає, що дейтаграми, адресовані у ці мережі, краще відразу ж направляти маршрутизатора G.
  Можливі й інші приклади. Якщо поле «Forwarding Address» обнулені, то дейтаграми слід пересилати того ASBR, який оголосив дане LSA.

• External Route Tag (4 октету) - поле, що використовується ASBR для цілей зовнішньої маршрутизації; модулем OSPF ігнорується.

Якщо можливо, адреси декількох зовнішніх мереж агрегуються в загальну адресу з коротшою маскою, що зменшує кількість LSA і розмір бази даних.

Конфігурування OSPF маршрутизатора

Для конфігурації OSPF маршрутизатора буде потрібно, як мінімум, наступні кроки:

• вказати зв'язку, які будуть включені в OSPF систему; якщо це широкомовні мережі, то вказати адреси цих мереж; у разі нешіроковещательних мереж і двоточкових зв'язків вказати адреси можливих сусідів;

• якщо потрібно, вказати тип c об'єднання (двоточковим, point - to - multipoint);

• якщо є розбиття на області, для кожного зв'язку вказати номер області і її тип;

• якщо потрібно, конфігурувати віртуальні зв'язку;

• сконфігурувати зовнішні маршрути або організувати їх отримання від протоколів зовнішньої маршрутизації, або встановити маршрут за замовчуванням - на прикордонних маршрутизаторах системи.