|
10 СЛУЖБА ДОМЕННИХ ІМЕН DNS.
10.1 Служба доменних імен DNS
Служба іменування доменів (DNS, Domain Name System) призначена для встановлення глобальної відповідності між символічними іменами вузлів і їх IP-адресами. Завдання DNS – перетворення символьного імені в ІР-адресу та навпаки в умовах експоненційного зростання кількості вузлів Інтернету. На думку користувача, головною машиною в системі є хост користувача, за яким він працює. Проте окрім хоста користувача і маршрутизатора не останню роль виконує сервер імен (DNS-система) RFC 2136, 2137, 2152 - програма керування розподіленою базою даних, в якої зберігаються символьні імена мереж та хостів з їхніми ІР-адресами. Найпоширенішою програмою для розв'язку подібних задач є BIND (Berkelay Internet Name Domen). Іноді для таких цілей виділяють окрему машину. IP-адреси достатньо ефективні, але користувачеві краще пам’ятати символи, ніж цифри. Тому числові адреси замінюють текстовою формою – доменними іменами. DNS використовує ієрархічну схему виділення імен доменів (рисунок 10.1), дозволяючи децентралізувати управління окремими ділянками простору імен. Доменні імена мають ієрархічну структуру и складені з послідовності елементів, розділених точками, які ідентифікують (справа наліво) спочатку мережу, потім індивідуальний хост-вузол, а іноді – службу хоста (WWW, FTP и т. д.). Правий елемент – є доменом верхнього рівня, який базується або за географічними ознаками (наприклад, uk для Великої Британії, ua для України, ru – Росії) або за типом організації.
Рисунок 10.1 – Дерево доменів
Для відображення доменних імен на IP-адреси застосовують спеціальні бази даних, які містять IP-адреси для кожного доменного імені. Такі бази даних підтримуються особливими серверами імен, доступ до яких виконується через спеціальний DNS-протокол. Домени верхнього рівня регіструють в одному з реєстрів, головним з яких є InterNIC (Internet Network Information Center), Інформаційний центр мережі Internet (організація з питань формування, реєстрації й стратегічного розвитку мережі Internet, включаючи реєстрацію доменних імен) (США). Домени верхнього рівня розбиті на піддомени, а регістраторі доменів верхнього рівня регіструють розміщення серверів імен кожного з цих піддоменів. Регістратори здатні додавати нові імена в свої піддомени без контакту з сервером імен верхнього рівня. Наприклад, домен верхнього рівня uа поділяється на піддомени kyiv.uа, lviv.uа, kharkiv.uа и ck.uа. Піддомен ck.uа м. Черкаси функціонує в мережі UАNET. Піддомен, який визначений університету ЧДТУ, реєструє свої сервери імен в мережі. Проте зрозуміло, що він може призначити піддомен fitis факультету інформаційних технологій і систем, а піддомен ks601 – індивідуальному хост-вузлу цієї мережі, шляхом простого оновлення їх локальних серверів імен. DNS-сервер домену повинен підтримувати таблицю відповідностей IP-адрес і символічних імен для всіх вузлів, що входять в домен. Кожен вузол домену повинен знати тільки IP-адресу свого серверу домену і направляти йому всі запити на перетворення символічних імен вузлів в IP-адреси. Якщо сервер домену не може самостійно відповісти на запит (наприклад, запитана IP-адреса вузла, що належить до іншого домену), він може звернутися до кореневого DNS-серверу, дізнатися від нього IP-адресу сервера необхідного домену, а потім звернутися вже до цього сервера домену. Природно, DNS-сервер може запам'ятовувати результати подібних пошуків і при повторному зверненні за тією ж інформацією не повторювати знову шлях, а відразу видавати кешовані дані. В базі даних DNS-сервера є інформація про адреси всіх DNS-серверів даного домену (для підвищення надійності підтримується, як правило, не менше двох DNS-серверів для кожного домену, причому всі вони повинні розташовуватися в різних IP-підмережах), списки псевдонімів (один і той же вузол може мати декілька символічних імен), а також список поштових серверів даного домену.
10.2 Записи ресурсів, формати, повідомлення DNS
Адресу хоста мережі Internet, як уже зазначено, можна записати за допомогою цифр, а також і літерами, що надає їй змістовності, поліпшує запам'ятовування та опрацювання людьми. Змінюючи IP-адреси, що повертаються, DNS забезпечує також ряд додаткових служб, таких, наприклад, як служби заміщення (aliasing) імен хост-вузлів і поштових серверів і служба розподілення навантаження. IP-адреса і відображення імені хоста зберігаються в формі запису ресурса (Resource Record, RR). Він має 4 поля: Iм’я, Значення, Tип и Час життя. Існує чотири основні типи RR-записів. Якщо сервер імен знає IP-адресу потрібного доменного імені, то вона збережена у запису типу А (от autoritative- авторитетний), яка співставляє IP-адресу (з поля Значення) з іменем хоста (з поля Iм’я). Якщо сервер імен не знає такої ІР-адреси, тоді він буде знати адресу іншого серверу імен, який повинен знати цю адресу (сам або через кого-небудь ще), а записи типу NS співставляють ім’я домену (з поля Iм’я) с сервером імен (з поля Значення). Записи типу MX співставляють ім’я хоста поштового сервера (з поля Iм’я) з його псевдонімом (з поля Значення). Записи CN співставляють канонічне ім’я (з поля Значення) з іменем хоста (з поля Iм’я). Деякі комп’ютери для зручності задають додаткові, зазвичай коротші, імена, а CN-запис співставляє ці імена з повним іменем хоста. Таблиця 10.1 – Записи DNS
Локальні сервери зберігають результати попередніх запитів DNS у своїй кеш-пам’яті. Це прискорює DNS-процес, тому що не потрібен контакт з іншими серверами. Останнє поле RR-запису – час життя, вказує на час зберігання запису у кеші до виводу з нього. Першу версію DNS створено у 1983 p., роботи з удосконалення DNS тривають. Довільний домен або хост характеризований повним доменним ім'ям (Fully Qualified Domain Name (FQDN)). Окремі частини імені відділені крапкою. Наприклад, для хоста hostl ім'я буде таке: host1.firm1.ck.ua. Ознакою повного доменного імені (та наявності кореневого домена) є остання крапка. Адресація за повним доменним ім'ям є абсолютною доменною адресацією. Крім абсолютної, використовують і відносну доменну адресацію, зокрема, якщо звертаються до комп'ютера в межах одного "старшого" домену. Наприклад, hostl може звертатися до host2 за адресою host2. У відносній доменній адресі немає кінцевої крапки і вона автоматично доповнюється до абсолютної адреси додаванням адреси "старшого" домену. Обмеження: імена доменів повинні бути унікальними в межах старшого домену, їхня довжина не повинна перевищувати 12 символів, недопустиме повторення частини імені домену. У заявці зазначають імена та адреси двох комп'ютерів, на яких буде зберігатися БД домену. Сервер імен, зазвичай, відповідає не за один домен, а за декілька суміжних, або їхні частини - так звану зону відповідальності (zone of authority). Зона - це домен без піддоменів. Програму, яка відповідає на запити DNS, називають сервером імен, а клієнта - визначником. Сервери імен бувають головними, допоміжними, кешування. Сервери імен обслуговують зону. В кожній зоні є один головний сервер імен. Він зберігає головний варіант БД цього домену. Відповідь головного сервера імен є "авторитетною", тобто точною. Обмін DNS-повідомленнями між хостами і серверами імен використовує UDP-протокол. Він викликає підходящі сервери імен, які відображатимуть імена на IP-адреси. DNS повертає запис ресурсу, яку підтримує сервер, і яка містить IP-адресу, тому застосування, наприклад, FTP або HTTP, можуть його використати. Розрізняють локальні, кореневі й авторитетні сервери імен. В комунікаційному ланцюжку можуть також використовуватися проміжні сервери імен. DNS- запити можуть бути рекурсивними або ітеративними. В першому (найбільше загальному) випадку, кожний сервер домену отримує відображення імені сервера або хоста, що зробив запит. Ітеративні запити (які зазвичай виконуються поміж кореневим і локальним серверами, аби мінімізувати опрацювання завантаження у кореневому сервері) приводять в результаті або до потрібного відображення, або до адреси наступного у ланцюжку сервера, який дозволяє зробити наступний прямий DNS-запит. В прикладі на рисунку 10.2 показаний ітеративний запит (крок 2), якій дає відгук (крок 3), сповіщуючий локальний сервер, аби той входив у прямий контакт з проміжним сервером. Якби запит (2) був рекурсивним, то відгук (3) був би спрямований прямо до проміжного серверу і тому не сталося б прямого діалогу в будь-якому напрямку між проміжним та локальним серверами. У кожному домені для гарантування надійності повинно бути принаймні два сервери (первинний та вторинний). Інформація, в тому числі й отримана від інших серверів DNS, зберігається у кеш-пам'яті. Визначено максимальний час зберігання інформації у кеші і, отже, періоди оновлення інформації з первинного сервера. Всі зміни спочатку відбуваються на первинному сервері. На інших серверах нова інформація буде врахована внаслідок нового питання після її вилучення з кешу. Найчастіше використовують нерекурсивний режим, оскільки в цьому разі менше завантажений сервер DNS, а також можна ліпше простежити за проходженням запитів. База даних DNS - це набір текстових файлів, які створює та супроводжує адміністратор. Ця база даних складається з записів різних типів (RFC 882, 1035, 1183). Формат запису: [назва] [час] [клас] тип дані, де назва - ім'я комп'ютера або домену, для якого визначено цей запис. Якщо група записів має однакові імена, то всі імена, починаючи з другого, можна пропустити.
Рисунок 10.2 – Рекурсивний та ітеративний DNS-запити
Можна використовувати як повністю, так і неповністю визначені імена. До неповністю визначених імен додають: - ім'я локального домену; - час – час, протягом якого запис можна тримати у кеші; - клас - тип мережі, де діє служба. За замовчуванням приймають IN (Internet); - тип - тип запису, що характеризує його призначення; - дані - список параметрів, формат яких окремий для кожного типу запису. Усі записи умовно розділяють на три групи: - зонні записи. Визначають домени, їхні сервери, а також межі дії наступних записів; - головні записи. Ці записи зіставляють імена та адреси, а також перемаршрутизовують пошту; - додаткові записи. Містять додаткову інформацію. У файлі БД, зазвичай, спочатку записують зонні записи, а потім інші. Зонні записи Запис SOA визначає параметри зони. Зонний запис діє доти, доки у файлі не виявлено запису для іншої зони. Запис NS. Ці записи визначають головні та допоміжні сервери зони. Зазвичай, вони йдуть після записів SOA. Формат запису: Зона] [час] [клас] NS ім'я_хоста У записах зазначають тільки головні та допоміжні (авторитетні) сервери. Водночас тип сервера не специфікований. Записи типу NS фактично не використовують у межах локальної зони. Однак вони визначають сервери імен для зовнішніх користувачів. Зовнішні користувачі можуть бачити тільки сервери імен, специфіковані в NS. Бувають також внутрішні сервери, приховані від зовнішнього світу. Головні записи. Запис А використовують для перетворення імені (доменної адреси) машини в IP-адресу. Наприклад: vasyl IN A 196.168.2.1. Неповне ім'я доповнюють іменем локального домену. Запис PTR призначено для перетворення IP-адреси в доменне ім'я хоста. Щодо цього запис PTR виконує протилежну до запису А функцію. Значна кількість програм користується сервісом PTR. Зазвичай, вони отримують з мережі деяку IP-адресу і повинні знайти відповідне їй ім'я для порівняння зі списками імен у своїх файлах конфігурації. До таких програм належать netstat, sendmail, syslog, ftp, finger, rlogind та ін. Формат запису: адреса [час] [клас] PTR ім'я_хоста Між записами А та PTR повинна бути повна однозначна відповідність. Запис MX призначено для переадресування електронної пошти. Формат запису: ім'я_адресата [час] [клас] MX пріоритет ім'я_переспрямування Пріоритет записують цілим числом від 0 до 65535. Повідомлення спрямовують у першу чергу відповідно до записів з меншим пріоритетом. Додаткові записи Запис CNAME дає змогу визначати для гостів мнемонічні імена, використовувати декілька варіантів імен для одного хоста. Запис HINFO відображає виробника та модель комп'ютера. Запис WKS визначає сервісні програми, які пропонує хост. Запис ТХТ. Довільний текст.
10.3 Протокол мережного управління SNMP
Враховуючи важливість функції мережного управління, створено протокол SNMP (Simple Network Management Protocol, RFC 1157, 1215, 1187, 1089). Він розроблений у 1988 році. Протокол SNMP для передачі повідомлень використовує протокол UDP і призначений для використання керуючими мережевими станціями. Він дозволяє станціям, що управляють, збирати інформацію про стан TCP/IP-мережі. Протокол визначає формат даних, а їх обробка і інтерпретація залишаються на розсуд станцій, що управляють, або менеджера мережі. SNMP-повідомлення не мають фіксованого формату і фіксованих полів. SNMP використовує базу даних, що управляє (MIB - management information base). Алгоритми управління в Інтернет зазвичай описують в нотації ASN.1 (abstract syntax notation). Всі об'єкти в Інтернет розділені на 10 груп і описані в MIB: система, інтерфейси, обміни, трансляція адрес, IP, ICMP, TCP, UDP, EGP, SNMP. У групу “система” входить назва і версія обладнання, операційної системи, мережного програмного забезпечення і тому подібне. У групу “інтерфейси” входить число підтримуваних інтерфейсів, тип інтерфейсу, що працює під IP (Ethernet, LAPB, тощо), розмір дейтаграм, швидкість обміну, адреса інтерфейсу. Група “IP” включає час життя дейтаграм, інформація про фрагментацію, маски підмереж і так далі. До групи “TCP” входять параметри алгоритму повторного пересилання – максимальне число повторних пересилок і т. д. Нижче наведена таблиця 10.2 команд SNMP. Таблиця 10.2 – Команди SNMP
SNMP-клієнт чекає надходження дейтаграм на UDP-порт 161. Якщо SNMP-менеджер замовляє повідомлення, то клієнт відправляє UDP-дейтаграму з повідомленням на порт 162 менеджера. 10.4 Протоколи маршрутизації
Маршрутизація в IP-мережах точно така сама, як і в будь-якій мережі передачі даних, тому що застосовані ті ж основні принципи. Мережа розглядена як об’єднання так званих автономних мереж. Кожна з цих мереж незалежна й може виконувати свій власний алгоритм маршрутизації. Проблема зосереджена у поєднанні різних мереж, і потребує узгодженого Internet-протоколу маршрутизації поміж сусідніми мережами. Сьогодні існує два загальні протоколи подібних OSPF, які замінюють початковий протокол маршрутної інформації та зовнішній шлюзовий протокол такий, що використаний у Internet. RIP і OSPF розроблені для маршрутизації в індивідуальних автономних системах, проте як EGP і ВGP зазначені для маршрутизації поміж автономними підмережами (рисунок 10.3).
Рисунок 10.3 – Приклад таблиці маршрутизатора
Головний параметр маршрутизації IP-пакета - це його IP-адреса. Протокол IP поділяє всі комп'ютери на маршрутизатори (routers) та хости (hosts). Зазвичай комп'ютери не розсилають маршрутних таблиць. Водночас на хості можуть бути запущені програми маршрутизації, тобто він може виконувати функції маршрутизатора. Розглянемо приклад виконання маршрутизації (рисунок 10.4).
Рисунок 10.4 – Приклад маршрутизації
Автономна система складається з чотирьох локальних мереж (у розумінні протокольного стека TCP/ IP), сполучених трьома маршрутизаторами, кожен з яких є одночасно елементом кількох локальних мереж. Маршрутизатор мас окрему IP-адресу в кожній мережі, за якою до нього звертаються гости цієї мережі. Маршрутна таблиця такої мережі для передавання пакета через М2 в найпростішому випадку могла б мати вигляд, зображений на рисунку 10.3. Елементом таблиці маршрутизації, зазвичай, є маршрут за замовчуванням (default). Якщо маршруту в таблицях не виявлено, то пакет надсилається за замовчуванням маршрутизатору, який має додаткову інформацію. Алгоритм вибору маршруту:
Якщо мережа має підмережі, то перед порівнянням адрес над IP-адресою призначення обчислюється побітове '&' з використанням маски. Метрика маршруту - це його числова характеристика за критерієм: кількість проміжних маршрутизаторів, тривалість передавання, надійність тощо. Найпоширеніші протоколи маршрутизації такі: RIP, OSPF, BGP, EGP, IGRP.
10.4.1 Протокол внутрішньої маршрутизації RIP
Протокол RIP (Routing Information Protocol) – RFC 1058,1721,1627 – протокол внутрішньої маршрутизації, призначений для невеликих мереж. Дистанційно-векторний протокол. Розроблений фірмою Xerox. Простий, використовує одну метрику - кількість кроків, базується на лічильнику мережевих переходів, який обмежений числом й поновлюється кожні 30 с. Його поступово витісняє протокол OSPF. RIP-повідомлення інкапсулюються у дейтаграми UDP. Використано порт 520. Метрика маршрутизації - кількість кроків до мети. Наприклад, якщо між відправником та одержувачем три маршрутизатори, то значення метрики - 4. Така метрика не враховує різниць у перепускній здатності та завантаження окремих сегментів мережі. Таблиця маршрутизації містить один запис про кожен комп'ютер, у якому зазначено таке: IP-адреса місця призначення, характеристика ціни маршруту (від 1 до 16), IP-адреса найближчого маршрутизатора, таймери маршруту. Маршрут за замовчуванням має адресу 0.0.0.0. Кожен маршрут має таймери тайм-ауту та "збирача сміття". Таймер тайм-ауту скидають на нуль кожного разу, коли маршрут коректують або ініциалізують. Якщо з часу останньої корекції минуло 3 хв. або одержано повідомлення, що відстань дорівнює 16, то маршрут вважається закритим, однак запис про нього не стирається, доки не настане час "збирати сміття". Структура повідомлення протоколу RIP-2 (RFC 1721-24) зображена на рисунку 10.5. Поле Команда має значення 1 для запиту і значення 2 для відповіді. Значення поля Версія становить 1 (для протоколу RIP2 - 2). Поле Набір протоколів визначає протоколи, які використовують у мережі (для Internet - 2). В одному повідомленні може бути інформація про 25 маршрутів і не більше. У RIP2 на додаток до циркулярного режиму підтримуване групове передавання, можна працювати з масками підмереж. Поле Маршрутний демон є ідентифікатором резидентної програми-маршрутизатора. У полі Позначка маршрутизації записують коди автономних систем, їх використовують для підтримки зовнішньої маршрутизації. Режими роботи RIP: - ініціалізація - розсилання всім маршрутизаторам запитів, одержання від них таблиць; - одержано запит - залежно від типу запиту надсилається вся таблиця або її частина; - одержано відповідь - корекція таблиць. Недоліки RIP: - потрібно багато часу на відновлення після збою у маршрутизаторі; - кількість кроків до мети – не найважливіша метрика, крім того, найбільше значення RIP1 -15 кроків - для сучасних мереж недостатнє.
Рисунок 10.5 – Структура RIP2- повідомлення
10.4.2 Протокол маршрутизації OSPF
Протокол OSPF (Open Shortest Path First) RFC 1850, 1523, 1587, 1584 - протокол першочергового відкриття найкоротших маршрутів є альтернативою протоколу RIP. Метрикою в ньому є якість обслуговування. Кожен маршрутизатор має повну інформацію про стан усіх інтерфейсів усіх маршрутизаторів автономної системи. OSPF- протокол внутрішньої маршрутизації, складний, використовує кілька типів метрик, функціонує за станом каналу, зв’язків. Застосовують у завданнях маршрутизації кожної внутрішньої підмережі. Дозволяє автентифікацію повідомлень маршрутизації та численні маршрути. Окрім того, протокол дозволяє встановлювати, яким чином домени розділяються на області, тому пакети не завжди можна точно спрямовувати у конкретний домен, а тільки – у правильному напрямку. Автономна система може складатися з кількох зон. У цьому випадку внутрішні маршрутизатори зони можуть і не мати інформації про топологію іншої частини АС. Мережа зазвичай має спеціальний призначений маршрутизатор, який є джерелом інформації для інших маршрутизаторів АС. Кожен маршрутизатор самостійно вирішує проблему оптимізації маршрутів, аналізуючи орієнтований граф мережі (алгоритми Дійкстри). Якість обслуговування характеризують такі параметри: - перепускна здатність каналу; - затримка передавання пакета; - кількість дейтаграм, що є в черзі на передавання; - завантаження каналу; - вимоги безпеки; - кількість кроків до мети. Головними параметрами є затримка, перепускна здатність та надійність. Для транспортних потреб OSPF використовує протокол IP без проміжної інкапсуляції в UDP- або TCP-пакети. Маршрутизацію визначає IP-адреса та тип сервісу. Керування складними мережами з великою кількістю мостів та комутаторів у мережі протоколу OSPF спрощене. Повідомлення OSPF мають заголовок, зображений на рисунку 10.6.
Рисунок 10.6 – Структура заголовка повідомлення OSPF Поле Версія визначає версію протоколу (2), поле Тип - функцію повідомлення: 1 - повідомлення hello; 2 - опис бази даних (топологія мережі); 3 - запит про стан каналу; 4 - зміна стану каналу; 5 - підтвердження про одержання повідомлення щодо статусу каналу. Поле Ідентифікатор зони містить 32-бітовий код зони. Всі OSPF-пакети асоціюються з певною зоною. Одним з важливих є повідомлення hello. Цими пакетами обмінюються сусідні маршрутизатори. Структура такого пакета зображена на рисунку 10.7. Поле Маска мережі відповідає підмережі інтерфейсу, а поле Час між hello задає час між повідомленнями цього типу. Поле Опції характеризує можливості маршрутизатора. У ньому є два біти керування - Е та Т. Біт Е відповідає за зовнішню маршрутизацію.
Рисунок 10.7 – Структура повідомлення hello
Якщо E=0, то маршрутизатор не буде взаємодіяти із зовнішніми автономними підсистемами. Біт T визначає сервісні можливості маршрутизатора. Якщо T=0, то це означає, що маршрутизатор підтримує тільки один різновид послуг. Такі маршрутизатори не використовують для транзитних потоків. Поле Пріоритет характеризує можливість використання маршрутизатора як резервного, поле Час увімкнення маршрутизатора – часовий інтервал, після закінчення якого "німий" маршрутизатор буде вважатись увімкненим. Поле IP-адреса сусіда є списком адрес сусідніх маршрутизаторів, від яких останнім часом були одержані повідомлення hello. Другий тип пакета відповідає інформації про топологію мережі з бази даних OSPF, яка с на кожному маршрутизаторі. Маршрутизатори обмінюються повідомленнями цього типу з метою ініціалізації та актуалізації інформації в своїх базах даних щодо стану топології мережі. Обмін відбувається в режимі клієнт-сервер. Клієнт підтверджує одержання кожного повідомлення. Розмір бази даних може бути значним, тому передбачена можливість її пересилання частинами. Пакет третього типу - Запит про стан каналу – надсилають з метою одержати інформацію про стан каналу, її надсилає сусід, що одержав запит. Останні три поля повторюються залежно від кількості каналів, інформація про які потрібна. Якщо стан каналів, безпосередньо з'єднаних з маршрутизатором, змінився, то надсилаються циркулярні або групові повідомлення. Можливі причини розсилання повідомлень такі: вік маршруту досяг граничного значення, змінився стан інтерфейсу, відбулися зміни в маршрутизаторі тощо. Повідомлення про стан каналу має свою структуру, яка може залежати від типу каналу (рисунок 10.8).
Рисунок 10.8 – Структура повідомлення про стан каналу
Коди TOS (Type of Sevice) такі: 0 - Звичайний сервіс; 1 - Мінімізація вартості; 4 - Максимальна надійність; 8 - Максимальна перепускна здатність; 16 - Мінімальна затримка. Біт E=1, якщо маршрутизатор є граничним для автономної системи, біт В=1, якщо маршрутизатор є граничним для зони.
10.4.3 Протоколи зовнішньої маршрутизації
Автономні системи проводять кожна власну маршрутну політику, користуються одним протоколом внутрішньої маршрутизації та сполучені з іншими автономними системами за допомогою граничних маршрутизаторів, через які проходить весь транзитний потік (рисунок 10.9).
Рисунок 10.9 – Зовнішня маршрутизація
Одним із протоколів зовнішньої маршрутизації є BGPv4 (Border Gateway Protocol) RFC-1267, 1655, 1657, 1771 - протокол зовнішньої маршрутизації. На відміну від маршрутизаторів, що є всередині автономної системи, граничні маршрутизатори можуть сполучати АС з різними протоколами маршрутизації. Кожен граничний маршрутизатор формує свої власні маршрутні таблиці і повідомляє сусідні граничні маршрутизатори про зміни у них. Маршрутні таблиці зберігаються у спеціальній базі даних маршрутів RIB (Routing Information Base). На відміну від внутрішніх маршрутизаторів, граничні маршрутизатори не зобов'язані передавати всю інформацію на інші маршрутизатори. (Один граничний маршрутизатор не зобов'язаний надсилати, а інший - приймати). Протокол визначає тільки формат інформації, порядок обміну. Тому важливою є політика маршрутизації, її задає адміністратор, який визначає параметри обміну маршрутною інформацією, часові параметри, канали, яким треба надавати перевагу, та інше. Зовнішній шлюзовий протокол маршрутизації EGP (Exterior Gateway Protocol), реалізує пересилання маршрутної інформації на маршрутизатори, які з'єднують автономні системи. Втім EGP розрахований на єдину магістраль та відсутність петель, тому в наш час в Інтернеті вже не застосовується. Подібний до OSPF IGRP (Interior Gateway Routing Protocol) - протокол внутрішньої маршрутизації, розроблений фірмою Cisco для великих неоднорідних мереж.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||