Електронний посібник

Лекція № 16

Тема: Статична та динамічна маршрутизація

Мета: ознайомитися з поняттями статичної та динамічної маршрутизації

План

1 Статична маршрутизація.

2 Динамічна маршрутизація.

3 Програма routed.

4 Програма gated.

Лекційний матеріал

Статична маршрутизація

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

Взагалі кажучи, з усієї статичної маршрутизації виділяють, так звану, мінімальну маршрутизацію. Така маршрутизація виникає тоді, коли локальна мережа не має виходу в Internet і не складається з підмереж. У цьому випадку достатньо виконати команди ifconfig для інтерфейсу lo і інтерфейсу Ethernet і все буде працювати:

/ Usr / paul> ifconfig lo inet 127.0.0.1

/ Usr / paul> ifconfig ed1 inet 144.226.43.1 netmask 255.255.255.0

У таблиці маршрутів з'являться тільки ці два рядки, але так як мережа обмежена, і пакети не треба відправляти в інші мережі, то модуль ARP буде чудово справлятися з доставкою пакетів по мережі.

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

Команда route має такий вигляд:

route <команда> <мережу або хост> <шлюз> <метрика>

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

У полі "мережа або хост" вказується адреса відправки пакета.

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

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

Типовим прикладом застосування команди route є призначення шлюзу за замовчуванням:

/ Usr / paul> route add default 144.206.160.32

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

Для того, щоб отримати таблицю маршрутів, потрібно виконати наступні команди:

/ Usr / paul> route add 144.206.0.0 144.206.136.5 netmask 255.255.224.0

/ Usr / paul> route add 144.206.96.0 144.206.130.135 netmask 255.255.224.0

/ Usr / paul> route add 144.206.128 144.206.130.138 netmask 255.255.224.0

/ Usr / paul> route add 144.206.192.0 144.206.192.1 netmask 255.255.224.0

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

У поле прапорів звіту netstat ми можемо зустріти наступні прапори:

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

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

G - говорить про те, що пакети направляються на шлюз, який веде до адресата;

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

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

Destination Gateway Flags Refs Use IfaceMTU Rtt

194.226.56 144.206.130.207 UGD 0 0 ed1 - -

Поле прапорів містить прапори: U-маршрут активний, G-пакети направляються на шлюз і D-маршрут отримано за повідомленням ICMP про перенаправлення пакетів. Отже, спочатку такого маршруту в таблиці маршрутів не було.

Якщо користувачі системи часто ходять в мережу 194.226.56.0, то в таблицю такий маршрут слід додати:

/ Usr / paul> route add 194.226.56.0 144.206.130.207 netmask 255.255.224.0


За допомогою команди route можна не тільки додавати маршрути в таблицю маршрутів, але і видаляти їх звідти. Робиться це по команді delete. Наприклад, якщо нам треба змінити значення шлюзу за замовчуванням, то ми можемо виконати наступну послідовність команд:

/ Usr / paul> route delete default

/ Usr / paul / route add default 144.206.136.10 netmask 255.255.224.0

У даному випадку спочатку ми вилучимо з таблиці (приклад 2.1) маршрут умовчання, а потім додамо туди новий. При видаленні маршруту досить назвати тільки адреса призначення, щоб route ідентифікувала маршрут, який слід видалити.

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

У висновку обговорення питань статичної маршрутизації хотілося б зробити невеличке зауваження з приводу Windows NT. До версії 4.0 в Windows NT штатно існувала тільки статична маршрутизація. Для мереж локальних з надійними лініями зв'язку цього цілком достатньо. Фактично, адміністраторові потрібно тільки вказати IP-адреси на кожному з мережевих інтерфесом, вказати адресу шлюзу за умовчанням і підняти прапорець пересилки пакетів з одного інтерфейсу на інший. Після цього все повинно працювати. Якщо локальна мережа підключається до провайдера, то, як правило, все зводиться до отримання адреси з мережі провайдера для зовнішнього інтерфейсу, тобто інтерфейсу, який буде пов'язувати вас з адресою шлюзу провайдера та адресою своєї мережі або підмережі. Якщо тільки провайдер не затіє зміни структури своєї мережі, вага буде працювати роками без будь-яких змін. Для таких мереж шлюз на основі Windows NT можна організувати. Однак, не все так просто, коли мова йде про мережі або підмережі, які підключаються в якості частини мережі, яка не організована за ієрархічним принципом. У цьому випадку можлива зміна найкращих маршрутів набагато частіше, ніж один раз на десятиліття і в цьому випадку статична маршрутизація може виявитися недостатньою. Крім того, важливим фактором підвищення надійності мережевої взаємодії є наявність декількох маршрутів до одних і тих же інформаційних ресурсів. У разі відмови одного з них можна використовувати інші. Але проблема полягає в тому, що система завжди використовує той маршрут, який першим зустрівся в таблиці маршрутів, хоча й існують мультімаршрутние системи, але вони поширені, м'яко кажучи не дуже широко. Отже, маршрути з таблиці треба видаляти і вносити. Якщо мережа працює не стійко, то це перетворюється на головний біль адміністратора. Ось чому до версії Windows NT 4.0 розглядати цю систему як реальний претендент на маршрутизатор не представляється можливим. У Windows NT 4.0 з'явилася підтримка динамічної маршрутизації в особі протоколу RIP, але підтримки інших протоколів маршрутизації поки ще немає.

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




Динамічна маршрутизація


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



Рис. 1. Схема взаємодії автономних систем


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

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

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

Зовнішні протоколи служать для обміну інформацією про маршрути між автономними системами.

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

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

До зовнішніх протоколів відносяться Exterior Gateway Protocol (EGP) та

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

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

До внутрішніх протоколів відносяться протоколи Routing Information Protocol (RIP), HELLO, Intermediate System to Intermediate System (ISIS), Shortest Path First (SPF) і Open Shortest Path First (OSPF).

Протокол RIP (Routing Information Protocol) призначений для автоматичного оновлення таблиці маршрутів. При цьому використовується інформація про стан мережі, яка розсилається маршрутизаторами (routers). Відповідно до протоколу RIP будь-яка машина може бути маршрутизатором. При цьому, всі маршрутизатори діляться на активні і пасивні. Активні маршрутизатори повідомляють про маршрути, які вони підтримують в мережі. Пасивні маршрутизатори читають ці широкомовні повідомлення і виправляють свої таблиці маршрутів, але самі при цьому інформації в мережу не надають. Зазвичай в якості активних маршрутизаторів виступають шлюзи, а в якості пасивних - звичайні машини (hosts).

В основу алгоритму маршрутизації за протоколом RIP покладена проста ідея: чим більше шлюзів треба пройти пакету, тим більше часу потрібно для проходження маршруту. При обміні повідомленнями маршрутизатори повідомляють в мережу IP-номер мережі і кількість "стрибків" (hops), яке треба зробити, користуючись даним маршрутом. Треба відразу зазначити, що такий алгоритм справедливий тільки для мереж, які мають однакову швидкість передачі з будь-якого сегменту мережі. Часто в реальному житті виявляється, що набагато вигідніше скористатися оптоволокном з 3-ма шлюзами, ніж одним повільним комутованих телефонних каналом.

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

На жаль, многовариантную маршрутизацію підтримує не дуже багато систем. Різні клони Unix і NT, головним чином орієнтовані на протокол RIP. Досить подивитися на програмне забезпечення динамічної маршрутизації, щоб переконається в цьому. Програма routed підтримує тільки RIP, програма gated підтримує RIP, HELLO, OSPF, EGP і BGP, в Windows NT підтримується тільки RIP.

Тому ми розглянемо можливість динамічного управління таблицею маршрутів лише за протоколом RIP.


Програма routed


Програма routed поставляється з будь-яким клоном Unix і використовується в якості демона протоколу RIP за замовчуванням. Як правило, вона використовується без аргументів і запускається в момент завантаження операційної системи. Однак, якщо машина не є шлюзом, то має сенс вказати прапор "-q". Цей прапор означає, що routed не буде посилати інформації в мережу, а тільки буде слухати інформацію від інших машин. Зазвичай, активними є шлюзи, а всі інші системи є пасивними.

Однак, часто буває корисно при початковій завантаженні ініціалізувати таблицю маршрутів і визначити рядки, які з неї не слід видаляти ні за яких умов. Самий типовий випадок - призначення шлюзу за замовчуванням. Для цієї мети можна використовувати файл / etc / gateways, який програма routed переглядає при запуску і використовує для початкового налаштування таблиці маршрутів. Зміст цього файлу може виглядати наступним чином:

net 0.0.0.0 gateway 144.206.136.10 netric 1 passive

У даному прикладі адреса 0.0.0.0 використовується для визначення адреси умовчання, машина 144.206.136.10 - це шлюз за замовчуванням, метрика визначає число hop'ов до цього шлюзу, а параметр "passive" - ​​говорить про те, що навіть якщо з цього шлюзу ніякої інформації про маршрути не приходить, то його все одно не треба видаляти з таблиці маршрутів. Останній параметр вказується в тому випадку, якщо шлюз тільки один, якщо ж можливе використання іншого шлюзу і ці шлюзи активно сповіщають машини мережі про свої таблицях маршрутів, то слід замість passive використовувати active:

net 0.0.0.0 gateway 144.206.136.10 netric 1 active

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

Коли використовується тільки Ethernet, то програма routed може використовуватися і на машинах шлюзах, але якщо система пов'язана з зовнішнім світом через SLIP чи PPP, то використання routed може призвести до втрати самого головного маршруту. Він буде вилучений з таблиці з міркувань неактивності. У цьому випадку краще всього використовувати програму gated.


Програма gated


Gated - це колективний продукт американських університетів, який був розроблений для роботи мережі NFSNET. Права copyright закріплені за Корнельському університеті, хоча частині коду є власністю інших університетів і асоціацій.

Gated - це модульна програма призначена організації багато функціонального шлюзу, який міг би обслуговувати як внутрішню маршрутизацію, так і зовнішню. Gated підтримує протоколи RIP (версії 1 і 2), HELLO, OSPF версії 2, EGP версії 2 і BGP версій від 2 до 4. Всі перераховані можливості ставляться до версії 3.5. На системах типу HPUX 9.x або IRIX 6.x можуть стояти і більш ранні версії, які всього цього набору протоколів можуть і не підтримувати.

Розглянемо два основних приклад використання gated в локальній мережі: замість routed на звичайній машині і на машині-шлюзі в іншу мережу. При цьому будемо спиратися на наступну схему, зображену на малюнку 2.



Рис. 2. Підключення локальної мережі до Internet і налаштування gated


Gated налаштовується за допомогою свого файлу конфігурації / etc / gated.conf. Саме в ньому пишуться всі команди налаштування, які gated перевіряє при запуску.

При роботі на звичайній машині, системі треба тільки вказати інтерфейс і протокол динамічної маршрутизації, який gated повинна використовувати:

#

# Interface shouldn `t be removed from routing table

#

interface 144.206.160.40 passive;

#

# Routing protocol is rip.

#

rip yes;

У більшості випадків достатньо просто вказати протокол, тому що інтерфейс потрапить в таблицю маршрутизації після виконання команди ifconfig.

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

# Interfaces shouldn `t be removed from routing table

interface 144.206.160.32 passive;

interface 144.206.130.137 passive;

# Routing protocol is rip.

rip yes;

Проте можна використовувати і більш складне опис, засноване на логіці роботи gated. А логіка ця полягає в тому, що gated оголошує сусіднім шлюзів по RIP, що підмережа 144.206.160.0 доступна через інтерфейс 144.206.130.137, у свою чергу для підмережі gated оголошує, що весь світ доступний через інтерфейс 144.206.160.32. Очевидно, що це логіка запозичена з архітектури зовнішніх протоколів маршрутизації і поширена на протоколи внутрішні. Це дозволяє вести опис маршрутів у єдиному ключі.

rip yes;

export proto rip interface 144.206.130.137

{

proto direct

{

announce 144.206.160.0 metric 0;

};

};

export proto rip interface 144.206.160.32

{

proto rip interface 144.206.130.137

{

announce all;

};

};


Перша команда export анонсує підмережа 144.206.160.0 через інтерфейс 144.206.130.137. При цьому повідомляється, що це шлюз в дану підмережа, тобто інтерфейс 144.206.130.137 розташований на машині, яка включена в цю підмережа. Про те, що пакети для підмережі треба надсилати безпосередньо на цей інтерфейс говорить пропозицію proto direct, а те, що інтерфейс стоїть на шлюзі в підмережа говорить метрика, що дорівнює 0.

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

При написанні керуючих пропозицій export слід завжди пам'ятати, що зовнішнє пропозиція визначає завжди інтерфейс, через який повідомляється інформація, а внутрішня пропозиція визначає джерело, через який цю інформацію отримує gated.

Важливим є і синтаксис пропозицій, який сильно змахує на синтаксис мови програмування С.

У всіх довідниках по gated наводиться ще один приклад, коли мережа, через підмережа підключають до Internet. Тут наведемо приклад з керівництва до gated 3.5.

rip yes;

export proto rip interface 136.66.12.3 metric 3

{

proto rip interface 136.66.1.5

{

announce all;

};

};

export proto ripinterface 136.66.1.5

{

proto rip interface 136.66.12.3

{

announce 0.0.0.0;

};

{;


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

Друга пропозиція export визначає куди слід відправляти інформацію по умовчання з мережі, щоб вона досягла адресата, розташованого за межами даної локальної мережі. Адреса 0.0.0.0, який відповідає будь-якій машині за інтерфейсом 136.66.12.3 анонсується через інтерфейс 136.66.1.5. для всієї локальної мережі.

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