Протокол обміну керуючими повідомленнями ICMP Протоколи обміну маршрутною інформацією

Кафедра інформаційно-комунікаційні технології

Курсова робота

«Протокол обміну керуючими повідомленнями - ICMP. Протоколи обміну маршрутною інформацією »

з дисципліни «Основи побудови об'єднаних мереж»

Введення

Протокол міжмережевих керуючих повідомлень ICMP (Internet Control Message Protocol, ICMP), дозволяє маршрутизатору повідомити кінцевому вузлу про помилки, з якими Машрутизатор зіткнувся при передачі будь-якого IP-пакета від даного кінцевого вузла.

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

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

Кожне повідомлення протоколу ICMP передається по мережі всередині пакету IP. Пакети IP з повідомленнями ICMP маршрутизуються точно так само, як і будь-які інші пакети, без пріоритетів, тому вони також можуть губитися. Крім того, в завантаженій мережі вони можуть викликати додаткове завантаження маршрутизаторів. Для того, щоб не викликати лавини повідомлення про помилки, втрати пакетів IP, які переносять повідомлення ICMP про помилки, не можуть породжувати нові повідомлення ICMP.

Всі протоколи обміну маршрутною інформацією стека TCP / IP відносяться до класу адаптивних протоколів, які в свою чергу діляться на дві групи, кожна з яких пов'язана з одним із наступних типів алгоритмів:

 дистанційно-векторний алгоритм (Distance Vector Algorithms, DVA),

 алгоритм стану зв'язків (Link State Algorithms, LSA).

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

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

Найбільш поширеним протоколом, заснованим на дистанційно-векторному алгоритмі, є протокол RIP.

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

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

Протоколом, заснованим на алгоритмі стану зв'язків, в стеку TCP / IP є протокол OSPF.

Протокол BGP розроблений компаніями IBM і CISCO. Головна мета BGP - скоротити транзитний трафік.

BGP відрізняється від RIP і OSPF тим, що використовує TCP в якості транспортного протоколу. Дві системи, що використовують BGP, зв'язуються один з одним і пересилають за допомогою TCP повні таблиці маршрутизації.

Протокол ICMP

Загальна характеристика протоколу

Протокол ICMP грає в мережі допоміжну роль. Специфікація цього протоколу міститься в RFC 792.

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

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

Повідомлення ICMP протоколу, як правило, сповіщають про проблеми, які виникають при обробці датаграм. При цьому, деякі з пакетів можуть зникнути в мережі, не викликавши при цьому ніяких повідомлень. Щоб піти від нескінченної посилки повідомлень про повідомлення і т.д., коли кількість повідомлень лавиноподібно зростає («штормів»), повідомлення ICMP не надсилаються про повідомлення ICMP. Також ICMP повідомлення надсилаються тільки про помилки в обробці нульового фрагмента фрагментованих датаграм (нульовий фрагмент має 0 у полі зсуву). Якщо помилка виникла при передачі будь-якого фрагмента, крім нульового, а також коли втрачений пакет мав широкомовна адресу або був упакований в кадр з широкомовною адресою несучої технології, ICMP повідомлення не передаються.

Оскільки IP-пакет містить адресу відправника, але не містить ніякої адресної інформації про проміжні маршрутизатори, ICMP-повідомлення направляються тільки кінцевим вузлам. Тут повідомлення можуть бути оброблені або ядром операційної системи, або протоколами транспортного і прикладного рівнів, або додатками, або просто проігноровані. Важливо, що обробка ICMP-повідомлень не входить в обов'язки протоколів IP і ICMP.

Формат повідомлень

Існує кілька типів ICMP. Кожен тип повідомлення має свій формат, при цьому всі вони починаються з загальних трьох полів: 8-бітового цілого числа, що позначає тип повідомлення (TYPE), 8-бітного поля коду (CODE), який конкретизує призначення повідомлення, і 16-бітного поля контрольної суми (CHECKSUM). Крім того, повідомлення ICMP завжди містить заголовок і перші 64 біта даних пакету IP, який викликав помилку. Це робиться для того, щоб вузол-відправник зміг більш точно проаналізувати причину помилки, так як всі протоколи прикладного рівня стека TCP / IP містять найбільш важливу інформацію для аналізу в перших 64 бітах своїх повідомлень.

Всі типи ICMP-повідомлень можуть бути розділені на 2 класи:

• діагностичні повідомлення

• інформаційні повідомлення типу запит / відповідь

ICMP-повідомлення инкапсулируется в поле даних IP-пакета (рис 1).

ICMP-повідомлення

Тема ICMP складається з 8 байт; поля заголовка перераховані нижче:

• Тип (розміром 1 байт) містить код, що визначає тип повідомлення. Основні типи перелічені в таблиці 1.

• Код (розміром 1 байт) більш тонко диференціює тип помилки.

• Контрольна сума, підрахована для всього ICMP-повідомлення, займає 2 байти.

Тема також включає поле з 4 байт, вміст якого залежить від значень полів типу і коду. У повідомленнях типу запит / відповідь це поле містить 2-байтові підполя ідентифікатора і порядкового номера. Числа з цих підполів дублюються з повідомлення-запиту в повідомлення-відповідь. Ідентифікатор дозволяє вузлу-одержувачу повідомлення визначити, якому додатку спрямований цей відповідь, а порядковий номер у програми, щоб зв'язати відповідь з відповідним запитом. У повідомленнях про помилку це поле не використовується і заповнюється нулями.

Таблиця 1. Можливі значення поля типу

Значення	Тип повідомлення
0	Ехо - відповідь (Echo Replay)
3

Кожен тип помилки може бути більш точно охарактеризований кодом помилки. Наприклад, у таблиці 2 наведено коди для повідомлення про недосяжність вузла призначення (помилка типу 3 з табл. 1). Ці коди, які можуть бути зазначені в повідомленні цього типу, дозволяють виділити безліч різних причин даної ситуації.

Таблиця 2. Коди, які деталізують причину помилки про недосяжність

Маршрутизатор, виявив з ​​якої-небудь причини, що він не може передати IP-пакет далі по мережі, повинен відправити ICMP-повідомлення вузла-джерела, і тільки потім відкинути пакет. Крім причини помилки, ICMP-повідомлення включає також заголовок недоставленого пакета і його перші 64 біта поля даних.

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

Недосяжність протоколу і порту означають відсутність реалізації будь-якого протоколу прикладного рівня у вузлі призначення або ж відсутність відкритого порту протоколів UDP або TCP у вузлі призначення.

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

Перенаправлення маршруту

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

Для коректування поведінки комп'ютерів маршрутизатор може використовувати повідомлення протоколу ICMP, зване «Перенаправлення маршруту» (Redirect).

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

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

У повідомленні «Перенаправлення маршруту» маршрутизатор поміщає IP-адреса маршрутизатора, яким потрібно користуватися в подальшому, і заголовок вихідного пакету з першими 64 бітами його поля даних. Із заголовка пакету вузол дізнається, для якої мережі необхідно користуватися зазначеним маршрутизатором.

Приклад:

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

Таблиця 3.

Ця таблиця містить запис про локальну IP-мережі 128.6.4 і маршрут за замовчуванням, вказує шлюз 128.6.4.27. Припустимо, що існує шлюз 128.6.4.30, який є найкращим шляхом доступу до IP-мережі 128.6.7.

Припустимо, що потрібно посилати IP-пакети по IP - адресою 128.6.7.23. Перший IP-пакет піде на шлюз за замовчуванням, так як це єдиний підходящий маршрут, описаний в таблиці. Однак шлюз 128.6.4.27 знає, що існує кращий маршрут, що проходить через шлюз 128.6.4.30. У цьому випадку шлюз 128.6.4.27 повертає повідомлення перенаправлення, де вказує, що IP-пакети для вузла 128.6.7.23 повинні надсилатися через шлюз 128.6.4.30.

Модуль IP на машині-відправника повинен додати запис в таблицю маршрутів:

Таблиця 4.

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

Аналіз застосовності протоколу ICMP при переході з набору протоколів IP v 4 на набір IP v 6

На перший погляд, новий протокол має ряд істотних переваг перед IPv4. Проте до цих пір швидкість його впровадження продовжує залишатися низькою. За даними Форуму IPv6, тільки сім із 21 найбільших інтернет-провайдерів роблять кроки, необхідні для повноцінного переходу до використання нової технології.

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

У специфікації RFC 1726 представлений набір функцій, основними серед них є:

• масштабованість: ідентифікація та визначення адрес як мінімум ^{12 жовтня} кінцевих систем і 10 ⁹ індивідуальних мереж;

• топологічна гнучкість: архітектура маршрутизації і протокол повинні працювати в мережах з різною топологією;

• спадкоємність: забезпечення чіткого плану переходу від існуючої версії IPv4;

• незалежність від середовища передачі: робота серед безлічі мереж з різними середовищами передачі даних зі швидкостями до сотень гігабіт на секунду;

• автоматичне конфігурування хостів і маршрутизаторів;

• безпеку на мережевому рівні;

• мобільність: забезпечення роботи з мобільними користувачами, мережами і міжмережевих системами;

• розширюваність: можливість подальшого розвитку відповідно до нових потреб.

У результаті реалізації заявлених функцій найважливіші інновації IPv6 полягають у наступному:

• спрощений стандартний заголовок IP-пакета;

• змінено подання необов'язкових полів заголовка;

• розширено адресний простір;

• покращена підтримка ієрархічної адресації, агрегування маршрутів і автоматичного конфігурування адрес;

• введені механізми аутентифікації і шифрування на рівні IP-пакетів;

• введені мітки потоків даних.

Протокол IP v6 передбачає також значні поліпшення при роботі в локальній мережі. Єдиний протокол NDP (Neighbor Discovery Protocol - протокол розпізнавання сусідів) замінює застосовувані в IP v4 протоколи ARP, ICMP і значно розширює їх функціональні можливості. Замість використовуються в протоколі ARP широкомовних пакетів канального рівня використовуються групові повідомлення (multicast), тобто адресовані всім членам підмережі, притому, не на канальному, а на мережевому рівні, що має значно знизити широкомовний трафік, що є бичем локальних мереж Ethernet. Удосконалено функції протоколу ICMP, полегшуючи роботу різних підмереж в одному фізичному сегменті. Включений механізм розпізнавання несправних маршрутизаторів, що дозволяє підвищити стійкість до збоїв устаткування.

IPv6 і DNS

Ще одна проблема, пов'язана із запровадженням IPv6, - її несумісність з DNS, яка використовується сьогодні в Інтернеті.
Існування DNS (Domain Name System) позбавляє рядового користувача від необхідності замислюватися про числові IP-адреси. Вона дозволяє присвоювати будь-якому IP-адресою символьне ім'я (домен). Перетворення символьного імені в числове і навпаки здійснюється DNS-серверами. На них міститься інформація про кожному домені. Вона представлена ​​у вигляді ресурсних записів, кожна з яких належить конкретному доменному імені і містить ряд відомостей про нього, в тому числі його IP-адресу. До початку впровадження IPv6 існувало 20 типів таких записів. Вони ставилися до 32-розрядним IP-адресами (так звані записи «A»), що робило DNS і IPv6 несумісними.

Однак потім був визначений новий тип ресурсної запису «AAAA», який служить для зберігання 128-бітного IPv6-адреси. Сам адреса визначена в інформаційній частині цього запису та у вигляді імені представляється у спеціально створеному домені ip6.int. Це ім'я виглядає як набір символів, розділених крапками, і закінчується суфіксом ip6.int.

Клієнт, що направляє з пристрою запити на DNS-сервер, повинен вміти розпізнавати записи як про адреси IPv4, так і про адреси IPv6. Отримавши запит, DNS-сервер визначає тип ресурсної записи (A або AAAA) і відправляє її пристрою. Розпізнавши запис, пристрій вибере для передачі даних або протокол IPv4, або протокол IPv6.

При цьому, коли IPv4-сумісний адреса призначається якомусь вузлу, в DNS створюється дві ресурсних запису: AAAA і A. Перша відображає цю адресу в 128-бітному форматі, а друга - в 32-бітному. Це дозволяє пристроїв з існуючим тільки протокол IPv6, отримувати IPv6-адреси, а вузлам, що працює тільки на IPv4 - IPv4 адреси.

Одним словом, для повної сумісності з IPv6 DNS вимагає серйозної перебудови.

Впровадження набору протоколів IP v 6 і його переваги перед IP v 4

При розгляді можливостей, що надаються новим протоколом, може виникнути питання, а навіщо він все-таки потрібен? Більшість функцій або вже є в IP v4, або можуть бути реалізовані шляхом доопрацювання відповідних протоколів. Так, автоматичне виділення адрес проводиться за допомогою протоколу DHCP, адресний бар'єр долається за допомогою протоколу NAT і т.д. і т.п. Однак розробка всіх необхідних латочок для протоколу IP v4 зажадала б витрати не менших (а то й більших) зусиль, ніж створення нового протоколу «з чистого аркуша». Зрозуміло, лист був не зовсім чистим, оскільки питання сумісності та спільної роботи обох протоколів малися на увазі з самого початку проектування. Зрештою Інтернет все одно прийшла б до кризи дефіциту адрес, так що завчасна розробка і поступове впровадження протоколу IP v6 були більш ніж доречні.

Для реалізації переходу на новий протокол утворилася неформальна некомерційна організація 6bone, що включає в себе більше 100 організацій, в основному, мережевих провайдерів та університетів. Головне завдання організації - створення інфраструктури, що дозволяє транспортування пакетів стандарту IP v6 по всій мережі Інтернет. Як і існуюча сьогодні інфраструктура IP v4, вона буде складатися з великої кількості провайдерів і локальних мереж, об'єднаних в єдину Мережу. В даний час до складу 6bone входять представники 41 країни, від США, Англії і Японії і до Камеруну і Казахстану.

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

Підсумки:

1. Базовий набір протоколів IP v 6 охоплює функції набору протоколів IP v 4

2. Базовий набір протоколів IP v 6 розширює функції набору протоколів IP v 4 (у тому числі ICMP, які охоплюється єдиним протоколом NDP).

3. Тестування та впровадження IP v 6 вимагає значних зусиль і витрат.

Протоколи обміну маршрутною інформацією

Загальна характеристика протоколів обміну маршрутною інформацією

Всі протоколи обміну маршрутною інформацією стека TCP / IP відносяться до класу адаптивних протоколів, які в свою чергу діляться на дві групи, кожна з яких пов'язана з одним із наступних типів алгоритмів:

 дистанційно-векторний алгоритм (Distance Vector Algorithms, DVA),

 алгоритм стану зв'язків (Link State Algorithms, LSA).

В алгоритмах дистанційно-векторного типу кожен маршрутизатор періодично і широкомовно розсилає по мережі вектор відстаней від себе до всіх відомих йому мереж. Під відстанню звичайно розуміється число проміжних маршрутизаторів через які пакет повинен пройти перш, ніж потрапить у відповідну мережу. Може використовуватися і інша метрика, що враховує не тільки число перевалочних пунктів, але й час проходження пакетів по зв'язку між сусідніми маршрутизаторами. Отримавши вектор від сусіднього маршрутизатора, кожний маршрутизатор додає до нього інформацію про відомі йому інших мережах, про які він дізнався безпосередньо (якщо вони підключені до його портів) або з аналогічних оголошень інших маршрутизаторів, а потім знову розсилає нове значення вектора по мережі. Зрештою, кожен маршрутизатор дізнається інформацію про наявні в інтермережі мережах і про відстань до них через сусідні маршрутизатори.

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

Найбільш поширеним протоколом, заснованим на дистанційно-векторному алгоритмі, є протокол RIP.

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

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

Протоколом, заснованим на алгоритмі стану зв'язків, в стеку TCP / IP є протокол OSPF.

Дистанційно-векторний протокол RIP

Протокол RIP (Routing Information Protocol) маршрутизації призначений для порівняно невеликих і щодо однорідних мереж (алгоритм Белмана-Форда). Протокол розроблений в університеті Каліфорнії (Берклі), базується на розробках фірми Ксерокс та реалізує ті ж принципи, що і програма маршрутизації routed, використовувана в ОC UNIX (4BSD). Маршрут тут характеризується вектором відстані до місця призначення. Передбачається, що кожен маршрутизатор є відправною точкою декількох маршрутів до мереж, з якими він пов'язаний.

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

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

Описи цих маршрутів зберігається в спеціальній таблиці, званої маршрутної. Таблиця маршрутизації RIP містить по запису на кожну обслуговується машину (на кожен маршрут). Запис повинен включати в себе:

• IP-адреса місця призначення.

• Метрика маршруту (від 1 до 15; число кроків до місця призначення).

• IP-адресу найближчого маршрутизатора (gateway) по дорозі до місця призначення.

• Таймери маршруту.

Першим двом полів запису ми зобов'язані появи терміну вектор відстані (місце призначення - напрям; метрика - модуль вектора). Періодично (раз на 30 сек) кожен маршрутизатор посилає широкомовно копію своєї маршрутної таблиці всім сусідам-маршрутизаторам, з якими пов'язаний безпосередньо. Маршрутизатор-одержувач переглядає таблицю. Якщо в таблиці присутній новий шлях або повідомлення про більш короткому маршруті, або сталися зміни довжин шляху, ці зміни фіксуються одержувачем у своїй маршрутної таблиці. Протокол RIP повинен бути здатний обробляти три типи помилок:

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

Для придушення нестабільностей RIP повинен використовувати мале значення максимально можливого числа кроків (<16).

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

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

У RIP повідомлення інкапсулюються в udp-дейтограмми, при цьому передача здійснюється через порт 520. В якості метрики RIP використовує число кроків до мети. Якщо між відправником і приймачем розташовано три маршрутизатора (gateway), вважається, що між ними 4 кроки. Такий вид метрики не враховує відмінностей у пропускній здатності чи завантаженості окремих сегментів мережі. Застосування вектора відстані не може гарантувати оптимальність вибору маршруту, адже, наприклад, два кроки по сегментах мережі ethernet забезпечать більшу пропускну здатність, ніж один крок через послідовний канал на основі інтерфейсу RS-232.

Маршрут за замовчуванням має адресу 0.0.0.0 (це вірно і для інших протоколів маршрутизації). Кожному маршрутом ставиться у відповідність таймер тайм-ауту і «збирача сміття». Тайм-аут-таймер скидається кожен раз, коли маршрут ініціалізується або коригується. Якщо з часу останньої корекції пройшло 3 хвилини або отримано повідомлення про те, що вектор відстані дорівнює 16, маршрут вважається закритим. Але запис про нього не стирається, поки не закінчиться час «збирання сміття» (2 хв). При появі еквівалентного маршруту перемикання на нього не відбувається, таким чином, блокується можливість осциляції між двома або більше рівноцінними маршрутами. Формат повідомлення протоколу RIP має вигляд, показаний на рис. 4.4.11.2. Поле команда визначає вибір згідно наступної таблиці:

Таблиця 5. Значення кодів поля команда

Поле версія для RIP одно 1 (для RIP-2 двом). Поле набір протоколів мережі i визначає набір протоколів, які використовуються у відповідній мережі (для Інтернет це поле має значення 2). Поле відстань до мережі i містить ціле число кроків (від 1 до 15) до даної мережі. В одному повідомленні може бути присутнім інформація про 25 маршрутах. При реалізації RIP можна виділити наступні режими:

Ініціалізація, визначення всіх «живих» інтерфейсів шляхом посилки запитів, отримання таблиць маршрутизації від інших маршрутизаторів. Часто використовуються широкомовні запити.

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

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

Рис. 2. Формат повідомлення RIP.

Протокол стану зв'язків OSPF

Протокол OSPF (Open Shortest Path Firs) є достатньо сучасної реалізацією алгоритму стану зв'язків (він прийнятий у 1991 році) і володіє багатьма особливостями, орієнтованими на застосування у великих гетерогенних мережах.

Протокол OSPF обчислює маршрути в IP-мережах, зберігаючи при цьому інші протоколи обміну маршрутною інформацією.

Безпосередньо пов'язані (тобто досяжні без використання проміжних маршрутизаторів) маршрутизатори називаються «сусідами». Кожен маршрутизатор зберігає інформацію про те, в якому стані на його думку знаходиться сусід. Маршрутизатор покладається на сусідні маршрутизатори і передає їм пакети даних лише в тому випадку, якщо він впевнений, що вони повністю працездатні. Для з'ясування стану зв'язків маршрутизатори-сусіди досить часто обмінюються короткими повідомленнями HELLO.

Для розповсюдження по мережі даних про стан зв'язків, маршрутизатори обмінюються повідомленнями іншого типу. Ці повідомлення називаються router links advertisement - оголошення про зв'язки маршрутизатора (точніше, про стан зв'язків). OSPF-маршрутизатори обмінюються не тільки своїми, але й чужими оголошеннями про зв'язки, отримуючи в кінці-кінців інформацію про стан всіх зв'язків мережі. Цю інформацію і утворює граф зв'язків мережі, який, природно, один і той же для всіх маршрутизаторів мережі.

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

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

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

У OSPF такі вимоги відсутні: мережі можуть мати різну кількість хостів і можуть перекриватися. Під перекриттям розуміється наявність декількох маршрутів до однієї і тієї ж мережі. У цьому випадку адреса мережі у отриманому пакеті може співпасти з адресою мережі, присвоєним кільком портів.

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

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

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

У протоколі OSPF підмережі діляться на три категорії:

 «хост-мережа», що представляє собою підмережа з однієї адреси,

 «тупикова мережа», яка представляє собою підмережа, підключену тільки до одного маршрутизатора,

 «транзитна мережа», яка представляє собою підмережа, підключену до більш ніж одного маршрутизатора.

Транзитна мережа є для протоколу OSPF особливим випадком. У транзитній мережі декілька маршрутизаторів є взаємно і одночасно досяжними. У широкомовних локальних мережах, таких як Ethernet або Token Ring, маршрутизатор може послати одне повідомлення, яке отримають всі його сусіди. Це зменшує навантаження на маршрутизатор, коли він посилає повідомлення для визначення існування зв'язку або оновлені оголошення про сусідів. Однак, якщо кожен маршрутизатор буде перераховувати всіх своїх сусідів у своїх оголошеннях про сусідів, то оголошення займуть багато місця в пам'яті маршрутизатора. При визначенні шляху за адресами транзитної підмережі може виявитися багато надлишкових маршрутів до різних маршрутизаторам. На обчислення, перевірку і відбракування цих маршрутів піде багато часу.

Коли маршрутизатор починає працювати в перший раз (тобто інсталюється), він намагається синхронізувати свою базу даних з маршрутизаторами транзитної локальної мережі, які за визначенням мають ідентичні бази даних. Для спрощення та оптимізації цього процесу в протоколі OSPF використовується поняття «виділеного» маршрутизатора, який виконує дві функції.

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

По-друге, виділений маршрутизатор робить оголошення про мережеві зв'язках, перераховуючи своїх сусідів по підмережі. Інші маршрутизатори просто оголошують про свій зв'язок з виділеним маршрутизатором. Це робить оголошення про зв'язки (яких багато) більш короткими, розміром з оголошення про зв'язки окремої мережі.

Для початку роботи маршрутизатора OSPF потрібен мінімум інформації - IP-конфігурація (IP-адреси і маски підмереж), деяка інформація за замовчуванням (default) і команда на включення. Для багатьох мереж інформація за замовчуванням вельми схожа. У той же час протокол OSPF передбачає високий ступінь програмованість.

Інтерфейс OSPF (порт маршрутизатора, що підтримує протокол OSPF) є узагальненням підмережі IP. Подібно підмережі IP, інтерфейс OSPF має IP-адресу та маску підмережі. Якщо один порт OSPF підтримує більш ніж одну підмережа, протокол OSPF розглядає ці підмережі так, як якщо б вони були на різних фізичних інтерфейсах, і обчислює маршрути відповідно.

Інтерфейси, до яких підключені локальні мережі, називаються широкомовними (broadcast) інтерфейсами, так як вони можуть використовувати широкомовні можливості локальних мереж для обміну сигнальною інформацією між маршрутизаторами. Інтерфейси, до яких підключені глобальні мережі, які не підтримують широкомовлення, але забезпечують доступ до багатьох версій сайту через одну точку входу, наприклад мережі Х.25 або frame relay, називаються нешіроковещательнимі інтерфейсами з множинним доступом або NBMA (non-broadcast multi-access). Вони розглядаються аналогічно широкомовним інтерфейсам за винятком того, що широкомовлення емулюється шляхом посилки повідомлення кожному сусідові. Так як виявлення сусідів не є автоматичним, як в широкомовних мережах, NBMA-сусіди повинні задаватися при конфігуруванні вручну. Як на широкомовних, так і на NBMA-інтерфейсах можуть бути задані пріоритети маршрутизаторів для того, щоб вони могли вибрати виділений маршрутизатор.

Інтерфейси «точка-точка», подібні PPP, дещо відрізняються від традиційної IP-моделі. Хоча вони і можуть мати IP-адреси і подмаскі, але необхідності в цьому немає.

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

Число, яке використовується в якості метрики шляху, може бути призначено довільним чином за бажанням адміністратора. Але за умовчанням як метрики використовується час передачі біта в 10-ти наносекундних одиницях (10 Мб / с Ethernet "призначається значення 10, а лінії 56 Кб / с - число 1785). Обчислюється протоколом OSPF метрика шляху являє собою суму метрик всіх прохідних в дорозі зв'язків; це дуже груба оцінка затримки шляху. Якщо маршрутизатор виявляє більше, ніж один шлях до віддаленої підмережі, то він використовує шлях з найменшою вартістю шляху.

У протоколі OSPF використовується кілька часових параметрів, і серед них найбільш важливими є інтервал повідомлення HELLO і інтервал відмови маршрутизатора (router dead interval).

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

Протокол BGP

Протокол BGP розроблений компаніями IBM і CISCO. Головна мета BGP - скоротити транзитний трафік.

BGP відрізняється від RIP і OSPF тим, що використовує TCP в якості транспортного протоколу. Дві системи, що використовують BGP, зв'язуються один з одним і пересилають за допомогою TCP повні таблиці маршрутизації.

Завдання зовнішньої маршрутизації

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

Розглянутий на цьому рівні, Інтернет являє собою безліч автономних систем, довільним чином з'єднаних між собою (рис. 3). Внутрішня будова автономних систем приховано, відомі лише адреси IP-мереж, що становлять АС.

Рис. 3. Автономні системи

Автономні системи з'єднуються за допомогою прикордонних маршрутизаторів. Зв'язки між маршрутизаторами можуть мати різну фізичну природу: наприклад, це може бути мережа Ethernet, до якої підключено відразу декілька прикордонних маршрутизаторів різних автономних систем, виділений канал типу «точка-точка» між двома маршрутизаторами і т.п. Часто сама єднальна мережа не належить ні до однієї автономної системи, в такому випадку вона називається демілітаризованою зоною (DMZ).

У залежності від свого розташування в загальній структурі Інтернет автономна система може бути тупикової (stub) - має зв'язок тільки з одного АС (АС7 на рис. 7.1.1), - або багатопортовий (multihomed), тобто має зв'язки з кількома АС. Якщо адміністративна політика автономної системи дозволяє передавати через свої мережі транзитний трафік інших АС, то таку автономну систему можна назвати транзитної (transit).

Прикордонний маршрутизатор повідомляє пов'язаним з ним іншим прикордонним маршрутизаторам, які мережі яких автономних систем досяжні через нього. Обмін такою інформацією дозволяє прикордонним маршрутизаторам занести в таблицю маршрутів запису про мережі, що знаходяться в інших АС. При необхідності ця інформація потім поширюється усередині своєї автономної системи за допомогою протоколів внутрішньої маршрутизації (див., наприклад, зовнішні маршрути в OSPF) з тим, щоб забезпечити зовнішню коннективність своєї АС.

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

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

Наприклад, розглянемо систему маршрутизаторів, аналогічну графу автономних систем, зображеному на рис. 7.1.1. Алгоритм SPF гарантує, що якщо вузол (1) обчислив маршрут у вузол (6) як (1) - (3) - (5) - (6), то вузол (3) також буде використовувати маршрут (3) - (5) - (6). Це відбувається тому, що всі вузли однаково інтерпретують метрики зв'язків і використовують одні й ті самі математичні процедури для обчислення маршрутів. Однак якщо застосовувати протокол стану зв'язків на рівні автономних систем може відбутися наступне: АС1 встановила, що оптимальний маршрут з міркувань пропускної здатності мереж у АС6 виглядає 1-3-5-6. Але АС3 вважає, що вигідніше добиратися в АС6 за маршрутом 3-1-2-4-6, так як АС5 дорого бере за передачу транзитного трафіку. У підсумку, через те, що у кожної АС своє поняття метрики, тобто якості маршруту, відбувається зациклення.

Здавалося б, дистанційно-векторний підхід міг би вирішити проблему: АС3, яка не бажає використовувати АС5 для транзиту в АС6, просто не надіслала б у АС1 елемент вектора відстаней для АС6, отже перша система ніколи не дізналася б про маршрут 1-3-5 - 6. Але з іншого боку при використанні дистанційно-векторного підходу одержувачу вектора відстаней невідомо опис маршруту на всій його протяжності. Розглянемо іншу політичну ситуацію на прикладі того ж рис. 7.1.1: АС1 отримує від АС3 вектор АС6 = 2 і направляє свій трафік в АС6 через АС3, не підозрюючи, що на цьому маршруті розташовується АС5, яка перебуває з АС1 у стані війни і, природно, не пропускає транзитний трафік від і для АС1 . У результаті АС1, встановивши зовні нешкідливий маршрут в АС6, залишилася без зв'язку з цією автономною системою. Якби АС1 отримала повний опис маршруту, то вона безсумнівно б вибрала альтернативний варіант 1-2-4-6, проте в дистанційно-векторних протоколах така інформація не передається.

Для вирішення завдання зовнішньої маршрутизації був розроблений протокол BGP (Border Gateway Protocol). Використовувана в даний момент версія цього протоколу має номер 4, відповідний стандарт - RFC-1771, 1772.

Загальна схема роботи BGP така. BGP-маршрутизатори сусідніх АС, які вирішили обмінюватися маршрутною інформацією, встановлюють між собою з'єднання по протоколу BGP і стають BGP-сусідами (BGP-peers).

Далі BGP використовує підхід під назвою path vector, що є розвитком дистанційно-векторного підходу. BGP-сусіди розсилають (анонсують, advertise) один одному вектори шляхів (path vectors). Вектор шляхів, на відміну від вектора відстаней, містить не просто адреса мережі і відстань до неї, а адреса мережі і список атрибутів (path attributes), що описують різні характеристики маршруту від маршрутизатора-відправника в зазначену мережу. У подальшому для стислості ми будемо називати набір даних, що складаються з адреси мережі й атрибутів шляху до цієї мережі, маршрутом у дану мережу.

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

Наприклад, найбільш важливим атрибутом маршруту є AS_PATH - список номерів автономних систем, через які має пройти дейтаграма на шляху в зазначену мережу. Атрибут AS_PATH можна використовувати для:

виявлення циклів - якщо номер однієї і тієї ж АС зустрічається в AS_PATH двічі;

обчислення метрики маршруту - метрикою в даному випадку є число АС, які потрібно перетнути;

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

Анонсуючи який-небудь маршрут, BGP-маршрутизатор додає в AS_PATH номер своєї автономної системи.

Внутрішній BGP, маршрутні сервери і атрибут NEXT_HOP

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

Відмінність IBGP від EBGP полягає в тому, що при оголошенні маршруту BGP-сусіду, що знаходиться в тій же самій АС, маршрутизатор не повинен додавати в AS_PATH номер своєї автономної системи. Дійсно, якщо номер АС буде доданий, і сусід анонсує цей маршрут далі (знову з додаванням номера тієї ж АС), то одна і та ж АС буде перерахована AS_PATH двічі, що розцінюється як цикл.

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

Наслідком цього слідства є необхідність повного графа IBGP-з'єднань між прикордонними маршрутизаторами однієї автономної системи: тобто кожна пара маршрутизаторів повинна встановлювати між собою з'єднання по протоколу IBGP. При цьому виникає проблема великого числа сполук (порядку N2, де N-число BGP-маршрутизаторів в АС). Для зменшення числа з'єднань застосовуються різні рішення: розбивка АС на конфедерації (підсистеми), застосування серверів маршрутної інформації та ін

Сервер маршрутної інформації (аналог виділеного маршрутизатора в OSPF), обслуговуючий групу BGP-маршрутизаторів, працює дуже просто: він приймає маршрут від одного учасника групи і розсилає його всім іншим. Таким чином, учасникам групи немає необхідності встановлювати BGP-з'єднання попарно; замість цього кожен учасник встановлює одне з'єднання з сервером. Групою маршрутизаторів можуть бути, наприклад, всі BGP-маршрутизатори даної АС, проте маршрутні сервери можуть застосовуватися для зменшення числа сполук також і на зовнішніх BGP-з'єднання - у разі, коли в одній фізичній мережі знаходиться багато BGP-маршрутизаторів з різних АС (наприклад, в точці обміну трафіком між провайдерами, рис. 4).

Рис. 4. Точка обміну трафіком (Internet Exchange Point)

AE - прикордонні BGP-маршрутизатори, АС1-АС5 - мережі автономних систем, RS - сервер маршрутної інформації.

Слід особливо відзначити, що сервер маршрутної інформації обслуговує лише анонси маршрутів, а не сам трафік по цих маршрутах. Наприклад (рис 7.2.1), маршрутизатор А анонсує сервера RS маршрути в мережі АС1. Маршрутизатор E отримує інформацію про ці маршрутах від сервера RS, але при цьому в таблиці маршрутів вузла Е наступним маршрутизатором на шляху до АС1 значиться вузол А, що абсолютно розумно, оскільки ці вузли можуть передавати дані один одного безпосередньо. Виняток маршрутного сервера з маршруту проводиться шляхом встановлення значення атрибута NEXT_HOP: анонсуючи маршрути в мережу АС1, сервер RS вказує NEXT_HOP = A. Таким чином, маршрутизатор (наприклад, Е), який отримав та прийняв до використання такий маршрут, буде пересилати дані, призначені для АС1, безпосередньо маршрутизатора А.

З вищесказаного можна зробити два важливих висновки. По-перше, вузол, зазначений як NEXT_HOP, повинен бути досяжний, тобто в таблиці маршрутів маршрутизатора, що прийняв маршрут з цим атрибутом, повинна бути запис про вузол NEXT_HOP або його мережі. Якщо такого запису немає, то маршрутизатор повинен забракувати отриманий маршрут, тому що він не знає, як відправляти дейтаграми до вузла NEXT_HOP.

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

Атрибути шляху (Path Attributes)

Нижче перераховані всі атрибути шляху, визначені для протоколу BGP.

ORIGIN

ORIGIN (тип 1) - обов'язковий атрибут, який вказує джерело інформації про маршрут:

0 - IGP (інформація про досяжності мережі отримана від протоколу внутрішньої маршрутизації або введена адміністратором),

1 - EGP (інформація про досяжності мережі імпортована із застарілого протоколу EGP),

2 - INCOMPLETE (інформація отримана іншим чином, наприклад, RIP-> OSPF-> BGP або BGP-> OSPF-> BGP).

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

AS_PATH

AS_PATH (тип 2) - обов'язковий атрибут, який містить список автономних систем, через які має пройти дейтаграма на шляху у вказану в маршруті мережу. AS_PATH являє собою чергування сегментів двох типів: AS_SEQUENCE - впорядкований список АС, і AS_SET - безліч АС (останнє може виникнути при агрегування декількох маршрутів зі схожими, але не однаковими AS_PATH в один загальний маршрут).

Кожен BGP-вузол при анонсуванні маршруту (за винятком IBGP-з'єднань) додає в AS_PATH номер своєї АС. Можливо (в залежності від політики) додатково додаються номери інших АС.

NEXT_HOP

NEXT_HOP (тип 3) - обов'язковий атрибут, який вказує адреса наступного BGP-маршрутизатора на шляху в заявлену мережу (див. обговорення в п. 7.2); може збігатися або не збігатися з адресою BGP-вузла, що анонсує маршрут. Зазначений у NEXT_HOP маршрутизатор повинен бути досяжний для одержувача даного маршруту. При передачі маршруту по IBGP NEXT_HOP не змінюється.

MULTI_EXIT_DISC

MULTI_EXIT_DISC (тип 4) - необов'язковий атрибут, який представляє собою пріоритет використання оголошує маршрутизатора для досягнення через нього анонсируемой мережі, тобто фактично це метрика маршруту з точки зору анонсує маршрут BGP-вузла. Має сенс не саме значення а різниця значень, коли кілька маршрутизаторів однієї АС оголошують про досяжності через себе однієї і тієї ж мережі, надаючи таким чином одержувачам кілька варіантів маршрутів в одну мережу. За інших рівних умов дейтаграми в оголошується мережу будуть надсилатися через маршрутизатор, який заявив менше значення MULTI_EXIT_DISC.

Атрибут зберігається при подальших оголошеннях маршруту по IBGP, але не за EBGP.

LOCAL_PREF

LOCAL_PREF (тип 5) - необов'язковий атрибут, що встановлює для даної АС пріоритет даного маршруту серед усіх маршрутів до заявленої мережі, відомих всередині АС. Атрибут обчислюється кожним прикордонним маршрутизатором для кожного надісланого йому по EBGP маршруту і потім поширюється разом з цим маршрутом по IBGP в межах даної АС. Спосіб обчислення значення атрибута визначається політикою прийому маршрутів (за замовчуванням береться до уваги тільки довжина AS_PATH). LOCAL_PREF використовується для погодженого між маршрутизаторами однієї АС вибору маршруту з декількох варіантів.

Атрибути агрегування

ATOMIC_AGGREGATE (тип 6) і AGGREGATOR (тип 7) - необов'язкові атрибути, пов'язані з операціями агрегування (об'єднання) декількох маршрутів в один.

Приклади маршрутизації

Приклад маршрутизації за алгоритмом RIP

На малюнку 3 наведено приклад мережі, що складається з шести маршрутизаторів, що мають ідентифікатори від 1 до 6, і з шести мереж від A до F, утворених прямими зв'язками типу «точка-точка».

Малюнок 3. Обмін маршрутною інформацією по протоколу RIP

На малюнку наведена початкова інформація, що міститься в топологічному базі маршрутизатора 2, а також інформація в цій же базі після двох ітерацій обміну маршрутними пакетами протоколу RIP. Після певного числа ітерацій маршрутизатор 2 буде знати про відстані до всіх мереж інтермережі, причому у нього може бути кілька альтернативних варіантів відправки пакета до мережі призначення. Нехай у нашому прикладі мережею призначення є мережа D.

При необхідності відправити пакет у мережу D маршрутизатор переглядає свою базу даних маршрутів і вибирає порт, що має найменше відстані до мережі призначення (у даному випадку порт, що зв'язує його з маршрутизатором 3).

Для адаптації до зміни стану зв'язків та обладнання з кожним записом таблиці маршрутизації пов'язаний таймер. Якщо за час тайм-ауту не прийде нове повідомлення, яке підтверджує цей маршрут, то він видаляється з маршрутної таблиці.

При використанні протоколу RIP працює евристичний алгоритм динамічного програмування Белмана-Форда, і рішення, знайдене з його допомогою є не оптимальним, а близьким до оптимального. Перевагою протоколу RIP є його обчислювальна простота, а недоліками - збільшення трафіку при періодичній розсилці широкомовних пакетів і неоптимальність знайденого маршруту.

На малюнку 4 показаний випадок нестійкої роботи мережі по протоколу RIP при зміні конфігурації - відмову лінії зв'язку маршрутизатора M1 з мережею 1. При працездатному стані цьому зв'язку в таблиці маршрутів кожного маршрутизатора є запис про мережу за номером 1 і відповідним відстанню до неї.

Малюнок 4. Приклад нестійкої роботи мережі при використанні протоколу RIP

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

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

Існують і інші, більш складні випадки нестабільного поведінки мереж, що використовують протокол RIP, при змінах в стані зв'язків або маршрутизаторів мережі.

Приклад маршрутизації за алгоритмом OSPF

Уявімо собі один день з життя транзитної локальної мережі. Нехай у нас є мережа Ethernet, в якій є три маршрутизатора - Джон, Фред і Роб (імена членів робочої групи Internet, що розробила протокол OSPF). Ці маршрутизатори пов'язані з мережами в інших містах за допомогою виділених ліній.

Нехай відбулося відновлення живлення мережі після збою. Маршрутизатори та комп'ютери перевантажуються і починають працювати по мережі Ethernet. Після того, як маршрутизатори виявляють, що порти Ethernet працюють нормально, вони починають генерувати повідомлення HELLO, які говорять про їх присутність у мережі і їх конфігурації. Однак маршрутизація пакетів починає здійснюватися не відразу - спочатку маршрутизатори повинні синхронізувати свої маршрутні бази (малюнок 5).

Малюнок 5. Гіпотетична мережу з OSPF маршрутизаторами

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

Коли період відмови маршрутизатора закінчується, то маршрутизатор з найвищим пріоритетом і найбільшим ідентифікатором оголошує себе виділеним (а наступний за ним за пріоритетом маршрутизатор оголошує себе резервним виділеним маршрутизатором) і починає синхронізувати свою базу даних з іншими маршрутизаторами.

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

Бази даних тепер синхронізовані з виділеним маршрутизатором, яким є Джон. Джон підсумовує свою базу даних з кожною базою даних своїх сусідів - базами Фреда, Роба і Джеффа - індивідуально. У кожній синхронизирующей парі оголошення, знайдені тільки в якій-небудь одній базі, копіюються в іншу. Виділений маршрутизатор, Джон, поширює нові оголошення серед інших маршрутизаторів своєї локальної мережі. Наприклад, оголошення Міло і Робіна передаються Джону Робом, а Джон у свою чергу передає їх Фреду і Джеффрі. Обмін інформацією між базами продовжується якийсь час, і поки він не завершиться, маршрутизатори не будуть вважати себе працездатними. Після цього вони себе такими вважають, тому що мають всю доступну інформацію про мережу.

Подивимося тепер, як Робін обчислює маршрут через мережу. Дві із зв'язків, приєднаних до його портів, представляють лінії T-1, а одна - лінію 56 Кб / c. Робін спочатку виявляє двох сусідів - Роба з метрикою 65 і Міло з метрикою 1785. З оголошення про зв'язки Роба Робін виявив найкращий шлях до Міло з вартістю 130, тому він відкинув безпосередній шлях до Міло, оскільки він пов'язаний з більшою затримкою, тому що проходить через лінії з меншою пропускною здатністю. Робін також виявляє транзитну локальну мережу з виділеним маршрутизатором Джоном. З оголошень про зв'язки Джона Робін дізнається про шлях до Фреда і, нарешті, дізнається про шлях до маршрутизаторів Келлі і Джефу і до їх тупиковим мереж.

Після того, як маршрутизатори повністю входять в робочий режим, інтенсивність обміну повідомленнями різко падає. Зазвичай вони посилають повідомлення HELLO за своїми подсетям кожні 10 секунд і роблять оголошення про стан зв'язків кожні 30 хвилин (якщо виявляються зміни в стані зв'язків, то оголошення передається, природно, негайно). Оновлені оголошення про зв'язки служать гарантією того, що маршрутизатор працює в мережі. Старі оголошення видаляються з бази через певний час.

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

Практичний приклад роботи з BGP-мережею

Маємо наступну BGP-мережу

Малюнок 6.

Якщо AS пов'язана з двома ISP через EBGP, IBGP повинен використовуватися між роутерами всередині даної AS для кращого управління маршрутами.

Розглянемо AS100, яка має два EBGP з'єднання (роутери «A» і «B») з зовнішнім світом (роутери «C» і «D»). «A» і «B» спілкуються між собою за IBGP.

Між роутерами «AF», «AB» і «BF» цієї AS також використовується OSPF (протокол сімейства IGP).

Наведена нижче конфігурація роутерів - попередня, оскільки вона не повна. Це зроблено для того, щоб продемонструвати методи BGP виправлення помилок.

! Router A

hostname RouterA

!

interface loopback 0

ip address 203.250.13.41 255.255.255.0

!

interface ethernet 0

ip address 203.250.14.1 255.255.255.0

!

interface serial 0

ip address 128.213.63.1 255.255.255.252

!

router ospf 10

network 203.250.0.0 0.0.255.255 area 0

router bgp 100

network 203.250.13.0 mask 255.255.255.0

network 203.250.14.0 mask 255.255.255.0

neighbor 128.213.63.2 update-source loopback 0

! Router B

!

hostname RouterB

!

interface serial 0

ip address 203.250.15.2 255.255.255.252

!

inetrface serial 1

ip address 192.208.10.6 255.255.255.252

!

router ospf 10

network 203.250.0.0 0.0.255.255 area 0

!

router bgp 100

network 203.250.15.0

neighbor 192.208.10.5 remote-as 300

neighbor 203.250.15.1 remote-as 100

! Router C

hostname RouterC

!

interface loopback 0

ip address 128.213.63.130 255.255.255.192

!

interface serial 2 / 0

ip address 128.213.63.5 255.255.255.252

!

interface serial 2 / 1

ip address 128.213.63.2 255.255.255.252

!

router bgp 200

network 128.213.0.0

neighbor 128.213.63.1 remote-as 100

neighbor 128.213.63.6 remote-as 400

! Router D

hostname RouterD

!

interface loopback 0

ip address 192.208.10.174 255.255.255.192

!

interface serial 0 / 0

ip address 192.208.10.5 255.255.255.252

!

interface serail 0 / 1 (ERROR: тут і строчка нижче в оригіналі - з друкарською помилкою)

ip address 192.208.10.2 255.255.255.252

!

router bgp 300

network 192.208.10.0

neighbor 192.208.10.1 remote-as 500

neighbor 192.208.10.6 remote-as 100

! Router E

hostname RouterE

!

interface loopback 0

ip address 200.200.10.1 255.255.255.0

!

interface serial 0

ip address 195.211.10.2 255.255.255.252

!

interface serial 1

ip address 128.213.63.6 255.255.255.252

!

router bgp 400

network 200.200.10.0

neighbor 128.213.63.5 remote-as 200

neighbor 195.211.10.1 remote-as 500

! Router F

!

hostname RouterF

!

interface ethernet 0

ip address 203.250.14.2 255.255.255.0

!

interface serial 1

ip address 203.250.15.1 255.255.255.252

!

router ospf 10

network 203.250.0.0 0.0.255.255 area 0

! Router G

hostname RouterG

!

interface loopback 0

ip address 195.211.10.174 255.255.255.192

!

interface serial 0

ip address 192.208.10.0 255.255.255.252

!

interface serial 1

ip address 195.211.10.1 255.255.255.252

!

router bgp 500

network 195.211.10.0

neighbor 192.208.10.2 remote-as 300

neighbor 195.211.10.2 remote-as 400

Визначення стану BGP

Припустимо, що (див. рисунок 6) зв'язок між роутерами «B» і «D» зіпсувалася. Виконаємо на роутері «B» команду show ip bgp:

RouterB # show ip bgp

table version is 4, local router ID is 203.250.15.2

Status codes: s suppesed, d damped, h history, * valid,> best, i internal

Origin codes: i - IGP, e - EGP,? - Incomplete

Network Next Hop Metric LocPrf Weight Path

* I128.213.0.0 128.213.63.2 0100 0200 i

* I192.208.10.0 128.213.63.2 100 0 200 400 500 300 i

* I195.211.10.0 128.213.63.2 100 0200400500 i

* I200.200.10.0 128.213.63.2 100 0200400 i

*> I203.250.13.0 203.250.13.41 0100 0 i

*> I203.250.14.0 203.250.13.41 0100 0 i

*> 203.250.15.0 0.0.0.0 0 32 768 i

Символ «i» на початку рядка означає, що про даний маршруті стало відомо від IBGP peer'а.

Символ «i» наприкінці рядка означає, що інформація про даний шляху прийшла від IGP.

Перший рядок читається так:

Інформація про доступність мережі 128.213.0.0 отримана через AS_path 200, і для того, щоб з даного роутера досягти цієї мережі, в якості Next Hop'а слід використовувати 128.213.63.2.

Зауваження: будь-який маршрут, який згенерований на даному роутері (див. 203.250.15.0) має next hop = 0.0.0.0.

Символ «>» означає, що BGP вибрав даний маршрут, як кращий. Процес вибору найкращого маршруту описаний вище в розділі «Summary of the BGP Path Selection Process». BGP завжди вибирає тільки один маршрут, як кращий. Після чого він записує цей маршрут у IP routong table і анонсує цей шлях іншим BGP peer'ам.

Зауважимо, що next hop attribute 128.213.63.2, що має місце для частини маршрутів, успадкований від EBGP.

Тепер перевіримо IP routing table на роутері «B»:

RouterB # show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate

default

Gateway of last resort not set

203.250.13.0 255.255.255.255 is subnetted, 1 subnets

O 203.250.13.41 [110/75] via 203.250.15.1, 2:50:45, Serial0

203.250.15.0 255.255.255.252 is subnetted, 1 subnets

C 203.250.15.0 is directly connected, Serial0

O 203.250.14.0 [110/74] via 203.250.15.1, 2:40:46, Serial0

Зауважимо, що жоден BGP маршрут не з'явився в IP routing table. Це сталося тому, що в даній конфігурації ми маємо одну проблему: маршрути до деяких мереж, що містяться в BGP route table на «B», мають next hop = 128.213.63.2, який недоступний з «B».

Адреса 128.213.63.2 недоступний тому, що в таблиці маршрутизації на «B» відсутній запис про те, як досягти даний адресу через IGP (у даному випадку, через OSPF). Отже, роутер «B» не знає про 128.213.63.0 з OSPF.

Виправлення проблеми Next Hop

У даному прикладі проблема з next hop може бути вирішена двома способами:

* Використанням на роутері «A» команди «next-hop-self» для зміни значення next hop між роутерами «A» і «B».

* На роутері «A» налаштувати OSPF _на інтерфейсе_ Serial 0, вказавши його як passive. У цьому випадку роутер «B» буде знати, яким чином досягти next hop 128.213.63.2.

Отже, наступна конфігурація роутера «A» встановлює OSPF на Serial 0 і робить його passive:

! Router A

hostname RouterA

!

interface loopback 0

ip address 203.250.13.41 255.255.255.0

!

interface ethernet 0

ip address 203.250.14.1 255.255.255.0

!

interface serial 0

ip address 128.213.63.1 255.255.255.252

!

router ospf 10

passive-interface serial 0

network 203.250.0.0 0.0.255.255 area 0

network 128.213.0.0 0.0.255.255 area 0

!

router bgp 100

network 203.250.13.0 mask 255.255.255.0

network 203.250.14.0 mask 255.255.255.0

neighbor 128.213.63.2 remote-as 200

neighbor 203.250.15.2 remote-as 100

neighbor 203.250.15.2 update-source loopback 0

Тепер, BGP таблиця сусідів на роутері «B» буде містити наступні маршрути:

RouterB # show ip bgp

table version is 4, local router ID is 203.250.15.2

Status codes: s suppesed, d damped, h history, * valid,> best, i internal

Origin codes: i - IGP, e - EGP,? - Incomplete

Network Next Hop Metric LocPrf Weight Path

*> I128.213.0.0 128.213.63.2 0100 0200 i

*> I192.208.10.0 128.213.63.2 100 0 200 400 500 300 i

*> I195.211.10.0 128.213.63.2 100 0200400500 i

*> I200.200.10.0 128.213.63.2 100 0200400 i

*> I203.250.13.0 203.250.13.41 0100 0 i

*> I203.250.14.0 203.250.13.41 0100 0 i

*> 203.250.15.0 0.0.0.0 0 32 768 i

Як видно, символ «>» з'явився у всіх записів про маршрути, і це означає, що BGP задоволений наявністю досяжного next Hop'а в цих записах.

Тепер IP Routing Table на роутері «B» буде виглядати по-іншому:

RouterB # show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate

default

Gateway of last resort not set

203.250.13.0 255.255.255.255 is subnetted, 1 subnets

O 203.250.13.41 [110/75] via 203.250.15.1, 2:50:45, Serial0

203.250.15.0 255.255.255.252 is subnetted, 1 subnets

C 203.250.15.0 is directly connected, Serial0

O 203.250.14.0 [110/74] via 203.250.15.1, 2:40:46, Serial0

128.213.0.0 255.255.255.252 is subnetted, 1 subnets

O 128.213.63.0 [110/138] via 203.250.15.1, 00:04:47, Serial0

Поки що ми добилися лише того, що мережа 128.213.63.0 стала доступною OSPF. Зауважимо, що BGP запису все ще не з'явилися в IP routing table.

Проблема полягає в синхронізації: BGP НЕ синхронізований з IGP, тому маршрути BGP не передалися в IP routing table, і відповідно дані маршрути не включені до передаються далі BGP update.

Роутер «F» не знає про мережі 192.208.10.0, 195.211.10.0 тому що BGP маршрути усе ще не redistributed into OSPF.

Вимкнення синхронізації

Якщо ввести команду конфігурації «no synchronisation» на роутері «B», і потім перевірите таблицю IP маршрутизації на ньому ж, то виведуться наступні маршрути:

RouterB # show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate

default

Gateway of last resort not set

B 200.200.10.0 [200 / 0] via 128.213.63.2, 00:01:07

B 195.211.10.0 [200 / 0] via 128.213.63.2, 00:01:07

B 192.208.10.0 [200 / 0] via 128.213.63.2, 00:01:07

203.250.13.0 is variably subnetted, 2 subnets, 2 masks

O 203.250.13.41 255.255.255.255

[110/75] via 203.250.15.1, 00:12:37, Serial 0

B 203.250.13.0 255.255.255.0 [200 / 0] via 203.250.13.41, 00:01:08

203.250.15.0 255.255.255.252 is subnetted, 1 subnets

C 203.250.15.0 255.255.255.252 is directly connected, Serial 0

O 203.250.14.0 [110/74 via 203.250.15.1, 00:12:37, Serial 0

128.213.0.0 is is variably subnetted, 2 subnets, 2 masks

B 128.213.0.0 255.255.0.0 [200 / 0] via 128.213.63.2, 00:01:08

O 128.213.63.0 255.255.255.252

[110/138] via 203.250.15.1, 00:12:37, Serial 0

Отже, таблиця маршрутизації на перший погляд правильна, але досягти вказані в ній мережі не представляється можливим через те, що роутер «F», розташований на шляху до них, не знає маршрутів до цих мереж. Це видно в результатах виконання команди show ip route на «F»:

RouterF # show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate

default

Gateway of last resort not set

203.250.13.0 255.255.255.255 is subnetted, 1 subnets

O 203.250.13.41 [110/11] via 203.250.14.1, 00:14:15

203.250.15.0 255.255.255.252 is subnetted, 1 subnets

C 203.250.15.0 is directly connected, Serial1

C 203.250.14.0 is directly connected, Ethernet0

128.213.0.0 255.255.255.252 is subnetted, 1 subnets

O 128.213.63.0 [110/74] via 203.250.14.1, 00:14:15, Ethernet0

Якщо пакети, що прийшли з мережі, роутери якою обмінюються маршрутами по BGP, потраплять на роутер «F», вони будуть втрачені. Таким чином, вимикання синхронізації не вирішує цю проблему. Ми бачимо, що OSPF необхідно зробити перерозподіл своїх маршрутів в BGP на роутері «A»; таким чином, роутер «F» дізнається про BGP маршрутах.

Ре-аннонсірованіе OSPF

Отже, наступна конфігурація роутера «A» модифікування таким чином, що BGP маршрути передаються (redistributed) в OSPF:

! Router A

hostname RouterA

!

interface loopback 0

ip address 203.250.13.41 255.255.255.0

!

interface ethernet 0

ip address 203.250.14.1 255.255.255.0

!

interface serial 0

ip address 128.213.63.1 255.255.255.252

!

router ospf 10

redistribute bgp 100 metric 2000 subnets

passive-interface serial0

network 203.250.0.0 0.0.255.255 area 0

network 128.213.0.0 0.0.255.255 area 0

!

router bgp 100

network 203.250.0.0 mask 255.255.0.0

neighbor 128.213.63.2 remote-as 200

neighbor 203.250.15.2 remote-as 100

neighbor 203.250.15.2 update-source loopback 0

Тепер IP routing table буде виглядати наступним чином:

RouterB # show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

Gateway of last resort not set

O E2 200.200.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0

O E2 195.211.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0

O E2 192.208.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0

203.250.13.0 is variably subnetted, 2 subnets, 2 masks

O 203.250.13.41 255.255.255.255

[110/75] via 203.250.15.1, 00:00:15, Serial0

O E2 203.250.13.0 255.255.255.0

[110/2000] via 203.250.15.1, 00:00:15, Serial0

203.250.15.0 255.255.255.252 is subnetted, 2 subnets

C 203.250.15.8 is directly connected, Loopbackl

C 203.250.15.0 is directly connected, Serial0

O 203.250.14.0 [110/74] via 203.250.15.1, 00:00:15, Serial0

128.213.0.0 is variably subnetted, 2 subnets, 2 masks

O E2 128.213.0.0 255.255.0.0 [110/2000] via 203.250.15.1, 00:00: l5, Serial0

O 128.213.63.0 255.255.255.252

[110/138] via 203.250.15.1, 00:00:16, Serial0

Тепер запису про BGP маршрутах пропали, оскільки OSPF має краще значення Administrative Distance (110), ніж IBGP (200).

Відключення синхронізації на роутері «A» означає, що роутер «A» анонсує маршрути до мережі 203.250.15.0; Це потрібно тому, що роутер «A» не синхронізований з OSPF через mask differences. З тієї ж самої причини, синхронізація повинна бути відключена на роутері «B», щоб цей роутер міг анонсувати мережа 203.250.13.0.

Необхідно додати, що OSPF повинен бути включений на інтерфейсі Serial 1 роутера «B» і бути passive, таким чином роутер «A» дізнається про next hop 192.208.10.5 через IGP.

Отже, нові конфігурації роутерів «A» і «B»:

! Router A

hostname RouterA

!

interface loopback 0

ip address 203.250.13.41 255.255.255.0

!

interface ethernet 0

ip address 203.250.14.1 255.255.255.0

!

interface serial 0

ip address 128.213.63.1 255.255.255.252

!

router ospf 10

redistribute bgp 100 metric 2000 subnets

passive-interface serial 0

network 203.250.0.0 0.0.255.255 area 0

network 128.213.0.0 0.0.255.255 area 0

!

router bgp 100

no synchronization

network 203.250.13.0 mask 255.255.255.0

network 203.250.14.0 mask 255.255.255.0

neighbor 128.213.63.2 remote-as 200

neighbor 203.250.15.2 remote-as 100

neighbor 203.250.15.2 update-source loopback 0

Конфігурація роутера «B»:

! Router B

hostname RouterB

!

interface serial 0

ip address 203.250.15.2 255.255.255.252

!

interface serial 1

ip address 192.208.10.6 255.255.255.252

!

router ospf 10

redistribute bgp 100 metric 1000 subnets

passive-interface serial 1

network 203.250.0.0 0.0.255.255 area 0

network 192.208.0.0 0.0.255.255 area 0

!

router bgp 100

network 203.250.15.0

neighbor 192.208.10.5 remote-as 300

neighbor 203.250.13.41 remote-as 100

Тепер піднімемо Serial 1 на роутері «B» і отримаємо таку таблицю BGP маршрутизації на роутері «A»:

RouterA # show ip bgp

table version is 117, local router ID is 203.250.13.41

Status codes: s suppressed, d damped, h history, * valid,> best, i - internal

Origin codes: i - IGP, e - EGP,? - Incomplete

Network Next Hop Metric LocPrf Weight Path

*> 128.213.0.0 128.213.63.2 0 100 0 200 i

*> I192.208.10.0 192.208.10.5 0100 0300 i

*> I195.211.10.0 192.208.10.5 100 0300500 i

* 128.213.63.2 0200400500 i

*> 203.250.13.0 0.0.0.0 0 32 768 i

*> 203.250.14.0 0.0.0.0 0 32 768 i

*> I203.250.15.0 203.250.15.2 0100 0 i

Результати виконання команди show ip route на роутері «A»:

RouterA # show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

Gateway of last resort not set

192.208.10.0 is variably subnetted, 2 subnets, 2 masks

O E2 192.208.10.0 255.255.255.0

[110/1000] via 203.250.14.2, 00:41:25, Ethernet0

O 192.208.10 4 255.255.255.252

[110/138] via 203.250.14.2, 00:41:25, Ethernet0

C 203.250.13.0 is directly connected, Loopback0

203.250.15.0 is variably subnetted, 3 subnets, 3 masks

O 203.250.15.10 255.255.255.255

[110/75] via 203.250.14.2, 00:41:25, Ethernet0

O 203.250.15.0 255.255.255.252

[110/74] via 203.250.14.2, 00:41:25, Ethernet0

B 203.250.15.0 255.255.255.0 [200 / 0] via 203.250.15.2, 00:41:25

C 203.250.14.0 is directly connected, Ethernet0

128.213.0.0 is variably subnetted, 2 subnets, 2 masks

B 128.213.0.0 255.255.0.0 [20 / 0] via 128.213.63.2, 00:41:26

C 128.213.63.0 255.255.255.252 is directly connected, Serial0

B * 200.200.0.0 255.255.0.0 [20 / 0] via 128.213.63.2, 00:02:38

Результати виконання команди show ip bgp на роутері «B»:

RouterB # show ip bgp

table version is 12, local router ID is 203.250.15.2

Status codes: s suppressed, d damped, h history, * valid,> best, i - internal

Origin codes: i - IGP, e - EGP,? - Incomplete

Network Next Hop Metric LocPrf Weight Path

*> I128.213.0.0 128.213.63.2 0100 0200 i

* 192.208.10.5 0 300 500 400 200 i

*> 195.208.10.0 192.208.10.5 0 0 300 i

*> 195.211.10.0 192.208.10.5 0300500 i

*> I200.200.10.0 128.213.63.2 100 0200400 i

*> 192.208.10.5 0300500400 i

*> I203.250.13.0 203.250.13.41 0100 0 i

*> I203.250.14.0 203.250.13.41 0100 0 i

*> 203.250.15.0 0.0.0.0 0 32 768 i

Література

1. Оліфер В.Г., Оліфер Н.А., «Комп'ютерні мережі. Принципи, технології, протоколи: Підручник для вузів », СПб: Питер, 2007.

2. Комп'ютерні мережі. Е. Таненбаум, - СПб: Питер, 2002.

3. Оліфер В.Г., Оліфер Н.А., «Введення в IP-мережі». Електронний підручник.