Лабораторна робота № 7

Конфігурування та дослідження протоколу ppp

Мета: Навичитись конфігурувати протоколу РРР засобами CISCO IOS, а також засвоїти шлях відлагодження та пошук несправностей у роботі PPP.

Основні теоретичні відомості

Наприкінці 1980 р. у мережі Internet почалось різко зростати кількість обчислювальних машин, що працювали на базі TCP/IP. Їх переважна частина була під’єднана до локальних мереж (LAN) різних типів, найпопулярнішою серед яких була технологія Ethernet. Велика частина інших обчислювальних машин з'єднувалися через глобальні мережі (WAN), такі як загальнодоступні мережі передачі даних (PDN) типу Х.25. Порівняно невелика кількість обчислювальних машин були підключені до каналів зв'язку (КЗ) з безпосереднім (двоточковим) з'єднанням (тобто до послідовних каналів зв'язку).

Як відомо, КЗ з безпосереднім з'єднанням належать до числа найстаріших методів передачі інформації, і майже кожна обчислювальна машина підтримує безпосередні з'єднання (наприклад, асинхронні інтерфейси RS-232-С зустрічаються фактично всюди). Однією з причин малої кількості каналів зв'язку IP з безпосереднім з'єднанням була відсутність стандартного протоколу формування пакета даних Internet. Протокол каналу зв'язку з безпосереднім з'єднанням Point-to-Point Protocol (PPP) і призначався для вирішення цієї проблеми.

Крім вирішення проблеми формування стандартних пакетів даних Internet IP в каналах з безпосереднім з'єднанням, РРР також повинен був вирішити інші проблеми, в тому числі присвоєння і керування адресами IP, асинхронне (старт/стоп) і синхронне біт-орієнтоване формування пакета даних, мультиплексування протоколу мережі, конфігурування КЗ, перевірка якості каналу зв'язку, виявлення помилок, узгодження адреси мережевого рівня та узгодження компресії інформації.

РРР вирішує ці питання шляхом забезпечення розширюваного протоколу управління каналом (Link Control Protocol, LCP) і сімейства протоколів управління мережею (Network Control Protocols, NCP), які дозволяють узгоджувати факультативні параметри конфігурації та різні можливості. Сьогодні PPP, крім IP, забезпечує також і інші протоколи, у тому числі IPX і DECnet.

Взагалі, протокол PPP містить три складові частини:

• Метод інкапсуляції дейтаграм під час передавання по послідовних комунікаційних каналах.

• Протокол LCP для встановлення, конфігурування і тестування інформаційних каналів

• Набір протоколів NCP для установки і конфігурування різних протоколів мережевого рівня.

Протокол управління каналом lcp

Протокол управління каналом (LCP - Link Control Protocol) є частиною PPP. Ідеологія NCP реалізована і в протоколі TCP. Кожен кадр PPP починається і завершується прапором 0x7E. За стартовим прапором-октетом міститься байт адреси, що завжди дорівнює 0xFF. Формат кадру PPP наведено на рис. 1. Кадр PPP може містити тільки ціле число байт. При інкапсуляції інших пакетів у PPP використовується біт-орієнтований протокол HDLC (High-level Data Link Control).

Рис. 1 – Формат кадра у протоколі PPP.

Поле „адреса” завжди містить байт 0xFF. Це вказує на те, що всі станції повинні прийняти цей кадр, і виключає необхідність виділення будь-яких спеціальних адрес. Байт керування завжди дорівнює 0x03, що вказує на ненумерований тип кадру. За замовчуванням кадри PPP передаються в режимі "без встановлення з'єднання". Якщо потрібна надійне доставлення, використовується версія, описана в RFC-1663. Двухоктетне поле „протокол” подібне по функції з полем „тип” у кадрі Ethernet і визначає те, як слід інтерпретувати інформаційне поле (табл. 1). Значення 0x0021 цього поля говорить про те, що подальше інформаційне поле містить у собі IP-дейтаграму. Поле „CRC” (Cyclic Redundancy Check) містить циклічну контрольну суму, призначену для виявлення помилок при транспортуванні PPP-кадру. Для визначення початку та кінця застосовуються прапори-обмежувачі кадру (0x7E). Ці байти не можуть бути присутніми в інформаційному полі. У синхронному режимі це завдання вирішується на апаратному рівні. При роботі в асинхронному режимі для цього використовується спеціальний ESC-символ, рівний 0x7D. Коли цей esc-символ зустрічається в інформаційному полі, шостий біт у наступному за ним байті інвертується. Так байт 0x7E буде перетворений у послідовність 0x7D, 0x5E, а байт 0x7D - у два байти 0x7D, 0x5D. Усі символи з кодами менше 0x20 також перетворяться в ESC-послідовності. Наприклад, 0x07 буде перетворений в 0x7D, 0x27. Такі дії потрібні оскільки керуючі символи можуть зробити непередбачені впливи на режим роботи драйверів або модемів, використовуваних у каналі. Протокол PPP на відміну від SLIP допускає мультипротокольне і динамічне визначення IP-адрес партнерів.

Таблиця 1 – Стандартизовані DLL-номери протоколів для PPP (поле протокол)

DLL-код протоколу (шестнадцітирічний)	Найменування протоколу
0001	Протокол заповнення (padding)
0003-001F	Зарезервовано
0021	IP-протокол
0023	Мережевий рівень OSI
0025	Xerox NS IDP
0027	Decnet фаза IV
0029	Appletalk
002B	Novell IPX
002D	Компресований TCP/IP протокол Ван Джекобсона
002F	Не компресований TCP/IP протокол Ван Джекобсона
0031	PDU мостів
0033	Потоковий протокол (ST-II)
0035	Banyan Vines
0039	Appletalk EDDP
003B	​​Appletalk Smartbuffered
003D	Multi-link
003F	Кадри Netbios
0041	Cisco Systems
0043	Ascom Timeplex
0047	Тимчасова локальна мережа DCA
0049	Транспортний протокол для послідовних даних (PPP-SDTP)
004B	SNA через 802.2
004D	SNA
004F	Стиснення заголовків IPv6
007D	Зарезервовано (Управл. ESC) [RFC1661]
00FD	перший варіант компресії
0201	Пакети відгуку 802.1d
0203	IBM BPDU базової маршрутизації
8021	Керуючий протокол Інтернету (IPCP)
8023	Керуючий протокол мережевого рівня OSI
8025	Керуючий протокол Xerox NS IDP
8027	Керуючий протокол Decnet фаза VI
8029	Керуючий протокол Appletalk
802B	Керуючий протокол Novell IPX
8031	Бридж NCP
8033	Потоковий керуючий протокол
8035	Керуючий протокол Banyan Vines
803D	Багатозв'язних керуючий протокол
803F	Керуючий протокол кадрів NetBIOS
8041	Керуючий протокол Cisco
8043	Ascom Timeplex
8045	Керуючий протокол Fujitsu LBLB
8047	Керуючий протокол віддалених локальних мереж DCA (RLNCP)
8049	Керуючий протокол передачі послідовних даних (PPP-SDCP)
	Керуючий протокол для передачі SNA поверх 802.2
804D	Керуючий протокол SNA
804F	Керуючий протокол стиснення заголовків IPv6
80FD	Керуючий протокол стиснення
C021	Канальний керуючий протокол
C023	Протокол аутентифікації паролів
C025	Повідомлення про стан каналу
C081	Керуючий протокол для роботи з контейнерами

Значення кодів поля протоколу від 0xxx до 3xxx ідентифікують протоколи мережевого рівня, а значення в інтервалі 8xxx - Bxxx говорять про те, що протокол відповідає NCP (Network Control Protocol). Коди з діапазону 4xxx - 7xxx використовуються для протоколів з низьким рівнем трафіку, а коди від Cxxx до Exxx відповідають керуючим протоколам (наприклад, LCP).

Протокол PPP при встановленні з'єднання передбачає процедуру аутентифікації, яка є опціонною (рис. 2.). Після переходу на мережевий рівень викликається NCP-протокол, який виконує необхідне конфігурування каналу.

Рис. 2 – Алгоритм встановлення з’єднання PPP

При виявлені несійної або з ініціативи клієнта система може спробувати встановити з'єднання. У разі успіху система переходить у фазу аутентіфікації. Якщо ж і фаза аутентіфікації завершується благополучно, система виконує підключення до Мережі (IP, IPX, Appletalk тощо), налаштування мереженого рівня виконується в рамках протоколу NCP. У всіх інших випадках проводитися повернення в початковий стан. Процедура закриття з'єднання здійснюється протоколом LCP.

У поле даних PPP-пакета може бути вкладено один LCP-пакет, в цьому випадку у поле протокол повинен був записаний код 0xC021 (Link Control Protocol). LCP-протокол служить для встановлення з'єднання шляхом обміну конфігураційнімі пакетами. По завершенні цього обміну система переходить у фазу аутентіфікації (рис. 2). Формат LCP-пакета показано на рис. 3.

Рис. 3. – Формат заголовку LCP-пакету

За заголовком слідує поле даних. Поле „код” ідентифікує модифікацію LCP-пакета. Якщо отримано пакет з невідомим полем код, посилається пакет-відгук "відхилення коду". Поле „ідентифікатор” служить для знаходження відповідності між запитами і відгуками. Якщо отримано пакет з неправильним ідентифікатором, він просто знищується. Поле „довжина” визначає розмір LCP-пакета, включаючи розмір заголовка. Октети прийнятого пакета за межами, заданими полем довжина ігноруються.

Як приклад можна розглянути процедуру підключення ПК до сервера через модем. Після того як модем маршрутизатора відповість на виклик модема-клієнта і встановить фізичне з'єднання, ПК посилає послідовність LCP-пакетів, вкладених в поля даних одного або декількох PPP-кадрів. Це дозволяє вибрати необхідні параметри PPP. По завершенню цієї процедури надсилається послідовність NCP-пакетів, які конфігурують мережевий рівень. Ймовірно, ПК захоче працювати зі стеком протоколів TCP/IP, і тому потребує IP-адресі. Якщо провайдер має N IP-адрес в резерві, він може підключити одночасно N ПК. Присвоєння IP-адреси здійснюється також в рамках NCP-протоколу. Після цього ПК стає вузлом Інтернет. Завершення сесії та звільнення IP-адреси виконується також через NCP-протокол. Розрив з'єднання здійснює протокол LCP.

За полем „довжина” можуть слідувати поля опцій. Опції визначаються всі відразу на фазі конфігурування каналу. Опис опції містить однооктетні субполя типу і довжини, за якими слідує поле даних. Значення субполя типу представлені в таблиці 2.

Таблиця 2 – Значення субполя типу.

Значення коду поля типа	Призначення опції
0	Зарезервовано
1	Maximum-Receive-Unit (вказує макс. розмір блоку даних, що може бути прийнятий)
3	Authentication-Protocol (протокол аутентифікації)
4	Quality-Protocol (протокол якості)
5	Magic-Number (магічне число, опція служить для виявлення каналів з петлями зворотного зв’язку)
6	Protocol-Field-Compression
7	Address-and-Control-Field-Compression