Адаптація 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.
Нехай маршрутизатор M1 виявив, що його зв'язок з безпосередньо підключеною мережею 201.36.14.0 загублено (наприклад, через відмову інтерфейсу 201.36.14.3). M1 відзначив у своїй ТМ, що мережа 201.36.14.0 недоступна. У найгіршому разі він виявив це відразу ж після відправлення чергових RIP-повідомлень, так що до початку нового циклу його оголошень, у якому він повинен повідомити сусідам, що відстань до мережі 201.36.14.0 стала дорівнювати 16, залишається майже 30 секунд.
Кожний маршрутизатор працює на підставі свого внутрішнього таймера, не синхронізуючи роботу з розсилання оголошень із іншими маршрутизаторами. Тому досить імовірно, маршрутизатор М2 випередив маршрутизатор M1 і надіслав йому своє повідомлення раніше, ніж M1 встиг переказати новину про недосяжність мережі 201.36.14.0. А в цьому повідомленні є дані, породжені наступним записом у таблиці маршрутизації М2 (табл. 5).
Таблиця 5 Таблиця маршрутизації маршрутизатора М2 |
|||
Номер мережі |
Адреса наступному маршрутизаторі |
Порт |
Відстань |
201.36.14.0 |
132.11. 0.7 |
1 |
2 |
Цей запис був отриманий від маршрутизатора M1 і коректний до відмови інтерфейсу 201.36.14.3, а тепер вона застаріла, але маршрутизатор М2 про це не довідався.
Тепер M1 одержав нову інформацію про мережу 201.36.14.0 - ця мережа досяжна через маршрутизатор М2 з метрикою 2. Раніше M1 також одержував цю інформацію від М2. Але ігнорував її, тому що його власна метрика для 201.36.14.0 була краще. Тепер M1 повинен прийняти дані про мережу 201.36.14.0, отримані від М2, і замінити запис у таблиці маршрутизації про недосяжність цієї мережі (табл. 6).
Таблиця 6 Таблиця маршрутизації маршрутизатора M1 |
|||
Номер мережі |
Адреса наступному маршрутизаторі |
Порт |
Відстань |
201.36.14.0 |
132.11. 0.101 |
2 |
3 |
В результаті у мережі утворилася маршрутна петля: пакети, що направляють вузлам мережі 201.36.14.0, будуть передаватися маршрутизатором М2 маршрутизатору M1, а маршрутизатор M1 буде повертати їхньому маршрутизатору М2. IP-пакети будуть циркулювати по цій петлі доти, поки не мине час життя кожного пакета.
Маршрутна петля буде існувати в мережі досить довго. Розглянемо періоди часу, кратні часу життя записів у таблицях маршрутизаторів.
Час 0-180 с. Після відмови інтерфейсу в маршрутизаторах M1 і М2 будуть зберігатися некоректні записи, наведені вище. Маршрутизатор М2 як і раніше постачає маршрутизатор M1 своїм записом про мережу 201.36.14.0 з метрикою 2, тому що її час життя не минув. Пакети зациклюються.
Час 180-360 с. На початку цього періоду в маршрутизаторі М2 спливає час життя запису про мережу 201.36.14.0 з метрикою 2, оскільки маршрутизатор M1 у попередній період надсилав йому повідомлення про мережу 201.36.14.0 з гіршою метрикою, ніж у М2, і вони не могли підтверджувати цей запис. Тепер маршрутизатор М2 приймає від маршрутизатора M1 запис про мережу 201.36.14.0 з метрикою 3 і трансформує її у запис з метрикою 4. Маршрутизатор M1 не отримує нових повідомлень від маршрутизатора М2 про мережу 201.36.14.0 з метрикою 2, тому час життя його запису починає зменшуватись. Пакети продовжують зациклюватись.
Час 360-540 с. Тепер у маршрутизатора M1 спливає час життя запису про мережу 201.36.14.0 з метрикою 3. Маршрутизатори M1 і М2 знову міняються ролями - М2 постачає M1 застарілою інформацією про шлях до мережі 201.36.14.0, вже з метрикою 4, що M1 перетворить у метрику 5. Пакети продовжують зациклюватися.
Якби у протоколі RIP не була обрана відстань 16 у якості недосяжної, то описаний процес тривав би нескінченно (вірніше, поки не була б вичерпана розрядна сітка поля відстані й не було б зафіксоване переповнення при черговому нарощуванні відстані).
В результаті М2 на черговому етапі описаного процесу отримує від маршрутизатора M1 метрику 15, що після нарощування, перетворюючись у метрику 16, фіксує недосяжність мережі. Період нестабільної роботи мережі тривав 36 хвилин, що є неприпустими.
Обмеження у 15 хопів звужує область застосування протоколу RІP до мереж, у яких число проміжних маршрутизаторів не може перевищувати 15. Для більш масштабних мереж слід застосовувати інші протоколи маршрутизації, наприклад OSPF, або розбивати мережу на автономні області.
Наведений приклад добре ілюструє головну причину нестабільної роботи маршрутизаторів, що працюють за протоколом RIP. Ця причина знаходиться у принципі роботи дистанційно-векторних протоколів - використанні інформації, отриманій з других рук (дійсно, М2 передав M1 інформацію про досяжність мережі 201.36.14.0, за вірогідність якої він сам не відповідає. Усунути цю причину повністю не можна, адже сам спосіб побудови ТМ пов'язаний з передачею чужої інформації без вказання джерела її походження.
Не слід думати, що при будь-яких відмовах інтерфейсів і маршрутизаторів у мережах виникають маршрутні петлі. Якби M1 встиг передати повідомлення про недосяжність мережі 201.36.14.0 раніше помилкової інформації маршрутизатора М2, то маршрутна петля не утворилась б. Взагалі, маршрутні петлі навіть без додаткових методів боротьби з ними, виникають в середньому не більше ніж у половині потенційно можливих випадків.