Статична маршрутизація, альтернатива динамічної - це процес, у якому адміністратор системної мережі вручну налаштовував мережеві маршрутизатори з усією інформацією, необхідної для успішного пересилання пакетів. Адміністратор створює у кожному пристрої, розміщуючи записи для кожної мережі, яка може бути призначенням. Статичні шляхи передачі для мережних маршрутів незмінні.
Визначення
Статичний спосіб - це керований мережевим адміністратором метод мережної маршрутизації, який полягає в ручному налаштуванні та виборі мережного маршруту. Використовується у сценаріях, де мережні параметри та середовище мають залишатися постійними.
Маршрутизація є однією з найважливіших процедур передачі даних. Це гарантує, що дані переміщаються з однієї мережі до іншої з оптимальною швидкістю та мінімальною затримкою, і що її цілісність зберігається в цьому процесі.
У широкому значенні маршрутизація виконується двома різними способами:
- Динамічна — періодично оновлює свою таблицю маршрутизації шляхами та його вартістю/метрикою, приймаючи оптимальні рішення з урахуванням зміни мережевих робочих умов.
- Статична — вважається найпростішою формою цього процесу, виконує правила маршрутизації з попередньо налаштованими шляхами передачі у таблиці, які можуть бути змінені вручну лише адміністраторами.
Статичні маршрути зазвичай використовуються в тих ситуаціях, коли вибір обмежений або існує лише один доступний за промовчанням шлях. Крім того, статична методика може використовуватись, якщо є лише кілька пристроїв для налаштування маршруту, і в майбутньому не виникне потреба його змінювати.
Різновиди маршрутизації
Пристрій може використовувати три шляхи для вивчення маршрутів:
Статична маршрутизація – це метод, за допомогою якого адміністратор вручну додає шляхи передачі інформації до електронної таблиці/бази даних.
Маршрутизація за замовчуванням - це методика, де всі маршрутизатори налаштовані на відправку всіх пакетів по одному шляху. Це дуже корисний метод для невеликих мереж або для мереж з єдиною точкою входу та виходу. Він зазвичай використовується на додаток до статичного та динамічного способів.
Динамічна методика - це спосіб, при якому протоколи та алгоритми використовуються для автоматичного поширення інформації про маршрутизацію. Це найпоширеніший і найскладніший метод.
Класифікація протоколів
Протоколи маршрутизації класифікуються як протоколи внутрішніх шлюзів (IGP) чи зовнішні шлюзові протоколи (EGP). IGP використовуються для обміну інформацією про процес у міжмережевих мережах, які підпадають під єдиний адміністративний домен (також званий автономними системами). EGP використовуються для обміну інформацією між різними автономними системами. Звичайними прикладами IGP є протокол маршрутизації (RIP), розширений протокол внутрішніх шлюзів (EIGRP) та Open Shortest Path First (OSPF).
Протокол маршрутизації використовує програмне забезпечення та алгоритми для визначення оптимальної передачі мережевих даних та шляхів зв'язку між мережевими вузлами. Також відомий як політика маршрутизації. Вони суттєво полегшують взаємодію маршрутизаторів, а також загальну топологію мережі.
У більшості (IP) використовуються такі протоколи маршрутизації:
Протокол маршрутизації (RIP) та протокол маршрутизації внутрішніх шлюзів (IGRP): забезпечують процес внутрішніх шлюзів через протоколи маршрутних чи дистанційних векторів. RIP використовується для визначення найкоротшого шляху від джерела до місця призначення. Це дозволяє передавати дані на високій швидкості у найкоротший термін.
Open Shortest Path First (OSPF): забезпечує процес внутрішніх шлюзів через протоколи маршрутизації стану каналу.
- Протокол прикордонного шлюзу (BGP) v4: надає загальнодоступний протокол маршрутизації через зовнішню взаємодію зі шлюзом.
Як налаштувати статичну маршрутизацію Cisco
Щоб настроїти статичний маршрут, пристрій повинен знаходитись у режимі глобальної конфігурації.
Код для командного рядка: ip route prefix mask(адреса|інтерфейс)[відстань]. Роз'яснимо основні складові коду:
мережа - цільова мережа;
mask - маска підмережі для цієї мережі;
адреса - IP-адреса маршрутизатора наступного переходу;
інтерфейс - інтерфейс обладнання вихідного трафіку;
відстань - адміністративна відстань маршруту.
Адміністративна відстань використовується для застосування свого роду пріорітизації на статичних маршрутах, так що різні шляхи до даного місця призначення будуть наслідувати певну схему активації. Адміністративна відстань є цілим числом від 0 до 255, де 0 вказує шлях першого пріоритету, а 255 означає, що трафік не може проходити через цей маршрут. За замовчуванням адміністративна відстань безпосередньо підключених інтерфейсів дорівнює 0, а статичних маршрутів 1.
Приклад статичної маршрутизації:
ip route 10.0.0.0 255.0.0.0 131.108.3.4 110, де 10.0.0.0 — цільова мережа, 255.0.0.0 — маска підмережі, а 131.108.3.4 — наступний стрибок для дистанційного 100.0.0.
Приклад створення статичного маршруту
Як приклад того, коли потрібний статичний маршрут, розглянемо наступний випадок:
Маршрутизатор надає та отримує повідомлення на інтерфейсах пристрою.
Отримані повідомлення та інформація використовуються спільно іншими приладами, які використовують такий самий протокол.
Ваш основний доступ до Інтернету здійснюється через кабельний модем для інтернет-провайдера.
У вас є маршрутизатор ISDN у домашній мережі для підключення до компанії, в якій ви працюєте. Адреса цього пристрою у локальній мережі 192.168.1.100.
Мережева адреса вашої компанії 134.177.0.0.
При налаштуванні статичної маршрутизації cisco створюються два неявні статичні маршрути.
Шлях передачі даних за замовчуванням був створений з вашим провайдером як шлюз, а другий статичний маршрут створюється в локальній мережі для всіх адрес 192.168.1.x. У цій конфігурації при спробі доступу до пристрою в мережі 134.177.0.0 маршрутизатор перенаправляє запит постачальнику інтернет-послуг.
У цьому випадку необхідно визначити статичний маршрут, вказавши приладу, що 134.177.0.0 має бути доступним через маршрутизатор ISDN за адресою 192.168.1.100.
Статичні та динамічні маршрутизатори
Для ефективної роботи в мережі мережі маршрутизатори повинні мати інформацію про інші ідентифікатори або налаштовуватися з використанням шляху за замовчуванням. У великих мережах таблиці маршрутизації повинні підтримуватися так, щоб трафік завжди переміщався оптимальними шляхами прямування. Від того, як підтримуються електронні таблиці, визначається різниця між статичною та динамічною маршрутизацією.
Статична маршрутизація
Пристрій із вручну налаштованими таблицями маршрутизації користувачам відомий як статичний. Мережевий адміністратор, який володіє топологією міжмережевої мережі, вручну створює та оновлює таблицю шляхів проходження інформації, програмуючи всі маршрути. Статичні маршрутизатори можуть добре працювати для невеликих міжмережевих мереж, але не масштабуються для великих або динамічно змінюваних міжмережевих мереж через їхнє ручне адміністрування.
Хорошим прикладом статичного пристрою є багатомережевий комп'ютер під керуванням Windows 2000 (комп'ютер із кількома мережевими інтерфейсами). Створення статичної маршрутизації в Windows 2000 так само просто, як встановлення кількох карт мережного інтерфейсу, налаштування TCP/IP та включення IP-маршрутизації.
Динамічна маршрутизація
Прилад із динамічно налаштованими таблицями відомий як динамічний. Динамічна маршрутизація складається з таблиць, які створюються та підтримуються автоматично через постійний зв'язок між пристроями. Це повідомлення полегшується протоколом маршрутизації, серією періодичних або на вимогу повідомлень, що містять інформацію, якою обмінюються маршрутизатори. Динамічні пристрої, за винятком їхньої початкової конфігурації, вимагають незначного постійного обслуговування і можуть масштабуватися до більших міжмережевих мереж.
Динамічна маршрутизація є стійкою до відмови. Динамічні шляхи передачі даних, отримані з інших пристроїв, мають обмежений термін служби.
Можливість масштабування та відновлення від міжмережевих помилок робить цей спосіб найкращим вибором для середніх та великих міжмережевих мереж.
Динамічна методика - це забезпечує оптимальну маршрутизацію даних. На відміну від статичної, динамічна дозволяє маршрутизаторам вибирати шляхи відповідно до змін логічної мережі в режимі реального часу. У динамічному процесі протокол, що працює на пристрої, відповідає за створення, обслуговування та оновлення електронної таблиці даних. У статичній маршрутизації ці завдання виконуються адміністратором системи вручну.
Динамічна методика використовує безліч різних алгоритмів та протоколів. Найбільш популярними є протокол маршрутизації (RIP) та Open Shortest Path First (OSPF).
Вартість маршрутизації є критичним чинником всім організацій. Найменш дорога технологія цього процесу забезпечується динамічною методикою, яка автоматизує зміни таблиць та забезпечує найкращі шляхи для стабільної передачі даних.
Операції протоколу динамічної маршрутизації можна пояснити так:
Маршрутизатори змінюють інформацію про маршрутизацію для виявлення даних про віддалені мережі. Щоразу, коли пристрій знаходить зміну топології, протокол маршрутизації вносить зміна топології інших приладах.
Динамічна маршрутизація легко налаштовується у великих мережах і більш інтуїтивно зрозуміла при виборі найкращого шляху передачі інформації, визначення змін та виявлення віддалених мереж. Однак оскільки маршрутизатори обмінюються оновленнями, вони споживають більше смуги пропускання, ніж у статичній методиці. Процесори та операційна система обладнання можуть зіткнутися з додатковими навантаженнями внаслідок більш складної роботи протоколів. Динамічна маршрутизація менш безпечна, ніж статична.
Порівняльний аналіз
Статична маршрутизація cisco не є протоколом маршрутизації. Це просто процес ручного введення маршрутів в електронну таблицю даних пристрою через конфігураційний файл, який завантажується при запуску пристрою. В якості альтернативи ці шляхи передачі можуть бути введені адміністратором мережі, який налаштовує їх вручну. Оскільки ці налаштовані вручну маршрути не змінюються після налаштування, вони називаються статичними.
Статична методика - це найпростіша форма маршрутизації, але це кропіткий ручний процес. Використовуйте цей метод, коли у вас дуже мало пристроїв для налаштування (менше 5), і ви впевнені, що шляхи передачі інформації, мабуть, ніколи не зміняться.
Статична маршрутизація cisco packet tracer також не обробляє випадкові збої у зовнішніх мережах, тому що будь-який маршрут, який налаштований вручну, повинен бути оновлений або переналаштований вручну, щоб виправити або відновити втрачені з'єднання.
Протоколи динамічної маршрутизації підтримуються програмними програмами, запущеними на приймальному/передавальному пристрої (маршрутизаторі).
Пристрій, що використовує динамічну методику, розпізнає маршрути всім мереж, які безпосередньо до нього підключені. Потім маршрутизатор вивчає дані інших приладів, які виконують той самий протокол (RIP, RIP2, EIGRP, OSPF, IS-IS, BGP). Потім кожен маршрутизатор сортує список маршрутів та вибирає один або кілька оптимальних шляхів для кожного адресата мережі.
Потім протоколи динамічної маршрутизації розповсюджують отримані дані інші пристрої, що працюють з одним протоколом, тим самим розширюючи інформацію про те, які мережі існують і можуть бути досягнуті. Це дає динамічним протоколам можливість адаптуватися до змін логічної топології мережі чи збоїв роутера статичної маршрутизації.
Плюси і мінуси
Статична маршрутизація має такі переваги:
Жодної додаткової обробки та додаткових ресурсів, як у разі динамічних протоколів маршрутизації.
Відсутність додаткових вимог до пропускної спроможності, викликаних передачею надмірних пакетів процесу оновлення таблиці маршрутизації.
Додаткова безпека обумовлюється шляхом ручного введення чи відхилення шляхів передачі у певні мережі.
Налаштування статичної маршрутизації безпечніше.
Для використання статичних маршрутів немає витрат. З динамічними пропускною здатністю мережі використовується зв'язок доступних мереж між маршрутизаторами. При використанні статичних маршрутів, оскільки адміністратор кодує дані, пристроям не потрібно передавати інформацію про маршрутизацію.
Статичну маршрутизацію простіше настроїти для невеликої мережі. Припустимо, що у вас є лише два пристрої та необхідно налаштувати повідомлення між ними. Для цього потрібно налаштувати лише два оператори маршруту - по одному на кожному маршрутизаторі. З динамічним протоколом, таким як RIP, наприклад, довелося б вводити два мережеві оператори на кожному приладі.
Статичні маршрути не вимагають будь-яких суттєвих ресурсів маршрутизатора. Протокол динамічної маршрутизації, такий як OSPF, може вимагати значних ресурсів для розрахунку найкоротшого шляху мережі за наявності великої кількості підключених пристроїв.
До недоліків належать такі:
Мережеві адміністратори повинні добре знати всю, щоб правильно налаштувати шляхи передачі даних.
Зміни топології вимагають ручного настроювання статичної маршрутизації cisco packet tracer для всіх пристроїв, що дуже трудомістко.
Статичні маршрути не масштабуються зі зростанням мережі. Це з тим, що вони налаштовуються адміністратором вручну.
При динамічній методиці ручне втручання відсутнє, і трафік маршрутизується автоматично щоразу, коли у мережі відбувається відключення. Також він досить масштабований і легко керований.
У чому різниця між статичною та динамічною маршрутизацією?
Статична IP-маршрутизація – це коли ви статично налаштовуєте пристрій для відправки трафіку для певних пунктів призначення у попередньо налаштованих напрямках. Динамічний спосіб — це коли ви використовуєте протокол маршрутизації, такий як OSPF, ISIS, EIGRP або BGP, щоб з'ясувати, який тип трафіку повинен пройти. У реальному світі дуже мало ситуацій, коли використовується лише один із двох методів. Типова мережа використовуватиме динамічний протокол OSPF для визначення оптимальних маршрутів усередині підприємства, BGP — для визначення найкращих точок виходу для решти інтернету та статичну маршрутизацію для відправлення специфічного трафіку виділеними шляхами.
IP-адресація та маршрутизація: як це працює?
Маршрутизатори, щоб мати можливість передавати пакети в кінцевий пункт призначення, повинні підтримувати таблицю маршрутизації, де зберігається вся необхідна інформація, що містить комбінацію мереж та інтерфейсів виведення.
Щоразу, коли пристрій отримує пакет, він перевіряє IP-адресу одержувача і намагається знайти, переглянувши у своїй електронній таблиці даних можливий шлях проходження інформації до цієї IP-адреси. Маршрутизатори не надсилають широкомовні розсилки в пошуку віддалених мереж: якщо мережа не вказана в таблиці, пристрій просто відкидає пакети.
Коли використовувати маршрутизацію за замовчуванням
Маршрутизація за промовчанням використовується лише в мережах-заглушках. Stub – це мережі, які мають лише один інтерфейс виведення, і все, що проходить через ці мережі, має перетинати єдину точку виходу.
Замість того, щоб велика кількість статичних маршрутів вказувала на віддалені мережі через один вихідний інтерфейс, налаштовується один шлях за замовчуванням, який відповідає всім можливим маршрутам.
Використання адміністративних відстаней
За промовчанням для статичних маршрутів адміністративна відстань становить 1. AD використовуються визначення пріоритетів. Для різних маршрутів у конкретній цільовій мережі можуть бути призначені різні ваги, тому один із шляхів передачі даних використовується в пріоритеті. Маршрути з однаковим ваговим навантаженням поділяють трафік.
Отже, почнемо.
Статей та відео про те, як налаштувати OSPF гори. Набагато менше за описи принципів роботи. Взагалі, тут така справа, що OSPF можна просто налаштувати згідно з мануалами, навіть не знаючи про алгоритми SPF і незрозумілі LSA. І все буде працювати і навіть, швидше за все, чудово працювати – на те він і розрахований. Тобто, тут не як з вланами, де доводилося знати теорію аж до формату заголовка.
Але інженера від енікейника відрізняє те, що він розуміє, чому його мережа функціонує так, а не інакше, і не гірше самого OSPF знає, який маршрут буде обраний протоколом.
У рамках статті, яка вже зараз становить 8 000 символів, ми не зможемо поринути в глибини теорії, але розглянемо принципові моменти.
Дуже просто і зрозуміло, до речі, написано про OSPF на xgu.ru або в англійській вікіпедії.
Отже, OSPFv2 працює поверх IP, саме, він заточений лише під IPv4 (OSPFv3 залежить від протоколів 3-го рівня і тому може працювати з IPv6).
Розглянемо його роботу на прикладі ось такої спрощеної мережі:
Для початку треба сказати, що для того, щоб між маршрутизаторами почалася дружба (відносини суміжності) повинні виконатися такі умови:
1) у OSPF повинні бути налаштовані однакові Hello Intervalна маршрутизаторах, що підключені один до одного. За замовчуванням це 10 секунд у мережах Broadcast, типу Ethernet. Це свого роду KeepAlive повідомлення. Тобто кожні 10 секунд кожен маршрутизатор відправляє Hello пакет своєму сусідові, щоб сказати: "Хей, я живий",
2) Однаковими повинні бути і Dead Intervalна них. Зазвичай це 4 інтервали Hello – 40 секунд. Якщо протягом цього часу від сусіда не отримано Hello, то він вважається недоступним і починається процес перебудови локальної бази даних і розсилання оновлень усім сусідам,
3) Інтерфейси, підключені один до одного, повинні бути в однієї підмережі,
4) OSPF дозволяє зменшити навантаження на CPU маршрутизаторів, розділивши Автономну Систему на зони. Так ось номери зонтеж повинні збігатися,
5) У кожного маршрутизатора, який бере участь у процесі OSPF, є свій унікальнийіндентифікатор - Router ID. Якщо ви про нього не подбаєте, маршрутизатор вибере його автоматично на основі інформації про підключені інтерфейси (вибирається найвища адреса з інтерфейсів, активних на момент запуску процесу OSPF). Але знову ж таки у хорошого інженера все під контролем, тому зазвичай створюється Loopback інтерфейс, якому присвоюється адреса з маскою /32 і саме він призначається Router ID. Це буває зручно при обслуговуванні та траблшутингу.
6) Повинен співпадати розмір MTU
1) Штиль. Стан OSPF - DOWN
Цієї короткої миті в мережі нічого не відбувається - всі мовчать.
2) Піднімається вітер: маршрутизатор розсилає Hello-пакети на мультикасну адресу 224.0.0.5 з усіх інтерфейсів, де запущено OSPF. TTL таких повідомлень дорівнює одному, тому їх отримають лише маршрутизатори, що знаходяться у тому ж сегменті мережі. R1 переходить у стан INIT.
У пакети вкладається така інформація:
- Router ID
- Hello Interval
- Dead Interval
- Neighbors
- Subnet mask
- Area ID
- Router Priority
- Адреси DR та BDR маршрутизаторів
- Пароль автентифікації
Повідомлення Hello від маршрутизатора R1 несе в собі його Router ID і не містить Neighbors, тому що у нього поки що немає.
Після отримання мультикастного повідомлення маршрутизатор R2 додає R1 в свою таблицю сусідів (якщо збіглися всі необхідні параметри).
І відправляє на R1 вже юнікастом нове повідомлення Hello, де міститься Router ID цього маршрутизатора, а у списку Neigbors перераховані всі його сусіди. Серед інших сусідів у списку є Router ID R1, тобто R2 вже вважає його сусідом.
3) Дружба. Коли R1 отримує це повідомлення Hello від R2, він перегортає список сусідів і знаходить у ньому свій Router ID, він додає R2 до свого списку сусідів.
Тепер R1 і R2 один у одного у взаємних сусідах - це означає, що між ними встановлені відносини суміжності та маршрутизатор R1 переходить у стан TWO WAY.
Загальна порада з усіх завдань:
Навіть якщо Ви відразу не знаєте відповіді та рішення, постарайтеся подумати, до чого належить умова завдання:
- До яких особливостей, налаштувань протоколу?
- Глобальні ці налаштування чи прив'язані до конкретного інтерфейсу?
Якщо Ви не знаєте чи забули команду, такі міркування, швидше за все, приведуть Вас до правильного контексту, де Ви просто, за допомогою підказки в командному рядку, можете здогадатися або згадати, як налаштувати те, що потрібно в завданні.
Постарайтеся поміркувати в такому ключі, перш ніж підете в гугл або на якийсь сайт у пошуку команд.
На реальній мережі при виборі діапазону анонсованих підмереж потрібно керуватися регламентом та нагальними потребами.
Перш ніж ми перейдемо до тестування резервних лінків та швидкості, зробимо ще одну корисну річ.
Якби ми мали змогу відловити трафік на інтерфейсі FE0/0.2 msk-arbat-gw1, який дивиться у бік серверів, то ми б побачили, що кожні 10 секунд у невідомість відлітають повідомлення Hello. Відповісти на Hello нікому, відносини суміжності встановлювати нема з ким, тому й намагатися розсилати звідси повідомлення сенсу немає.
Вимикається це дуже просто:
msk-arbat-gw1(config)#router OSPF 1
msk-arbat-gw1(config-router)#passive-interface fastEthernet 0/0.2
Таку команду потрібно дати для всіх інтерфейсів, на яких немає сусідів OSPF (у тому числі в бік інтернету).
У результаті картина у вас буде така:
*Не уявляю, як ви досі не заплуталися*
Крім того, ця команда підвищує безпеку - ніхто з цієї мережі не прикинеться маршрутизатором і не намагатиметься поламати нас повністю.
Тепер займемося найцікавішим – тестуванням.
Нічого складного немає у налаштуванні OSPF на всіх маршрутизаторах у Сибірському кільці – зробите самі.
І після цього картина має бути такою:
msk-arbat-gw1#sh ip OSPF neighbor
172.16.255.32 1 FULL/DR 00:00:31 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:31 172.16.2.18 FastEthernet0/1.5
172.16.255.80 1 FULL/BDR 00:00:36 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/BDR 00:00:37 172.16.2.197 FastEthernet1/0.911
Пітер, Кемерово, Красноярськ та Владивосток – безпосередньо підключені.
msk-arbat-gw1#sh ip route172.16.0.0/16 is variably subnetted, 25 subnets, 6 masks
S 172.16.2.4/30 via 172.16.2.2
O 172.16.2.160/30 via 172.16.2.130, 00:05:53, FastEthernet0/1.8
O 172.16.2.192/30 via 172.16.2.197, 00:04:18, FastEthernet1/0.911
S 172.16.16.0/21 via 172.16.2.2
S 172.16.24.0/22 via 172.16.2.18
O 172.16.24.0/24 via 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.128.0/24 via 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.129.0/26 via 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.32/32 via 172.16.2.2, 00:24:03, FastEthernet0/1.4
O 172.16.255.48/32 via 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.255.80/32 via 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.96/32 via 172.16.2.130, 00:04:18, FastEthernet0/1.8
via 172.16.2.197, 00:04:18, FastEthernet1/0.911
O 172.16.255.112/32 via 172.16.2.197, 00:04:28, FastEthernet1/0.911
Всі про всіх знають.
Яким маршрутом трафік доставляється з Москви до Красноярська? З таблиці видно, що krs-stolbi-gw1 підключений безпосередньо і це видно з трасування:
1 172.16.2.130 35 msec 8 msec 5 msec
Тепер рвемо інтерфейс між Москвою та Красноярськом і дивимося, через скільки лінк відновиться.
Не минає і 5 секунд, як усі маршрутизатори дізналися про подію та перерахували свої таблиці маршрутизації:
msk-arbat-gw1(config-subif)#do sh ip ro 172.16.128.0
Known via «OSPF 1», distance 110, metric 4, type intra area
Last update from 172.16.2.197 on FastEthernet1/0.911, 00:00:53 ago
Routing Descriptor Blocks:
* 172.16.2.197, від 172.16.255.80, 00:00:53 ago, via FastEthernet1/0.911
Route metric is 4, traffic share count is 1Vld-gw1#sh ip route 172.16.128.0
Routing entry for 172.16.128.0/24
Known via «OSPF 1», distance 110, metric 3, type intra area
Last update from 172.16.2.193 on FastEthernet1/0, 00:01:57 ago
Routing Descriptor Blocks:
* 172.16.2.193, від 172.16.255.80, 00:01:57 ago, via FastEthernet1/0
Route metric is 3, traffic share count is 1Msk-arbat-gw1#traceroute 172.16.128.1
Type escape sequence to abort.
Tracing the route to 172.16.128.11 172.16.2.197 4 msec 10 msec 10 msec
2 172.16.2.193 8 msec 11 msec 15 msec
3 172.16.2.161 15 msec 13 msec 6 msec
Тобто тепер Красноярська трафік сягає таким шляхом:
Як тільки ви піднімете лінк, маршрутизатори знову вступають у зв'язок, обмінюються своїми базами, перераховуються найкоротші шляхи та заносяться до таблиці маршрутизації.
На відео все це наочно. Рекомендую ознайомитись.
Як і будь-який хороший протокол, OSPF підтримує автентифікацію - два сусіди перед встановленням співвідношень сусідства можуть перевіряти справжність отриманих OSPF-повідомлень. Залишаємо на самостійне вивчення – досить просто.
EIGRP
Тепер займемося іншим дуже важливим протоколомОтже, чим хороший EIGRP?
- простий у конфігурації
- швидке перемикання на заздалегідь прорахованийзапасний маршрут
- вимагає менше ресурсів роутера (проти OSPF)
- підсумовування маршрутів на будь-якому роутері (в OSPF тільки на ABR\ASBR)
- балансування трафіку на нерівноцінних маршрутах (OSPF лише на рівноцінних)
Ми вирішили перекласти один із записів блогу Івана Пепельняка, в якому розбирається ряд популярних міфів про EIGRP:
- "EIGRP це гібридний протокол маршрутизації". Якщо я правильно пам'ятаю, це почалося з першої презентації EIGRP багато років тому і зазвичай розуміється як «EIGRP взяв краще від link-state та distance-vector протоколів». Це зовсім не так. EIGRP не має жодних відмінних особливостей link-state. Правильно буде говорити "EIGRP це просунутий distance-vector-протокол маршрутизації".- "EIGRP це distance-vector протокол". Непогано, але не до кінця так само. EIGRP відрізняється від інших DV способом, яким обробляє втрачені маршрути (або маршрути зі зростаючою метрикою). Всі інші протоколи пасивно чекають на оновлення інформації від сусіда (деякі, наприклад, RIP, навіть блокують маршрут для запобігання петель маршрутизації), в той час як EIGRP поводиться активніше і запитує інформацію сам.
- "EIGRP складний у впровадженні та обслуговуванні". Неправда. Свого часу, EIGRP у великих мережах з низькошвидкісними лінками було важко правильно впровадити, але до того моменту, як були введені stub routers. З ними (а також декількома виправленнями роботи DUAL-алгоритму) він не ледве не гірший, ніж OSPF.
- "Як і LS протоколи, EIGRP зберігає таблицю топології маршрутів, якими обмінюється". Просто дивно, наскільки це не так. EIGRP не має взагалі ніякого уявлення про те, що знаходиться далі найближчих сусідів, тоді як протоколи LS точно знають топологію всієї області, до якої вони підключені.
- “EIGRP це DV протокол, який діє як LS”. Непогана спроба, але, як і раніше, абсолютно неправильна. LS протоколи будують таблицю маршрутизації, проходячи через такі кроки:
- кожен маршрутизатор описує мережу, виходячи з інформації, доступної йому локально (його лінки, підмережі, в яких він знаходиться, сусіди, яких він бачить) за допомогою пакета (або декількох), званого LSA (OSPF) або LSP (IS-IS)
- LSA розповсюджуються по мережі. Кожен маршрутизатор повинен отримати кожну LSA, створену в мережі. Інформація, отримана з LSA, заноситься до таблиці топології.
- кожен маршрутизатор незалежно аналізує свою таблицю топології та запускає SPF алгоритм для підрахунку найкращих маршрутів до кожного з інших маршрутизаторів
Поведінка EIGRP навіть близько не нагадує ці кроки, тому незрозуміло, з якого дива він «діє, як LS»Єдине, що робить EIGRP, - це зберігає інформацію, отриману від сусіда (RIP відразу ж забуває те, що не може бути використане в даний момент). У цьому сенсі він схожий на BGP, який теж зберігає все в таблиці BGP і вибирає кращий маршрут звідти. Таблиця топології (яка містить всю інформацію, отриману від сусідів), дає EIGRP перевагу перед RIP - вона може містити інформацію про запасний (не використовуваний в даний момент) маршрут.
Тепер трохи ближче до теорії роботи:
Кожен процес EIGRP обслуговує 3 таблиці:
- Таблицю сусідів (neighbor table), де міститься інформація про “сусіди”, тобто. інших маршрутизаторах, які безпосередньо підключені до поточного та беруть участь в обміні маршрутами. Можна подивитися за допомогою команди show ip eigrp neighbors
- Таблицю топології мережі (topology table), де міститься інформація про маршрути, отримана від сусідів. Дивимося командою show ip eigrp topology
- Таблицю маршрутизації (routing table), з урахуванням якої роутер приймає рішення про перенаправлення пакетів. Перегляд через show ip routeМетрики.
Для оцінки якості певного маршруту, у протоколах маршрутизації використовується деяке число, що відбиває різні його характеристики чи сукупність характеристик-метрика. Характеристики, що приймаються до уваги, можуть бути різними-починаючи від кількості роутерів на даному маршруті і закінчуючи середнім арифметичним завантаженням всіх інтерфейсів по ходу маршруту. Що стосується метрики EIGRP, процитуємо Jeremy Cioara: “у мене склалося враження, що творці EIGRP, окинувши критичним поглядом своє творіння, вирішили, що все дуже просто і добре працює. І тоді вони придумали формулу метрики, щоб усі сказали “ВАУ, це справді складно та професійно виглядає”. Подивіться ж повну формулу підрахунку метрики EIGRP: (K1 * bw + (K2 * bw) / (256 - load) + K3 * delay) * (K5 / (reliability + K4)), в якій:
- bw це не просто пропускна спроможність, а (10000000/найменша пропускна спроможність по дорозі маршруту в кілобітах) * 256
- delay це не просто затримка, а сума всіх затримок по дорозі десятках мікросекунд* 256 (delay у командах show interface, show ip eigrp topology та інших показується в мікросекундах!)
- K1-K5 це коефіцієнти, які служать у тому, щоб у формулу “включився” той чи інший параметр.Страшно? було б, якби це все працювало, як написано. Насправді ж із усіх 4 можливих доданків формули, за замовчуванням використовуються тільки два: bw і delay (коефіцієнти K1 і K3=1, решта нуля), що сильно її спрощує - ми просто складаємо ці два числа (не забуваючи при цьому, що вони все одно вважаються за своїми формулами). Важливо пам'ятати таке: метрика вважається за найгіршому показнику пропускної спроможності по всій довжині маршруту.
Цікава штука вийшла з MTU: досить часто можна зустріти відомості про те, що MTU має відношення до метрики EIGRP. Значення MTU передаються при обміні маршрутами. Але, як ми можемо бачити з повної формули, жодної згадки про MTU там немає. Справа в тому, що цей показник береться до уваги в досить специфічних випадках: наприклад, якщо роутер повинен відкинути один з рівнозначних за іншими характеристиками маршрутів, він вибере той, у якого менший MTU. Хоча не все так просто (див. коментарі).Визначимося з термінами, які застосовуються всередині EIGRP. Кожен маршрут в EIGRP характеризується двома числами: Feasible Distance та Advertised Distance (замість Advertised Distance іноді можна зустріти Reported Distance, це те саме). Кожне з цих чисел являє собою метрику, або вартість (чим більше-тем гірше) даного маршруту з різних точок вимірювання: FD це "від мене до місця призначення", а AD- "від сусіда, який мені розповів про цей маршрут, до місця призначення”. Відповідь на закономірне питання "Навіщо нам треба знати вартість від сусіда, якщо вона і так включена в FD?" - трохи нижче (поки можете зупинитися і поламати голову самі, якщо хочете).
У кожної підмережі, про яку знає EIGRP, на кожному роутері існує Successor-роутер з-поміж сусідів, через який йде найкращий (з меншою метрикою), на думку протоколу, маршрут до цієї підмережі. Крім того, підмережі може також існувати один або кілька запасних маршрутів (роутер-сусід, через якого йде такий маршрут, називається Feasible Successor). EIGRP- єдиний протокол маршрутизації, що запам'ятовує запасні маршрути (в OSPF вони є, але містяться, так би мовити, в "сирому вигляді" в таблиці топології-їх ще треба обробити алгоритмом SPF), що дає йому плюс у швидкодії: як тільки протокол визначає, що основний маршрут (через successor) недоступний, він відразу перемикається на запасний. Для того, щоб роутер міг стати feasible successor для маршруту, його AD має бути меншим за FD successor'а цього маршруту (ось навіщо нам потрібно знати AD). Це правило застосовується для того, щоб уникнути кілець маршрутизації.
Попередній абзац підірвав мозок? Матеріал важкий, тому вкотре на прикладі. У нас є ось така мережа:
З точки зору R1, R2 є Successor для підмережі 192.168.2.0/24. Щоб стати FS для цієї підмережі, R4 потрібно, щоб його AD була меншою за FD для цього маршруту. FD у нас ((10000000/1544)*256)+(2100*256) =2195456, AD у R4 (з його точки зору це FD, тобто скільки йому коштує дістатися цієї мережі) = ((10000000/100000) ) * 256) + (100 * 256) = 51200. Все сходиться, AD у R4 менше, ніж FD маршруту, він стає FS. *тут мозок такий і каже: "БИТЧ"*. Тепер дивимося на R3 – він анонсує свою мережу 192.168.1.0/24 сусідові R1, який, у свою чергу, розповідає про неї своїм сусідам R2 та R4. R4 не знає, що R2 знає про цю підмережу, і вирішує йому розповісти. R2 передає інформацію про те, що він має доступ через R4 до підмережі 192.168.1.0/24 далі на R1. R1 суворо дивиться на FD маршруту і AD, якою хвалиться R2 (яка, як легко зрозуміти за схемою, буде явно більше FD, тому що включає і його теж) і проганяє його, щоб не ліз із всякими дурощами. Така ситуація досить малоймовірна, але може мати місце за певного збігу обставин, наприклад, при відключенні механізму “розщеплення горизонту” (split-horizon). А тепер до більш вірогідної ситуації: уявімо, що R4 підключений до мережі 192.168.2.0/24 не через FastEthernet, а через модем на 56k (затримка для dialup становить 20000 usec), відповідно дістатися йому варто ((100000000/56)*256 )+(2000*256)= 46226176. Це більше, ніж FD для цього маршруту, тому R4 не стане Feasible Successor'ом. Але це не означає, що EIGRP взагалі не використовуватиме цей маршрут. Просто перемикання на нього займе більше часу (докладніше про це далі).
сусідство
Роутери не розмовляють про маршрути з будь-ким - перш ніж почати обмінюватися інформацією, вони повинні встановити відносини сусідства. Після включення процесу командою router eigrp із зазначенням номера автономної системи, ми, командою network говоримо, які інтерфейси братимуть участь і одночасно, інформацію про які мережі ми бажаємо поширювати. Негайно через ці інтерфейси починають розсилатися hello-пакети на мультикаст-адресу 224.0.0.10 (за замовчуванням кожні 5 секунд для ethernet). Всі маршрутизатори з увімкненим EIGRP отримують ці пакети, далі кожен маршрутизатор-одержувач робить наступне:
- звіряє адресу відправника hello-пакета, з адресою інтерфейсу, з якого отримано пакет, та засвідчується, що вони з однієї підмережі
- звіряє значення отриманих із пакета K-коефіцієнтів (простіше кажучи, які змінні використовуються у підрахунку метрики) зі своїми. Зрозуміло, що якщо вони різняться, то метрики для маршрутів рахуватимуться за різними правилами, що неприпустимо
- перевіряє номер автономної системи
- опціонально: якщо настроєно автентифікацію, перевіряє відповідність її типу та ключів.Якщо одержувача все влаштовує, він додає відправника до списку своїх сусідів, і посилає йому (вже юнікастом) update-пакет, де міститься список всіх відомих йому маршрутів (aka full-update). Відправник, отримавши такий пакет, своєю чергою, робить те саме. Для обміну маршрутами EIGRP використовує Reliable Transport Protocol (RTP, не плутати з Real-time Transport Protocol, який використовується в IP-телефонії), який має на увазі підтвердження про доставку, тому кожен з роутерів, отримавши update-пакет, відповідає ack-пакетом (скорочення від acknowledgement- підтвердження). Отже, ставлення сусідства встановлені, роутери дізналися один у одного вичерпну інформацію про маршрути, що далі? Далі вони продовжуватимуть посилати мультикаст hello-пакети на підтвердження того, що вони на зв'язку, а в разі зміни топології-update-пакети, що містять відомості лише про зміни (partial update).
Тепер повернемося до попередньої схеми із модемом.
R2 з якихось причин втратив зв'язок із 192.168.2.0/24. До цієї підмережі він не має запасних маршрутів (тобто відсутня FS). Як і будь-який відповідальний роутер з EIGRP, він хоче відновити зв'язок. І тому він починає розсилати спеціальні повідомлення (query- пакети) всім своїм сусідам, які, своєю чергою, не знаходячи потрібного маршруту в себе, розпитують всіх своїх сусідів, тощо. Коли хвиля запитів докочується до R4, він каже “почекайте, у мене є маршрут до цієї підмережі! Поганий, але хоч щось. Все про нього забули, а я пам'ятаю”. Все це він пакує в reply-пакет і відправляє сусідові, від якого отримав запит (query), і далі по ланцюжку. Зрозуміло, це все займає більше часу, ніж просто перемикання на Feasible Successor, але, зрештою, ми отримуємо зв'язок з підмережею.
А зараз небезпечний момент: може, ви вже звернули увагу і насторожилися, прочитавши момент про цю віялову розсилку. Падіння одного інтерфейсу викликає щось схоже на широкомовний шторм в мережі (не в таких масштабах, звичайно, але все-таки), причому чим більше в ній роутерів, тим більше ресурсів витратиться на всі запити-відповіді. Але це ще пів-біди. Можлива ситуація й гірше: припустимо, що роутери, зображені на картинці- це лише частина великої та розподіленої мережі, тобто. деякі можуть бути за багато тисяч кілометрів від нашого R2, на поганих каналах та інше. Так ось, біда в тому, що, надіславши query сусідові, роутер повинен дочекатися від нього reply. Неважливо, що у відповіді він повинен прийти. Навіть якщо роутер вжеотримав позитивну відповідь, як у нашому випадку, він не може поставити цей маршрут у роботу, доки не дочекається відповіді на всі свої запити. А запити, може, ще десь на Алясці блукають. Такий стан маршруту називається stuck-in-active. Тут нам потрібно познайомитися з термінами, що відображають стан маршруту EIGRP: active\passive route. Зазвичай вони вводять в оману. Здоровий глузд підказує, що active означає маршрут "активний", включений, працює. Однак тут все навпаки: passive це "все добре", а стан active означає, що дана підмережа недоступна, і маршрутизатор знаходиться в активному пошуку іншого маршруту, розсилаючи query і чекаючи на reply. Так ось, стан stuck-in-active (застряг в активному стані) може тривати до 3 хвилин! Після закінчення цього терміну роутер обриває відносини сусідства з тим сусідом, від якого він не може дочекатися відповіді, і може використовувати новий маршрут через R4.
Історія, льодова кров мережевого інженера. 3 хвилини даунтайму це не жарти. Як ми можемо уникнути інфаркту цієї ситуації? Виходу два: підсумовування маршрутів та так звана stub-конфігурація.
Загалом, є ще один вихід, і він називається фільтрація маршрутів (route filtering). Але це настільки об'ємна тема, що окрему статтю під неї писати, а в нас і так вже пів-книги вийшло цього разу. Тому на ваш розсуд.Як ми вже згадували, у EIGRP підсумовування маршрутів можна проводити на будь-якому роутері. Для ілюстрації, припустимо, що до нашого багатостраждального R2 підключені підмережі від 192.168.0.0/24 до 192.168.7.0/24, що дуже зручно підсумовується в 192.168.0.0/21 (згадуємо binary math). Роутер анонсує цей сумарний маршрут і всі інші знають: якщо адреса призначення починається на 192.168.0-7, то це до нього. Що відбуватиметься, якщо одна з підмереж пропаде? Роутер розсилатиме query-пакети з адресою цієї мережі (конкретною, наприклад, 192.168.5.0/24), але сусіди, замість того, щоб уже від свого імені продовжити порочну розсилку, будуть відразу у відповідь надсилати протверезні реплаї, мовляв, це твоя підсіти ти й розбирайся.
Другий варіант-stub-конфігурація. Образно кажучи, stub означає "кінець шляху", "глухий кут" в EIGRP, тобто, щоб потрапити в якусь підсіть, не підключену безпосередньодо такого роутера, доведеться йти назад. Роутер, налаштований, як stub, не пересилатиме трафік між підмережами, які йому стали відомі від EIGRP (простіше кажучи, які в show ip route позначені буквою D). Крім того, його сусіди не надсилатимуть йому query-пакети. Найпоширеніший випадок застосування - hub-and-spoke топології, особливо з надмірними лінками. Візьмемо таку мережу: зліва-філії, праворуч-основний сайт, головний офіс тощо. Для відмовостійкості надлишкові лінки. Запущено EIGRP із дефолтними налаштуваннями.
А тепер "увага, питання": що буде, якщо R1 втратить зв'язок з R4, а R5 втратить LAN? Трафік з підмережі R1 у підмережу головного офісу йтиме за маршрутом R1->R5->R2(або R3)->R4. Чи буде це ефективно? Ні. Страждатиме не тільки підсіти за R1, а й підсіти за R2 (або R3), через збільшення обсягів трафіку та його наслідків. Ось для таких ситуацій і придуманий stub. За роутерами у філіях немає інших роутерів, які б вели в інші підмережі, це “кінець дороги”, далі тільки назад. Тому ми з легким серцем можемо сконфігурувати їх як stub'и, що, по-перше, позбавить нас проблеми з “кривим маршрутом”, викладеної трохи вище, а по-друге, від флуду query-пакетів у разі втрати маршруту.
Існують різні режими роботи stub-роутера, задаються командою eigrp stub:
R1(config)#router eigrp 1
R1(config-router)#eigrp stub?
connected Do advertise connected routes
leak-map Allow dynamic prefixes based on the leak-map
receive-only Set IP-EIGRP як receive only neighbor
redistributed Do advertise redistributed routes
static Do advertise static routes
summary Do advertise summary routes
За замовчуванням, якщо просто дати команду eigrp stub, включаються режими сonnected і summary. Інтерес представляє режим receive-only, в якому роутер не анонсує жодних мереж, тільки слухає, що йому кажуть сусіди (у RIP є команда passive interface, яка робить те саме, але в EIGRP вона повністю відключає протокол на вибраному інтерфейсі, що не дозволяє встановити сусідство).Важливі моменти в теорії EIGRP, які не потрапили до статті:
- У EIGRP можна налаштувати автентифікацію сусідів
- Graceful shutdown концепції
Практика EIGRP
"Ліфт мі Ап" купили фабрику в Калінінграді. Там виробляють мізки ліфтів: мікросхеми, ПЗ. Фабрика дуже велика – три точки по місту – три маршрутизатори з'єднані в кільце.
Але невдача - на них вже запущено EIGRP як протокол динамічної маршрутизації. Причому адресація кінцевих вузлів з іншої підмережі - 10.0.0.0/8. Всі інші параметри (лінкові адреси, адреси лупбек інтерфейсів) ми змінили, але кілька тисяч адрес локальної мережі з серверами, принтерами, точками доступу – робота не на пару годин – відклали на потім, а в IP-плані зарезервували на майбутнє для Калінінграда підсіти 172.16 .32.0/20.
Зараз у нас використовуються такі мережі:
Як налаштовується це диво? Нехитро, на перший погляд:
router eigrp 1
network 172.16.0.0 0.0.255.255
network 10.0.0.0
В EIGRP зворотну маску можна задавати, вказуючи тим самим вужчі рамки, або не задавати, тоді буде обрано стандартну маску для цього класу (16 для класу B - 172.16.0.0 і 8 для класу 8 - 10.0.0.0)Такі команди надаються на всіх маршрутизаторах Автономної Системи. АС визначається цифрою у команді router eigrp, тобто у нашому випадку маємо АС №1. Ця цифра має бути однаковою на всіх маршрутизаторах (на відміну від OSPF).
Але є в EIGRP серйозна каверза: за замовчуванням включено автоматичне підсумовування маршрутів у класовому вигляді (у версіях IOS до 15).
Порівняємо таблиці маршрутизації на трьох маршрутизаторах Калінінграда:Мережа 10.0.0.1/24 підключена у нас до klgr-center-gw1 і він про неї знає:
klgr-center-gw1:
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:35:23, Null0
C 10.0.0.0/24 є безпосередньо підключеним, FastEthernet1/0
Але не знає про 10.0.1.0/24 та 10.0.2.0/24/Klgr-balt-gw1 знає про свої дві мережі 10.0.1.0/24 і 10.0.2.0/24, але мережу 10.0.0.0/24 він кудись сховав.
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:42:05, Null0
C 10.0.1.0/24 є безпосередньо підключеним, FastEthernet1/1.2
C 10.0.2.0/24 є безпосередньо підключеним, FastEthernet1/1.3
Обидва вони створили маршрут 10.0.0.0/8 з адресою next hop Null0.А ось klgr-center-gw2 знає, що підмережі 10.0.0.0/8 знаходяться за обома його WAN інтерфейсами.
D 10.0.0.0/8 via 172.16.2.41, 00:42:49, FastEthernet0/1
via 172.16.2.45, 00:38:05, FastEthernet0/0
Щось дуже дивне діється.
Але якщо ви перевірите конфігурацію цього маршрутизатора, то, ймовірно, помітите:router eigrp 1
network 172.16.0.0
network 10.0.0.0
auto-summary
У всьому винне автоматичне підсумовування. Це найбільше зло EIGRP. Розглянемо докладніше, що відбувається. klgr-center-gw1 та klgr-balt-gw1 мають підмережі з 10.0.0.0/8, вони їх підсумовують за умовчанням, коли передають сусідам.
Тобто, наприклад, msk-balt-gw1 передає не дві мережі 10.0.1.0/24 та 10.0.2.0/24, а одну узагальнену: 10.0.0.0/8. Тобто його сусід думатиме, що за msk-balt-gw1 знаходиться вся ця мережа.
Але що станеться, якщо раптом на balt-gw1 потрапить пакет з адресатом 10.0.50.243, про який той нічого не знає? На цей випадок і створюється так називаний Blackhole-маршрут:
10.0.0.0/8 is a summary, 00:42:05, Null0
Отриманий пакет буде викинутий у цю чорну дірку. Це робиться, щоб уникнути петель маршрутизації.
Так ось обидва ці маршрутизатори створили свої blackhole-маршрути та ігнорують чужі анонси. Реально на такій мережі ці три девайси один одного так і не зможуть пінгувати, поки що... поки ви не відключите auto-summary.Перше, що ви повинні зробити при налаштуванні EIGRP:
router eigrp 1
no auto-summary
На всіх пристроях. І всім буде добре:Klgr-center-gw1:
C 10.0.0.0 є безпосередньо підключеним, FastEthernet1/0
D 10.0.1.0 via 172.16.2.37, 00:03:11, FastEthernet0/0
D 10.0.2.0 via 172.16.2.37, 00:03:11, FastEthernet0/0
klgr-balt-gw110.0.0.0/24 is subnetted, 3 subnets
D 10.0.0.0 via 172.16.2.38, 00:08:16, FastEthernet0/1
C 10.0.1.0 є безпосередньо підключеним, FastEthernet1/1.2
C 10.0.2.0 є безпосередньо підключеним, FastEthernet1/1.3
klgr-center-gw2:10.0.0.0/24 is subnetted, 3 subnets
D 10.0.0.0 via 172.16.2.45, 00:11:50, FastEthernet0/0
D 10.0.1.0 via 172.16.2.41, 00:11:48, FastEthernet0/1
D 10.0.2.0 via 172.16.2.41, 00:11:48, FastEthernet0/1Налаштування передачі маршрутів між різними протоколами
Наше завдання – організувати передачу маршрутів між цими протоколами: з OSPF до EIGRP і навпаки, щоб усі знали маршрут до будь-якої підмережі.
Це називається редистрибуцією (перерозподілом) маршрутів.Для її здійснення нам потрібна хоча б одна точка стику, де буде запущено одночасно два протоколи. Це може бути msk-arbat-gw1 або klgr-balt-gw1. Виберемо другий.
З EIGRP до OSPF:
klgr-gw1(config)#router ospf 1
klgr-gw1(config-router)#redistribute eigrp 1 subnets
Дивимося маршрути на msk-arbat-gw1:msk-arbat-gw1#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - мобільний, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS рівень-1, L2 - IS-IS рівень-2, ia - IS-IS рівень області
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static routeGateway of last resort is 198.51.100.1 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O E2 10.0.0.0/8 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.1.0/24 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.2.0/24 via 172.16.2.34, 00:24:50, FastEthernet0/1.7
172.16.0.0/16 is variably subnetted, 30 subnets, 5 masks
O E2 172.16.0.0/16 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
C 172.16.0.0/24 є безпосередньо підключеним, FastEthernet0/0.3
C 172.16.1.0/24 є безпосередньо підключеним, FastEthernet0/0.2
C 172.16.2.0/30 є безпосередньо підключеним, FastEthernet0/1.4
C 172.16.2.16/30 є безпосередньо підключеним, FastEthernet0/1.5
C 172.16.2.32/30 є безпосередньо підключеним, FastEthernet0/1.7
O E2 172.16.2.36/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.40/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.44/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
C 172.16.2.128/30 є безпосередньо підключеним, FastEthernet0/1.8
O 172.16.2.160/30 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.2.192/30 via 172.16.2.197, 00:13:21, FastEthernet1/0.911
C 172.16.2.196/30 є безпосередньо підключеним, FastEthernet1/0.911
C 172.16.3.0/24 є безпосередньо підключеним, FastEthernet0/0.101
C 172.16.4.0/24 є безпосередньо підключеним, FastEthernet0/0.102
C 172.16.5.0/24 є безпосередньо підключеним, FastEthernet0/0.103
C 172.16.6.0/24 є безпосередньо підключеним, FastEthernet0/0.104
O 172.16.24.0/24 via 172.16.2.18, 01:00:55, FastEthernet0/1.5
O 172.16.128.0/24 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.129.0/26 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.144.0/24 via 172.16.2.130, 00:13:21, FastEthernet0/1.8
O 172.16.160.0/24 via 172.16.2.197, 00:13:31, FastEthernet1/0.911
C 172.16.255.1/32 є directly connected, Loopback0
O 172.16.255.48/32 via 172.16.2.18, 01:00:55, FastEthernet0/1.5
O E2 172.16.255.64/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.65/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.66/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O 172.16.255.80/32 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.255.96/32 via 172.16.2.130, 00:13:21, FastEthernet0/1.8
via 172.16.2.197, 00:13:21, FastEthernet1/0.911
O 172.16.255.112/32 via 172.16.2.197, 00:13:31, FastEthernet1/0.911
198.51.100.0/28 is subnetted, 1 subnets
C 198.51.100.0 is directly connected, FastEthernet0/1.6
S* 0.0.0.0/0 via 198.51.100.1Ось ті, що з міткою Е2 – нові імпортовані маршрути. Е2 означає, що це зовнішні маршрути 2-го типу (), тобто вони були введені в процес OSPF ззовні
Тепер з OSPF до EIGRP. Це трохи складніше:
klgr-gw1(config)#router eigrp 1
klgr-gw1(config-router)#redistribute ospf 1 metric 100000 20 255 1 1500
Без вказівки метрики (ось цього довгого набору цифр) команда виконається, але не відбудеться редистрибуції.Імпортовані маршрути отримують мітку EX у таблиці маршрутизації та адміністративну дистанцію 170, замість 90 для внутрішніх:
klgr-gw2#sh ip routeGateway of last resort is not set
172.16.0.0/16 is variably subnetted, 30 subnets, 4 masks
D EX 172.16.0.0/24 [170 /33280] via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.1.0/24 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.0/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.4/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.16/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D 172.16.2.32/30 [ 90 /30720] via 172.16.2.37, 00:38:59, FastEthernet0/0
C 172.16.2.36/30 є безпосередньо підключеним, FastEthernet0/0
D 172.16.2.40/30 via 172.16.2.37, 00:38:59, FastEthernet0/0
via 172.16.2.46, 00:38:59, FastEthernet0/1
….Ось так, здавалося б нехитро це робиться, але поверхнева простота - редистрибуція таїть в собі багато тонких і неприємних, коли додається хоча б один надлишковий лінк між двома різними доменами.
Універсальна порада - намагайтеся уникати редистрибуції, якщо це можливо. Тут працює головне життєве правило - що простіше, то краще.Маршрут за замовчуванням
Тепер саме час перевірити доступ до Інтернету. З Москви він чудово собі працює, а от якщо перевірити, наприклад з Петербурга (пам'ятаємо, що ми видалили всі статичні маршрути):PC>ping linkmeup.ruPinging 192.0.2.2 with 32 bytes of data:
Reply from 172.16.2.5: Destination host unreachable.
Reply from 172.16.2.5: Destination host unreachable.
Reply from 172.16.2.5: Destination host unreachable.Ping statistics for 192.0.2.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Це пов'язано з тим, що ні spb-ozerki-gw1, ні spb-vsl-gw1, ні будь-хто інший у нашій мережі не знає про маршрут за замовчуванням, крім msk-arbat-gw1, на якому він налаштований статично.
Щоб виправити цю ситуацію, нам достатньо дати одну команду у Москві:msk-arbat-gw1(config)#router ospf 1
msk-arbat-gw1(config-router)#default-information originate
Після цього лавинно поширюється інформація про те, де знаходиться шлюз останньої надії.Інтернет тепер доступний:
PC>tracert linkmeup.ruTracing route to 192.0.2.2 over a maximum of 30 hops:
1 3 ms 3 ms 3 ms 172.16.17.1
2 4 ms 5 ms 12 ms 172.16.2.5
3 14 ms 20 ms 9 ms 172.16.2.1
4 17 ms 17 ms 19 ms 198.51.100.1
5 22 ms 23 ms 19 ms 192.0.2.2Корисні команди для траблшутингу
1) Список сусідів та стан зв'язку з ними викликається командою show ip ospf neighbor
msk-arbat-gw1:Neighbor ID Pri State Dead Time Address Interface
172.16.255.32 1 FULL/DROTHER 00:00:33 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:34 172.16.2.18 FastEthernet0/1.5
172.16.255.64 1 FULL/DR 00:00:33 172.16.2.34 FastEthernet0/1.7
172.16.255.80 1 FULL/DR 00:00:33 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/DR 00:00:33 172.16.2.197 FastEthernet1/0.911
2) Або для EIGRP: show ip eigrp neighborsIP-EIGRP небагатьох процесів 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.2.38 Fa0/1 12 00:04:51 40 1000 0 54
1 172.16.2.42 Fa0/0 13 00:04:51 40 1000 0 58
3) За допомогою команди show ip protocolsможна переглянути інформацію про запущені протоколи динамічної маршрутизації та їх взаємозв'язок.Klgr-balt-gw1:
Routing Protocol is «EIGRP 1»
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: EIGRP 1, OSPF 1
Automatic network summarization is in effect
Automatic address summarization:
Maximum path: 4
Routing for Networks:
172.16.0.0
172.16.2.42 90 4
172.16.2.38 90 4
Distance: internal 90 external 170Routing Protocol is «OSPF 1»
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 172.16.255.64
It is an autonomous system boundary router
Redistributing External Routes from,
EIGRP 1
Номер області в цьому router є 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
172.16.2.32 0.0.0.3 area 0
Routing Information Sources:
Gateway Distance Last Update
172.16.255.64 110 00:00:23
Distance: (default is 110)
4) Для налагодження та розуміння роботи протоколів буде корисно скористатися такими командами:
debug ip OSPF events
debug ip OSPF adj
debug EIGRP packetsСпробуйте посмикати різні інтерфейси та подивитися, що відбувається в дебазі, які повідомлення летять.
Завдання №7
Наостанок комплексне завдання.
На останній нараді Ліфт мі Ап було вирішено, що мережу Калінінграда необхідно також перекладати на OSPF.
Перехід має бути здійснений без розривів зв'язку. Було вирішено, що найкращим варіантом буде паралельно з EIGRP підняти OSPF на трьох маршрутизаторах Калінінграда і після того, як буде перевірено, що вся інформація про маршрути Калінінграда поширилася рештою мережі і навпаки, відключити EIGRP. логотип сайту.OSPF EIGRP route redistribution packet tracer мережі для найменших Додати теги
Маршрутизатори функціонують у мережах із комутацією пакетів, де всі можливі маршрути вже існують. Процес прокладання шляху здійснюється або вручну адміністратором (статична маршрутизація), або автоматично маршрутизуючим протоколом (динамічна маршрутизація).
Маршрутизатори, знаючи про шлях до деяких мереж, обмінюються цією інформацією з іншими пристроями. Після таких оновленьвсі маршрутизатори матимуть узгоджену інформацію про маршрути доступних мереж. Процес обміну оновлення реалізують протоколи маршрутизації. Таким чином, протоколи маршрутизації поділяють мережну інформацію між маршрутизаторами.
При змінах топології потрібен деякий час ( час збіжності чи конвергенції) для узгодження інформаціїу таблицях маршрутизації всіх маршрутизаторів мережі. Час збіжності є важливим чинником під час виборів протоколу маршрутизації.
Маршрутна інформація збирається за певними правилами під час реалізації алгоритму динамічного обміну оновленнями(update, модифікаціями) між маршрутизаторами. Протокол маршрутизаціїповинен створювати та підтримувати таблиці маршрутизації, де зберігаються шляхи всім доступним мереж призначення, і навіть сповіщати інші маршрутизатори про всі відомі йому зміни у топології мережі, тобто. вирішувати задачу виявлення мереж.
Сукупність мереж, представлених маршрутизаторами під загальним адміністративним управлінням, утворює автономну систему(рис. 3.1). Прикладами автономних систем є мережі окремих провайдерів ISP. Автономні системи нумеруються (AS1, AS2, …AS107, …) та у деяких протоколах ( IGRP , EIGRP ) ці номери використовуються для конфігурації.
Мал. 3.1.
У цьому курсі розглядається маршрутизація лише всередині автономної системи, де працюють протоколи внутрішньої маршрутизації (Interior Gateway Protocols - IGP), до яких відносяться RIP, RIPv2, EIGRP, OSPF, IS-IS. Маршрутизацію між автономними системами здійснюють протоколи зовнішньої маршрутизації ( Exterior Gateway Protocols - EGP). Прикладом протоколу зовнішньої маршрутизації є протокол BGP, який працює на прикордонних маршрутизаторах автономних систем (рис. 3.1).
Сукупність протоколів маршрутизації наведено у табл. 3.1 , з якої випливає, що протоколи динамічної маршрутизації, що працюють всередині автономних систем, в свою чергу поділяються на протоколи вектора відстані (distance-vector)і протоколи стану каналу (link-state).
Протоколи вектор відстаньвизначають відстань та напрямок, тобто. вектор з'єднання у складовій мережі на шляху до адресата. При використанні протоколу вектор відстаньмаршрутизатори надсилають всю або частину таблиці маршрутизації сусіднім (суміжним) маршрутизаторам. У таких протоколах як RIPі RIP-2відстань виражається в кількості переходів (hop count)у з'єднанні по дорозі від вузла джерела до адресата призначення. Обмін оновленнями ( update ) чи модифікаціями відбувається періодичнонавіть якщо в мережі немає жодних змін, на що витрачається значна частина смуги пропускання. Отримавши оновлення маршрутної інформації, маршрутизатор може знову обчислити всі відомі шляхи і модернізувати таблицю маршрутизації.
Протоколи стану каналустворюють повну картину топології мережі та обчислюють найкоротші шляхи до всіх мереж призначення. Якщо шляхів з однаковою метрикою кілька, то вибирається перший із обчислених. Розсилання оновленьмаршрутної інформації проводиться тільки при змінах топології мережі. Протоколи стану каналу (або з'єднання) швидше реагують на зміни в мережі порівняно з протоколами вектора відстані, але потребують великих обчислювальних ресурсів.
Коли інкапсульований кадр кадр прибуває на вхідний інтерфейс , маршрутизатор декапсулирует його, потім використовує таблицю маршрутизації, щоб визначити, яким маршрутом направити пакет, тобто. на який свій вихідний інтерфейс передати пакет, що надійшов. Вихідний інтерфейс пов'язаний із найбільш раціональним маршрутом до адресата призначення. Цей процес називається комутацієюабо просуваннямпакет. На вихідному інтерфейсі пакет інкапсулюється в новий кадр, при цьому маршрутизатор додає інформацію для формування кадру (див. матеріали "Принципи та засоби міжмережевої взаємодії").
Маршрутизатори здатні одночасно підтримувати кілька незалежних протоколів із різними адміністративними відстанями (AD), Що показують ступінь достовірності джерела маршруту. Чим менше AD, тим вища достовірність (див. табл. 1.1). У таблицю маршрутизації встановлюються маршрути, створені протоколами з найменшою адміністративною відстанню.
Визначення протоколом маршрутизації найбільш раціонального (оптимального) шляху провадиться на основі певного критерію - метрики. Значення метрики використовується для оцінки можливих шляхів до адресата призначення. У цьому курсі розглядаються такі протоколи маршрутизації:
Перелічені протоколи використовують різні параметри метрики.
Різні протоколи маршрутизації використовують різні алгоритми під час виборів маршруту, тобто. вихідного інтерфейсу та (або) адреси наступного переходу, на який має бути переданий пакет. Алгоритм і метрика визначаються цілим рядом завдань, таких як простота, стійкість, гнучкість, швидка збіжністьабо конвергенція. Східність – це процес узгодження між маршрутизаторами мережі інформації про доступні маршрути. При зміні стану мережі необхідно, щоб обмін модифікаціями відновив узгоджену мережну інформацію.
Кожен алгоритм за своїм інтерпретує вибір найбільш раціонального шляху на основі метрики. Зазвичай менше значення метрики відповідає кращому маршруту. Метрика може базуватися на одному або кількох параметрах шляху. У протоколах маршрутизації найчастіше використовуються такі параметри метрики:
| Смуга пропуску(Bandwidth) | - | здатність з'єднання передавати дані із деякою швидкістю. Наприклад, з'єднання мережі FastEthernet передають дані зі швидкістю 100 Мбіт/c, переважно каналів Е1 зі швидкістю 2,048 Мбіт/c. |
| Затримка(Delay) | - | це тривалість проходження пакета від джерела до адресата призначення. Затримка залежить від кількості проміжних з'єднань та їх типів, обсягу буферних пристроїв маршрутизаторів, збіжності мережі та відстані між вузлами. | - | визначається кількістю інформації, що завантажує мережеві ресурси (маршрутизатори та канали). Чим більше завантаження, тим більше черги на обслуговування, тим довше пакет буде в дорозі. |
| Надійність(Reliability) | - | визначається інтенсивністю помилок кожному мережевому соединении. |
| Кількість переходів(Hop count) | - | це кількість маршрутизаторів, якими пакет має пройти шляху до адресату призначення (кількість переходів від маршрутизатора до маршрутизатору). |
| Вартість(Cost) | - | узагальнений параметр витрат за передачу пакета до адресату призначення. Іноді вартість має довільне значення, призначене адміністратором. |
Найбільш відомим у мережі Internet протоколом вектора відстані (distance-vector) є Routing Information Protocol (RIP), який використовує як метрику кількість переходів(hop count) на шляху до адресата призначення.
Іншим простим протоколом вектора відстані є Interior Gateway Routing Protocol ( IGRP), який був розроблений у корпорації Cisco. Для роботи у великих мережах на зміну йому прийшов протокол Enhanced IGRP (EIGRP)що включає багато особливостей протоколів як типу link-state, так і distance-vector. Тому він є гібридним протоколом. Однак розробники фірми Cisco відносять його до протоколів distance-vector.
Протоколи вектора відстані (RIP, IGRP) періодично розсилають оновленнямаршрутної інформації У протоколу RIP цей період дорівнює 30 с. При цьому оновлюються таблиці маршрутизації, які зберігають всю інформацію про маршрути мережі. При зміні в мережі маршрутизатор, який виявив таку зміну, відразу починає обмін маршрутною інформацією із сусідніми маршрутизаторами. Цей обмін йде послідовно від маршрутизатора до маршрутизатора з деякою затримкою, яка визначається часом модифікації таблиць у кожному маршрутизаторі, а також спеціальним таймером. Тому збіжність (конвергенція)мережі, коли всі маршрутизатори матимуть узгоджену інформацію про мережеві з'єднання, відбувається повільнощо є недоліком протоколів вектора відстані.
Таким чином, протоколи вектора відстані RIP характеризуються повільною збіжністю, тобто. тривалим часом узгодження інформації у таблицях маршрутизації за змін топології мережі.
Протокол вектора відстані RIP використовує лічильник переходів (hop count) як метрику, щоб визначити відстань до певного з'єднання в складовій мережі. Якщо існує кілька шляхів, то RIP вибере шлях із найменшим числом маршрутизаторів або переходів до адресата призначення. Однак вибраний маршрут не завжди є найкращим шляхом до адресата, оскільки вибраний маршрут з найменшою кількістю пристроїв може характеризуватись меншою швидкістю передачі (вужчою смугою пропускання, меншою пропускною здатністю) порівняно з альтернативними маршрутами, створеними іншими протоколами. Крім того, RIP не може спрямовувати пакети далі 15 переходів, тому він рекомендований для роботи в малих та середніх мережах. Розсилання оновленьпротоколом першої версії RIPv1 виробляється в широкомовному режимі(адреса 255.255.255.255 ).
Протокол першої версії RIPv1 вимагає, щоб усі пристрої підмережі використовували однакову маску підмережі, т.к. RIP не включає інформацію про маску підмережі під час оновлення маршрутизації. Такий метод отримав назву маршрутизації з урахуванням класів (classful routing), що обмежує застосування протоколу RIPv1 у сучасних мережах.
Протокол вектора відстані другої версії RIPVersion 2 ( RIPv2) забезпечує безкласову маршрутизацію CIDR(Classless Interdomain Routing ), оскільки до оновлення маршрутизації включено інформацію про маску підмережі(Про префікс). При цьому всередині однієї мережі можуть бути підмережі з масками змінної довжини (Variable-Length Subnet Mask - VLSM). В оновлення також включено адресну інформацію про шлюзи за замовчуванням. Розсилання оновлень протоколом версії RIPv2 здійснюється в багатоадресному режимі (
Протоколи динамічної маршрутизації призначені для автоматизації процесу побудови маршрутних таблиць маршрутизаторів. Принцип їх використання досить простий: маршрутизатори за допомогою порядку, що встановлюється протоколом, розсилають певну інформацію зі своєї таблиці маршрутизації іншим і коригують свою таблицю на основі отриманих від інших даних.
Такий метод побудови та підтримки маршрутних таблиць суттєво спрощує завдання адміністрування мереж, у яких можуть відбуватися зміни (наприклад, розширення) або у ситуаціях, коли якісь маршрутизатори та/або підмережі виходять з ладу.
Слід зазначити, що використання протоколів динамічної маршрутизації не скасовує можливість «ручного» внесення даних до таблиць маршрутизаторів. Внесені в такий спосіб записи називають статичними, а записи, отримані результаті обміну інформацією між маршрутизаторами – динамічними. У будь-якій таблиці маршрутизації завжди є принаймні один статичний запис – маршрут за замовчуванням.
Сучасні протоколи маршрутизації поділяються на дві групи: протоколи типу «вектор-відстань» та протоколи типу «стан каналу».
У протоколах типу «вектор-відстань» кожен маршрутизатор розсилає список адрес доступних йому мереж («векторів»), з кожною з яких пов'язано параметр «відстань» (наприклад, кількість маршрутизаторів до цієї мережі, значення, засноване на продуктивності каналу тощо) .). Основним представником протоколів цієї групи є протокол RIP (Routing Information Protocol, протокол маршрутної інформації).
Протоколи типу «стан каналу» ґрунтуються на іншому принципі. Маршрутизатор обмінюються між собою топологічною інформацією про зв'язки в мережі: які маршрутизатори з якими мережами пов'язані. У результаті кожен маршрутизатор має повне уявлення про структуру мережі (причому це уявлення буде однаковим всім), з урахуванням якого обчислює власну оптимальну таблицю маршрутизації. Протоколом цієї групи є протокол OSPF (Open Shortest Path First, «відкрий найкоротший шлях першим»).
Протокол RIP.
Протокол RIP (Routing Information Protocol, протокол маршрутної інформації) є найпростішим протоколом динамічної маршрутизації. Він відноситься до протоколів типу "вектор-відстань".
Під вектором протокол RIP визначає IP-адреси мереж, а відстань вимірюється в переходах («хопах», hope) – кількості маршрутизаторів, які мають пройти пакет, щоб досягти зазначеної мережі. Слід зазначити, що максимальне значення відстані для протоколу RIP дорівнює 15 значення 16 трактується особливим чином «мережа недосяжна». Це визначило основний недолік протоколу - він виявляється незастосовним у великих мережах, де можливі маршрути, що перевищують 15 переходів.
Протокол RIP версії 1 має низку суттєвих для практичного використання недоліків. До важливих проблем належать такі:
- Оцінкака відстанілише з урахуванням числа переходів. Протокол RIP враховує реальну продуктивність каналів зв'язку, що може бути неефективним у гетерогенних мережах, тобто. мережах, що поєднують канали зв'язку різного пристрою, продуктивності, в яких використовуються різні мережеві технології.
- Проблема повільної конвергенції. Маршрутизатори, які використовують протокол RIP. Розсилають маршрутну інформацію кожні 30 с, причому їхня робота не синхронізована. У ситуації, коли деякий маршрутизатор виявить, що якась мережа стала недоступною, то в гіршому випадку (якщо проблему було виявлено відразу після чергової розсилки) він повідомить про це сусідам через 30 с. Для сусідніх маршрутизаторів все відбуватиметься також. Це означає, що інформація про недоступність будь-якої мережі може поширюватися маршрутизаторам досить довго, очевидно, що мережа при цьому перебуватиме в нестабільному стані.
- Широкомовне розсилання таблиць маршрутизації. Протокол RIP спочатку припускав, що маршрутизатори розсилають інформацію у широкомовному режимі. Це означає, що відправлений пакет змушені отримати та проаналізувати на канальному, мережевому та транспортному рівні всі комп'ютери мережі, до якої він спрямований.
Частково ці проблеми вирішуються у версії 2 (RIP2).
Протокол OSPF
Протокол OSPF (Routing (Open Shortest Path First, «відкрий найкоротший шлях першим»)) є більш новим протоколом динамічної маршрутизації і відноситься до протоколів типу стан каналу.
Функціонування протоколу OSPF ґрунтується на використанні всіма маршрутизаторами єдиної бази даних, що описує, як і з якими мережами пов'язаний кожен маршрутизатор. Описуючи кожен зв'язок, маршрутизатори зв'язки
ють з нею метрику – значення, що характеризує «якість» каналу. Наприклад, для мереж Ethernet зі швидкістю обміну 100 Мбіт/с використовується значення 1, а для комутованих з'єднань 56 Кбіт/с – значення 1785. Це дозволяє маршрутизаторам OSPF (на відміну від RIP, де всі канали рівнозначні) враховувати реальну пропускну здатність та виявляти ефективні маршрути. Важливою особливістю протоколу OSPF є те, що використовується групове, а не широкомовне розсилання.
Зазначені особливості, такі як групове розсилання замість широкомовної, відсутність обмежень на довжину маршруту, періодичний обмін лише короткими повідомленнями про стан, облік якості каналів зв'язку дозволяють використовувати OSPF у великих мережах. Однак таке використання може породити серйозну проблему - велика кількість маршрутної інформації, що циркулює в мережі, і збільшення таблиць маршрутизації. А оскільки алгоритм пошуку ефективних маршрутів є, з погляду обсягу обчислень, досить складним, то великих мережах можуть знадобитися високопродуктивні і, отже, дорогі маршрутизатори. Тому можливість побудови ефективних таблиць маршрутизації може розглядатися як гідність, і як недолік протоколу OSPF.
Вступ
Все про що ми говорили в попередньому розділі, стосувалося статичної маршрутизації. Записи в таблиці маршрутизації створювалися при конфігурації інтерфейсу (для інтерфейсів підключених безпосередньо), додавалися командою route (зазвичай із системних файлів завантаження) або створювалися за допомогою ICMP перенаправлення (при використанні невірних маршрутів).
Все це чудово, якщо мережа маленька. А саме, якщо існує лише одна точка підключення до інших мереж та не існує запасних маршрутів (запасні маршрути можуть бути використані у разі виходу з ладу основних). Якщо хоча б одна з трьох наведених вище умов неправильна, використовується динамічна маршрутизація.
У цьому розділі розглядаються протоколи динамічної маршрутизації, якими користуються маршрутизатори спілкування друг з одним. Ми детально розглянемо RIP, протокол обміну інформацією про маршрутизацію (Routing Information Protocol), широко використовуваний протокол, який є практично у всіх версіях TCP/IP. Потім ми розглянемо ще два протоколи маршрутизації, OSPF та BGP. Наприкінці розділу ми познайомимося з новою технікою маршрутизації, яка називається безкласовою маршрутизацією між доменами, і яка починає застосовуватися в Інтернеті для економії адрес класу B.
Динамічна маршрутизація
Динамічна маршрутизація використовується для спілкування маршрутизаторів. Маршрутизатори передають один одному інформацію про те, які мережі зараз підключені до кожного з них. Маршрутизатори спілкуються, використовуючи протоколи маршрутизації. Користувальницький процес, з якого маршрутизатори можуть спілкуватися із сусідніми маршрутизаторами, називається демоном маршрутизації (routing daemon). Як видно з малюнку 9.1, демон маршрутизації оновлює таблицю маршрутизації в ядрі відповідно до інформації, яку він одержує від сусідніх маршрутизаторів.
Динамічна маршрутизація не змінює способи, з допомогою яких ядро здійснює маршрутизацію на IP рівні, як у розділі глави 9. Ми назвали це механізмом маршрутизації (routing mechanism). Ядро так само переглядає свою таблицю маршрутизації, відшукуючи маршрути до хостів, маршрути до мереж та маршрути за замовчуванням. Змінюється лише спосіб поміщення інформації в таблицю маршрутизації - замість запуску команди route або використання завантажувальних файлів маршрути додаються та видаляються динамічно демоном маршрутизації, який працює постійно.
Як було зазначено раніше, демон маршрутизації відповідає за політику маршрутизації (routing policy), вибираючи, які маршрути необхідно помістити в таблицю маршрутизації. Якщо демон виявив кілька маршрутів до пункту призначення, він вибирає (якимось чином), який маршрут краще, і саме цей маршрут (єдиний) додає до таблиці маршрутизації. Якщо демон визначив, що канал зник (можливо через вихід з ладу маршрутизатора або телефонної лінії), він може видалити відповідні маршрути або додати альтернативні маршрути, щоб уникнути несправності.
У Internet, сьогодні, використовується безліч різних протоколів маршрутизації. Internet організований як спільнота автономних систем (AS - autonomous systems), кожна з яких зазвичай адмініструється незалежно від інших. Наприклад, мережа, побудована університетському містечку, зазвичай вважається автономної системою. Магістраль (backbone) NSFNET з погляду Internet - це автономна система, тому що всі маршрутизатори на магістралі знаходяться під єдиним адміністративним контролем.
p align="justify"> Для кожної автономної системи вибирається власний протокол маршрутизації, за допомогою якого здійснюється взаємодія між маршрутизаторами в цій автономній системі. Такий протокол називається протоколом внутрішніх маршрутизаторів (IGP - interior gateway protocol) або протоколом внутрішньодоменної маршрутизації (intradomain routing protocol). Найбільш популярний IGP – це протокол обміну інформацією про маршрутизацію (RIP – Routing Information Protocol). Новіший IGP це протокол Open Shortest Path First (OSPF). Він був розроблений як заміна RIP. Застарілий IGP, який нині не використовується, HELLO - це IGP, який спочатку використовувався на магістралі NSFNET до 1986 року.
Нові вимоги до маршрутизаторів Router Requirements RFC [Almquist 1993] визначають, що маршрутизатор, який реалізує будь-які динамічні протоколи маршрутизації, повинен підтримувати OSPF та RIP, а також може підтримувати інші IGP.
Існують протоколи маршрутизації, які називаються протоколами зовнішніх маршрутизаторів (EGP – exterior gateway protocols) або протоколами міждоменної маршрутизації (interdomain routing protocols). Вони призначені для спілкування між маршрутизаторами, що у різних автономних системах. Історично (і на превеликий жаль) попередником всіх EGP був протокол з тим самим ім'ям: EGP. Новіший EGP - протокол прикордонних маршрутизаторів (BGP - Border Gateway Protocol) в даний час використовується між магістраллю NSFNET і деякими регіональними мережами, які підключені до магістралі. Планується, що BGP замінить собою EGP.
Демони маршрутизації в Unix
У Unix системах зазвичай запускається демон маршрутизації, званий routed. Він присутній практично у кожній версії TCP/IP. Цей демон розуміє лише протокол RIP. (Ми опишемо routed у наступному розділі.) routed призначений для мереж малого або середнього розмірів.
Альтернативна програма – gated. Цей демон підтримує як IGP, і EGP. [Fedor 1988] описує ранню реалізацію gated. На малюнку 10.1 наведено протоколи маршрутизації, що підтримуються демоном routed та двома версіями демона gated. Більшість систем, які використовують демони маршрутизації, запускають routed, проте якщо виникає необхідність підтримувати різні протоколи маршрутизації, використовується gated.
|
Протоколи внутрішніх маршрутизаторів |
Протоколи зовнішніх маршрутизаторів |
||||
| routed | |||||
| gated, Version 2 | |||||
| gated, Version 3 | |||||
Рисунок 10.1 Протоколи маршрутизації, що підтримуються routed та gated.
Ми опишемо RIP Version 1 у наступному розділі, а відмінності RIP Version 2, OSPF та BGP відповідно у розділах , і цього розділу.
RIP: протокол обміну інформацією про маршрутизацію
У цьому розділі наводиться огляд RIP, так як це протокол маршрутизації, що найбільш широко використовується. Офіційна специфікація протоколу RIP знаходиться в RFC 1058 [Hedrik 1988a], проте цей RFC був написаний через кілька років після того, як протокол набув широкого поширення.
Формат повідомлення
RIP повідомлення передаються в UDP датаграмах, як показано малюнку 10.2. (Ми розглянемо UDP в.)
Рисунок 10.2 Інкапсуляція RIP повідомлення у UDP датаграму.
На малюнку 10.3 показано формат RIP повідомлення разом з IP адресами.
Якщо поле команда дорівнює 1 – це запит, якщо 2 – відгук. Існують ще два значення поля команди (3 та 4), а також два недокументовані значення: опитування (5) та пункт опитування (6). У запиті міститься вимога до іншої системи надіслати всю або частину її таблиці маршрутизації. У відповідь міститься вся або частина таблиці маршрутизації відправника.
Поле версія зазвичай встановлене в 1, однак для RIP Version 2 (розділ ) це значення встановлюється в 2.
Наступні 20 байт стримають: сімейство адрес (яке завжди дорівнює 2 для IP адрес), IP адрес і відповідний показник. У наступних розділах ми побачимо, що ролі показника RIP виступає лічильник пересилок.
У RIP повідомленні може бути оголошено до 25 маршрутизаторів. Обмеження 25 визначається повним розміром RIP повідомлення, 20х25+4=504, менше ніж 512 байт. Через обмеження 25 маршрутизаторів, на один запит, як правило, потрібно надіслати кілька відгуків, щоб передати всю таблицю маршрутизації.
Рисунок 10.3 Формат RIP повідомлення.
Звичайне функціонування
Давайте подивимося, як зазвичай працює routed з використанням RIP. Номер зарезервованого порту для RIP – UDP порт 520.
- Ініціалізація. Коли демон стартує, він визначає всі активізовані інтерфейси та посилає пакет із запитом на кожен інтерфейс, з вимогою до віддалених маршрутизаторів надіслати повні таблиці маршрутизації. У разі каналу точка-точка, цей запит надсилається на інший кінець каналу. Запит надсилається широкомовними повідомленнями, якщо мережа їх підтримує. Порт призначення – UDP порт 520 (демон маршрутизації на іншому маршрутизаторі). Характеристики такого запиту такі: поле команди встановлено в 1, поле сімейство адрес встановлено в 0 і показник встановлено в 16. Подібний формат відповідає спеціальному запиту, у відповідь на який потрібно надіслати повну таблицю маршрутизації.
- Запит ухвалено. У разі спеціального запиту, який ми щойно описали, запитувачу надсилається повна таблиця маршрутизації. Інакше обробляється кожен пункт у запиті: якщо є маршрут на вказану адресу, показник встановлюється у певне значення, інакше показник встановлюється у 16. (Показник, встановлений у 16, це спеціальне значення, яке означає "нескінченно" (infinity) і повідомляє, що маршруту до цього пункту призначення немає.) Повертається відповідь.
- Відповідь прийнято. Якщо відповідь визнана коректною, таблицю маршрутизації можна оновити. Можуть бути додані нові записи, існуючі можуть бути модифіковані або видалені.
- Регулярне поновлення маршрутизації. Кожні 30 секунд вся або частина таблиці маршрутизації надсилається кожному сусідньому маршрутизатору. Таблиця маршрутизації поширюється широкомовними повідомленнями (у разі Ethernet) або відправляється на інший кінець каналу точка-точка.
- Незаплановане оновлення. Відбувається, якщо змінюється показник маршруту. У цьому випадку немає необхідності надсилати таблицю маршрутизації повністю, передається лише той запис, який було змінено.
З кожним маршрутом пов'язаний тайм-аут. Якщо система, що використовує RIP, визначила, що маршрут не було оновлено протягом трьох хвилин, показник маршруту встановлюється в стан "нескінченно" (16) і позначається для видалення. Це означає, що пропущено шість 30-секундних оновлень від маршрутизатора, який оголосив маршрут. Однак, видалення маршруту з локальної таблиці маршрутизації відкладається ще на 60 секунд, щоб переконатися, що маршрут дійсно зник.
Показники (metrics)
Як показник RIP використовуються лічильник пересилок. Для всіх безпосередньо підключених інтерфейсів лічильник пересилок дорівнює 1. Розглянемо маршрутизатори та мережі, показані на малюнку 10.4. Чотири пунктирні лінії показують широкомовні повідомлення RIP.
Рисунок 10.4 Приклад маршрутизаторів та мереж.
Маршрутизатор R1 оголошує маршрут N2 з лічильником пересилок рівним 1, надіславши широкомовне повідомлення на N1. (Безглуздо оголошувати маршрут до N1 у широкомовному повідомленні, надісланому на N1.) Він також оголошує маршрут до N1 з лічильником пересилок рівним 1, надіславши широкомовне повідомлення на N2. Так само, R2 оголошує маршрут до N2 з показником 1 і маршрут до N3 з показником 1.
Якщо суміжний з нами маршрутизатор оголосив маршрут до віддаленої мережі з лічильником пересилок рівним 1, то для нас показник до цієї мережі дорівнюватиме 2, так пакет необхідно надіслати спочатку на наш маршрутизатор, щоб отримати доступ до мережі. У прикладі, наведеному вище, показник N1 для R2 дорівнює 2, так само як і показник N3 для R1.
Оскільки кожен маршрутизатор посилає свої таблиці маршрутизації сусідам, визначається кожна мережа кожної автономної системі (AS). Якщо всередині AS існує кілька шляхів від маршрутизатора до мережі, маршрутизатор вибирає шлях із найменшою кількістю пересилань та ігнорує інші шляхи.
Величина лічильника пересилок обмежена значенням 15, що означає, що RIP може бути використаний тільки всередині AS, де максимальна кількість пересилок між хостами становить 15. Спеціальне значення показника, що дорівнює 16, вказує на те, що на цю IP-адресу не існує маршруту.
Проблеми
Хоч би як це звучало, все одно існують проблеми. По-перше, RIP не має уявлення про поділ на підмережі. Якщо звичайний 16-бітовий ідентифікатор хоста в адресі класу В ненульовий, RIP не може визначити, чи ненульова частина належить ідентифікатору підмережі або IP адреса - це повністю адреса хоста. Деякі реалізації використовують маску підмережі того інтерфейсу, через який надійшла RIP інформація, однак такий спосіб не завжди коректний.
По-друге, для RIP потрібно дуже багато часу, щоб відновити функціонування мережі після того, як вийшов з ладу маршрутизатор або канал. Час зазвичай становить кілька хвилин. У цей час можуть з'явитися петлі маршрутизації. У сучасних реалізаціях RIP існує безліч рекомендацій, які дозволяють позбавлятися петель маршрутизації і збільшити швидкість збіжності мереж. У RFC 1058 [Hedrik 1988a] докладно описано, як повинен бути реалізований RIP.
Використання кількості пересилок як показник маршрутизації не дозволяє використовувати інші змінні, які також повинні братися до уваги при виборі маршруту. І насамкінець, максимальне значення - 15 пересилок обмежує розмір мереж, у яких можна використовувати RIP.
Ми скористаємося програмою ripquery, щоб отримати таблиці маршрутизації деяких маршрутизаторів. ripquery відправляє один із недокументованих запитів (назване "опитування" (poll), при цьому поле команда встановлюється в 5, рисунок 10.3) на маршрутизатор, вимагаючи від нього надіслати повну таблицю маршрутизації. Якщо відповідь не отримана протягом 5 секунд, надсилається стандартний RIP запит (поле команда встановлено 1). (Раніше ми говорили, що запит із полем сімейства протоколів встановленим у 0 і з показником встановленим у 16 запитує повну таблицю маршрутизації маршрутизатора.)
На малюнку 10.5 показано два маршрутизатори, які потребують їх таблиці маршрутизації на хості sun. Ми запустимо ripquery з sun, і отримаємо інформацію про маршрутизацію з маршрутизатора наступного пересилання, netb:
sun % ripquery -n netb
504 bytes from netb (140.252.1.183): перше повідомлення містить 504 байти
тут видалено кілька рядків
140.252.1.0, metric 1 верхній Ethernet малюнку 10.5
140.252.13.0, metric 1 нижній Ethernet малюнку 10.5
244 bytes from netb (140.252.1.183): друге повідомлення з 244 байтами, що залишилися.
кілька рядків видалено
Як ми й очікували, netb оголошує нашу підмережу з показником 1. Верхній Ethernet, до якого також підключений netb (140.252.1.0), має показник 1. імена хостів.) У цьому прикладі netb налаштований таким чином, щоб вважати всі хости, що знаходяться в підмережі 140.252.13, підключеними до нього безпосередньо - таким чином, netb нічого не знає про ті хости, які дійсно знаходяться в підмережі 140.252.13. Оскільки існує лише одна точка підключення до підмережі 140.252.13, оголошення різних показників для кожного хоста не має практичного значення.
Малюнок 10.5 Два маршрутизатори netb та gateway, на які ми надіслали запит про їх таблиці маршрутизації.
На малюнку 10.6 показаний обмін пакетами, отриманий за допомогою команди tcpdump. Ми вказали інтерфейс SLIP з опцією -i sl0.
sun % tcpdump -s600 -i sl0
1 0.0 sun.2879 > netb.route: rip-poll 24
2 5.014702 (5.0147) sun.2879 > netb.route: rip-req 24
3 5.560427 (0.5457) netb.route > sun.2879: rip-resp 25:
4 5.710251 (0.1498) netb.route > sun.2879: rip-resp 12:
Рисунок 10.6 Виведення команди tcpdump під час запуску програми ripquery.
Перший запит - це команда опитування RIP (poll) (рядок 1). Тут відпрацьовується тайм-аут в 5 секунд, після чого відправляється звичайний RIP запит (рядок 2). Число 24 в кінці рядків 1 і 2 це розмір пакетів запиту в байтах: 4 байти RIP заголовок (з командою та версією), після чого слідує одна 20-байтова адреса і показник.
У рядку 3 показаний перший відгук, причому число 25 в кінці рядка вказує, що в повідомленні знаходиться 25 пар адрес та показників, що, як ми розрахували раніше, становлять 504 байти. Саме цю інформацію видає ripquery. Ми вказали опцію -s600 для tcpdump, повідомляючи про необхідність прочитати з мережі 600 байт. Це дозволяє прийняти UDP датаграму повністю (замість прийняти лише її першу частину) і потім надрукувати вміст RIP відповіді.
У рядку 4 показано друге повідомлення у відповідь від маршрутизатора, з наступними 12-ма парами адрес та показників. Ми можемо розрахувати розмір цього повідомлення, який становитиме 12х20+4=244, що якраз і друкувала ripquery раніше.
Якщо ми звернемося до маршрутизатора, який знаходиться позаду netb, до gateway, то швидше за все отримаємо, що показник до нашої підмережі 140.252.13.0 дорівнюватиме 2. Давайте перевіримо це припущення:
sun % ripquery -n gateway
504 bytes від gateway (140.252.1.4):
кілька рядків видалено
140.252.1.0, metric 1 верхній Ethernet малюнку 10.5
140.252.13.0, metric 2 нижній Ethernet малюнку 10.5
Тут показник для верхнього Ethernet на малюнку 10.5 (140.252.1.0) залишився рівним 1, тому що цей Ethernet безпосередньо підключений і до gateway, і до netb, проте наша підмережа 140.252.13.0, як ми очікували, має рівний показник 2.
Ще один приклад
Зараз ми розглянемо всі оновлення RIP, які відбуваються в мережі Ethernet без отримання запитів, і побачимо, що RIP регулярно надсилає своїм сусідам. На малюнку 10.7 показані мережі noao.edu. Для простоти маршрутизатори названі як Rn, де n – номер підмережі. Канали точка-точка показані за допомогою пунктирних ліній із зазначенням IP адрес для кожного кінця каналу.
Малюнок 10.7 Мережі noao.edu 140.252.
Ми запустили на Solaris 2.x програму snoop, що нагадує програму tcpdump, яку ми запускали на комп'ютері solaris. Цю програму можна запустити без привілею суперкористувача, проте тільки для того, щоб перехоплювати широкомовні пакети, групові пакети або пакети, що надсилаються на хост. На малюнку 10.8 показано пакети, спіймані за 60 секунд. Ми замінили більшість офіційних імен хостів на нашу виставу у формі Rn.
solaris % snoop -P -tr udp port 520
0.00000 R6.tuc.noao.edu ->
4.49708 R4.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
6.30506 R2.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
11.68317 R7.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
16.19790 R8.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
16.87131 R3.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
17.02187 gateway.tuc.noao.edu ->
20.68009 R10.tuc.noao.edu ->
29.87848 R6.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
34.50209 R4.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
36.32385 R2.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
41.34565 R7.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
46.19257 R8.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
46.52199 R3.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
47.01870 gateway.tuc.noao.edu -> 140.252.1.255 RIP R (15 destinations)
50.66453 R10.tuc.noao.edu -> BROADCAST RIP R (4 destinations)
Рисунок 10.8 RIP - широкомовні повідомлення, спіймані на solaris за 60 секунд.
Завдяки прапору -P пакети ловляться не перемішуючись, завдяки -tr друкуються відповідні тимчасові марки, а завдяки port 520 захоплюються тільки UDP датаграми у яких як порт джерела або порт призначення зазначений порт 520.
Перші 6 пакетів приходять від R6, R4, R2, R7, R8 та R3, у кожному оголошується лише одна мережа. Якщо ми заглянемо всередину пакетів, то побачимо, що R6 оголошує маршрут до мережі 140.252.6.0 з лічильником пересилок 1, R4 оголошує маршрут до 140.252.4.0 з лічильником пересилок 1, і так далі.
Маршрутизатор gateway, однак, оголосив 15 маршрутизаторів. Ми можемо запустити snoop з -v прапором і подивитися вміст RIP повідомлення. (Цей прапор видає повний вміст вхідного пакета: Ethernet заголовок, IP заголовок, UDP заголовок та RIP повідомлення. Ми видалили всю інформацію за винятком інформації RIP.) На малюнку 10.9 показаний висновок.
Порівняйте оголошені лічильники пересилок мережі 140.252.1 з топологією, наведеної малюнку 10.7.
Дуже дивний факт у тому, що у виведенні малюнку 10.8 R10 оголошує чотири мережі, тоді як малюнку 10.7 показано лише три. Якщо ми заглянемо в RIP-пакет за допомогою snoop, то побачимо наступні оголошені маршрути:
RIP: Address Metric
RIP: 140.251.0.0 16 (неможливо)
RIP: 140.252.9.0 1
RIP: 140.252.10.0 1
RIP: 140.252.11.0 1
Маршрут до мережі класу 140.251 фіктивний і не повинен оголошуватися. Він не належить noao.edu.
solaris % snoop -P -v -tr udp port 520 host gateway
багато рядків видалено
RIP: Opcode = 2 (route response)
RIP: Version = 1
RIP: Address Metric
RIP: 140.252.101.0 1
RIP: 140.252.104.0 1
RIP: 140.252.51.0 2
RIP: 140.252.81.0 2
RIP: 140.252.105.0 2
RIP: 140.252.106.0 2
RIP: 140.252.52.0 3
RIP: 140.252.53.0 3
RIP: 140.252.54.0 3
RIP: 140.252.55.0 3
RIP: 140.252.58.0 3
RIP: 140.252.60.0 3
RIP: 140.252.82.0 3
RIP: 192.68.189.0 3
RIP: 140.252.57.0 4
Рисунок 10.9 RIP відповідь від gateway.
Вираз "BROADCAST" у виведенні snoop на малюнку 10.8 для RIP пакета, надісланого R10, означає, що IP адреса призначення це обмежена широкомовна адреса 255.255.255.255 (глава 12, розділ ), а не широкомовна адреса, що вказує на подсеть521. , що використовують інші маршрутизатори.
RFC 1388 визначає нові розширення RIP, які зазвичай називаються RIP-2. Ці розширення не змінюють протокол, проте додають додаткову інформацію в поля, позначені як "мають бути нульовими" (must be zero) на малюнку 10.3. RIP та RIP-2 можуть взаємодіяти в тому випадку, якщо RIP ігнорує поля, які мають бути встановлені в нуль.
На малюнку 10.10 показано формат повідомлення RIP-2. Для RIP-2 поле версії встановлюється 2.
Домен маршрутизації - це ідентифікатор демона, що маршрутизує, якому належить цей пакет. У реалізаціях Unix це має бути ідентифікатор процесу демона. Це поле дозволяє адміністратору запустити RIP на тому самому маршрутизаторі кілька разів, причому кожен функціонуватиме з одним доменом маршрутизації.
Поле позначки маршруту призначене для підтримки протоколів зовнішніх маршрутизаторів. Тут зберігається номер автономної системи для EGP та BGP.
Маска підмережі для кожного пункту відповідає IP адресі. IP-адреса наступного пересилання - це IP-адреса пункту призначення, куди повинні посилатися пакети. Значення 0 у цьому полі означає, що пакети повинні надсилатися до системи, яка надіслала повідомлення RIP.
Рисунок 10.10 Формат повідомлення RIP2.
RIP-2 надається проста схема аутентифікації. Перші 20 байт у повідомленні RIP містять сімейство адрес, яке встановлено в 0xffff, а поле route tag, встановлено в значення 2. Решта 16 байт містять пароль у відкритому вигляді.
І насамкінець, RIP-2 підтримує групові запити на додаток до широкомовних (). При цьому зменшується завантаження хостів, які не приймають повідомлення RIP-2.
OSPF: "відкрити першим найкоротший маршрут" (Open Shortest Path First)
OSPF – це альтернативний RIP протокол внутрішніх маршрутизаторів. У OSPF знято всі обмеження, властиві RIP. OSPF Version 2 описується в RFC 1247 [Moy 1991].
OSPF - протокол стану каналу (link-state), тоді як RIP - протокол вектора відстаней (distance-vector). Термін вектор відстаней означає, що повідомлення, що надсилаються RIP, містять вектор відстаней (лічильник пересилок). Кожен маршрутизатор оновлює свою таблицю маршрутизації виходячи з векторів відстаней, що він отримує від своїх сусідів.
Коли використовується протокол стану каналу, маршрутизатор не обмінюється інформацією про відстані зі своїми сусідами. Натомість кожен маршрутизатор активно тестує статус своїх каналів до кожного сусіднього маршрутизатора та надсилає цю інформацію іншим своїм сусідам, які можуть направити потік даних в автономну систему. Кожен маршрутизатор приймає інформацію про стан каналу і на її підставі будує повну таблицю маршрутизації.
З практичної точки зору основна відмінність полягає в тому, що протокол стану каналу працює значно швидше ніж протокол вектора відстаней. Слід зазначити, що у разі протоколу стану каналу значно швидше здійснюється збіжність мережі. Під поняттям збіжності (converge) ми маємо на увазі стабілізацію мережі після будь-яких змін, як-от, поломки маршрутизатора або виходу з ладу каналу. У розділі 9.3 [Perlman 1992] порівнюються між собою два типи протоколів маршрутизації.
OSPF також відрізняється від RIP (як і багато інших протоколів маршрутизації) тим, що OSPF використовує безпосередньо IP. Це означає, що вона не використовує UDP або TCP. OSPF має власну величину, яка встановлюється в полі протоколу (protocol) в заголовку IP (рисунок 3.1).
До того ж, оскільки OSPF це протокол стану каналу, а не протокол вектора відстаней, він має інші характеристики, які роблять його кращим по відношенню до RIP.
- OSPF може розрахувати окремий набір маршрутизаторів кожного типу сервісу IP (type-of-service) (рисунок 3.2). Це означає, що з будь-якого пункту призначення може бути кілька пунктів у таблиці маршрутизації, по одному кожному типу сервісу IP.
- Кожному інтерфейсу призначається вартість. Вона може бути призначена на підставі пропускної спроможності, часу повернення, надійності або за будь-яким іншим параметром. Окрема ціна може бути призначена кожному за типу сервісу IP.
- Якщо існує декілька маршрутів до одного пункту призначення з однаковою ціною, OSPF розподіляє трафік (потік даних) порівну між цими маршрутами. Це називається балансом завантаженості.
- OSPF підтримує підмережі: маска підмережі відповідає кожному оголошеному маршруту. Це дозволяє розбити IP-адресу будь-якого класу на кілька підмереж різного розміру. (Ми показали це в прикладі розділу 3 і назвали підмережами змінної довжини.) Маршрути до хостів оголошуються з маскою підмережі, з усіх одиничних біт. Маршрут за промовчанням оголошується як IP-адреса 0.0.0.0 з маскою з усіх нульових бітів.
- Канали точка-точка між маршрутизаторами немає IP адрес на кожному кінці. Це називається мережами без адреси (unnumbered). Такий підхід дозволяє заощадити IP-адреси - дуже цінний ресурс в даний час!
- Використовується проста схема аутентифікації. Може бути вказаний пароль у вигляді відкритого тексту, як це робиться в схемі RIP-2 (розділ ).
- OSPF використовує групову адресацію () замість широкомовної, що зменшує завантаженість систем, які не розпізнають OSPF.
Оскільки більшість постачальників маршрутизаторів підтримують OSPF, він починає поступово заміщати собою RIP у більшості мереж.
BGP: протокол граничних маршрутизаторів (Border Gateway Protocol)
BGP – це протокол зовнішніх маршрутизаторів, призначений для зв'язку між маршрутизаторами в різних автономних системах. BGP заміняє старий EGP, який використовувався в ARPANET. BGP Version 3 визначено в RFC 1267 .
RFC 1268 визначає використання BGP в Internet. Практично все, що наведене нижче, взято саме із цих двох RFC. На додаток, слід зазначити, що у 1993 року BGP Version 4 розроблявся в такий спосіб (RFC 1467 [ Topolcic 1993]), щоб підтримувати CIDR, який ми опишемо у розділі цього розділу.
Системи, що підтримують BGP, обмінюються інформацією про доступність мережі з іншими системами BGP. Ця інформація включає повний шлях по автономних системах, якими повинен пройти трафік (потік даних), щоб досягти цих мереж. Ця інформація адекватна побудові графа з'єднань AS (автономних систем). При цьому виникає можливість легко оминати петлі маршрутизації, а також спрощується процес прийняття рішень щодо маршрутизації.
По-перше, необхідно сказати, що IP датаграма в AS може належати як до локального трафіку, так і транзитного трафіку. Локальний - це трафік, у якого джерело і пункт призначення знаходяться в одній AS. При цьому IP адреси джерела та призначення вказує на хости, що належать до однієї автономної системи. Решта трафік називається транзитним. Основна перевага використання BGP в Інтернеті полягає в зменшенні транзитного трафіку.
Автономна система може належати до таких категорій:
- Обмежена (stub) AS автономна система має єдине підключення до однієї зовнішньої автономної системи. У такій автономній системі є лише локальний трафік.
- Багатоінтерфейсна (multihomed) AS має приєднання до кількох віддалених автономних систем, проте за нею заборонено проходження транзитного трафіку.
- Транзитна (transit) AS має підключення до кількох автономних систем і відповідно до обмежень може пропускати через себе як локальний, так і транзитний трафік.
Загальна топологія Internet складається з транзитних, багатоінтерфейсних та обмежених автономних систем. Обмежені та багатоінтерфейсні автономні системи не потребують використання BGP – вони можуть використовувати EGP, щоб обмінюватися інформацією про доступність із транзитними автономними системами.
BGP дозволяє використовувати маршрутизацію, що базується на політичних рішеннях (policy-based routing). Усі правила визначаються адміністратором автономної системи та вказуються у конфігураційних файлах BGP. "Політичні рішення" не є частиною протоколу, проте дозволяють робити вибір між маршрутами, коли є кілька альтернативних, і дозволяють керувати перерозподілом інформації. Рішення приймаються відповідно до питань безпеки або економічної доцільності.
BGP відрізняється від RIP або OSPF тим, що BGP використовує TCP як транспортний протокол. Дві системи, що використовують BGP, встановлюють TCP з'єднання між собою та потім обмінюються повними таблицями маршрутизації BGP. Оновлення подаються як зміни таблиці маршрутизації (таблиця не передається повністю).
BGP це протокол вектора відстаней, однак, на відміну від RIP (який оголошує пересилання до пункту призначення), BGP перераховує маршрути до кожного пункту призначення (послідовність номерів автономних систем до пункту призначення). При цьому зникають деякі проблеми, пов'язані з використанням векторних протоколів відстаней. Кожна автономна система ідентифікується 16-розрядним номером.
BGP визначає вихід з ладу каналу або хоста на іншому кінці TCP з'єднання шляхом регулярного відправлення повідомлення "залишайся живими" (keepalive) своїм сусідам. Рекомендований час між цими повідомленнями становить 30 секунд. Повідомлення "залишайся в живих", яке використовується на рівні додатків, незалежно від TCP опцій "залишайся в живих" ().
CIDR: безкласова маршрутизація між доменами (Classless Interdomain Routing)
Було сказано, що в даний час відчувається брак адрес класу В, тому вузлам з кількома мережами доводиться надавати кілька ідентифікаторів мереж класу С замість одного ідентифікатора мережі класу В. З одного боку, поява адрес класу С вирішує одну проблему (переповнення кількості адрес класу В ). З іншого боку, з'являється ще одна проблема: кожна мережа класу вимагає запису в таблиці маршрутизації. Безкласова маршрутизація між доменами (CIDR - Classless Interdomain Routing) це спосіб, який дозволяє мінімізувати зростання таблиць маршрутизації в Internet. Цей спосіб також називається supernetting і описується RFC 1518 і RFC 1519 [ Fuller et al. 1993], огляд можна знайти у . CIDR схвалений Internet Architecture Board [Huitema 1993]. RFC 1467 [Topolcic 1993] коротко описує стан та розвиток CIDR в Internet.
Основна концепція, закладена в CIDR, полягає в тому, що кілька IP адрес можна розташувати певним чином, що дозволить зменшити кількість записів у таблиці маршрутизації. Наприклад, якщо один вузол складається з 16 адрес класу С, всі 16 можуть бути розташовані таким чином, що вони сумуватимуться, тому до всіх 16 можна буде звернутися через один запис в таблиці маршрутизації. Також, якщо 8 різних вузлів підключені до одного і того ж Internetовскому "постачальнику сервісу" через ту саму точку підключення до Internet, і якщо всі 8 вузлів мають 8 різних IP адрес, вони можуть бути підсумовані, після чого буде потрібно лише один запис в таблиці маршрутизації, яка буде використовуватися в Інтернеті для всіх 8 вузлів.
Для того, щоб використовувати подібне підсумовування, необхідно, щоб виконували три умови.
- Декілька IP адрес, які будуть складені разом для маршрутизації, повинні мати у своїх адресах однакові біти старшого порядку.
- Таблиці маршрутизації та алгоритми маршрутизації повинні бути розширені таким чином, щоб рішення про маршрутизацію приймалися з використанням 32-бітових IP-адрес та 32-бітових масок.
- Протоколи маршрутизації, які будуть використовуватись, повинні бути розширені таким чином, щоб дозволяти передачу 32-бітових масок та 32-бітових адрес. OSPF (розділ ) і RIP-2 (розділ ) здатні передавати 32-бітові маски, як і BGP Version 4.
Як приклад скажемо, що RFC 1466 [Gerich 1993] рекомендує, щоб нові адреси класу С у Європі знаходилися в діапазоні 194.0.0.0 - 195.255.255.255. У шістнадцятковому поданні ці адреси лежать у діапазоні 0xc2000000 – 0xc3ffffff. Це дозволяє використовувати 65536 різних ідентифікаторів мережі класу С, проте всі вони мають однакові 7 біт старшого порядку. В інших (неєвропейських) країнах може бути використаний єдиний запис у таблиці маршрутизації з IP адресою 0xc2000000 та 32-бітною маскою 0xfe000000 (254.0.0.0), щоб організувати маршрут до всіх цих ідентифікаторів мереж класу С (у кількості 65. Послідовність бітів на адресу класу С (це біти, наступні за 194 або 195) може бути розташована в ієрархічному порядку, наприклад, країнами або постачальниками сервісу, щоб тим самим дозволити додаткове додавання всередині європейських маршрутизаторів з використанням додаткових бітів, що стоять після 7 біт старшого порядку у 32-бітовій масці.
CIDR також використовує техніку, яка визначає, що "кращий збіг це завжди найдовший збіг (longest match)": тобто збіг максимальної кількості бітів у 32-бітовій масці. Продовжуючи приклад із попереднього параграфа, слід зазначити таке. Припустимо, що один постачальник сервісу в Європі потребує використання іншого маршрутизатора для входу в Internet, ніж решта Європи. Якщо цей постачальник сервісу знаходиться в діапазоні адрес 194.0.16.0 - 194.0.31.255 (16 ідентифікаторів мереж класу С), записи в таблиці маршрутизації для цих мереж повинні мати IP адресу 194.0.16.0 та маску 255.250.04.04. Датаграма, що маршрутизується на адресу 194.0.22.1, співпадатиме з цим пунктом таблиці маршрутизації та з однією з мереж класу С в решті Європи. Однак, оскільки маска 255.255.240 "довша" ніж маска 254.0.0.0, буде використаний пункт у таблиці маршрутизації, який має найдовшу маску.
Термін "безкласовий" використовується тому, що рішення про маршрутизацію приймаються на основі масок, що накладаються на повну 32-бітову IP адресу. При цьому немає різниці між адресами класу А, В або С.
Спочатку передбачається використовувати CIDR в адресах нових мереж класу С. Завдяки внесенню подібної зміни значно зменшиться зростання таблиць маршрутизації в Internet, при цьому не потрібно вносити жодних змін в існуючі маршрутизатори. Хоча треба зазначити, що подібне рішення є короткочасним заходом. Більше покращення можна отримати, якщо CIDR буде використовуватися для всіх IP адрес, і існуючі IP адреси будуть перепризначені (при цьому всі існуючі хости отримають нові адреси!) відповідно до обмежень країн, континентів та постачальників сервісів . Виграш полягатиме в наступному: сучасна таблиця маршрутизації містить до 10 000 записів, тоді як після застосування CIDR кількість записів зменшиться до 200.
Короткі висновки
Існують два основних типи протоколів маршрутизації: протоколи внутрішніх маршрутизаторів (IGP - interior gateway protocol), для маршрутизаторів, що знаходяться всередині автономної системи (autonomous system), та протоколи зовнішніх маршрутизаторів (EGP - exterior gateway protocol), для маршрутизаторів, які спілкуються з маршрутизаторами інших автономних системах.
Найбільш популярний IGP це Routing Information Protocol (RIP), проте поступово новий IGP - OSPF стає популярнішим, і дедалі частіше починає замінювати собою RIP. Новий та популярний EGP це Border Gateway Protocol (BGP). У цьому розділі ми розглянули RIP та типи повідомлень, які він використовує. RIP Version 2 – це сучасне розширення, яке підтримує розбиття на підмережі та інші важливі покращення. Також ми описали OSPF, BGP та безкласову маршрутизацію між доменами (CIDR), нову технологію, яка покликана зменшити розмір таблиць маршрутизацій в Internet.
Існує ще два OSI протоколи маршрутизації, на які слід звернути увагу. Протокол міждоменної маршрутизації (IDRP – Interdomain Routing Protocol) з'явився як версія BGP, модифікована для використання з OSI адресами замість IP. Протокол проміжна система – проміжна система (IS-IS – Intermediate System to Intermediate System) – це OSI стандарт IGP. Він використовується як протокол маршрутизації в мережах без з'єднання (CLNP - Connectionless Network Protocol), протокол OSI, схожий на IP. IS-IS та OSPF дуже схожі.
Динамічна маршрутизація досі залишається плідним ґрунтом для досліджень у галузі міжмережевої взаємодії. Тому вибрати, який протокол маршрутизації необхідно використовувати та який демон маршрутизації необхідно запустити, досить складно. [Perlman 1992] надає безліч подробиць.
Вправи
- Зверніться до рисунка 10.9. Яким маршрутом можна пройти від маршрутизатора kpno до маршрутизатора gateway?
- Уявіть, що маршрутизатор має 30 маршрутів, які необхідно оголосити з використанням RIP, при цьому потрібна одна датаграма на 25 маршрутів та інша на 5, що залишилися. Що станеться, якщо один раз на годину перша датаграма з 25-ма маршрутами буде втрачена?
- У пакеті OSPF є поле контрольної суми, а пакеті RIP - немає. Чому?
- Який ефект дає балансування завантаженості, що використовується у OSPF. Як це впливає на рівень транспорту?
- Прочитайте RFC 1058, звідки Ви дізнаєтесь додаткові подробиці того, як реалізується RIP. На малюнку 10.8 кожен маршрутизатор оголошує лише ті маршрути, які він надає, та не оголошує інші маршрути, про які він знає з широкомовних повідомлень від інших маршрутизаторів у мережі 140.252.1. Як називається така технологія?
- У розділі глави 3 ми сказали, що у підмережі 140.252.1 існує більше 100 хостів на додаток до 8 маршрутизаторів, які ми показали на малюнку 10.7. Що роблять ці 100 хостів із вісьмома широкомовними повідомленнями, які прибувають кожні 30 секунд (рисунок 10.8)?
