Протокол маршрутизації – такий протокол, який підтримує маршрутизовані протоколи і надає механізми обміну маршрутною інформацією. Повідомлення протоколу маршрутизації передаються між маршрутизаторами (роутерами). Протокол маршрутизації дозволяє роутерам обмінюватись інформацією між собою для оновлення записів і підтримки таблиці маршрутизації. Приклади протоколів маршрутизації: RIP, IGRP, EIGRP, OSPF. Легше зрозуміти, що таке протоколи маршрутизації, якщо пам’ятати, що це протоколи обміну маршрутною інформацією.
І так, для чого призначені всі протоколи маршрутизації?
1. Вони дозволяють зменшити обсяг робіт, які виконуються мережевим адміністратором, оскільки вводять в таблиці маршрутизації маршрути до всіх мереж;
2. За наявності більше одного маршруту до деякої мережі вони виконують одну з таких дій:
- поміщають в таблицю найкращий маршрут;
- вводять у таблицю кілька маршрутів і забезпечують розподіл навантаження по цих маршрутах;
3. Дозволяють автоматично видаляти з таблиці недійсні маршрути при виникненні відмови каналу;
4. Після отримання інформації про найкращий маршрут вводять дані про нього в таблицю;
5. Усувають маршрутні цикли з максимально можливою оперативністю.
Протокол RIP
Протокол RIP (Routing Information Protocol) є внутрішнім протоколом маршрутизації дистанційно-векторного типу, він являє собою один з найбільш ранніх протоколів обміну маршрутною інформацією і досі надзвичайно поширений в обчислювальних мережах зважаючи на простоту реалізації. Окрім версії RIP для мереж TCP/IP існує також версія RIP для мереж IPX/SPX компанії Novell.
Для IP є дві версії протоколу RIP: перша і друга. Протокол RIPvl не підтримує масок, тобто він поширює між маршрутизаторами тільки інформацію про номери мереж і відстанях до них, а інформацію про маски цих мереж не поширює, вважаючи, що всі адреси належать до стандартних класів А, В або С. Протокол RIPv2 передає інформацію про маски мереж, тому він більшою мірою відповідає вимогам сьогодення. Так як при побудові таблиць маршрутизації робота версії 2 принципово не відрізняється від версії 1, то в подальшому для спрощення записів буде описуватися робота першої версії.
Формат RIP пакету
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
| |
~ RIP Entry (20) ~
| |
+---------------+---------------+---------------+---------------+
command — Команда, визначає призначення датаграми (1 — request; 2 — response)
version — Номер версії, залежно від версії, визначається формат пакета
must be zero — повинно бути нулем;
RIP Entry — (RTE) Запис маршрутної інформації RIP. RIP пакет може містити від 1 до 25 записів RIP Entry.
Формат RIP Entry для протоколу RIP-1 (version = 1)
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address family identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IPv4 address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| metric (4) |
+---------------------------------------------------------------+
address family identifier — (AFI) Тип адреси, звичайно підтримується тільки запис AF_INET, яке дорівнює 2 (тобто використовується для протоколу IP)
must be zero — повинно бути нулем
IPv4 address — IP адреса місця призначення (хост або мережа)
metric — Метрика маршруту
Формат RIP Entry для протоколу RIP-2 (version = 2)
0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family Identifier (2) | Route Tag (2) | +-------------------------------+-------------------------------+ | IP Address (4) | +---------------------------------------------------------------+ | Subnet Mask (4) | +---------------------------------------------------------------+ | Next Hop (4) | +---------------------------------------------------------------+ | Metric (4) | +---------------------------------------------------------------+
Address Family Identifier — (AFI) Тип адреси, звичайно підтримується тільки запис AF_INET, яке дорівнює 2 (тобто використовується для протоколу IP)
Route Tag — (RT) Тег маршруту. Призначений для поділу «внутрішніх» маршрутів від «зовнішніх», взяті наприклад з іншого IGP або EGP
IP Address — IP адреса місця призначення
Subnet Mask — Маска підмережі
Next Hop — Наступний хоп. Містить IP адреса маршрутизатора до місця призначення. Значення 0.0.0.0 — хопом до місця призначення є відправник пакета. Незамінне, якщо протокол RIP не може бути запущений на всіх маршрутизаторах!
Metric — Метрика маршруту
Побудова таблиці маршрутизації
В якості відстані до мережі стандарти протоколу RIP допускають різні види метрик: хопи, метрики, що враховують пропускну здатність, затримки і надійність мереж (тобто відповідні ознаками D, Т і R в поле «Якість сервісу» IP-пакета), а також будь-які комбінації цих метрик. Метрика повинна мати властивість адитивності – метрика складового шляху повинна дорівнювати сумі метрик складових цього шляху. У більшості реалізації RIP використовується найпростіша метрика – кількість хопов, тобто кількість проміжних маршрутизаторів, які потрібно подолати пакету до мережі призначення.
Розглянемо процес побудови таблиці маршрутизації за допомогою протоколу RIP на прикладі складеної мережі, зображеної на мал.
Мал. Мережа побудована на маршрутизаторах RIP.
Етап 1 – створення мінімальних таблиць. У цій мережі є вісім IP-мереж, пов’язаних чотирма маршрутизаторами з ідентифікаторами: Ml, М2, МЗ і М4. Маршрутизатори, що працюють по протоколу RIP, можуть мати ідентифікатори, проте для роботи протоколу вони не є необхідними. У RIP-повідомленнях ці ідентифікатори не передаються.
У вихідному стані в кожному маршрутизаторі програмним забезпеченням стека TCP/IP автоматично створюється мінімальна таблиця маршрутизації, в якій враховуються тільки безпосередньо приєднані мережі. На малюнку адреси портів маршрутизаторів на відміну від адрес мереж поміщені в овали.
Таблиця. Мінімальна таблиця маршрутизації маршрутизатора Ml
Таблиця. Мінімальна таблиця маршрутизації маршрутизатора М2
Етап 2 – розсилка мінімальних таблиць сусідам. Після ініціалізації кожного маршрутизатора він починає посилати своїм сусідам повідомлення протоколу RIP, в яких міститься його мінімальна таблиця.
RIP-повідомлення передаються в пакетах протоколу UDP і включають два параметри для кожної мережі: її IP-адресу та відстань до неї від маршрутизатора, що передає повідомлення.
Сусідами є ті маршрутизатори, яким даний маршрутизатор безпосередньо може передати IP-пакет з якої-небудь своєї мережі, не користуючись послугами проміжних маршрутизаторів. Наприклад, для маршрутизатора Ml сусідами є маршрутизатори М2 і МЗ, а для маршрутизатора М4 – маршрутизатори М2 і МЗ.
Таким чином, маршрутизатор Ml передає маршрутизатору М2 і МЗ таке повідомлення:
- мережа 201.36.14.0, відстань 1;
- мережа 132.11.0.0, відстань 1;
- мережа 194.27.18.0, відстань 1.
Етап 3 – отримання RIP-повідомлень від сусідів і обробка отриманої інформації.
Після отримання аналогічних повідомлень від маршрутизаторів М2 і МЗ маршрутизатор Ml нарощує кожне отримане поле метрики на одиницю і запам’ятовує, через який порт і від якого маршрутизатора отримана нова інформація (адреса цього маршрутизатора буде адресою наступного маршрутизатора, якщо цей запис буде внесено в таблицю маршрутизації). Потім маршрутизатор починає порівнювати нову інформацію з тією, яка зберігається в його таблиці маршрутизації (табл. 3).
Таблиця 3. Таблиця маршрутизації маршрутизатора M1
Записи з четвертої по дев’ятий отримані від сусідніх маршрутизаторів, і вони претендують на занесення в таблицю. Однак лише записи з четвертої по сьому потрапляють в таблицю, а записи восьма і дев’ята – ні. Це відбувається тому, що вони містять дані про вже наявні в таблиці Ml мережах, а відстань до них гірша, ніж в існуючих записах.
Протокол RIP заміщає запис про будь-яку мережу тільки в тому випадку, якщо нова інформація має кращу метрику (відстань в хопах менше), ніж наявна. У результаті в таблиці маршрутизації про кожну мережі залишається тільки один запис, а якщо є декілька рівнозначних щодо відстані шляхів до однієї і тієї ж мережі, то все одно в таблиці залишається один запис, який прийшов в маршрутизатор першим. Для цього правила існує виняток – якщо найгірша інформація про будь-якої мережі прийшла від того ж маршрутизатора, на підставі повідомлення якого був створений цей запис, то найгірша інформація заміщає кращу.
Аналогічні операції з новою інформацією виконують і інші маршрутизатори мережі.
Етап 4 – розсилка нової, вже не мінімальної, таблиці сусідам. Кожен маршрутизатор відсилає нове RIP-повідомлення всім своїм сусідам. У цьому повідомленні він поміщає дані про всі відомі йому мережі – як безпосередньо підключених, так і віддалених, про які маршрутизатор дізнався з RIP-повідомлень.
Етап 5 – отримання RIP-повідомлень від сусідів і обробка отриманої інформації. Етап 5 повторює етап 3 – маршрутизатори приймають RIP-повідомлення, обробляють записи що містяться в них і коректують свої таблиці маршрутизації.
Подивимося, як це робить маршрутизатор Ml (табл. 4).
Таблиця 4. Таблиця маршрутизації маршрутизатора M1.
На цьому етапі маршрутизатор Ml отримав від маршрутизатора М3 інформацію про мережу 132.15.0.0, яку той у свою чергу на попередньому циклі роботи отримав від маршрутизатора М4. Маршрутизатор вже знає про мережу 132.15.0.0, причому стара інформація має кращу метрику, ніж нова, тому нова інформація про цю мережі відкидається.
Про мережу 202.101.16.0 маршрутизатор Ml дізнається на цьому етапі вперше, причому дані про неї приходять від двох сусідів – від МЗ і М4. Оскільки метрики в цих повідомленнях вказані однакові, то в таблицю потрапляють дані, які прийшли першими. У нашому прикладі вважається, що маршрутизатор М2 випередив маршрутизатор МЗ і першим переслав своє RIP-повідомлення маршрутизатору Ml.
Якщо маршрутизатори періодично повторюють етапи розсилки та обробки RIP-повідомлень, то за кінцевий час в мережі встановиться коректний режим маршрутизаціі. Під коректним режимом маршрутизації тут розуміється такий стан таблиць маршрутизації, коли всі мережі будуть досяжні з будь-якої мережі за допомогою деякого раціонального маршруту. Пакети будуть доходити до адресатів і не зациклюватися в петлях, подібних до тієї, яка утворюється на мал. 1, маршрутизаторами М1-М2-МЗ-М4.
Очевидно, якщо в мережі всі маршрутизатори, їх інтерфейси і канали зв’язку, що з’єднують їх постійно працездатні, то оголошення по протоколу RIP можна робити досить рідко, наприклад, один раз на день. Проте в мережах постійно відбуваються зміни – змінюється як працездатність маршрутизаторів і каналів, так і самі маршрутизатори і канали можуть додаватися в існуючу мережу або ж виводитися з її складу.
Для адаптації до змін у мережі протокол RIP використовує ряд механізмів.
Адаптація RIP-маршрутизаторів до змін стану мережі
До нових маршрутів RIP-маршрутизатори пристосовуються просто – вони передають нову інформацію в черговому повідомленні своїм сусідам і поступово ця інформація стає відома всім маршрутизаторам мережі. А ось до негативних змін, пов’язаних з втратою будь-якого маршруту, RIP-маршрутізатори пристосовуються складніше. Це пов’язано з тим, що у форматі повідомлень протоколу RIP немає поля, яке б вказувало на те, що шлях до цієї мережі більше не існує.
Замість цього використовуються два механізми повідомлення про те, що деякий маршрут більш недійсний:
- закінчення часу життя маршруту;
- вказівка спеціальної відстані (нескінченної) до мережі, що стала недоступною.
Для відпрацювання першого механізму кожен запис таблиці маршрутизації (як і записи таблиці просування моста/комутатора), отримана за протоколом RIP, має час життя (TTL). При надходженні чергового RIP-повідомлення, яке підтверджує справедливість даного запису, таймер TTL встановлюється в початковий стан, а потім з нього кожну секунду віднімається одиниця. Якщо за час тайм-ауту не прийде нове маршрутне повідомлення про цей маршрут, то він позначається як недійсний.
Час тайм-ауту пов’язаний з періодом розсилки векторів по мережі. У RIP IP період розсилки рівний 30 секундам, а в якості тайм-ауту вибрано шестиразове значення періоду розсилки, тобто 180 секунд. Вибір досить малого часу періоду розсилки пояснюється декількома причинами. Шестиразовий запас часу потрібний для впевненості в тому, що мережа дійсно стала недоступна, а не просто відбулися втрати RIP-повідомлень (а це можливо, оскільки RIP використовує транспортний протокол UDP, який не забезпечує надійної доставки повідомлень).
Якщо який-небудь маршрутизатор відмовляє і перестає слати своїм сусідам повідомлення про мережі, які можна досягти через нього, то через 180 секунд всі записи, які породив цей маршрутизатор, стануть недійсними у його найближчих сусідів. Після цього процес повториться вже для сусідів найближчих сусідів – вони викреслять подібні записи вже через 360 секунд, тому що перші 180 секунд найближчі сусіди ще передавали повідомлення про ці записи.
Як видно з пояснення, відомості про недоступні мережі через маршрутизатор, що відмовив поширюються по мережі не дуже швидко, час поширення кратний часу життя запису, а коефіцієнт кратності дорівнює кількості хопов між самими далекими маршрутизаторами мережі. У цьому полягає одна з причин вибору періоду розсилки в 30 секунд.
Якщо відмовляють не маршрутизатор, а інтерфейс або мережу, що зв’язують його з яким-небудь сусідом, то ситуація зводиться до щойно описаної – знову починає працювати механізм тайм-ауту і маршрути, стали недійсними поступово будуть викреслені з таблиць всіх маршрутизаторів мережі.
Тайм-аут працює в тих випадках, коли маршрутизатор не може послати сусідам повідомлення про маршрути, що відмовили, тому що або він сам непрацездатний, або непрацездатна лінія зв’язку, по якій можна було б передати повідомлення.
Коли ж повідомлення послати можна, RIP-маршрутизатори не використовують спеціальної ознаки в повідомленнях, а вказують нескінченну відстань до мережі, причому в протоколі RIP воно вибрано рівним 16 хопам (при іншій метриці необхідно вказати маршрутизатору її значення, що вважається нескінченністю). Отримавши повідомлення, в якому деяка мережу супроводжується відстанню 16 (або 15, що призводить до того ж результату, так як маршрутизатор нарощує отримане значення на 1), маршрутизатор повинен перевірити, надходить ця «погана» інформація про мережу від того ж маршрутизатора, повідомлення якого послужило свого часу підставою для запису про дану мережу в таблиці маршрутизації. Якщо це той же маршрутизатор, то інформація вважається достовірною і маршрут позначається як недоступний.
Таке невелике значення «нескінченної» відстані викликано тим, що в деяких випадках відмови зв’язків у мережі викликають тривалі періоди некоректної роботи RIP-маршрутизаторів, що виражається в зацикленні пакетів у петлях мережі. І чим менше відстань, що використовується як «нескінченна», тим такі періоди стають коротшими.
Приклад зациклювання пакетів
Розглянемо випадок зациклювання пакетів на прикладі мережі, зображеної на рис. 1.
Нехай маршрутизатор Ml виявив, що його зв’язок з безпосередньо підключеною мережею 201.36.14.0 втрачена (наприклад, з причини відмови інтерфейсу 201.36.14.3). Ml зазначив у своїй таблиці маршрутизації, що мережа 201.36.14.0 недоступна. У гіршому випадку він виявив це відразу ж після відправлення чергових RIP-повідомлень, так що до початку нового циклу його оголошень, в якому він повинен повідомити сусідам, що відстань до мережі 201.36.14.0 стало рівним 16, залишається майже 30 секунд.
Кожен маршрутизатор працює на підставі свого внутрішнього таймера, не синхронізуючи роботу по розсилці оголошень з іншими маршрутизаторами. Тому дуже ймовірно, маршрутизатор М2 випередив маршрутизатор Ml і передав йому своє повідомлення раніше, ніж Ml встиг передати новину про недосяжність мережі 201.36.14.0. А в цьому повідомленні є дані, що породжені наступним записом в таблиці маршрутизації М2.
Таблиця. Таблиця маршрутизації маршрутизатора М2.
Цей запис був отриманий від маршрутизатора Ml і коректна до відмови інтерфейсу 201.36.14.3, а тепер вона застаріла, але маршрутизатор М2 про це не дізнався.
Тепер маршрутизатор Ml отримав нову інформацію про мережу 201.36.14.0 – ця мережа досяжна через маршрутизатор М2 з метрикою 2. Раніше Ml також отримував цю інформацію від М2. Але ігнорував її, так як його власна метрика для 201.36.14.0 була краща. Тепер Ml повинен прийняти дані про мережу 201.36.14.0, отримані від М2, і замінити запис в таблиці маршрутизації про недосяжність цієї мережі.
Таблиця. Таблиця маршрутизації маршрутизатора М1.
У результаті в мережі утворилася маршрутна петля: пакети, що направляються вузлам мережі 201.36.14.0, будуть передаватися маршрутизатором М2 маршрутизатору Ml, а маршрутизатор Ml буде повертати їх маршрутизатору М2. IP-пакети будуть циркулювати по цій петлі до тих пір, поки не закінчиться час життя кожного пакета.
Маршрутна петля буде існувати в мережі досить довго. Розглянемо періоди часу, кратні часу життя записів у таблицях маршрутизаторів.
- Час 0-180 с. Після відмови інтерфейсу в маршрутизаторах Ml і М2 будуть зберігатися некоректні записи, наведені вище. Маршрутизатор М2 як і раніше постачає маршрутизатор Ml своїм записом про мережу 201.36.14.0 з метрикою 2, так як її час життя не закінчився. Пакети зациклюються.
- Час 180-360 с. На початку цього періоду у маршрутизатора М2 закінчується час життя запису про мережу 201.36.14.0 з метрикою 2, так як маршрутизатор Ml в попередній період посилав йому повідомлення про мережу 201.36.14.0 з гіршого метрикою, ніж у М2, і вони не могли підтверджувати цей запис. Тепер маршрутизатор М2 приймає від маршрутизатора Ml запис про мережу 201.36.14.0 з метрикою 3 та трансформує її в запис з метрикою 4. Маршрутизатор Ml не отримує нових повідомлень від маршрутизатора М2 про мережу 201.36.14.0 з метрикою 2, тому час життя його запису починає зменшуватися. Пакети продовжують зациклюватися.
- Час 360-540 с. Тепер у маршрутизатора Ml закінчується час життя запису про мережу 201.36.14.0 з метрикою 3. Маршрутизатори Ml і М2 знову міняються ролями – М2 постачає Ml застарілою інформацією про шлях до мережі 201.36.14.0, вже з метрикою 4, яку Ml перетворює в метрику 5. Пакети продовжують зациклюватися.
Якщо б у протоколі RIP не було вибрано відстань 16 як недосяжна, то описаний процес тривав би до нескінченності (вірніше, поки не була б вичерпана розрядна сітка поля відстані і не було б зафіксовано переповнення при черговому нарощуванні відстані).
У результаті маршрутизатор М2 на черговому етапі описаного процесу отримує від маршрутизатора Ml метрику 15, яка після нарощування, перетворюючись на метрику 16, фіксує недосяжність мережі. Період нестабільної роботи мережі тривав 36 хвилин!
Обмеження в 15 хопов звужує сферу застосування протоколу RIP до мереж, в яких число проміжних маршрутизаторів не може бути більше 15. Для більш масштабних мереж потрібно застосовувати інші протоколи маршрутизації, наприклад OSPF, або розбивати мережу на автономні області.
Наведений приклад добре ілюструє головну причину нестабільної роботи маршрутизаторів, що працюють по протоколу RIP. Ця причина полягає в самому принципі роботи дистанційно-векторних протоколів – користування інформацією, отриманою з других рук. Дійсно, маршрутизатор М2 передав маршрутизатору Ml інформацію про досяжності мережі 201.36.14.0, за достовірність якої він сам не відповідає. Викорінити цю причину повністю не можна, адже сам спосіб побудови таблиць маршрутизації пов’язаний з передачею чужої інформації без зазначення джерела її походження.
Не слід думати, що при будь-яких відмовах інтерфейсів і маршрутизаторів в мережах виникають маршрутні петлі. Якби маршрутизатор Ml встиг передати повідомлення про недосяжність мережі 201.36.14.0 раніше неправдивої інформації маршрутизатора М2, то маршрутна петля не утворилася б. Так що маршрутні петлі навіть без додаткових методів боротьби з ними, описаними в наступному розділі, виникають в середньому не більш ніж у половині потенційно можливих випадків.
Методи боротьби з помилковими маршрутами в протоколі RIP
Незважаючи на те що протокол RIP не в змозі повністю виключити перехідні стани в мережі, коли деякі маршрутизатори користуються застарілою інформацією про вже неіснуючі маршрути, є кілька методів, які в багатьох випадках вирішують подібні проблеми.
Ситуація з петлею, що утворюється між сусідніми маршрутизаторами, описана в попередньому розділі, надійно вирішується за допомогою методу, який отримав назву розщеплення горизонту (split horizon). Метод полягає в тому, що маршрутна інформація про деяку мережу, що зберігається в таблиці маршрутизації, ніколи не передається тому маршрутизатора, від якого вона отримана (це наступний маршрутизатор в даному маршруті). Якщо маршрутизатор М2 в розглянутому вище прикладі підтримує техніку розщеплення горизонту, то він не передасть маршрутизатора Ml застарілу інформацію про мережу 201.36.14.0, оскільки отримав її саме від маршрутизатора Ml.
Практично всі сьогоднішні маршрутизатори, що працюють по протоколу RIP, використовують техніку розщеплення горизонту.
Однак розщеплення горизонту не допомагає в тих випадках, коли петлі утворюються не двома, а кількома маршрутизаторами. Розглянемо більш детально ситуацію, яка виникне в мережі, наведеною на рис. 1, у разі втрати зв’язку маршрутизатора 2 з мережею А. Нехай всі маршрутизатори цієї мережі підтримують техніку розщеплення горизонту. Маршрутизатори М2 і МЗ не повертатимуть маршрутизатора в цій ситуації дані про мережу 201.36.14.0 з метрикою 2, так як вони отримали цю інформацію від маршрутизатора Ml. Однак вони будуть передавати маршрутизатору інформацію про досяжності мережі 201.36.14.0 з метрикою 4 через себе, тому що отримали цю інформацію по складному маршруту, а не від маршрутизатора Ml безпосередньо. Наприклад, маршрутизатор М2 отримав цю інформацію по ланцюжку М4-МЗ-М1. Тому маршрутизатор Ml знову може бути обдуреним, поки кожен з маршрутизаторів в ланцюжку МЗ-М4-М2 не викреслить запис про досяжності мережі 1 (а це відбудеться через період 3 х 180 секунд).
Для запобігання зациклення пакетів по складовим петлям при відмовах зв’язків застосовуються два інших прийоми, так звані тригерні оновлення (triggered updates) і заморожування змін (hold down).
Спосіб тригерних оновлень полягає в тому, що маршрутизатор, отримавши дані про зміну метрики до будь-якої мережі, не чекає закінчення періоду передачі таблиці маршрутизації, а передає дані про зміну маршруту негайно. Цей прийом може в багатьох випадках запобігти передачі застарілих відомостей про маршрут, що відмовив, але він перевантажує мережу службовими повідомленнями, тому тригерні оголошення також робляться з деякою затримкою. Тому можлива ситуація, коли регулярне оновлення в будь-якому маршрутизаторі трохи випередить за часом прихід тригерніх оновлень від попереднього в ланцюжку маршрутизатора і даний маршрутизатор встигне передати по мережі застарілу інформацію про неіснуючий маршрут.
Другий прийом дозволяє виключити подібні ситуації. Він пов’язаний з введенням тайм-ауту на прийняття нових даних про мережу, яка щойно стала недоступною. Цей тайм-аут запобігає прийняттю застарілих відомостей про деякий маршрут від тих маршрутизаторів, які знаходяться на деякій відстані від зв’язку, що відмовив та передають застарілі відомості про його працездатність. Передбачається, що протягом тайм-ауту «заморожування змін» ці маршрутизатори викреслять даний маршрут зі своїх таблиць, оскільки не отримають про нього нових записів і не поширюватимуть застарілі відомості по мережі.
OSPF
OSPF (Open Shortest Path First) – протокол динамічної маршрутизації, заснований на технології відстеження стану каналу (про стан каналу технологій) і використовує для знаходження найкоротшого шляху алгоритм Дейкстри.
Протокол OSPF був розроблений IETF в 1988 році. Остання версія протоколу представлена в RFC 2328. Протокол OSPF являє собою протокол внутрішнього шлюзу (Interior Gateway Protocol – IGP). Протокол OSPF поширює інформацію про доступні маршрути між маршрутизаторами однієї автономної системи.
OSPF пропонує вирішення наступних завдань:
- Збільшення швидкості збіжності (у порівнянні з протоколом RIP2, так як немає необхідності вичікування багаторазових тайм-аутів по 30с);
- Підтримка мережевих масок змінної довжини (VLSM);
- Досяжність мережі (швидко виявляються маршрутизатори, що відмовили і топологія мережі змінюється відповідним чином);
- Оптимальне використання пропускної спроможності (так як будується мінімальний остовний граф за алгоритмом Дейкстри);
- Метод вибору шляху.
Опис роботи протоколу
- Маршрутизатори обмінюються hello-пакетами через всі інтерфейси, на яких активований OSPF. Маршрутизатори, що розділяють загальний канал передачі даних, стають сусідами, коли вони приходять до домовленості про певні параметри, зазначених в їх hello-пакетах.
- На наступному етапі роботи протоколу маршрутизатори будуть намагатися перейти в стан суміжності з маршрутизаторами, які перебувають з ними у межах прямого зв’язку (на відстані одного хопу). Перехід у стан суміжності визначається типом маршрутизаторів, які обмінюються hello-пакетами, і типом мережі, по якій передаються hello-пакети. OSPF визначає кілька типів мереж і кілька типів маршрутизаторів. Пара маршрутизаторів, що знаходяться в стані суміжності, синхронізує між собою базу даних стану каналів.
- Кожен маршрутизатор посилає оголошення про стан каналу маршрутизаторам, з якими він знаходиться в стані суміжності.
- Кожен маршрутизатор, який отримав оголошення від суміжного маршрутизатора, записує передану в ньому інформацію в базу даних стану каналів маршрутизатора і розсилає копію оголошення всім іншим суміжним з ним маршрутизаторам.
- Розсилаючи оголошення через зону, всі маршрутизатори будують ідентичну базу даних стану каналів маршрутизатора.
- Коли база даних побудована, кожен маршрутизатор використовує алгоритм Дейкстри для обчислення графа без петель, який буде описувати найкоротший шлях до кожного відомого пункту призначення з собою в якості кореня. Цей граф – дерево найкоротших шляхів.
- Кожен маршрутизатор будує таблицю маршрутизації зі свого дерева найкоротших шляхів.
Типи мереж, підтримувані протоколом OSPF
- Широкомовні мережі з множинним доступом (Ethernet, Token Ring)
- Точка-точка (T1, E1, комутований доступ)
- Мережі з множинним доступом (NBMA) (Frame relay)
- Віртуальні канали (virtual links)
Типи оголошень про стан каналу (LSA)
Type 1 LSA – Router LSA – оголошення про стан каналів маршрутизатора. Ці LSA поширюються всіма маршрутизаторами. У LSA міститься опис усіх каналів маршрутизатора і вартість (cost) кожного каналу. Поширюються тільки в межах однієї зони.
Type 2 LSA – Network LSA – оголошення про стан каналів мережі. Поширюється DR в мережах з множинним доступом. У LSA міститься опис всіх маршрутизаторів приєднаних до мережі, включаючи DR. Поширюються тільки в межах однієї зони.
Type 3 LSA – Network Summary LSA – сумарне оголошення про стан каналів мережі. Оголошення поширюється прикордонними маршрутизаторами. Оголошення описує тільки маршрути до мереж поза зоною і не описує маршрути усередині автономної системи. Прикордонний маршрутизатор відправляє окреме оголошення для кожної відомої йому мережі.
Коли маршрутизатор отримує Network Summary LSA від прикордонного маршрутизатора він не запускає алгоритм обчислення найкоротшого шляху. Маршрутизатор просто додає до вартості маршруту, вказаного в LSA вартість маршруту до прикордонного маршрутизатора. Потім маршрут до мережі через прикордонний маршрутизатор поміщається в таблицю маршрутизації.
Type 4 LSA – ASBR Summary LSA – сумарне оголошення про стан каналів прикордонного маршрутизатора автономної системи. Оголошення поширюється прикордонними маршрутизаторами. ASBR Summary LSA відрізняється від Network Summary LSA тим, що поширюється інформація не про мережу, а про прикордонний маршрутизаторі автономної системи.
Type 5 LSA – AS External LSA – оголошення про стан зовнішніх каналів автономної системи. Оголошення поширюється прикордонним маршрутизатором автономної системи в межах всієї автономної системи. Оголошення описує маршрути зовнішні для автономної системи OSPF або маршрути за замовчуванням (default route) зовнішні для автономної системи OSPF.
Type 6 LSA – Multicast OSPF LSA – спеціалізований LSA, який використовують мультікаст OSPF додатки (Not implemented by CISCO).
Type 7 LSA – AS External LSA for NSSA – оголошення про стан зовнішніх каналів автономної системи в NSSA зоні. Це оголошення може передаватися тільки в NSSA зоні. На кордоні зони прикордонний маршрутизатор перетворює type 7 LSA в type 5 LSA.
Type 8 LSA – Link LSA – анонсує link-local адреса і префікс (и) маршрутизатора всім маршрутизаторам розділяє канал (link). Відправляється тільки якщо на каналі присутні більше ніж один маршрутизатор. Поширюються лише в межах каналу (link).
Формат заголовка OSPF-пакета
OSPF-пакет інкапсулюється безпосередньо в полі даних IP-пакета. Значення поля «протокол верхнього рівня» в заголовку IP-дейтаграми для OSPF дорівнює 89.
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version | type | packet length |
+---------------+---------------+-------------------------------+
| router ID |
+---------------------------------------------------------------+
| area ID |
+-------------------------------+-------------------------------+
| checksum | authentication type |
+-------------------------------+-------------------------------+
| authentication |
+---------------------------------------------------------------+
| authentication |
+---------------------------------------------------------------+
- Version – номер версії протоколу OSPF. Поточна версія OSPF для мереж IPv4 – 2.
- Type – тип OSPF-пакета. В RFC 2328 описано 5 типів пакетів.
- Packet length – довжина пакету, включаючи заголовок.
- Router ID – ідентифікатор маршрутизатора – унікальне 32-хбітное число, ідентифікує
маршрутизатор в межах автономної системи.
- Area ID – 32-хбітний ідентифікатор зони.
- Checksum – поле контрольної суми. Підраховується для всього пакету, включаючи заголовок.
- Authentication type – тип використовуваної схеми аутентифікації. Можливі значення:
- 0 – аутентифікація не використовується
- 1 – аутентифікація відкритим текстом
- 2 – MD5-аутентифікація
- Authentication – поле даних аутентифікації.
Формат Hello-пакета
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version | type | packet length |
+---------------+---------------+-------------------------------+
| router ID |
+---------------------------------------------------------------+
| area ID |
+-------------------------------+-------------------------------+
| checksum | authentication type |
+-------------------------------+-------------------------------+
| authentication |
+---------------------------------------------------------------+
| authentication |
+---------------------------------------------------------------+
| network mask |
+-------------------------------+---------------+---------------+
| hello interval | options |router priority|
+-------------------------------+---------------+---------------+
| router dead interval |
+---------------------------------------------------------------+
| designated router |
+---------------------------------------------------------------+
| backup designated router |
+---------------------------------------------------------------+
| neighbor ID |
+---------------------------------------------------------------+
| neighbor ID |
+---------------------------------------------------------------+
| ... |
Нижче наведено короткий опис полів hello-пакета.
- Network mask – мережева маска інтерфейсу, через який відправляється hello-пакет.
- Hello interval – hello-інтервал задає частоту розсилки вітальних повідомлень для виявлення сусідів в автономній системі. Для LAN значення за замовчуванням дорівнює 10 секундам.
- Options – 8-бітове поле опцій. Описує можливості маршрутизатора.
- Router priority – пріоритет маршрутизатора – 8-бітове число, яке символізує пріоритет маршрутизатора при виборі DR і BDR.
- Router dead interval – період часу, протягом якого маршрутизатор очікує відповіді сусідів.
- Designated router (DR) – IP-адреса DR.
- Backup designated router (BDR) – IP-адреса BDR.
- Neighbor ID – ідентифікатор сусіда. Список складається з ідентифікаторів сусідів, від яких маршрутизатор отримав hello-пакети протягом часу, заданого в поле router dead interval.
Переваги OSPF
- Для кожної адреси може бути кілька маршрутних таблиць, по одній на кожен вид IP-операції (TOS).
- Кожному інтерфейсу привласнюється безрозмірна ціна, що враховує пропускну здатність, час транспортування повідомлення. Для кожної IP-операції може бути привласнена своя ціна (коефіцієнт якості).
- При існуванні еквівалентних маршрутів OSFP розподіляє потік рівномірно по цих маршрутах.
- Підтримується адресація субмереж (різні маски для різних маршрутів).
- При зв’язку точка-точка не потрібно IP-адресу для кожного з кінців. (Економія адрес!)
Застосування мультикастингу замість широкомовних повідомлень знижує завантаження не залучених сегментів.
Недоліки OSPF
- Важко отримати інформацію про перевагу каналів для вузлів, що підтримують інші протоколи, або зі статичною маршрутизацією.
- OSPF є лише внутрішнім протоколом.
IGP
Протокол IGRP (англ. Interior Gateway Routing Protocol) – протокол маршрутизації, розроблений фірмою Cisco, для своїх багато протокольних маршрутизаторів в середині 80-х років для маршрутизації в межах автономної системи (AS), що має складну топологію і різні характеристики смуги пропускання і затримки. IGRP є протоколом внутрішніх роутерів (IGP) з вектором відстані.
Для вибору маршруту в IGRP використовується комбінація показників, таких як затримка мережі, смуга пропускання, надійність і завантаженість мережі. Ваговий коефіцієнт цих показників може вибиратися автоматично або задаватися адміністратором мережі. Для надійності і завантаженості мережі це значення від 1 до 255, смуга пропускання – від 1200 біт / сек до 10 Гбіт / сек, затримка може приймати значення до 24-го порядку.
Для підвищення стабільності роботи IGRP передбачає такі механізми, як утримання змін, розділений горизонт (split-horizon) і коригування скасування.
Утримання змін Коли в мережу надходить інформація про зміни маршрутів (наприклад, про обрив зв’язку) від одного з роутерів, то зміни в таблиці маршрутизації надходять не миттєво, а протягом деякого часу. У цей період роутер, ще не отримав інформацію про зміни, може продовжувати поширювати інформацію про вже неіснуючому маршруті. При цьому можлива ситуація, коли пристрій, вже внёсшее зміни в свою таблицю маршрутизації, після отримання цих даних внесе повторне коригування в таблицю. Тимчасове утримання змін – це механізм, за яким утримуються всі зміни, які можуть вплинути на маршрути протягом деякого часу. Час утримання повинно бути більше часу, необхідного для того, щоб інформація про змінені маршрутах поширилася по всьому роутера системи.
Розділений горизонт (split-horizon) Суть цього механізму полягає в тому, для запобігання зациклення маршрутів між сусідніми роутерами, інформація про зміну маршруту не повинна поширюватися в напрямку того роутера, від якого вона прийшла.
Коригування скасування маршруту (route-poisoning) – це примусове видалення маршруту і переклад перейде в режим утримування, застосовується для боротьби з маршрутними петлями.
Таймери Таймер коригування визначає, як часто повинні відправлятися повідомлення про коригування маршрутів. Таймер недіючих маршрутів визначає, скільки часу повинен чекати роутер за відсутності повідомлень про коригування якогось конкретного маршруту, перш ніж оголосити цей маршрут недіючим. Час за замовчуванням IGRP для цієї змінної в три рази перевищує період коректування. Змінна величина часу утримування визначає проміжок часу утримування. Час за замовчуванням IGRP для цієї змінної в три рази більше періоду таймера коректування, плюс 10 сек. І нарешті, таймер відключення вказує, скільки часу має пройти перш, ніж який-небудь роутер повинен бути виключений з маршрутної таблиці. Час за замовчуванням IGRP для цієї величини в сім разів перевищує період коректування маршрутизації.
EIGRP
Enhanced Interior Gateway Routing Protocol – (EIGRP) – це пропрієтарний протокол маршрутизації, що базується на старому протоколі IGRP. EIGRP – дистанційно-векторний протокол маршрутизації, що був оптимізований для зменшення нестабільності протоколу після змін топології мережі, уникнення проблеми зациклення маршруту та більш ефективного і економного використання потужностей маршрутизатора. Роутери, що підтримують протокол EIGRP також підтримують і IGRP та перетворюють маршрутну інформацію для IGRP-сусідів з 32-бітної метрики EIGRP у 24-бітну метрику стандарту IGRP. Алгоритм визначення маршруту базується на алгоритмі Дейкстри пошуку в глибину на графі. EIGRP обчислює і враховує 5 параметрів для кожної ділянки маршруту між вузлами мережі:
- Total Delay – Загальна затримка передачі (з точністю до мікросекунди)
- Minimum Bandwidth – Мінімальна пропускна спроможність (в Кб/с – кілобіт/секунду)
- Reliability – Надійнсть (оцінка від 1 до 255; 255 найбільш надійно)
- Load – Завантаження (оцінка від 1 до 255; 255 найбільш завантажено)
- Maximum Transmission Unit (MTU) (не враховується при обчисленні оптимального маршруту, береться до уваги окремо) – максимальний розмір блоку, що можливо передати по ділянці маршруту.
Формула обчислення оцінки ділянки:
де (K1-K5) – змінні, що визначаються вручну користувачем для зміни приорітетів обчислення оцінок. За замовчанням всі змінні дорівнюють 1.
EIGRP обчислює пропускну спроможність і затримку наступним чином:
Bandwidth = 107 / Interface Bandwidth (пропускна спроможність інтерфейсу) Delay = Interface Delay(затримка інтерфейсу) / 10
На маршрутизаторах Cisco Interface Bandwidth (пропускна спроможність інтерфейсу) є налаштованим параметром, що задається користувачем. Аналогічно Interface Delay (затримка інтерфейсу) є конфігурованим статичним параметром. EIGRP також обчислює кількість вузлів (хопів – hop) для кожного маршруту, проте не використовує це в обчисленні маршруту. Це лише перевіряється з вбудованим максимумом на маршрутизаторі EIGRP (за замовчанням це встановлюється на 100 і може бути змінено на будь-яке значення між 1 і 255). Якщо число хопів для певного вузла вище, ніж максимум, вузол вважатиметься як недосяжний маршрутизатором.
SNMP
SNMP (англ. Simple Network Management Protocol — простий протокол керування мережею) — це протокол керування мережами зв’язку на основі архітектури TCP/IP.
Сімейство стандартів SNMP створено для вирішення задач обробки помилок і аналізу продуктивності і надійності.
Обробка помилок
Виявлення, визначення і усунення наслідків збоїв і відмов у роботі мережі. На цьому рівні виконується реєстрація повідомлень про помилки, їх фільтрація, маршрутизація і аналіз на основі деякої кореляційної моделі.
Аналіз продуктивності і надійності
Оцінка на основі статистичної інформації таких параметрів, як час реакції системи, пропускна спроможність каналів зв’язку, інтенсивність трафіку в окремих сегментах мережі, імовірність спотворення даних, коефіцієнт готовності служб мережі. Результати такого аналізу дозволяють контролювати угоду про рівень обслуговування (Service Level Agreement, SLA).
Згідно з ідеологією SNMP, управління повинне бути простим, нехай навіть ціною втрати потужності, масштабованості і захищеності. Тому при розробці стандартів SNMP враховувалися наступні умови:
- Широка сфера застосування. Системи під управлінням SNMP можуть бути будь-якими і можуть бути скрізь: від принтерів до мейнфреймів;
- Простота додавання керуючих функцій. Керована система обмежена в функціональності управління, дуже проста і не може контролювати себе. Замість цього всі керовані системи контролює складна керуюча система, функціональність якої можна розширювати;
- Стійкість у критичних ситуаціях. Наприклад, при перевантаженні і проблемах в мережі, тобто при множинних помилках.
Архітектура
Архітектуру розподіленої системи можна описати в термінах обробних елементів (або компонентів), що з’єднують елементів (або з’єднувачів) і елементів даних. Перерахуємо складові елементи системи управління SNMP:
1. компоненти:
- агент;
- менеджер;
2. з’єднувачі:
- транспортний протокол;
- Протокольні блоки даних (Protocol Data Units, PDU) і повідомлення SNMP;
3. дані:
- Керуюча інформація MIB;
Опишемо детальніше і проаналізуємо архітектуру SNMP з позиції досягнення поставлених перед SNMP цілей. Для цього використовуємо поняття архітектурного стилю мережевого програмного забезпечення. Архітектурний стиль – це узгоджений набір архітектурних обмежень, накладених на ролі і особливості архітектурних елементів (компонентів, з’єднувачів і даних) і відносин між ними, яка проявляється у будь-якій архітектурі, і яка задовольняє цьому стилю.
Компоненти
Архітектура SNMP передбачає побудову системи управління за схемою «менеджер-агент», тобто використання архітектурного стилю «клієнт-сервер». Система SNMP містить безліч керованих вузлів, на кожному з яких розміщується досить простий сервер – агент SNMP, а також, принаймні, один вузол, що містить складного клієнта – менеджера SNMP.
Менеджер взаємодіє з агентами за допомогою протоколу SNMP з метою обміну керуючою інформацією. В основному, ця взаємодія реалізується у вигляді періодичного опитування менеджером множини агентів, так як агенти всього лише надають доступ до інформації, але не знають, що їм з нею робити. Видно, що система, побудована за такими принципами, втрачає масштабованость, оскільки є виділений клієнт, який займається опитуванням всіх серверів. Зате така схема забезпечує простоту реалізації систем під управлінням SNMP.
Для підвищення масштабованості та адміністративної керованості вводиться поняття проксі-агента, який може переправляти операції протоколу SNMP, а також поняття менеджера проміжного рівня, який приховує несуттєві подробиці керуючої інформації від систем управління мережами верхнього рівня, інтегруючи одержувані від агентів дані. Це дозволяє створювати багаторівневі системи управління, що відповідають архітектурному стилю «багаторівневий клієнт-сервер».
Більш детальна класифікація компонентів за ролями:
1. Менеджер:
- Менеджер проміжного рівня;
- Система управління мережами;
2. Агент:
- Мінімальний агент;
- Проксі-агент;
Компоненти в SNMP узагальнено називаються сутностями SNMP.
Дані
Тепер розглянемо дані, якими маніпулюють системи SNMP, тобто керуючу інформацію. У SNMP кожний керований пристрій, на якому розташований агент, представляє свою керуючу інформацію у вигляді змінних. Такими змінними можуть бути, наприклад, ім’я системи, час з моменту її перезапуску, записи в таблиці маршрутизації і т. д. В загальному випадку змінні можна розділити на:
- Скалярні змінні;
- Таблиці змінних;
Схема даних описується структурою керуючої інформації (Structure of Management Information, SMI). Схема даних визначає, як виглядає керуюча інформація, тобто описує її синтаксис. SMI базується на Abstract Syntax Notation One (ASN.1).
Конкретні набори керуючої інформації для різних типів пристроїв, протоколів і т. д. описуються базами керуючої інформації (Management Information Bases, MIBs). Бази MIB визначають, яка управляюча інформація існує. Наприклад, для пристрою, що підтримує IP, MIB описує таблицю маршрутизації, прапорець активації функції маршрутизації, число переданих і прийнятих пакетів, число помилок різного характеру і т. д.
Таким чином, кожен пристрій містить набір значень змінних, визначених у деякій кількості MIB, описаних за правилами SMI. Цей набір змінних і є даними, що управляє інформацією для протоколу SNMP.
Важливим питанням є іменування змінних. У SNMP кожній змінній присвоюється унікальний ідентифікатор об’єкта (Object Identifier, OID). Простір імен OID є ієрархічним і контролюється організацією по розподілу номерів в Інтернеті (Internet Assigned Numbers Authority, IANA). Кожен компонент імені є числом. В текстовому вигляді імена записуються як десяткові числа, розділені крапками, зліва направо. Числам можуть бути поставлені у відповідність текстові рядки для зручності сприйняття. У цілому, структура імені схожа на систему доменних імен Інтернету (Domain Name System, DNS).
Кожна MIB визначає набір змінних, тобто певну гілку дерева OID, що описує керуючу інформацію в певній галузі. Наприклад, гілка 1.3.6.1.2.1.1 (мнемонічний еквівалент: iso.org.dod.internet.mgmt.mib-2.system) описує загальну інформацію про систему. Опишемо деякі змінні з цієї гілки:
- sysDescr (1.3.6.1.2.1.1.1) – короткий опис системи;
- sysUpTime (1.3.6.1.2.1.1.3) – час з моменту останнього перезапуску;
- sysName (1.3.6.1.2.1.1.5) – назва системи.
Змінні і відомості про їхній тип визначені також в MIB. А самі типи змінних – в SMI.
Крім безпосередньо даних, необхідно ввести операції над ними. Набір цих операцій змінювався і розширювався в міру розвитку SNMP. Основними операціями є:
- Читання змінної;
- Запис змінної;
- Читання змінної, наступної за заданою змінною (необхідне для перегляду таблиць змінних);
Більш докладно операції над даними описані нижче при обговоренні з’єднувачів в архітектурі SNMP.
В цілому, операції над даними в SNMP схожі на віддалене налагодження деякої програми: стан системи описується певним набором змінних, які можна переглядати і змінювати.
З’єднувачі
Для обміну даними між компонентами використовуються з’єднувачі. У разі SNMP в якості з’єднувача використовується протокол прикладного рівня Simple Network Management Protocol (SNMP), що звичайно працює поверх стека протоколів TCP / IP.
Розглянемо стек протоколів більш докладно, вказавши прив’язку протоколів до Open Systems Interconnection Reference Model (OSI RM).
| № | Протокол | Коментарі |
| 7 | SNMP | Повідомлення, PDU, операції |
| 6 | ASN.1 BER | Кодування даних |
| 5 | – | – |
| 4 | UDP | Транспорт між службами |
| 3 | IP | Зв’язок між вузлами мережі |
SNMP вводить свій протокол прикладного рівня. Є чотири версії даного протоколу: SNMPv1, SNMPv2, SNMPv2c і SNMPv3. У процесі розвитку SNMP розширювалися можливі операції, тобто типи протокольних блоків даних (Protocol Data Units, PDUs), а також вводилися нові формати повідомлень SNMP для забезпечення безпеки.
Повідомлення SNMP містить номер версії SNMP, інформацію про безпеку та протокольний блок даних PDU, який характеризує виконувану операцію і її параметри. Наприклад, SNMPv1 описує наступні PDU і відповідні операції:
- Get-Request – запит на отримання значень 1 .. N змінних;
- Get-Next-Request – запит на отримання значень 1 .. N змінних, чиї OID йдуть слідом за OID зазначених 1 .. N змінних;
- Get-Response – відповідь на запити Get-Request, Get-Next-Request і Set-Request;
- Set-Request – установка значень 1 .. N змінних;
- Trap – пастка (див. нижче);
SNMP – це протокол типу “запит-відповідь”, тобто на кожен запит, що надійшов від менеджера, агент повинен передати відповідь.
Описані PDU, як уже згадувалося, є частиною повідомлення SNMP. Повідомлення кодуються для передачі по мережі за допомогою ASN.1 Basic Encoding Rules (BER). Це функція шостого рівня (рівня подання) еталонної моделі OSI. Далі закодовані повідомлення відправляються одним компонентом SNMP іншого за допомогою транспортного протоколу.
Як вже зазначалося, стандарт передбачає використання різного транспорту для SNMP, але майже завжди використовується протокол користувацьких датаграм (User Datagram Protocol, UDP). Агенти використовують добре відомий порт UDP 161. Цей протокол надає мінімальні транспортні послуги (доставка повідомлень від служби до служби і перевірка контрольної суми) і не передбачає організацію сеансів і потокову передачу даних, як Transmission Control Protocol (TCP). За рахунок цього вдається домогтися великої швидкості реакції і швидкодії, що відповідає поставленим перед SNMP цілям.
Для підвищення швидкості реакції менеджера на термінові події вводиться спеціальний тип операції протоколу SNMP, так звана «пастка» (Trap). Він дозволяє агентам асинхронно інформувати менеджера (за власною ініціативою) про настання обмеженого числа значущих подій. У цьому випадку агент виступає в незвичній для себе ролі клієнта, а менеджер – в ролі сервера. У разі використання транспорту UDP для вхідних з’єднань менеджер використовує добре відомий порт UDP 162.
Як ми бачимо, жодна з цих операцій не припускає, що агент зберігає інформацію про сесії з менеджером. Для виконання операції Trap така інформація зберігається статично, тобто сесія в такому випадку статична і перманентна. Крім цього операції SNMP визначають єдині, уніфіковані інтерфейси агентів і менеджерів SNMP. Таким чином, SNMP – це протокол без збереження стану, який відповідає архітектурному стилю «уніфікований багаторівневий клієнт-сервер без збереження стану».
Опишемо деякі властивості операцій SNMP на прикладі SNMPv1:
| Ім’я | Безпека | Підтвердження | Ідемпотентність |
| Get-Request | 1 | 1 | 1 |
| Get-Next-Request | 1 | 1 | 1 |
| Get-Response | 1 | 0 | ? |
| Set-Request | 0 | 1 | ? |
| Trap | 1 | 0 | ? |
Таким чином, ми розглянули всі основні архітектурні особливості SNMP, крім моделей безпеки. Питання, пов’язані із захистом інформації, будуть розглянуті нижче при обговоренні версій стандартів SNMP.
Відповідність архітектурному стилю REST
Архітектурний стиль REST – це уніфікований багаторівневий клієнт-серверний стиль, з кодом за запитом та без збереження стану (Unified-Layered-Code-on-Demand-Client-Cached-Stateless-Server, ULCODCСSS). Як ми визначили в результаті аналізу архітектури SNMP, система SNMP визначається уніфікованим багаторівневим клієнт-серверних стилем без збереження стану (Unified-Layered-Client-Stateless-Server, ULCSS).
Як ми бачимо, на SNMP не накладаються обмеження, пов’язані з реплікацією (наявність кеша) і мобільним кодом (застосування коду за вимогою). У цьому сенсі стиль SNMP – більш вільний, ніж REST, тобто містить менше архітектурних особливостей, які, наприклад, необхідно враховувати при моделюванні систем з такою архітектурою.
Однак, навіть у SNMPv1 є особлива операція Trap, що ініціюється агентом асинхронно по відношенню до менеджера. У SNMPv2 вводиться операція Inform-Request, яка також виконується асинхронно, але між двома менеджерами. При виконанні таких операцій клієнт і сервер міняються ролями. При цьому використовується принцип інтеграції на основі повідомлень. Це елементи однорангового стилю взаємодії (Peer-to-Peer), хоча в даному випадку ролі клієнта і сервера для конкретних типів протокольних операцій виражені явно. У цьому сенсі стиль SNMP – більш обмежений, ніж REST.
Таким чином, при певних обмеженнях система SNMP може бути розглянута як REST-івська розподілена система.
Структура стандартів
Стандарти SNMP описують аспекти, відображені нижче:
1. Загальна інформація;
2. Обробка повідомлень (SNMP Messages):
- Прив’язки до транспорту;
- Розбір і диспетчеризація повідомлень;
- Безпека (аутентифікація, шифрування, своєчасність);
3. Обробка протокольних блоків даних (SNMP PDUs):
- Операції протоколу;
- Програми SNMP;
- Управління доступом;
4. Інформаційна модель:
- Структура керуючої інформації (SMI);
- Текстові конвенції;
- Вирази відповідності;
5. Модулі баз керуючої інформації (MIB);
Спочатку в стандартах виділялися не всі ці аспекти. Проте, структура стандартів SNMP всіх версій вписується в цю схему.
Інформаційна безпека
Розглянемо, як враховуються в SNMP основні елементи інформаційної безпеки:
- Конфіденційність;
- Цілісність;
- Доступність;
- Контрольованість;
У ході розвитку стандартів SNMP інфраструктура безпеки піддавалася найбільших змін. Для того, щоб простежити ці зміни, спочатку опишемо вимоги безпеки та загрози, потім структуру моделей безпеки, після чого розглянемо використання в різних версіях SNMP моделі.
Вимоги та загрози безпеці
Опишемо вимоги безпеки в архітектурі SNMP. Загрозами безпеці, проти яких повинна надавати захист будь-яка модель безпеки SNMP, є:
1. Первинні загрози:
- Модифікація інформації;
- Маскарад;
2. Вторинні загрози:
- Модифікація потоку повідомлень;
- Розголошення;
Загроза модифікації інформації – це можливість того, що деяка неавторизована сутність може змінити повідомлення SNMP, згенеровані за запитом авторизованого принципала, на шляху їх слідування таким чином, що це призведе до неавторизованих операцій управління, включаючи фальсифікацію значення об’єкта (змінної).
Загроза маскараду – це можливість того, що операції управління, не авторизовані для деякого принципала, можуть бути виконані при підстановці ідентифікатора іншого принципала, для якого подібні дії авторизовані.
Загроза модифікації потоку повідомлень полягає в наступному. Протокол SNMP звичайно що грунтується на транспортній службі без організації з’єднання. Перестановка, затримка або повторна посилка повідомлень може відбуватися і відбувається в ході звичайної експлуатації мереж із застосуванням таких протоколів. Загроза модифікацій потоку повідомлень – це можливість того, що повідомлення можуть бути переставлені, затримані чи повторно надіслані зі злим умислом із затримками, які перевищують наявне місце затримки при нормальній експлуатації, з метою виконання неавторизованих операцій управління.
Загроза розголошення – це можливість прослуховування обмінів повідомленнями між сутностями SNMP. Захист від цієї загрози може вимагати локальної політики безпеки.
Модель безпеки може не боротися з такими загрозами, як, наприклад, відмова в обслуговуванні, оскільки стан мережевих збоїв і помилок (нормальне для SNMP) часто не відрізняються від ситуацій відмови в обслуговуванні.
Як ми побачимо нижче, на практиці не кожна модель безпеки SNMP задовольняє вимогам нейтралізації перерахованих загроз.
Структура моделей безпеки
Сутність SNMP містить дві підсистеми:
- Підсистема безпеки;
- Підсистема управління доступом;
Підсистема безпеки функціонує на рівні повідомлень SNMP. Вона відповідає за аутентифікацію, шифрування і своєчасність. Документ з безпеки описує модель безпеки, загрози, проти яких вона захищає, цілі моделі безпеки, протоколи, використовувані для досягнення цих цілей, модуль MIB, що описує відповідні структури даних. Такий модуль потрібний у тому числі і для того, щоб віддалено конфігурувати параметри безпеки рівня повідомлень SNMP.
Підсистема управління доступом функціонує на рівні SNMP PDU. Очевидно, що вона відповідає за управління доступом до керованих об’єктів (змінних). Документи, що описують її, також визначають модуль MIB для віддаленого налаштування параметрів.
Моделі безпеки
Перелічимо основні моделі безпеки та відповідні їм інфраструктури:
1. SNMPv1:
- SNMPv1 – Community-based Security Model;
2. SNMPv2:
- SNMPv2p – Party-based Security Model;
- SNMPv2c – Community-based Security Model;
- SNMPv2u – User-based Security Model;
3. SNMPv3
- SNMPv3 USM User-based Security Model.
Модель безпеки на основі спільнот (Community-based Security Model) була першою, найпростішою і найбезпечнішою. Вона полягає лише у аутентифікації на основі «рядка спільноти», фактично, пароля, переданого по мережі в тексті повідомлення SNMP у відкритому вигляді. Ця модель безпеки не в змозі боротися ні з однією із загроз інформаційної безпеки в SNMP. Тим не менш, вона часто використовується до цих пір у зв’язку зі своєю простотою, а також завдяки наявності зовнішніх, не пов’язаних з SNMP систем безпеки, наприклад, міжмережевих екранів.
Модель безпеки на основі сторін (Party-based Security Model) передбачає введення поняття сторони. Сторона – це віртуальне оточення виконання, в якому набір допустимих операцій обмежений адміністративно. Сутність SNMP при обробці повідомлення діє як сторона, тому обмежена операціями, визначеними для цієї сторони. Сторона визначається наступними параметрами:
- Унікальний ідентифікатор сторони;
- Логічна мережева адреса (область адрес транспортного протоколу та адреса транспортного протоколу);
- Протокол аутентифікації і параметри, що вимагаються для аутентифікації всіх повідомлень сторони;
- Протокол шифрування і параметри, потрібні для шифрування всіх повідомлень сторони;
Можуть використовуватися різні алгоритми для протоколів аутентифікації і шифрування. Звичайно як алгоритму для протоколу аутентифікації використовують хеш-функцію Message Digest 5 (MD5), а для протоколу шифрування – алгоритм Data Encryption Standard (DES) в режимі Cipher Block Chaining (CBC).
Запроваджуються й інші поняття, що використовуються для реалізації цієї моделі. Проте тут вони докладно не розглядаються, так само як і деталі функціонування моделі. Зазначимо лише, що при використанні відповідних протоколів аутентифікації і шифрування модель успішно справляється з описаними вище загрозами безпеці SNMP. Дана модель безпеки не була широко прийнята, оскільки є занадто складною і заплутаною.
Модель безпеки на основі користувачів (User-based Security Model) вводить поняття користувача, від імені якого діє сутність SNMP. Цей користувач характеризується ім’ям користувача, використовуваними протоколами аутентифікації і шифрування, а також закритим ключем аутентифікації і шифрування. Аутентифікація і шифрування є необов’язковими. Їх наявність описується одним з параметрів моделі, якістю обслуговування (Quality of Service, QoS). Модель безпеки багато в чому схожа на модель сторін, але вона спрощує ідентифікацію користувачів, розподіл ключів і протокольні операції.
Версії SNMP
Коротко опишемо відмінності між версіями SNMP і документи, що визначають ці версії. Зауважимо, що тут наведено перші версії RFC кожної з версій SNMP, тобто майже всі з них були заміщені новішими RFC і визнані застарілими. На даний момент єдиною не застарілою версією SNMP є SNMPv3, визначена в RFC 3411-3418.
SNMPv1
Перші RFC, що описують стандарти SNMP, з’явилися в 1988 році. Версія 1 піддалася критиці за її слабку модель безпеки на основі спільнот. У той час безпека в Інтернеті не входила в коло першочергових завдань робочих груп IETF.
1. Обробка повідомлень
- RFC 1067. A Simple Network Management Protocol;
2. Обробка PDU
- RFC 1067. A Simple Network Management Protocol;
3. Інформаційна модель
- Структура керуючої інформації
RFC 1065. Structure and Identification of Management Information for TCP / IP-based internets
4. Модулі MIB
- RFC 1066. Management Information Base for Network Management of TCP / IP-based internets
SNMPv2
Версія 2, відома, як Party-based SNMPv2, або SNMPv2p, не отримала широкого розповсюдження через серйозні розбіжності з приводу інфраструктури безпеки в стандарті.
SNMPv2 поліпшував версію 1 в області швидкодії, безпеки, конфіденційності і взаємодій «менеджер-менеждер». Він представив новий тип PDU Get-Bulk-Request, альтернативу Get-Next-Request для отримання великих обсягів інформації за допомогою одного запиту. Проте, нова система безпеки на основі сторін виглядала для багатьох як надто складна і не була широко визнана.
1. Загальна інформація
- RFC 1441. Introduction to version 2 of the Internet-standard Network Management Framework
- RFC 1452. Coexistence between version 1 and version 2 of the Internet-standard Network
Management Framework
2. Обробка повідомлень
- Прив’язки до транспорту. RFC 1448. Transport Mappings for SNMPv2
- Безпека. RFC 1446. Security Protocols for SNMPv2
3. Обробка PDU
- Управління доступом. RFC 1445. Administrative Model for SNMPv2
- Протокольні операції. RFC 1448. Protocol Operations for SNMPv2
4. Інформаційна модель
- Структура керуючої інформації. RFC 1442. Structure of Management Information SNMPv2
- Текстові конвенції. RFC 1443. Textual Conventions for SNMPv2
- Вирази відповідності. RFC 1444. Conformance Statements for SNMPv2
5. Модулі MIB
- RFC 1447. Party MIB for SNMPv2
- RFC 1450. MIB for SNMPv2
- RFC 1451. Manager-to-Manager MIB
SNMPv2c
Community-based SNMPv2, або SNMPv2c, представив SNMPv2 без нової моделі безпеки версії 2. Замість неї пропонувалося використовувати стару модель безпеки версії 1 на основі спільнот. Відповідну пропозицію RFC було прийнято тільки як чернетку стандарту, однак стало де факто стандартом SNMPv2. Безпека SNMP знову опинилася невирішеним питанням.
1. Обробка повідомлень
- Безпека. RFC 1901. Introduction to Community-based SNMPv2
SNMPv2u
User-based SNMPv2, або SNMPv2u, є компромісом між незахищеністю SNMPv1 і надмірною складністю SNMPv2p. Запропонована модель безпеки на основі користувачів була покладена в основу SNMPv3.
1. Обробка повідомлень
- Безпека. RFC 1909 – An Administrative Infrastructure for SNMPv2 RFC 1910 – User-based Security Model for SNMPv2
2. Обробка PDU
- Управління доступом. RFC 1909. An Administrative Infrastructure for SNMPv2
SNMPv3
SNMPv3 нарешті вирішив проблеми з безпекою способом, який багато хто вважав прийнятним. Версія 3 SNMP прийнята IETF як стандарт Інтернету (IETF STD 62). Майже всі попередні RFC визнані застарілими.
1. Загальна інформація
- RFC 3411. An Architecture for Describing SNMP Management Frameworks
2. Обробка повідомлень
- Прив’язки до транспорту. RFC 3417. Transport Mappings for the SNMP
- Розбір і диспетчеризація повідомлень. RFC 3412. Message Processing and Dispatching for the SNMP
- Безпека. RFC 3414. User-based Security Model (USM) for SNMPv3
3. Обробка PDU
- Операції протоколу. RFC 3416. Version 2 of the Protocol Operations for SNMP
- Програми SNMP. RFC 3413. SNMP Applications
- Управління доступом. RFC 3415. View-based Access Control Model (VACM) for the SNMP
4. Модулі MIB. RFC 3418. MIB for the SNMP
Існуючі реалізації
Підтримка SNMP – у багатьох значущих системах управління мережами, зокрема:
- HP Network Node Manager;
- IBM Tivoli NetView;
- OpenNMS
Недоліки SNMP
Протокол SNMP служить основою багатьох систем управління, хоча має кілька принципових недоліків, які перераховані нижче:
- Відсутність засобів взаємної аутентифікації агентів і менеджерів. Єдиним засобом, який можна було б віднести до засобів аутентифікації, є використання в повідомленнях так званого рядка «community string». Цей рядок передається по мережі у відкритій формі в повідомленні SNMP і служить основою для поділу агентів і менеджерів на «спільноти», так що агент взаємодіє тільки з тими менеджерами, які вказують в поле community string такий же символьний рядок, що й рядок, який зберігається в пам’яті агента. Це, безумовно, не спосіб аутентифікації, а спосіб структурування агентів і менеджерів. Версія SNMP v.2 повинна була ліквідувати цей недолік, але в результаті розбіжностей між розробниками стандарту нові засоби аутентифікації хоча і з’явилися в цій версії, але як необов’язкові.
- Робота через ненадійний протокол UDP (а саме так працює переважна більшість реалізації агентів SNMP) призводить до втрат аварійних повідомлень (повідомлень trap) від агентів до менеджерів, що може призвести до неякісного управління.
Висновки
- SNMP широко використовується для управління мережами, особливо IP-мережами
- Успіх SNMP в порівнянні з іншими стандартами управління показує переваги процесу стандартизації IETF
- Історія розвитку SNMP показує важливість завдань захисту інформації
- Архітектура SNMP цікава для аналізу архітектури мережевого програмного забезпечення; вона відповідає поставленим перед SNMP цілям
- Архітектура SNMP відповідає архітектурному стилю ULCSS мережевого програмного забезпечення
- У SNMP для вирішення функцій 6 рівня моделі OSI RM використовується ASN.1, що незвично для стандартів IETF і позитивно впливає на питання формалізації протоколів, однозначності стандартів, зручності проектування додатків
- Структура стандартів SNMP добре продумана і показова для вивчення стандартів
- Лише деякі моделі безпеки SNMP відповідають поставленим перед системою безпеки SNMP цілям
- Агенти та менеджери SNMP прості в програмній реалізації, проте завжди потрібно пам’ятати про інформаційну безпеку