Відмінності між версіями «RIP»

Версія за 11:51, 19 грудня 2011

Загальні відомості

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

Для IP є дві версії протоколу RIP: перша і друга. Протокол RIPvl не підтримує масок, тобто він поширює між маршрутизаторами тільки інформацію про номери мереж і відстанях до них, а інформацію про маски цих мереж не поширює, вважаючи, що всі адреси належать до стандартних класів А, В або С. Протокол RIPv2 передає інформацію про маски мереж, тому він більшою мірою відповідає вимогам сьогодення. Так як при побудові таблиць маршрутизації робота версії 2 принципово не відрізняється від версії 1, то в подальшому для спрощення записів буде описуватися робота першої версії.

Побудова таблиці маршрутизації

В якості відстані до мережі стандарти протоколу RIP допускають різні види метрик: хопи, метрики, що враховують пропускну здатність, затримки і надійність мереж (тобто відповідні ознаками D, Т і R в поле «Якість сервісу» IP-пакета), а також будь-які комбінації цих метрик. Метрика повинна мати властивість адитивності - метрика складового шляху повинна дорівнювати сумі метрик складових цього шляху. У більшості реалізації RIP використовується найпростіша метрика - кількість хопов, тобто кількість проміжних маршрутизаторів, які потрібно подолати пакету до мережі призначення.

Розглянемо процес побудови таблиці маршрутизації за допомогою протоколу RIP на прикладі складеної мережі, зображеної на мал.1.

Мал. 1. Мережа побудована на маршрутизаторах RIP.

Етап 1 - створення мінімальних таблиць. У цій мережі є вісім IP-мереж, пов'язаних чотирма маршрутизаторами з ідентифікаторами: Ml, М2, МЗ і М4. Маршрутизатори, що працюють по протоколу RIP, можуть мати ідентифікатори, проте для роботи протоколу вони не є необхідними. У RIP-повідомленнях ці ідентифікатори не передаються.

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

Таблиця 1 дозволяє оцінити приблизний вигляд мінімальної таблиці маршрутизації маршрутизатора Ml.

Таблиця 1. Мінімальна таблиця маршрутизації маршрутизатора Ml

Мінімальні таблиці маршрутизації в інших маршрутизаторах будуть виглядати відповідно, наприклад, таблиця маршрутизатора М2 буде складатися з трьох записів (табл. 2).

Таблиця 2. Мінімальна таблиця маршрутизації маршрутизатора М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 (табл. 5).

Таблиця 5. Таблиця маршрутизації маршрутизатора М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, і замінити запис в таблиці маршрутизації про недосяжність цієї мережі (табл. 6).

Таблиця 6. Таблиця маршрутизації маршрутизатора М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).

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

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

Матеріали взяті з: В. Г. Олифер, Н. А. Олифер. Компьютерные сети. Принципы, технологии, протоколы. Учебник для вузов. 2010