Реферат об'єктом дослідження даної курсової роботи служить протокол динамічної маршрутизації bgp ефективність роботи даного протоколу розглядається в практичній частині за допомогою програмного забезпечення для симуляції комп’ютерних мереж Packet Tracer ця програма дозволяє емулювати І візуалізувати

Вид материалаРеферат

Содержание


Завдання до роботи
Список умовних позначень, термінів, скорочень
IP (Internet protocol) – Інтернет протокол. LAN
OSI (Open Systems Interconnection Reference Model) - модель взаємодії відкритих систем. Remote router ID
RID (Router ID) - ідентифікатор маршрутизатора. TCP
Основна частина
1.1.1. Огляд маршрутизаторів і схем маршрутизації
1.1.2. Приклад простої маршрутизації
1.2. Концепції протоколів маршрутизації
1.2.1 Дистанційно-векторні протоколи маршрутизації
1.2.2. Протоколи маршрутизації на основі аналіза стану каналу
2.1. Протокол граничного шлюзу Border Gateway Protocol версії 4
2.1.1. Алгоритм роботи BGP
Рис. 2.2. Обмін оновленнями маршрутної інформації
2.1.2. Формат заголовка повідомлення протоколу BGP
2.1.3. Взаємодія з сусідніми BGP - вузлами|
Автономна система (My autonomous system)
Довжина поля необов'язкових параметрів (Optional Parameter Length - Opt ParmLen)
Необов'язкові параметри (Optional Parameters)
2.1.4. Модель кінцевих станів
...
Полное содержание
Подобный материал:
  1   2


МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

ЧЕРНІВЕЦЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ


імені Ю. ФЕДЬКОВИЧА

ІНЖЕНЕРНО-ТЕХНІЧНИЙ ФАКУЛЬТЕТ

КАФЕДРА кореляційної оптики

Напрям підготовки: (0924 “Телекомунікації”)



Дисципліна: Телекомунікаційні комп’ютерні мережі



ПРОТОКОЛ ДИНАМІЧНОЇ МАРШРУТИЗАЦІЇ BGP



КУРСОВА РОБОТА


Завідувач кафедри

доктор фізико-математичних наук

професор (О. В. Ангельський)


Керівник роботи

кандидат фіз.-мат. наук

доцент (Д. М. Бурковець)


Виконавець роботи

студент 4-го курсу (Б. В. Романюк)


ЧЕРНІВЦІ

2010

Завдання до роботи
  1. Вивчити принцип динамічної маршрутизації в мережі Internet. З’ясувати місце та роль протоколів маршрутизації зовнішнього шлюзу.
  2. Дослідити ефективність роботи проколу маршрутизації BGPv4.
  3. Розробити методичний матеріал для лабораторної роботи з курсу телекомунікаційні комп’ютерні мережі для студентів 4-го курсу, напряму телекомунікації із використанням реалізації IOS Cisco.

РЕФЕРАТ

Об'єктом дослідження даної курсової роботи служить протокол динамічної маршрутизації BGPv4. Ефективність роботи даного протоколу розглядається в практичній частині за допомогою програмного забезпечення для симуляції комп’ютерних мереж - Packet Tracer v5.3. Ця програма дозволяє емулювати і візуалізувати мережі будь-якої складності і спроектувати їх стуктуру, що і було зроблено для наглядного прикладу роботи протоколу BGP.


Сторінок – 42, рисунків – 13, таблиць – 1, джерел літератури – 6, додатків – 3.


Ключові слова: маршрутизація, протокол граничного шлюзу BGP, дистанційно-векторний протокол, конвергенція, взаємодія з вузлами.

ЗМІСТ

Р
3

5

6

8

8

8

8

10

11

11


17

21

21

25

26

29

36

38

38


38

38

41

42

43
ЕФЕРАТ ………………………………………………………………………

СПИСОК УМОВНИХ ПОЗНАЧЕНЬ, ТЕРМІНІВ, СКОРОЧЕНЬ………......

ВСТУП …………………………………………………………………………

ОСНОВНА ЧАСТИНА ………………………………………………………..

1. Теоретична частина ………………………………………………….

1.1. Основи міждоменної маршрутизації …………………………….

1.1.1. Огляд маршрутизаторів і схем маршрутизації …………

1.1.2. Приклад простої маршрутизації …………………………

1.2. Концепції протоколів маршрутизації …………………………..…

1.2.1 Дистанційно-векторні протоколи маршрутизації ……….

1.2.2. Протоколи маршрутизації на основі аналіза стану каналу ………………………………………………………

2.1. Протокол граничного шлюзу Border Gateway Protocol версії 4 …

2.1.1. Алгоритм роботи BGP …………………………………….

2.1.2. Формат заголовка повідомлення протоколу BGP ……….

2.1.3. Взаємодія з сусідніми BGP – вузлами ……………………

2.1.4. Модель кінцевих станів …………………………………...

2.1.5. Атрибути маршруту ……………………………………….

3. Експериментальна частина ………………………………………….

3.1. Налаштування маршрутизації протоколу BGP …………………..

3.1.1 Основні команди для налаштування BGP на маршрутизаторах CISCO …………………………………

3.1.2 Команди для перевірки роботи протоколу BGP …………

ВИСНОВКИ ……………………………………………………………………

СПИСОК ЛІТЕРАТУРИ ………………………………………………………

ДОДАТКИ ……………………………………………………………………..

СПИСОК УМОВНИХ ПОЗНАЧЕНЬ, ТЕРМІНІВ, СКОРОЧЕНЬ

AS – автономна система.

BGP (Border Gateway Protocol) - протокол граничного шлюзу.

FSM (finite state machine) - модель кінцевих станів.

IOS – операційна система на маршрутизаторах фірми Cisco.

IP (Internet protocol) – Інтернет протокол.

LAN (Local Area Network) – Локальна мережа

Neighbors (або peers) – будь-які два маршрутизатори, між якими встановлене tcp з’єднання для обміну інформацією про маршрутизацію.

NLRI (Network Layer ReachabilityInformation ) – інформація мережевого рівня про доступність мережі.

OSI (Open Systems Interconnection Reference Model) - модель взаємодії відкритих систем.

Remote router ID - значення головного IP адресу peer маршрутизатора (або його головного loopback iface'а).

RID (Router ID) - ідентифікатор маршрутизатора.

TCP (Transmission Control Protocol) - Протокол керування передачею.

CIDR (Classless Interdomain Routing) - механізм підтримки безкласової міждоменної маршрутизації


ВСТУП

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

а) при використанні локальними комп'ютерними мережами (LAN) спільного середовища передачі при збільшенні числа підключених комп'ютерів збільшується кількість колізій при обміні інформацією (розширення домену колізій);

б) виникає необхідність об'єднання географічно віддалених комп'ютерних мереж;

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

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

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

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

Маршрутизація — процес визначення маршруту прямування інформації між мережами.

Най простіший спосіб маршрутизації – це статична маршрутизація. Але тут є багато мінусів:
  • Дуже погане масштабування;
  • Низька стійкість до пошкоджень ліній зв'язку (особливо, в ситуаціях, коли обрив відбувається між пристроями другого рівня і порт маршрутизатора не отримує статус down);
  • Відсутність динамічного балансування навантаження;
  • Необхідність у веденні окремої документації до маршрутів, проблема синхронізації документації і реальних маршрутів.

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

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

Отже, метою цієї курсової роботи є вивчення принципів динамічної маршрутизації в мережі Internet. З’ясування місця та ролі протоколів маршрутизації зовнішнього шлюзу. Дослідження ефективності роботи проколу маршрутизації BGPv4. Розроблення методичного матеріалу для лабораторної роботи з курсу телекомунікаційні комп’ютерні мережі для студентів 4-го курсу, напряму телекомунікації із використанням реалізації IOS Cisco.


ОСНОВНА ЧАСТИНА

1. Теоретична частина

1.1. Основи міждоменної маршрутизації

Мережа Інтернет є об’єднання автономних систем (autonomous systems), які ділять між собою зони адміністративної відповідальності і визначають для різних організацій правила маршрутизації. Автономні системи створюються на основі маршрутизаторів, які можуть працювати з протоколами внутрішнього шлюзу Interior Gateway Protocols (IGP), такими як: протокол інформації про маршрути Routing Information Protocol (RIP), розширений протокол внутрішнього шлюзу Enhanced Interior Gateway Protocol (EIGRP), протокол переважного вибору найкоротшого шляху Open Shortest Path First (OSPF) і протокол обміну маршрутною інформацією між проміжними системами Intermediate System-to-Intermediate System (IS-IS). Всі ці протоколи і граничні з ними взаємодіють за допомогою протоколу зовнішнього шлюзу Exterior Gateway Protocol (EGP). В даний час стандартом для мережі Internet є протокол граничного шлюзу версії 4 (Border Gateway Protocol Version 4 — BGP-4), описаний в RFC 17711 [1].


1.1.1. Огляд маршрутизаторів і схем маршрутизації

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

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

2. Маршрутизатори використовують інформацію про маршрути для заповнення своїх таблиць маршрутів, які пов'язані з відповідним протоколом маршрутизації.

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

4. Маршрутизатори взаємодіють при передачі трафіку з наступними найближчими пристроями (next-hop devices), що володіють адресою канального рівня, і з локальними інтерфейсами, які використовуються для пересилки пакетів в пункти призначення. Зверніть увагу, що як наступний найближчий пристрій може виступати ще один маршрутизатор і навіть просто видалений вузол, якому призначений пакет.

5. Інформація про пересилку для наступних найближчих пристроїв (адреса канального рівня і витікаючий інтерфейс) поміщається на маршрутизаторі в табліцю маршрутів пересилки (forwarding table).

6. Коли маршрутизатор приймає пакет, він аналізує заголовок пакету і виділяє адресу одержувача.

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

8. Крім того, маршрутизатор виконує всі необхідні додаткові функції (такі як зменшення значення "Часу життя" IP TTL і управління параметрами типу сервісу IP TOS) і потім пересилає пакет на відповідний пристрій.

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

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


1.1.2. Приклад простої маршрутизації

На рис. 1.1(див. Додаток А) представлено три маршрутизатори — RTA, RTB і RTC, об'єднуючі три локальні обчислювальні мережі, — 192.10.1.0, 192.10.5.0 і 192.10.6.0 за допомогою послідовних з'єднань. Кожне послідовне з'єднання має власна мережева адреса, тобто в результаті виходять три додаткові мережі — 192.10.2.0, 192.10.3.0 і 192.10.4.0. Кожна мережа має свою метрику, яка показує рівень складності службових операцій (вага) при передачі трафіку по певному каналу. Так, наприклад, з'єднання між RTA і RTB має вагу 2000, що набагато вище за вагу з'єднання між RTA і RTC, рівного 60. Насправді з'єднання між RTA і RTB може бути організоване на швидкості 56 Кбит/с з істотнішими затримками, ніж цифровий канал типа Т1 між RTA і RTC і між RTC і RTB.

Маршрутизатори RTA, RTB і RTC за допомогою одного з протоколів IGP обмінюються мережевою інформацією і будують відповідно до неї свої таблиці маршрутів. На рис. 1.1(див. Додаток А) представлені приклади таблиці маршрутів на маршрутизаторі RTA для двох різних випадків. В одному випадку маршрутизатори обмінюються інформацією про маршрути по протоколу RIP, а в іншому —с допомогою протоколу OSPF.

Як приклад того, як трафік переміщається між кінцевими станціями, розглянемо такий випадок. Припустим, що хост 192.10.1.2 спробував передати пакет на хост 192.10.6.2. При цьому йому доведеться використовувати маршрут, вручну встановлений за умовчанням, і переслати пакет спочатку на маршрутизатор RTA. Далі RTA проглядає свою таблицю маршрутів в пошуку мережі, до якої належить вузол одержувача, і з'ясовує, що мережа 192.10.6.0 доступна через наступний найближчий вузол 192.10.3.2 (RTC), сполучений послідовним каналом під номером 2 (S2). Маршрутизатор RTC, отримавши пакет, спробує знайти одержувача в своїй таблиці маршрутів (вона не показана на малюнку). Потім маршрутизатор RTC виявить, що хост одержувача безпосередньо підключений до його інтерфейсу Ethernet О (ЕО) і передасть пакет на хост 192. 10.6.2.

В даному прикладі маршрутизація відбувається однаково і при використанні протоколу RIP, і при роботі по протоколу OSPF. Проте слід пам'ятати, що RIP відноситься до дистанційно-векторних протоколів, а OSPF — до протоколів маршрутизації на основі аналізу стану каналу зв'язку. Для різних прикладів маршрутизації на базі схеми, представленої на рис. 1.1 (див. Додаток А), при застосуванні RIP і OSPF можуть бути отримані різні результати. Тепер цілком закономірно перейти до розгляду характеристик обох категорій протоколів IGP, історії їх розвитку і тенденцією до загального ускладнення системи маршрутизації [3].


1.2. Концепції протоколів маршрутизації

Більшість протоколів маршрутизації, використовуваних сьогодні, заснована на одному з двох алгоритмів розподіленої маршрутизації: аналіз стану каналу і дистанційний вектор.

1.2.1 Дистанційно-векторні протоколи маршрутизації

Дистанційно-векторні протоколи маршрутизації іноді іменуються протоколами Беллмана-Форда (Bellman-Ford) на честь винахідників алгоритму обчислень найкоротших маршрутов, які вперше описали механізм розподіленого застосування цього алгоритма. Термін дистанційний вектор (distance vector) виник з огляду на те, що в протоколі є вектор (список) відстаней (лічильник переприймань або інші параметри), який пов'язаний з кожним префіксом одержувача, що міститься в повідомленні про маршрут.

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

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

Початкові специфікації дистанційно-векторних протоколів, таких як RIP версії 1 (RIP-1), мали серйозні недоліки. Наприклад, підрахунок кількості переприймань був єдиною метрикою в RIP-1, яка використовувалася при виборі маршруту. Крім того, цей протокол мав декілька обмежень. Розглянемо, наприклад, маршрутні таблиці маршрутизатора RTA (рис.1.1 (див. Додаток А)). У одній з них представлена інформація про маршрути, зібрана протоколом RIP, а в іншій — протоколом OSPF (цей протокол маршрутизації на основі аналізу стану каналу обговорюватиметься в подальших розділах).

При використанні RIP-1 маршрутизатор RTA вибере пряме з'єднання між RTA і RTB, щоб досягти мережі 192.10.5.0. Маршрутизатор RTA вибирає це з'єднання тому, що при безпосередньому з'єднанні для того, щоб досягти заданої мережі, використовується лише одне переприймання через вузол RTB, проти двох переприймань при виборі маршруту через вузли RTC і RTB. Проте маршрутизатор RTA "знає" про те, що канал RTA RTB має меншу продуктивність і великий час затримки, а канал RTC-RTB забезпечить вища якість обслуговування.

З іншого боку, при використанні протоколу OSPF і метрик при виборі маршруту, крім підрахунку кількості переприймань, маршрутизатор RTA виявить, що шлях до маршрутизатора RTB через RTC (вага: 60 + 60 = 120; 2 переприймання) є більш оптимальним, ніж прямий шлях (вага: 2000; 1 переприймання).

Ще при підрахунку переприймань слід враховувати обмеження, що накладаються на кількість переприймань, тобто їх не може бути нескінченна множина. У дистанційно-векторних протоколах (наприклад, в RIP-1) кількість переприймань обмежена, як правило, числом 15. При перевищенні цієї межі вузол вважається недоступним по заданому маршруту. Таким чином, розповсюдження інформації про маршрути у великих мережах також викликало певні проблеми (у тих з них, де налічувалося більше 15 вузлів на маршрут). Залежність від кількості переприймань — одна з визначальних характеристик дистанційно-векторних протоколів, хоча новіші протоколи цієї категорії (RIP-2 і EIGRP) не такі строгі.

Ще один недолік — спосіб обміну маршрутною інформацією. Для традиційних дистанційно-векторних протоколів в даний час застосовується наступна концепція: маршрутизатори ведуть обмін всіма IP-адресами, які можуть бути досягнуті при періодичному обміні даними за допомогою широкомовних анонсів дистанційних векторів. Ці широкомовні повідомлення розсилаються згідно "таймеру оновлень" (refresh timer), встановленому для кожного повідомлення. Таким чином, якщо закінчується термін роботи "таймера оновлень" і при цьому поступає нова маршрутна інформація, що вимагає пересилки сусідам, цей таймер скидається, і маршрутна інформація не пересилається до тих пір, поки термін роботи таймера знову не закінчиться. Тепер розглянемо, щоб відбулося, якби з'єднання або певний маршрут раптом стали недоступні з яких-небудь причин відразу після оновлення маршрутів. Розповсюдження маршрутної інформації з відомостями про неробочий маршрут було б затримане на якийсь час до закінчення терміну роботи "таймера оновлення", отже, виникло б значне уповільнення при оновленні маршрутної інформації.

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

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

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

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

Ще один серйозний недолік дистанційно-векторних протоколів першого покоління — їх класова природа і відсутність повноцінної підтримки VLSM і CIDR. При оновленні маршрутної інформації ці дистанційно-векторні протоколи не передають відомості про мережеві маски і, отже, не можуть підтримувати ці технології. У протоколі RIP-1 маршрутизатор, що приймає оновлення маршрутів через певний інтерфейс, підставлятиме в цю посилку свою локальну маску підмережі. Протокол IGRP робить те ж саме, що і RIP-1, але він, крім того, прив'язується до мережевих масок мереж класу А, В і С, якщо частина переданої мережевої адреси не відповідає локальній мережевій адресі. Все це приводить до певних утруднень (в тому випадку, якщо інтерфейс належить мережі, яка розбита на підмережі за допомогою масок змінної довжини) і неправильної інтерпретації оновлень маршрутів, що приймаються. У новітніх дистанційно-векторних протоколах, таких як RIP-2 і EIGRP, вказані недоліки усунені.

З метою виправлення недоліків старих дистанційно-векторних протоколів маршрутизації було розроблено декілька їх модифікацій. Так, наприклад, протоколи RIP-2 і EIGRP вже підтримують роботу з VLSM і CIDR. До того ж протоколи IGRP і EIGRP здатні сприймати складні метрики, які використовуються для представлення характеристик, з'єднань складових маршрут (таких як смуга пропускання, поточне навантаження, затримки, розмір передаваного блоку (MTU) і т.д.), за допомогою яких можна обчислити більш оптимальний маршрут, ніж при простому підрахунку числа переприймань.

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

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


1.2.2. Протоколи маршрутизації на основі аналіза стану каналу

Протоколи маршрутизації на основі аналізу стану каналу (link-state routing protocols), такі як протокол першого найкоротшого відкритого маршруту Open Shortest Path First (OSPF) 4 і протокол обміну даними між проміжними системами Intermediate Sys-tem-to-Intermediate System (IS-IS) 5, використовують в роботі модель розподілених баз даних і вважаються складнішими протоколами маршрутизації. Протоколи з аналізом стану каналу працюють на основі обміну між маршрутизаторами спеціальними повідомленнями, які називаються звітами про стан каналу (link states). У цих звітах міститься інформація про з'єднання і вузли домена маршрутизації. Це означає, що на маршрутизаторах, де запущені протоколи аналізу стану каналу, не проводиться обмін маршрутними таблицями, як це робиться в дистанційно-векторних протоколах. Натомість маршрутизатори обмінюються інформацією про найближчих сусідів і про мережі, а також відомостями про метрику для кожного свого з'єднання.

Один із способів розгляду роботи протоколів маршрутизації на основі аналізу стану каналу дуже схожий на складання картинки-головоломки (паззла). Кожен маршрутизатор в мережі генерує один з елементів головоломки (звіт про стан каналу), де описується його стан і спосіб з'єднання з іншими елементами головоломки. Крім того, для з'єднання кожного елементу головоломки він надає список відповідних ним метрик. Елемент головоломки, який представляє сам маршрутизатор, потім розсилається по всій мережі від одного маршрутизатора до іншого до тих пір, поки всі вузли в домені не отримають його копію. Після завершення цієї процедури всі маршрутизатори в мережі матимуть копії кожного елементу головоломки і зберігатимуть їх в так званій базі даних стану каналів (link-state database). Далі маршрутизатори автономно збирають головоломку, внаслідок чого на кожному з них зберігаються ідентичні копії всіх маршрутизаторів в мережі.

Потім, застосовуючи алгоритм найкоротшого шляху (shortest path first — SPF), який відоміший як алгоритм Дейкстра, маршрутизатори обчислюють дерево найкоротших маршрутів до кожного віддаленого вузла, поміщаючи себе в корінь цього дерева.

Нижче перераховані переваги протоколів аналізу стану каналу.
  • Не ведеться підрахунок кількості переприймань. Відсутні які-небудь обмеження на кількість переприймань, складових маршруту. Протоколи аналіза стану каналу працюють на основі аналізу метрики каналу, а не подрахунку кількості переприймань. Для того, щоб переконатися в тому, що ці протоколи не залежать від підрахунку числа переприймань, звернемося до таблиць маршрутів для маршрутизатора RTA, представленим на рис. 4.1. У разі застосування протоколу OSPF, маршрутизатор RTA для того, щоб досягти маршрутизатора RTB, підбирає оптимальний маршрут на основі аналізу вагових коефіцієнтів різних з'єднань. У його таблиці маршрутів наступним вузлом на шляху в мережу 192.10.5.0 (RTB) значиться вузол 192.10.3.2 (RTC). Це корінним чином відрізняється від роботи по протоколу RIP, при якому вибирається неоптимальний маршрут.
    • Надання відомостей про смугу пропускання. Смуга пропускання каналу і затримки в ньому можуть бути (уручну або динамічно) враховані при підрахунку коротшого маршруту до заданого вузла. Це дозволяє збалансувати навантаження на канал краще, ніж при підрахунку переприймань.
    • Краща конвергенція. Зміни в каналі і на вузлі вмить розповсюджуються по всьому домену за допомогою звітів про стан каналу. Всі маршрутизатори в домені постійно оновлюватимуть свої таблиці маршрутів.
    • Підтримка VLSM і CIDR. Протоколи аналізу стану каналу дозволяють вести обмін інформацією про мережеві маски як частину інформаційних елементів, що пересилаються в домені. В результаті мережі з масками змінної довжини можуть легко розпізнаватися і маршрутизуватись.
    • Покращенна ієрархічна структура. Тоді як мережі з дистанційно-векторними протоколами є плоскими, протоколи аналізу стану канала забезпечують механізми для розбиття домена на рівні або області. Ієрархічна структура мережі дозволяє краще виявляти нестабільні ділянки.

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

Організовуючи внутрішню маршрутизацію між автономними системами (AS), більшість великих сервіс-провайдерів використовують протоколи аналізу стану каналу через їх здібність до швидкої конвергенції. Найчастіше з протоколів аналізу стану каналу застосовуються протоколи OSPF і IS-IS.

Багато провайдерів, які вже давно присутні на ринку, як протокол IGP вибрали для себе протокол IS-IS, а молодші провайдери використовують OSPF або також IS-IS. Спочатку в старих мережах частіше застосовувався протокол IS-IS, оскільки уряд США вимагав підтримки стандартів ISP CLNP в тих мережах, з якими полягали федеральні контракти. (Слід звернути вашу увагу на те, що протокол IS-IS здатний передавати інформацію як рівня CLNP, так і мережевого рівня IP, тоді як протокол OSPF розрахований для роботи тільки по протоколу IP). Проте якщо звернутися до історії Internet, основним "керівним чинником" при виборі протоколів маршрутизації перші провайдери вибрали стабільнішу реалізацію протоколу IS-IS, на відміну від OSPF, що тільки зароджувався. Очевидно, що стабільність протоколу при виборі ЮР мала для провайдерів вирішальне значення.

Сьогодні в мережах провайдерів широко використовуються обидва протоколи — і IS-IS, і OSPF. Завершеність і стабільність IS-IS з'явилася результатом того, що він успішно використовується в великих мережах і продовжує застосовуватися в розгортаних сьогодні мережах [2].

2.1. Протокол граничного шлюзу Border Gateway Protocol версії 4

Протокол граничного шлюзу Border Gateway Protocol (BGP) зазнав декілька змін з моменту виходу його першої версії BGP - 1 в 1989 році. Повсюдне впровадження BGP - 4 почалося в 1993 році. Це перша з версій BGP, в якій з'явилися можливості агрегації (об'єднання), що дозволило реалізувати безкласову міждоменну| маршрутизацію (classless interdomain routing - CIDR), і забезпечити підтримку супермереж [2].

Протокол BGP не пред'являє ніяких вимог до топології мережі. Маршрутизатори які належать до однієї AS обмінюються BGP update'ами по Internal BGP (IBGP); маршрутизатори які належать до різних AS і також обмінюються BGP update'ами, працюють по External BGP (EBGP). Команди для конфігурації IBGP і EBGP однакові [4].



На рис.2.1. показана різниця між EBGP і IBGP

2.1.1. Алгоритм роботи BGP

Протокол BGP являється протоколом вектора маршруту і використовується для обміну маршрутною інформацією між AS. Термін вектор маршруту (path vector) походить з самого принципу дії BGP : маршрутна інформація містить послідовності номерів AS, через які пройшов пакет із заданим префіксом мережі. Маршрутна інформація, пов'язана з префіксом, використовується для запобігання утворення петель в маршрутах.

Як транспортний протокол в BGP використовується протокол TCP (порт 179). Таким чином уся надійність доставки (включаючи повторну передачу) покладається на протокол TCP і не вимагає окремої реалізації в самому BGP, що природно спрощує механізми надійності в BGP.

Маршрутизатори, які працюють з протоколом BGP, часто називають спікерами BGP (BGP speakers). Два спікери BGP, які утворюють TCP – з’єднання| один з одним для обміну маршрутною інформацією, називають сусідніми (neighbors) або взаємодіючими (peers). Взаємодіючі маршрутизатори спочатку обмінюються відкритими повідомленнями для того, щоб визначити параметри з'єднання. Ці повідомлення використовуються для узгодження параметрів, таких як номер версії BGP та ін.

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

На початку сеансу BGP між декількома спікерами BGP ведеться обмін усіма маршрутами, які можуть далі використовуватися в роботі по протоколу BGP (Рис.2.2). Після того, як з'єднання встановлене і проведений початковий обмін маршрутами, по мережі розсилається лише інформація про нові маршрути - так звані інкрементні оновлення (incremental updates). Застосування інкрементних оновлень, в порівнянні з періодичним оновленням маршрутів, яке використовувалося в інших протоколах, таких як EGP, дозволило багаторазово збільшити продуктивність центральних процесорів на маршрутизаторах і розвантажити смугу пропускання.



Рис. 2.2. Обмін оновленнями маршрутної інформації

Згідно з протоколом BGP, пара маршрутизаторів повідомляється про маршрути і зміни в них за допомогою повідомлення UPDATE. Повідомлення UPDATE, окрім іншої корисної інформації, містить список записів типу <довжина, префікс> (), що вказують на список вузлів, на які можна доставити трафік через спікер BGP. У повідомлення UPDATE також включені атрибути маршруту. До них відносяться: міра переваги вибору певного маршруту і список AS, через яких пролягає маршрут.



Рис. 2.3. Маршрут N1 виходить з ладу. Посилається часткове оновлення

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

На Рис. 2.3 показана система в урівноваженому стані (steady state) : якщо немає ніяких змін в структурі маршрутів, то маршрутизатори обмінюються тільки пакетами KEEPALIVE.

Повідомлення KEEPALIVE періодично посилаються між сусідніми маршрутизаторами BGP, щоб переконатися, що з'єднання знаходиться у нормальному стані. Пакети KEEPALIVE (завдовжки 19 байт кожен) не створюють практично ніякого навантаження на процесор маршрутизатора і смугу пропускання, оскільки їм вимагається дуже незначна смуга пропускання (один 152-бітовий пакет кожні 60 секунд, тобто близько 2,5 байт/с).

У протоколі BGP враховується номер версії таблиці маршрутів, щоб відстежувати зміни маршрутів. Якщо до таблиці маршрутів вносяться які-небудь зміни, то BGP автоматично збільшує номер версії таблиці. Швидко зростаючі номери версії таблиці зазвичай вказують на те, що в мережі є нестабільно працююча ділянка (хоча це досить звичайна ситуація для мереж великих провайдерів Internet). Нестабільність мереж, підключених до Internet по всьому світу, призводить до зростання номерів версій таблиць маршрутів на кожному спікерові BGP, де є відомості про усі маршрутні таблиці мережі Internet. Для зниження дії цих неоднорідностей| в Internet були розроблені механізми комутації маршрутів і інші заходи [2].


2.1.2. Формат заголовка повідомлення протоколу BGP

Форматом заголовка повідомлення в BGP є поле маркера завдовжки 16 байт, за яким йде поле довжини (2 байти) і поле типу (1 байт). На Рис. 2.5 представлений формат заголовка повідомлення протоколу BGP.



Рис. 2.5. Формат заголовка повідомлення BGP


Залежно від типу повідомлення в повідомленні протоколу BGP за заголовком може слідувати або не слідувати блок даних. Так, наприклад, повідомлення KEEPALIVE складаються тільки із заголовка і ніяких даних не передають.

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

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

Поле довжини розміром 2 байти використовується для відображення повної довжини повідомлення BGP, включаючи заголовок. Найменша довжина повідомлення BGP складає 19 байт (16+2+1), а найбільша - 4096 байт.

Поле типу розміром 1 байт визначає тип повідомлення. Можливі наступні значення:
  • OPEN (Відкриття з'єднання)
  • UPDATE (Оновлення маршрутної інформації)
  • NOTIFICATION (Повідомлення про помилку)
  • KEEPALIVE (Перевірка стану з'єднання)

Далі ми розглянемо призначення і формат кожного типу повідомлень детальніше [4].


2.1.3. Взаємодія з сусідніми BGP - вузлами|

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

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

На Рис. 2.6 представлений формат повідомлення OPEN.



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

Розглянемо призначення кожного з полів повідомлення OPEN.

Версія (Version) - ціле число завдовжки 1 байт, яке відображує номер версії протоколу BGP, такий як BGP - 3 або BGP - 4. Протягом фази переговорів з сусідами сторони, що беруть участь в BGP - сеансі, повинні погоджувати номер версії протоколу BGP. Спочатку сторони намагаються "домовитися" про найвищу версію, яку вони можуть підтримувати. На цьому етапі сторони можуть скидати сеанс BGP і проводити повторні переговори до тих пір, поки не погоджують, за якою версією BGP проводитиметься сеанс. Для прискорення процесу переговорів компанія Cisco Systems ввела спеціальний параметр, в якому визначається версія протоколу. Як правило, номер версії встановлюється статично, коли версії BGP сторін вже відомі, хоча більшість реалізацій за умовчанням починають переговори з BGP - 4.

Автономна система (My autonomous system) - поле розміром 2 байти, де вказується номер AS спікера BGP.

Таймер утримання (Hold timer). У полі "Таймер утримання", що має в довжину 2байта, включаються цілі числа, що вказують максимальний інтервал часу між прийомом повідомлень KEEPALIVE і UPDATE. По суті таймер утримання є лічильником, величина якого збільшуються від 0 дозначения часу утримання. Прийом повідомлень типу KEEPALIVE або UPDATE скидає таймер в 0. Якщо час утримання для заданого сусіднього вузла перевищений, робиться висновок про недоступність такого вузла.

Маршрутизатор, що підтримує роботу по BGP, під час переговорів зі своїм сусідом підбирає для нього час утримання. Вибір часу утримання між сусідніми маршрутизаторами робиться на основі найменшого часу утримання. Таймер утримання може бути рівним 0, але тоді ні він, ні таймер стану з'єднання (KEEPALIVE timer) ніколи не скидатимуться. Іншими словами, обидва таймери завжди матимуть значення 0, отже, з'єднання вважатиметься активним. Якщо таймер не встановлений в 0, то за умовчанням мінімальне значення часу очікування для таймера утримання 3 секунди.

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

Ідентифікатор BGP (BGP Identifier) є чотирьохбайтовим цілим числом, яке відображує значення ідентифікатора BGP вузла відправника. В маршрутизаторах компанії Cisco це значення зазвичай відповідає ідентифікатору маршрутизатора (Router ID - RID), який обчислюється з найвищого IP - адреса на маршрутизаторі або з найвищої адреси зворотної петлі на початку сеансу BGP. Адреса зворотної петлі – це IP – адреса программно-віртуального інтерфейсу, який вважається завжди активним, незалежно від стану фізичного інтерфейсу на маршрутизаторі.

Довжина поля необов'язкових параметрів (Optional Parameter Length - Opt ParmLen). Це однобайтовий цілочисельний параметр, який відображує повну довжину в байтах поля "необов'язкові параметри". Якщо довжина дорівнює 0, то необов'язкові параметри відсутні.

Необов'язкові параметри (Optional Parameters). Це поле змінної довжини, в якому відображується список необов'язкових параметрів, використовуваних протоколом BGP при веденні переговорів між сусідніми вузлами. У цьому полі можуть відображуватися параметри <Параметр типу, параметр довжини, параметр значення> (
) завдовжки по одному байту і змінної довжини, відповідно. Прикладом необов'язкових параметрів може служити параметр інформації про аутентифікацію, який застосовується для аутентифікації сторін в сеансі BGP [2].

2.1.4. Модель кінцевих станів

Процес переговорів між BGP - сусідами| до повної установки з'єднання відбувається у декілька етапів. На Рис. 2.7 (див. Додаток А) приведена спрощена модель кінцевих станів (finite state machine - FSM), за допомогою якої можна розглядати основні події, в результаті яких генеруються повідомлення від одного вузла іншому і реакцію на них іншої сторони.

Нижче приведений список основних станів моделі FSM.

1. Очікування (Idle). Це перший стан, в якому знаходяться системи перед встановленням з'єднання. У протоколі BGP очікується настання події "Пуск" (Start), ініційованого оператором або самою BGP - системою|. Адміністратор викликає настання події "Пуск" шляхом встановлення BGP - сеансу| маршрутизатором або за допомогою скидання існуючого BGP - сеансу|. Після настання події "Пуск" BGP - система| ініціалізує свої ресурси, скидає таймер повторних спроб установки з'єднання (ConnectRetry timer), встановлює транспортне з'єднання по протоколу TCP і знаходиться в режимі очікування з'єднання з віддаленою стороною. Потім BGP - система| переходить в стан ведення зв'язку. У разі появи яких-небудь помилок BGP - система| повертається в стан очікування.

2. Зв'язок (Connect). У цьому стані BGP - система| чекає повного встановления з’єднання| транспортним протоколом. Якщо TCP - з’єднання | встановлене успішно, то система переходжуватиме в стан пересилки повідомлення OPEN(тобто на цьому етапі видаленій системі посилається повідомлення про відкриття з'єднання OPEN). Якщо витікає час, заданий таймером повторних спроб| ConnectRetry timer, то система залишається в стані "Зв'язок", таймер скидається|, і повторно починається установка з'єднання транспортним протоколом. При настанні яких-небудь інших подій, ініційованих оператором або самою системою, BGP - система| повертається в стан очікування.

3. Система активна (Active). На цьому етапі BGP - система| намагається досягти видаленої системи шляхом відкриття з'єднання транспортного протоколу. Якщо встановлено транспортне з'єднання, то система переходитиме в стан пересилки повідомлення OPEN (OpenSent), при якому генерується і посилається повідомлення OPEN. Якщо витікає інтервал часу, заданий таймером повторних| спроб, то система перезапускає таймер і повертається в стан "Зв'язок". При цьому BGP - система| продовжує чекати появи вхідного з’єднання| від віддаленого вузла. При настанні ще яких-небудь подій система може повернутися і в стан очікування. Такою подією може бути подія| "Зупинка" (Stop), ініційоване самою системою або оператором.

Якщо система знаходиться в стані, що коливається між станами "Зв'язок" і "Система активна", - це ознака того, що при установці транспортного TCP – з’єднання| щось відбувається неправильно. Причинами такого стану може бути велика кількість повторних передач пакетів по протоколу TCP або неможливість сусіднього вузла розпізнати IP - адресу| віддаленої сторони.

4. Стан пересилки повідомлення OPEN (OpenSent). У цьому стані BGP - система| чекає отримання повідомлення OPEN від віддаленої сторони. Отримане повідомлення перевіряється на цілісність. Якщо в нім знаходяться помилки, такі як| спотворений номер версії протоколу або неприпустимий номер AS, система відправляє| віддаленій стороні повідомлення про помилку NOTIFICATION і повертається в стан очікування. Якщо помилок не виявлено, BGP – система| починає посилати повідомлення KEEPALIVE і скидає свій таймер перевірки стану каналу (KEEPALIVE timer) в 0. З цієї миті обговорюється також час| утримання і встановлюється найменше його значення з пов'язаних систем. Якщо узгоджений час утримання дорівнює 0, то таймер утримання (Holdtimer) і таймер перевірки стану (KEEPALIVE timer) не перезапускаються.

В стані пересилки повідомлення OPEN BGP - система| шляхом порівняння власного номера AS з номером AS видаленої системи з'ясовує, чи належить маршрутизатор, з яким встановлений зв'язок, до тієї ж автономної системи (внутрішній Internal BGP) або це різні AS (зовнішній External BGP).

При розриві TCP - з’єднання система повертається в стан "Система активна". При виникненні інших подій, таких як витікання часу, заданого таймером утримання, BGP - система| посилає повідомлення NOTIFICATION, в якому знаходиться код помилки, і повертається в стан очікування. Крім того, у відповідь на подію "STOP", ініційоване системою або оператором, BGP - система| також переходить в стан очікування.

5. Підтвердження отримання повідомлення OPEN (OpenConfirm). У цьому стані BGP - система| чекає надходження повідомлення KEEPALIVE. Прийнявши таке повідомлення, система переходить в наступний стан "Зв'язок встановлено" (Established) і переговори з сусіднім вузлом завершуються. Прийнявши повідомлення KEEPALIVE, система перезапускає свій таймер утримання (за умови, що обумовлене значення часу очікування не дорівнює 0). Якщо ж система отримує повідомлення NOTIFICATION, то вона повертається в стан очікування. Система періодично посилає іншій стороні повідомлення KEEPALIVE з частотою, встановленої таймером перевірки стану каналу. У разі будь-якого розриву транспортного з'єднання або у відповідь на подію "Зупинка", ініційоване самою системою або оператором, система також повертається в стан очікування. При настанні якої-небудь іншої події система посилає повідомлення NOTIFICATION, що містить код помилки моделі кінцевих станів FSM, і повертається в стан очікування.

6. Зв'язок встановлений (Established). Це останній стан, в якому знаходяться сусідні вузли при веденні переговорів. У цьому стані BGP - система| починає обмін пакетами UPDATE зі своїми сусідами. Припустимо, що таймер утримання не дорівнює 0. Тоді він перезапускатиметься кожного разу при прийомі повідомлення UPDATE або KEEPALIVE. Якщо ж система отримує повідомлення NOTIFICATION (у разі виникнення якої-небудь помилки), то вона повертається в стан очікування.

Повідомлення UPDATE також перевіряються на наявність помилок, таких як бракуючі атрибути, дубльовані атрибути і інші. При виявленні помилки взаємодіючій стороні висилається повідомлення NOTIFICATION, і система переводиться в стан очікування. У стан очікування система повертається також після закінчення часу, заданого таймером утримання, при отриманні повідомлення про розрив транспортного з'єднання або при настанні події "Зупинка", прийнятого від іншого вузла або такого, що наступило в результаті якої-небудь іншої події [2].


Повідомлення NOTIFICATION

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



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


Повідомлення NOTIFICATION складається з коду помилки (1 байт), додаткового коду помилки (1 байт) і поля даних змінної довжини.

Код помилки (Error code) визначає тип повідомлення про помилку, а додатковий код помилки (Error subcode) надає детальнішу інформацію про природу помилки. У полі даних (Data field) знаходяться відомості про помилку, такі як неправильний заголовок, заборонений номер AS і так далі. У таблиці. 2.1 (див. Додаток Б) приведений список можливих помилок і їх додаткові коди [2].


Повідомлення KEEPALIVE

Сторони, що беруть участь в сеансі зв'язку, періодично обмінюються повідомленнями типу KEEPALIVE для того, щоб визначити наявність каналу зв'язку і можливість досягнення по ньому видаленого вузла. Як вже відзначалося, час утримання визначає максимальний інтервал часу між успішним прийомом двох повідомлень типу KEEPALIVE або UPDATE. Повідомлення типу KEEPALIVE посилаються зазвичай з частотою, меншою часу, встановленого таймером утримання, на підставі чого робиться висновок про нормальну роботу сеансу. Рекомендований інтервал часу для посилки повідомлень KEEPALIVE - 1/3 від значення таймера утримання. Якщо ж таймер утримання встановлений в 0, то обмін повідомленнями KEEPALIVE не ведеться. Як ми вже говорили раніше, повідомлення типу KEEPALIVE є 19-байтовим заголовком протоколу BGP, без яких-небудь значень в полі даних. Повідомлення цього типу можуть подавлятися протягом передачі повідомлення UPDATE [2].


Повідомлення UPDATE і маршрутна інформація

Основу протоколу BGP складає концепція оновлень маршрутної інформації. Оновлення маршрутів несуть в собі усю необхідну інформацію, яка використовується в протоколі BGP для побудови мережі без петель маршрутизації. У повідомлення UPDATE, як правило, входять три основні блоки:
  • інформація мережевого рівня про доступність мережі (Network Layer ReachabilityInformation - NLRI);
  • атрибути маршруту;
  • недосяжні маршрути.

На Рис. 2.9 показані усі компоненти повідомлення UPDATE.



Рис. 2.9. Формат повідомлення UPDATE протоколу BGP


Блок NLRI відображує форму запису IP - префікса| маршруту до оголошуваної мережі. Список атрибутів маршруту дозволяє протоколу BGP виявляти петлі маршрутизації і надає йому додаткову гнучкість при визначенні локальних і глобальних правил маршрутизації. Як приклад атрибутів маршруту можна привести атрибут AS_PATH, за допомогою якого визначається послідовність номерів AS, що становлять маршрут до маршрутизатора BGP.

Наприклад, на Рис. 2.10 автономна система AS3 отримує повідомлення UPDATE від AS2, де вказується, що в мережу 10.10.1.0/24 (NLRI) можна потрапити через два проміжні вузли - AS2 і AS1. На основі цієї інформації система AS3 може направляти трафік в мережу 10.10.1.0/24 через транзитний вузол AS2 в пункт призначення, підключений до AS1.



Рис. 2.10. Приклад оновлення маршрутної інформації в BGP


Третя частина повідомлення UPDATE є списком маршрутів, які стали недійсними, або, згідно термінології, прийнятої в BGP, видаленими. З Рис. 2.10 видно, що якщо мережа 10.10.1.0/24 стає недосяжною або в інформацію про атрибути маршруту внесені які-небудь зміни, протокол BGP на усіх трьох AS може видалити маршрут і розіслати повідомлення UPDATE із списком нової інформації про атрибути або про неможливість потрапити по заявленому раніше маршруту в задану мережу [5].


Маршрути, що видаляються

Видалення маршрутів дозволяє створити список маршрутів, які більше не обслуговуються або з яких-небудь причин недоступні в даний момент. Ці маршрути слід вилучити (видалити) з маршрутних таблиць BGP. Маршрути, що видаляються, записуються в тому ж форматі, що і NLRI: IP - адрес| і число біт, використовуваних в нім, вважаючи ліворуч (Див. Рис. 2.11).



Рис. 2.11. Загальний вигляд поля маршрутів, що видаляються


Маршрути, що видаляються, також представляються у форматі <довжина, префикс>| Запис у формі <18, 192.213.128.0> вказує на те, що буде видалений маршрут до мережі 192.213.128.0 255.255.192.0 або у форматі CIDR - 192.213.128.0/18.

Поле довжини недосяжних маршрутів (Unfeasible Routes Length) в повідомленні UPDATE показує довжину в байтах усіх маршрутів, що видаляються. У одному повідомленні UPDATE може міститися список з декількох маршрутів, які будуть видалені, або жодного маршруту, що видаляється.

Якщо поле довжини недосяжних маршрутів заповнене нулями, то це означає, що немає жодного маршруту, що видаляється. З іншого боку, в повідомленні UPDATE можна оголошувати більш за один маршрут, кожен з яких можна описати за допомогою декількох атрибутів маршруту. Повідомлення UPDATE, що не містять інформації про NLRI або про атрибути маршрутів, використовуються тільки для повідомлення про маршрути, які виводяться з експлуатації (про маршрути, що видаляються) [5].

2.1.5. Атрибути маршруту

Атрибути маршруту в BGP - це набір параметрів, використовуваних для охарактеризування| маршрутної інформації, такої як інформація про шлях дотримання, міра переваги маршруту, значення змінної NEXT_HOP для маршруту і інформації про можливу агрегацію. Усі ці параметри використовуються при фільтрації і виборі маршрутів на базі протоколу BGP. Кожне повідомлення типу UPDATE включає послідовність атрибутів маршруту змінної довжини. Атрибут маршруту має три складові і записується у формі <тип атрибуту, довжина атрибуту, значення атрибуту>. Тип атрибуту - це двобайтове поле, що складається з однобайтової мітки атрибуту і однобайтового коду типу атрибуту. На Рис.2.12 представлений загальний вигляд поля типу атрибутів маршруту.



Рис. 2.12. Формат поля типу атрибутів маршруту


Атрибути маршруту підрозділяються на чотири категорії: обов'язкові загальновідомі; загальновідомі, надані на власний розсуд; необов'язкові транзитивні і необов'язкові не транзитивні. Приналежність до однієї з цих категорій визначається першими двома бітами в полі флагів атрибуту (Atribute Flags).
  • Перший біт в полі прапорів атрибуту (біт 0) вказує на те, чи є атрибут загальновідомим (0) або необов'язковим (1).
  • Другий біт (біт 1) вказує, чи є необов'язковий атрибут не транзитивним (0) або транзитивним (1). Загальновідомі атрибути завжди транзитні|, так що другий біт завжди встановлений в 1.
  • Третій біт (біт 2) показує, чи являється інформація, що міститься в необов'язковому транзитивному атрибуті, повною (0) або частковою (1).
  • У четвертому біті (біт 3) визначається довжина атрибуту - 1 байт (0) або 2 байти (1).
  • Молодші біти (з 4 по 7) в полі атрибуту прапора нині не використовуються і завжди встановлені в 0 [4].

3. Експериментальна частина

3.1. Налаштування маршрутизації протоколу BGP

3.1.1Основні команди для налаштування BGP на маршрутизаторах CISCO

Для ввімкнення процесу BGP на маршрутизаторі необхідно ввести в режимі конфігурації команду[6]:

Router(config)# router bgp [AS]

Наприклад:

Router (config)#router bgp 200

Після цього в таблицю маршрутизації необхідно внести інформацію про сусідні маршрутизатори:

Router (config-router)# neighbor [ip address] remote-as [AS]

Наприклад:

Router (config-router)#neighbor 10.0.0.2 remote-as 100

Також необхідно вказати мережі

Router (config-router)#network [network address] mask [mask]

Наприклад:

Router (config-router)#network 12.0.1.0 mask 255.255.255.0


3.1.2 Команди для перевірки роботи протоколу BGP:

show ip route команда для перевірки таблиці маршрутизації.

Наприклад:

Router#show ip route


Gateway of last resort is 10.0.0.1 to network 0.0.0.0


172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks

C 172.16.0.0/30 is directly connected, Serial0/0/1

B 172.16.1.0/24 [20/0] via 172.16.0.1, 00:16:34

10.0.0.0/30 is subnetted, 1 subnets

C 10.0.0.0 is directly connected, Serial0/0/0

C 192.168.0.0/24 is directly connected, Loopback0

12.0.0.0/24 is subnetted, 1 subnets

B 12.0.1.0 [20/0] via 10.0.0.1, 00:16:39

C 192.168.1.0/24 is directly connected, Loopback1


show ip bgp neighborsкоманда для перевірки того, чи працюють BGP peers.

Наприклад:

Router#show ip bgp neighbors

BGP neighbor is 172.16.0.1, remote AS 300, external link

Index 2, Offset 0, Mask 0x4

BGP version 4, remote router ID 172.16.1.1

BGP state = Established, table version = 5, up for 00:02:24

Last read 00:00:24, hold time is 180


Router#show ip bgp – команда для перевірки працездатності BGP на маршрутизаторі.

Наприклад:

Router #show ip bgp

BGP table version is 5, local router ID is 192.168.1.1

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

*> 12.0.1.0/24 10.0.0.1 0 0 200 i

*> 172.16.1.0/24 172.16.0.1 0 0 300 i

*> 192.168.0.0 0.0.0.0 0 32768 i

*> 192.168.1.0 0.0.0.0 0 32768 i


В ході виконання експерементальної частини була виконана лабораторна робота (див. Додаток В).

ВИСНОВКИ


В даній курсовій роботі було розглянуто:
  1. Принцип динамічної маршрутизації в мережі Internet.
  2. Ефективність роботи проколу маршрутизації BGPv4. І було зроблено такий висновок, що BGP, на відміну від інших протоколів динамічної маршрутизації, призначений для обміну інформацією про маршрути не між окремими маршрутизаторами, а між цілими автономними системами. Він не використовує технічні метрики, а здійснює вибір найкращого маршруту виходячи з правил, прийнятих в мережі. Основу протоколу BGP складає концепція оновлень маршрутної інформації. Оновлення маршрутів несуть в собі усю необхідну інформацію, яка використовується в протоколі BGP для побудови мережі без петель маршрутизації.
  3. А також було розроблено методичний матеріал для лабораторної роботи з курсу телекомунікаційні комп’ютерні мережі для студентів 4-го курсу, напряму телекомунікації із використанням реалізації IOS Cisco.



СПИСОК ЛІТЕРАТУРИ
  1. Создание маштабируемых сетей Cisco. : Пер. с англ. – М. : Издательский дом «Вильямс», 2004. С.768
  2. n.org.ua/article/bgp - BGP протокол (перевод на русский)
  3. .com/univercd/cc/td/doc/product/software/ios100/rpcg/66010.php">
  4. Принципы маршрутизации в Internet, 2-е издание. : Пер. с англ. М. : Издательский дом "Вильяме", 2001. — 448 с. : ил. —Парал. тит. англ.

ISBN 5-8459-0188-Х (рус.)
  1. CCNP BSCI Official Exam Certification Guide, Fourth Edition.: Brent D. Stewart, Clare Gough, Copyright © 2008 Cisco Systems, Inc. Cisco Press logo is a trademark of Cisco Systems, Inc. Published by:Cisco Press
  2. ссылка скрыта - Cisco IOS Command Line Interface Tutorial


Додаток А



Рис. 1.1. Механізм простої маршрутизації




Рис. 2.7. Модель кінцевих станів при переговорах по протоколу BGP між сусідніми вузлами

Додаток Б

Таблиця 2.1. Коди помилок протоколу BGP

Код помилки

Додатковий код помилки

1 – Помилка в заголовку

1 – З'єднання не синхронізоване повідомлення

2 – неправильна довжина повідомлення

3 – неправильний тип повідомлення

2 – Помилка в повідомленні OPEN

1 – Номер версії не підтримується

2 – неправильний номер AS взаємодіючого вузла

3 – неправильний ідентифікатор BGP

4 – необов'язковий параметр не підтримується

5 – Помилка аутентифікації

6 – неприйнятне значення таймера утримання

7 – Параметр не підтримується

3 – Помилка в повідомленні UPDATE

1 – Список атрибутів сформований неправильно

2 – Загальновідомий атрибут не розпізнаний

3 – Загальновідомий атрибут не знайдений

4 – Помилка в атрибуті Flags

5 – Помилка в атрибуті Length

6 – неправильний атрибут Origin

7 – Петливши маршрутизації між AS

8 – неправильний атрибут NEXTJHOP

9 – Помилка в необов'язковому атрибуті

10 – неправильне поле «Мережа»

11 – Помилка в атрибуті AS_PATH

4 – Закінчення роботи таймера утримання

Ні

5 – Помилка моделі кінцевих

станів (для помилок виявлених FSM)

Ні

6 – Останов (при інших серйозних помилках, окрім вищезгаданих)

Ні



Додаток В

Лабораторна робота

Предмет: Телекомунікаційні та комп’ютерні мережі