Я хочу підключити свій мобільний інтернет до ПК за допомогою пристрою Bluetooth. Я встановив програмне забезпечення Blue Soleil на свій комп'ютер.

• Я можу з'єднати свій мобільний телефон із пристроєм Bluetooth bluetooth.
• Я вибрав свій пристрій і вибрав послугу комутованого доступу Bluetooth.
• Він запитує попередження "З'єднання DUN із пристроєм?" у моєму мобільному телефоні.
• Після натискання "ТАК" відкриється вікно підключення Bluetooth DUN.
• У цьому вікні з'явилися поля "User Name", "PassWord", які я залишаю порожніми, а потім "Dial = * 99 *** 1 #" та натисніть кнопку "Dial".
• Після цього він каже "Реєстрація вашого комп'ютера в мережі..." і перестає працювати.
• Помилка - це як "помилка 734. Протокол управління ppp-зв'язком був перерваний"

Такої ж процедури слід дотримуватись для Nokia 3110c, вона відмінно працює. Але у моєму мобільному телефоні samsung c3053 він не підключений, і я спробував з samsung corby pro BT3510 mobile.

Чи є якісь зміни налаштувань, необхідні для мобільних телефонів Samsung?

5 відповідей

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

Або GPRS APN неправильно налаштований.

Якщо ви намагаєтеся використовувати пристрій як модем загального призначення, може бути складно встановити GPRS APN без додаткового програмного забезпечення для набору номера. Найпростіший спосіб - додати команду "AT+CGDCONT" до "додаткових команд ініціалізації", які можуть бути налаштовані для модему на панелі керування Windows.

Конкретним прикладом того, що буде налаштовано для цієї "додаткової команди ініціалізації", є:

AT + CGDCONT = 1, "IP", "Інтернет"

Ви замінили б Інтернет у цьому прикладі ім'ям GPRS APN, до якого ви хочете підключитися.

Крім того, ви можете посилатися на наступне посилання для перевірки з'єднання:

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

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

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

• Моє ім'я користувача: [email protected]
• Пароль: 1234

Пробіл перед першим номером (7, як у прикладі вище) викликає це повідомлення про помилку. Отже, хлопці дайте йому чек, перш ніж шукати інші варіанти, такі як ефірний час та налаштування набору номера.

Якщо ви отримуєте "734, контрольний протонний канал ppp був завершений" з мобільним телефоном SAMSUNG, проблема у телефоні. У налаштуваннях телефону → Підключення до ПК виберіть, що телефон завжди перебуватиме в режимі "ПК-студія". Якщо ви виберете інші режими або "Запитайте кожен раз", ви отримаєте 743 під час спроби використовувати телефон як модем.

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

• Активувати GPRS, надіславши START sms на номер служби, ініційований BSNL
• Зачекайте деякий час принаймні на 2 години, щоб активуватися після активації, ви отримаєте повідомлення про активацію.
• Оскільки мережа bsnl, ми повинні створити APN - мережу точок доступу
  i) створити APN as - bsnlnet
  ii) пароль як 1111
• Тепер змініть мережу точок доступу як перемикач bsnlnet на свої мобільні дані. Насолоджуйтесь Інтернетом.

• Authentication (Аутентифікація).З'єднані маршрутизатори обмінюються повідомленнями автентифікації. Доступні два варіанти аутентифікації: на основі протоколу PAP та на основі протоколу CHAP.

• Compression (Стиск).Ця функція підвищує ефективну пропускну здатність підключень PPP, зменшуючи обсяг даних у кадрі, що передається каналом. Протокол розпаковує кадр у місці призначення. На маршрутизаторах Cisco є два протоколи стиснення: Stacker і Predictor.

• Error detection (Виявлення помилок). Ця функція визначає стан збою. Параметри Quality та Magic Number сприяють забезпеченню надійного безпетлевого каналу передачі даних. Поле Magic Number використовується для виявлення каналів, де виникла петля. Доки не буде успішно завершено узгодження параметра Magic-Number, має передаватися нульове значення цього параметра. Значення параметра Magic-Number генеруються випадково на кожному кінці підключення.

• PPP Callback (Зворотний виклик PPP). Зворотний виклик PPP використовується для підвищення безпеки. У разі використання цього параметра LCP маршрутизатор Cisco може працювати як клієнт або сервер зворотного дзвінка. Клієнт здійснює початковий дзвінок, запитує у сервера зворотний дзвінок та завершує початковий дзвінок. Маршрутизатор зворотного дзвінка відповідає на початковий дзвінок і виконує дзвінок у відповідь клієнта на основі команд налаштування. Використовується команда ppp callback [ accept | request ] .

Після налаштування параметрів відповідне значення поля вставляється у поле параметра протоколу LCP.

Команди базового налаштування PPP

Запуск PPP на інтерфейсі

Для налаштування PPPяк метод інкапсуляції, який використовується послідовним інтерфейсом, служить команда налаштування інтерфейсу encapsulation ppp .

У наступному прикладі активується інкапсуляція PPP інтерфейсі serial 0/0/0.

R3# configure terminal

R3(config)# interface serial 0/0/0

R3(config-if)# encapsulation ppp

У команди encapsulation pppнемає аргументів. Пам'ятайте, що якщо на маршрутизаторі Cisco не налаштовано інкапсуляцію PPP, за промовчанням для послідовних інтерфейсів буде використовуватися інкапсуляція HDLC.

На малюнку показані маршрутизатори R1 і R2, налаштовані використання на послідовних інтерфейсах як адреси IPv4, і адреси IPv6. PPP є інкапсуляцією рівня 2, що підтримує різні протоколи рівня 3 протоколу, включаючи IPv4 та IPv6.

Команди стиснення PPP

Налаштувати в протоколі «точка-точка» програмне стискування на послідовних інтерфейсах можна після активування інкапсуляції PPP. Оскільки в цьому режимі викликається процес стиснення програмним способом, може вплинути на продуктивність системи. Якщо трафік вже складається зі стислих файлів, таких як .zip, .tar або .mpeg, не слід користуватися цією можливістю. На малюнку показано синтаксис команди compress .

Щоб настроїти стиснення під час передачі PPP, введіть наступні команди.

R3(config)# interface serial 0/0/0

R3(config-if)# encapsulation ppp

R3(config-if)# compress [ predictor | stac ]

Команда моніторингу якості каналу PPP

Пам'ятайте, що LCP забезпечує додатковий етап визначення якості каналу. На цьому етапі LCP перевіряє канал, щоб визначити, чи є якість каналу достатньою для використання протоколів рівня 3.

Команда ppp quality percentageзабезпечує відповідність каналу встановленим вимогам до якості; інакше канал закривається.

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

Якщо відсоток якості каналу не підтримується, то якість каналу вважається низьким і канал відключається. У засобі спостереження за якістю (LQM) реалізовано механізм затримки у часі, щоб канал не піддавався послідовним активуванням та вимкненням.

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

R3(config)# interface serial 0/0/0

R3(config-if)# encapsulation ppp

R3(config-if)# ppp quality 80

Для відключення засобу LQM використовується команда no ppp quality .

Команди багатоканального протоколу PPP

p align="justify"> Багатоканальний протокол PPP (позначається також MP, MPPP, MLP або Multilink) надає метод розподілу трафіку між декількома фізичними каналами WAN. Багатоканальний протокол PPP забезпечує також фрагментацію та повторне складання пакетів, належне впорядкування, можливість використання обладнання різних постачальників та розподіл навантаження вхідного та вихідного трафіку.

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

Налаштування MPPP виконується за два кроки (див. малюнок).

Крок 1.Створення багатоканальної групи.

• Багатоканальний інтерфейс створюється командою interface multilink number .

• У режимі налаштування інтерфейсу багатоканальному інтерфейсу призначається IP-адреса. У цьому прикладі як IPv4, так і IPv6 адреси налаштовані на маршрутизаторах R3 і R4.

• На інтерфейсі запускається PPP багатоканальний.

• Інтерфейс призначається номер багатоканальної групи.

Крок 2Призначення інтерфейсів багатоканальної групи.

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

• Активується інкапсуляція PPP.

• Активується багатоканальний PPP.

• Здійснюється прив'язка до групи за допомогою номера групи, налаштованого в дії 1.

Для вимкнення багатоканального PPP використовується команда no ppp multilink .

Перевірка налаштування PPP

Для перевірки правильності настроювання інкапсуляції HDLC або PPP використовується команда show interfaces serial . У вихідних даних команди відображається налаштування PPP (див. мал.).

Після налаштування HDLC у вихідних даних команди show interfaces serial Потрібно з'явитися рядок encapsulation HDL C . Якщо налаштовано протокол PPP, слід також відобразити стан протоколів LCP і NCP. Зверніть увагу, що протоколи керування мережею IPCP та IPV6CP відкриті для IPv4 та IPv6, оскільки на маршрутизаторах R1 та R2 встановлені адреси IPv4 та адреси IPv6.

На рис. показано список команд для перевірки PPP.

Команда show ppp multilinkперевіряє, чи багатоканальний протокол PPP активовано на R3 (див. рис. 3).

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

Аутентифікація PPP

PPP визначає розширюваний протокол LCP, що дозволяє узгоджувати протокол автентифікації для перевірки справжності співрозмовника, перш ніж дозволити протоколам мережного рівня здійснювати передачу даних каналом. У документі RFC 1334 для аутентифікації визначаються два протоколи, PAP та CHAP (див. рисунок).

Протокол PAP (Password Authentication Protocol, «протокол автентифікації по паролю») – це дуже простий двоетапний процес. У ньому не використовується шифрування. Ім'я користувача та пароль надсилаються у незашифрованому вигляді. При отриманні дозволяється установка підключення. У протоколі CHAP (Challenge Handshake Authentication Protocol, «протокол аутентифікації із запитом») вищий рівень захисту, ніж PAP. У ньому застосовується триетапний обмін секретним ключем, що спільно використовується.

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

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

Password Authentication Protocol (PAP)

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

Ініціалізація PAP

Протокол PAP надає простий метод підтвердження вузла шляхом двоетапного «рукостискання». PAP – не інтерактивний протокол. Якщо використовується команда ppp authentication pap , ім'я користувача та пароль можна надіслати у вигляді одного пакета даних LCP замість відправки сервером запиту на введення імені для входу та очікування відповіді, як показано на рис. 1. Після того, як PPP виконає етап встановлення підключення, віддалений вузол повторно відправляє пару ім'я користувача-пароль по каналу доти, доки приймаючий вузол не підтвердить її або не завершить підключення.

Завершення PAP

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

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

Проте, існують ситуації, у яких використання PAP виправдано. Наприклад, незважаючи на свої недоліки, PAP можна використовувати у таких умовах.

• Великий парк встановлених клієнтських програм, які не підтримують протокол CHAP

• Несумісність між реалізаціями CHAP від ​​різних постачальників

Інкапсуляція та процес аутентифікації PPP

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

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

Простежте за етапами на рис., щоб ознайомитися з процесом встановлення маршрутизатором R1, що пройшов аутентифікацію CHAP підключення РРР до маршрутизатора R2.

Крок 1.Спочатку R1 з використанням LCP виконує узгодження підключення каналу з маршрутизатором R2 і дві системи домовляються використовувати аутентифікацію CHAP під час узгодження PPP LCP.

Крок 2 R2 генерує ідентифікатор та випадкове число, потім відправляє маршрутизатору R1 ці дані та своє ім'я користувача як контрольний пакет CHAP.

Крок 3Маршрутизатор R1 використовує ім'я користувача претендента (R2) і на основі цього імені за допомогою перехресних посилань шукає відповідний пароль у своїй локальній базіданих. Потім R1 генерує хеш-код MD5, використовуючи ім'я користувача маршрутизатора R2, ідентифікатор, випадкове число та спільно використовуваний секретний пароль. У цьому прикладі спільно використовується секретний пароль - boardwalk.

Крок 4.Потім маршрутизатор R1 передає маршрутизатору R2 ідентифікатор контрольного пакета, значення хеш-коду та ім'я користувача (R1).

Крок 5. R2 генерує своє власне значення хеш-коду з використанням ідентифікатора, спільно використовуваного секретного пароля і випадкового числа, що відправлявся маршрутизатору R1.

Крок 6 R2 порівнює своє значення хеш-коду зі значенням відправленим маршрутизатором R1. Якщо значення збігаються, R2 відправляє маршрутизатору R1 відповідь про встановлення каналу.

Якщо запит не пройшов автентифікацію, формується пакет CHAP з інформацією про помилку, що складається з наступних компонентів:

• 04 = тип повідомлення CHAP про помилку

• id = копіюється з пакета відповіді

• "Authentication failure" (Помилка аутентифікації) або подібне текстове повідомлення, зрозуміле користувачеві.

Спільний секретний пароль повинен бути ідентичним на обох маршрутизаторах R1 і R2.

Налаштування автентифікації PPP

Для вказівки порядку, в якому протоколи CHAP та PAP запитуються на інтерфейсі, використовується команда налаштування інтерфейсу ppp authentication, як показано на малюнку. Для вимкнення аутентифікації використовується варіант цієї команди із запереченням ( no ).

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

• Аутентифікація PAP запитує у віддаленого пристрою ім'я та пароль, щоб порівняти їх із відповідним записом у локальній базі даних імен користувачів або у віддаленій базі даних TACACS/TACACS+.

• Аутентифікація CHAP надсилає дистанційному пристрої контрольний запит. Видалений пристрій повинен зашифрувати контрольне значення за допомогою спільно використовується секретного ключа та у відповідному повідомленні повернути локальному маршрутизатору зашифроване значення та своє ім'я. Локальний маршрутизатор використовує ім'я дистанційного пристрою для пошуку відповідного секретного ключа в локальній базі даних імен користувачів або у віддаленій базі даних TACACS/TACACS+. Він використовує знайдений секретний ключдля шифрування вихідного контрольного значення та перевіряє зашифровані значення на тотожність.

Примітка. TACACS - виділений сервер автентифікації, авторизації та обліку (AAA), що використовується для автентифікації користувачів. Клієнти TACACS надсилають запит серверу автентифікації TACACS. Сервер виконує автентифікацію користувача, авторизує дії користувача та відстежує виконані користувачем дії.

Можна увімкнути PAP, CHAP або обидва протоколи. Якщо обидва методи включені, під час узгодження зв'язку запитується метод, зазначений першим. Якщо віддалений вузол пропонує використовувати другий метод або просто відмовляється використовувати перший метод, робиться спроба використовувати другий метод. Деякі віддалені пристрої підтримують лише CHAP, а деякі лише PAP. Порядок, у якому вказуються методи, ґрунтується на міркуваннях щодо здатності віддаленого пристрою правильно провести узгодження відповідного методу, а також міркування безпеки каналу даних. Імена користувачів PAP та паролі надсилаються у вигляді відкритих рядків і можуть бути перехоплені та повторно використані. У протоколі CHAP вдалося усунути більшість відомих проломів у захисті.

Налаштування PPP з автентифікацією

У таблиці описано процедуру налаштування інкапсуляції PPP та протоколи аутентифікації PAP/CHAP. Важливо правильно налаштувати, оскільки PAP та CHAP використовують ці параметри для автентифікації.

Налаштування автентифікації PAP

На рис. наведено приклад налаштування двосторонньої автентифікації PAP. Кожен із маршрутизаторів і проводить аутентифікацію, і проходить її, тому відповідні команди аутентифікації PAP відображають дзеркально один одного. Ім'я користувача та пароль PAP, що відправляються кожним з маршрутизаторів, повинні збігатися із зазначеними в команді username name password passwordіншого маршрутизатора

Протокол PAP надає простий метод підтвердження вузла шляхом двоетапного «рукостискання». Це виконується лише після початкового створення каналу. Ім'я вузла на одному маршрутизаторі має збігатися з ім'ям користувача, налаштованим для PPP іншим маршрутизатором. Паролі також мають збігатися. Параметри, що передають ім'я користувача та пароль, вкажіть у команді ppp pap sent-username name password password .

Налаштування аутентифікації CHAP

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

Лекція 10. HDLC та PPP – протоколи управління каналом

Для створення надійного механізму передачі між двома станціями необхідно визначити протокол, який дозволить приймати і передавати різні дані каналами зв'язку. Протоколи є просто набір умов (правил), які регламентують формат і процедури обміну інформацією між двома або декількома незалежними пристроями чи процесами. Протокол має три найважливіших елементів: синтаксис, семантику та синхронізацію. Синтаксис протоколу визначає поля; наприклад, може бути 16-байтове поле для адрес, 32-байтове поле для контрольних сум і 512 байт на пакет. Семантика протоколу надає цим полям значення: наприклад, якщо адресне поле складається з усіх адрес, це «широкомовний» пакет. Синхронізація – кількість бітів за секунду – це швидкість передачі. Вона важлива не лише на найнижчих рівнях протоколу, а й на найвищих.

Протокол канального рівня забезпечує такі функції:

Управління передачею даних через фізичний канал організований першому рівні;

Перевірка інформаційного каналу;

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

Контроль даних;

Забезпечення прозорості інформаційного каналу;

Управління каналом передачі.

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

Огляд протоколу HDLC. HDLC (High-Level Data Link Control) – протокол високорівневого управління каналом передачі даних, канального рівня (біт-орієнтований) моделі ISO та є базовим для побудови інших протоколів канального рівня (SDLC, LAP, LAPB, LAPD, LAPX та LLC).

Основні принципи роботи протоколу HDLC: режим логічного з'єднання, контроль спотворених та втрачених кадрів за допомогою методу ковзного вікна, керування потоком кадрів за допомогою команд RNR (приймач не готовий) та RR (приймач готовий).

Існує три типи станцій HDLC.

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

Вторинна станція (відома) працює як залежна стосовно первинної станції (провідної). Вона реагує на команди, отримані від первинної станції, як відповідей. Підтримує лише один сеанс, а саме лише з первинною станцією. Вторинна станція не відповідає за керування каналом.

Комбінована станція поєднує в собі одночасно функції первинної та вторинної станції. Передає як команди, так і відповіді та отримує команди та відповіді від іншої комбінованої станції, з якої підтримує сеанс.

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

Стан логічного роз'єднання (LDS). У цьому стані станція не може передавати або приймати інформацію. Якщо вторинна станція знаходиться в нормальному режиміроз'єднання (NDM) вона може прийняти кадр тільки після отримання явного дозволу на це від первинної станції. Якщо станція знаходиться в асинхронному режимі роз'єднання (ADM), вторинна станція може ініціювати передачу без отримання явного дозволу, але кадр повинен бути єдиним кадром, який вказує статус первинної станції. Умовами переходу в стан LDS можуть бути початкове або повторне включення джерела живлення (після короткочасного відключення); ручне керування встановленням у вихідний станлогічних ланцюгів різних пристроїв станції та визначається на основі прийнятих системних угод.

Стан ініціалізації (ІS). Цей стан використовується для передачі керування на віддалену вторинну/комбіновану станцію, її корекції у разі потреби, а також для обміну параметрами між віддаленими станціямиу ланці передачі даних, що використовуються у стані передачі інформації.

Стан передачі (ITS). Вторинній, первинній та комбінованим станціям дозволяється вести передачу та приймати інформацію користувача. У цьому стані станція може перебувати в режимах NRM, ARM та ABM, які описані нижче.

HDLC забезпечує наступні три режими передачі:

– режим нормальної реакції у відповідь (NRM). При цьому вторинні вузли не можуть мати зв'язку з первинним вузлом, поки первинний вузол не дасть дозволу;

– режим асинхронної реакції у відповідь (ARM). Цей режим передачі дозволяє вторинним вузлам ініціювати зв'язок з первинним вузлом без отримання дозволу;

– асинхронний збалансований режим (ABM). У режимі АВМ з'являється "комбінований" вузол, який, залежно від ситуації, може діяти як первинний або вторинний вузол.

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

N(S) – порядковий номер кадру, що передається, N(R) – порядковий номер кадру, що приймається, P/F – біт опитування / закінчення

Малюнок 10.1 – Формат кадру та керуючого поля HDLC

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

Усі кадри повинні починатися та закінчуватися полями прапора «01111110». Станції, підключені до каналу, постійно контролюють послідовність двійкову прапора. Прапори можуть постійно передаватися каналом між кадрами HDLC. Для індексації виняткової ситуації в каналі можуть бути надіслані сім одиниць, що йдуть поспіль. П'ятнадцять чи більша кількістьодиниць підтримують канал у стані спокою. Якщо станція, що приймає, виявить послідовність бітів, які не є прапором, вона тим самим повідомляється про початок кадру, про виняткову (з аварійним завершенням) ситуацію або ситуацію спокою каналу. При виявленні наступної прапорової послідовності станція знатиме, що надійшов повний кадр.

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

Керуюче полезадає тип команди або відповіді, а також порядкові номери, які використовуються для звітування про проходження даних у каналі між первинною та вторинною станціями. Формат та зміст керуючого поля (рис. 1) визначають кадри трьох типів: інформаційні (I), супервізорні (S) та ненумеровані (U).

Інформаційний формат(I – формат) використовується передачі даних кінцевих користувачів між двома станціями.

Супервізорний формат(S – формат) виконує керуючі функції: підтвердження (квитування) кадрів, запит на повторну передачу кадрів та запит на тимчасову затримку передачі кадрів. Фактичне використання супервізорного кадру залежить від режиму роботи станції (режим нормальної відповіді, збалансований асинхронний режим, асинхронний режим відповіді).

Ненумерований формат(U – формат) також використовується для цілей управління: ініціалізації чи роз'єднання, тестування, скидання та ідентифікації станції тощо. Конкретний типкоманди та відповіді залежить від класу процедури HDLC.

Інформаційне полемістить дійсні дані користувача. Інформаційне поле є лише у кадрі інформаційного формату. Його немає у кадрі супервізорного чи ненумерованого формату. [Примітка: кадри UI – ненумерована інформація та FRMR – Неприйом кадру ненумерованого формату мають інформаційне поле].

Поле CRC(Контрольна послідовність кадру) використовується для виявлення помилок передачі між двома станціями. Передавальна станція здійснює обчислення над потоком даних користувача, і результат цього обчислення включається кадр як поля CRC. У свою чергу приймаюча станція виробляє аналогічні обчислення і порівнює отриманий результат з полем CRC. Якщо є збіг, велика ймовірність того, що передача відбулася без помилок. У разі розбіжності, можливо, мала місце помилка передачі, і станція, що приймає, посилає негативне підтвердження, що означає, що необхідно повторити передачу кадру. Обчислення CRC називається циклічним контролем надмірності і використовує деякий виробляє поліном відповідно до рекомендації МККТТ V.41. Цей метод дозволяє виявляти всілякі кортежі помилок довжиною трохи більше 16 розрядів, викликані одиночної помилкою, і навіть 99,9984% всіляких кортежів помилок.

Сьогодні протокол HDLC на виділених каналах витіснив протокол "точка - точка", Point-to-Point Protocol, PPP.

Справа в тому, що одна з основних функцій протоколу HDLC – відновлення спотворених і втрачених кадрів. Справді, застосування протоколу HDLC забезпечує зниження ймовірності спотворення біта (BER) з 10 -3 , що притаманно територіальних аналогових каналів, До 10 -9.

Однак сьогодні популярні цифрові канали, які і без зовнішніх процедур відновлення кадрів мають високою якістю(Величина BER составляет10 -8 – 10 -9). Для роботи з таким каналом відновлювальні функції протоколу HDLC не потрібні. При передачі аналоговим виділеним каналам сучасні модеми самі застосовують протоколи сімейства HDLC. Тому використання HDLC на рівні маршрутизатора чи моста стає невиправданим.

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

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

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

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

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

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

Багатопротокольна підтримка – здатність протоколу РРР підтримувати кілька протоколів мережевого рівня – зумовила поширення РРР як стандарту де-факто. РРР працює з багатьма протоколами мережевого рівня, включаючи IP, Novell IPX, AppleTalk, DECnet, XNS, Banyan VINES та OSI, а також протоколами канального рівня локальної мережі. Найбільше параметрів встановлюється для протоколу IP – IP-адреса вузла, IP-адреса серверів DNS, використання компресії заголовка IP-пакета тощо.

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

Незалежність від світових служб. Початкова версія РРР працювала лише з кадрами HDLC. Тепер до стек РРР додані специфікації, що дозволяють використовувати РРР у будь-якій технології глобальних мереж, наприклад ISDN, Frame relay, Х.25, Sonet та HDLC.

Виникає питання – яким чином два пристрої, які ведуть переговори щодо протоколу РРР, дізнаються про параметри, які вони пропонують своєму партнеру? Зазвичай реалізації протоколу РРР є деякий набір параметрів за замовчуванням, які й у переговорах. Тим не менш, кожен пристрій (і програма, що реалізує протокол РРР в операційній системі комп'ютера) дозволяє адміністратору змінити параметри за замовчуванням, а також встановити параметри, які не входять до стандартного набору. Наприклад, IP-адреса для віддаленого вузла відсутня у параметрах за замовчуванням, але адміністратор може встановити її для сервера віддаленого доступу, після чого сервер пропонуватиме його віддаленому вузлу.

Хоча протокол РРР і працює з кадром HDLC, але в ньому відсутні процедури контролю кадрів та управління потоком протоколу HDLC. Тому в РРР використовується лише один тип кадру HDLC – ненумерований інформаційний. У полі управління такого кадру завжди міститься величина 03. Для виправлення дуже рідкісних помилок, що виникають у каналі, необхідні протоколи верхніх рівнів- TCP, SPX, NetBUEl, NCP тощо.

Однією з можливостей протоколу РРР є використання кількох фізичних ліній для утворення одного логічного каналу, так званий транкінг каналів (загальний логічний канал може складатися з каналів різної фізичної природи. Наприклад, один канал може бути утворений у телефонній мережі, а інший може бути віртуальним комутованим каналом мережі frame relay). Цю можливість реалізує додатковий протокол, який має назву MLPPP (Multi Link РРР). Багато виробників підтримують таку властивість у своїх маршрутизаторах та серверах віддаленого доступу фірмовим способом. Використання стандартного способу завжди краще, тому що він гарантує сумісність обладнання різних виробників.

Основна література: 2

Додаткова література: 7

Контрольні питання:

1. Навіщо потрібні протоколи управління каналом?

2. Які функції забезпечує протокол канального рівня?

3. Які основні засади роботи протоколу HDLC?

4. Які основні засади роботи протоколу РРР?

5. У чому відмінність протоколів HDLC та РРР?

15.10.06 6.1K

2.1 Introduction

PPP це Internet'овський стандарт по передачі IP пакетів по послідовним лініям. PPP підтримує синхронними та асинхронними лініями. За деякими моментами дискусії про PPP, а також PPP проти SLIP раджу подивитись документ на ftp.uu.net:vendor/MorningStar/papers/sug91-cheapIP.ps.Z (paper) та sug91-cheapIP.shar.Z (overhead projector slides )

2.2 PPP features which may or may not be present

По той і по цей бік сумісності з базовим PPP фармінгом треба знати, що багато програм додають свої додаткові можливості. Бажано запам'ятати, що не всі програми, що вільно розповсюджуються, а також комерційні програми мають у собі повний набір всіх можливостей.
Demand dial (додзвон за запитом) Підключення PPP інтерфейсу та набір тел. номера по приходу пакета. відключення інтерфейсу PPP після деякого періоду відсутності активності.
Redial Підключення PPP інтерфейсу, який потім не буде відключений і завжди зберігатиме в своєму розпорядженні підключений канал.
Campling (див. Redial)
Scripting Установка через серію повідомлень або проміжних з'єднань для встановлення PPP з'єднання, більше схоже на послідовності використовувані для встановлення зв'язку по UUCP.
Parallel Конфігурування декількох PPP ліній для одного і того ж підключення до хоста, для рівномірного поділу трафік між ними. (У процесі стандартизації)
Filtering Вибірка, при яких пакетах має сенс починати продзвон по лінії, а при яких немає. Відштовхуючись у прийнятті рішення від IP або TCP типу пакета або TOS (Type of Service). Наприклад, ігнорувати всі ICMP пакети.
Header Compression (стиснення заголовка) Стиснення TCP заголовка відповідно до RFC1144 Не обов'язково при використанні на високошвидкісних лініях, але дуже корисний на низькошвидкісних.
Server Прийняття вхідних PPP з'єднань, які можуть також вимагати додаткової маршрутизації.
Tunneling Побудова віртуальних мереж по PPP з'єднанню, через TCP потік, через існуючу IP мережу. (Build a virtual networkчерез PPP link across a TCP stream через existing IP network.)
Extra escaping Байт орієнтовані символи, що не входять у стандартний набір символів, використовуваний при встановленні зв'язку, вони можуть бути конфігуровані окремо, але також не перетинатися з тими, що використовуються при встановленні зв'язку. (Byte-stuffing characters outside the negotiated asyncmap, configurable in advance but not negotiable.)

2.3 PPP glossary

Кожна технологія з часом утворює акронімами ... PPP не виняток. оскільки майже всі терміни вживаються у своїй англійській/американській транскрипції, то мені здається, що переклад цих скорочень не має сенсу.
ack Acknowlegement
AO Active Open (нещодавно стала частиною FSM у RFC1331)
C Close
CHAP Challenge-Handshake Authentication Protocol (RFC1334)
D Lower layer down
DES Data Enryption Protocol
DNA Digital Network Architecture
IETF Internet Engineering Task Force.
IP Internet Protocol
IPCP IP Control Protocol.
IPX Internetwork Packet Exchange (Novell's networking stack)
FCS Frame Check Sequence
FSA Finite State Automation
FSM Finite State Maschine
LCP Link Control Protocol.
LQR Link Quality Report.
MD4 MD4 digital signature algorithm
MD5 MD5 digital signature algorithm
MRU Maximum Receive Unit
MTU Maximum Transmission Unit
nak Negative Acknowledgement
NCP Network Control Protocol.
NRZ Non-Return to Zero bit encoding. (SYNC ppp default because of availability)
NRZI Non-Return to Zero Inverted bit encoding. (SYNC ppp preferred alternative to NRZ)
OSI Open Systems Interconnect
PAP Password Authentication Protocol (RFC1334)
PDU Protocol Data Unit (теж що packet)
PO Passive open
PPP Point to Point Protocol (RFC1548/RFC1549,1332,1333,1334,1551,1376,1377,1378)
RCA Receive Configure-Ack
RCJ Receive Code-Reject
RCN Receive Configure-Nak or -Reject
RCR+ Receive good Configure-Request
RER Receive Echo-Request
RFC Request for Comments (Internet standard)
RTA Receive Terminate-Ack
RTR Receive Terminate-Request
RUC Receive unknown code
sca Send Configure-Ack
scj Send Code-Reject
scn Send Configure-Nak or -Reject
scr Send Configure-Request
ser Send Echo-Reply
sta Send Terminate-Ack
str Send Terminate-Request
ST-II Stream Protocol
TO+ Timeout with counter > 0
TO- Timeout with counter expired
VJ Van Jacobson (RFC1144 header compression algorithm)
XNS Xerox Network Services
Загальна інформація

Point-to-Point Protocol (PPP) розроблений для вирішення проблем, пов'язаних з недостатньою кількістюстандартних засобів інкапсуляції протоколів виду «point-to-point IP». До всього іншого PPP був також розроблений для спрощення видачі та управління IP адресами, асинхронної і bit-oriented синхронної інкапсуляцією, змішування мережевих протоколів (network protocol multiplexing), конфігурування і тестування якості зв'язку, таких як ройка адрес і встановлення стиснення даних. Для підтримки вище перерахованих якостей, PPP повинен надавати управління по розширеному Link Control Protocol (LCP) і сімейству протоколів Network Control Protocols (NCPs) які використовуються для встановлення параметрів зв'язку. Hа сьогоднішній день PPP підтримує не тільки IP, але й інші протоколи, включаючи IPX і DECNet.

PPP Components

PPP надає можливість передачі датаграм по послідовним point-to-point лініям. Він має 3 компоненти:

* Метод надання інкапсуляції датаграм по послідовним PPP лініях використовуючи HDLC (High-Level Data Link Control) протокол для пакування датаграм по PPP засобах зв'язку.
* Розширений LCP (Link Control Protocol) для встановлення, конфігурування та тестування фізичного з'єднання (test the data-link connection)
* Сімейство протоколів (NCPs) для встановлення та управління іншими мережевими протоколами, іншими словами: PPP розроблений для підтримки одночасно декількох мережевих протоколів.

General Operation

У момент встановлення зв'язку через PPP з'єднання, PPP драйвер спочатку шле пакети LCP для конфігурування та (можливо) тестування лінії зв'язку. Після того як зв'язок і додаткові можливості будуть встановлені як треба за допомогою LCP, PPP драйвер посилає NCP фрейми для зміни і/або настроювання одного або більше мережевих протоколів. Коли цей процес закінчиться, то мережеві пакети отримують можливість бути переданими через встановлене з'єднання. Воно буде залишатися налаштованим і активним до тих пір, поки певні LCP або NCP пакети не закриють з'єднання, або до тих пір, поки не відбудеться якась зовнішня подія, яка приведе до втрати з'єднання (до прикладу: таймер відсутності активу
Physical-Layer Requirements

PPP адаптований для роботи з будь-яким DTE/DCE інтерфейсом, включаючи EIA/TIA-232-C (RS-232), EIA/TIA-422-C(RS-422), EIA/TIA-423-C(RS-423) ITU-T (CCITT) V.35. Єдина вимога до обладнання, що накладається PPP - це наявність дуплексного обладнання, не важливо виділене воно або переключається (either dedicated or switched), яке може працювати на асинхронних або bit-oriented синхронних, прозорих.
PPP Link Layer
—————

PPP використовує принципи, термінологію та структуру пакетів в описаних ISO документах стосовно HDLC (ISO 3309-1979) та його доповненої версії:

* ISO 3309:1984/PDAD1 «Addendum 1: Start/stop transmission.»
* ISO 3309-1979: описує структуру пакетів HDLC для використання в синхронних системах.
* ISO 3309:1984/PDAD1: описує пропозиції щодо змін у ISO 3309-1979, які заохотять використовувати асинхронні системи.

Процедури управління PPP використовують визначення та керуючі поля стандартизовані в документах: ISO 4335-1979 та ISO 4335-1979/Addendum 1-1979.

Формат пакету PPP:
1 1 1 2 Variable 2 або 4
Flag Address Control Protocol DATA FCS

Flag: Один байт позначає початок або кінець пакета Поле прапора містить двійкову послідовність: 01111110.
Address: Один байт містить двійкову послідовність: 11111111, Стандартний широкомовний адресу. PPP не підтримує індивідуальну адресацію станцій.
Control: Один байт містить двійкову послідовність: 00000011, який посилається для передачі даних у нерозділених пакетах. (для передачі user data in an unsequenced frame.
Protocol: 2 байти кодують протокол упакований під час протоколу PPP. Значення протоколів можна дізнатися в документі Assigned Numbers Request for Comments (RFC).
Data: 0 або більше байт складових датаграми протоколу вказаного в полі «Protocol». Кінець інформаційного поля визначається знаходженням закінчуючої послідовності та 2байтної послідовності в полі FCS. За замовчуванням максимальна довжина інформаційного поля 1500 байт.
Frame Check Sequence (FCS): Зазвичай 16bit (2байта). Однак, за взаємною «договореністю» може використовуватися і 32bit (4байта) котpоль цілісності пакетів.

PPP Link Control Protocol

PPP LCP надає методи для встановлення, конфігурування, підтримування та тестування point-to-point з'єднання. LCP розпадається на 4 фази:

* Конфігурування та встановлення зв'язку — Перед передачею будь-якої датаграми (до прикладу IP) LCP повинен на початку відкрити з'єднання і провести початковий обмін параметрами настроювання. Цей етап закінчується, коли пакет про підтвердження виробленого настроювання буде надіслано і прийнято назад.
* Визначення якості зв'язку - LCP дозволяє (але не вимагає) додати фазу тестування каналу зв'язку, ця фаза буде слідувати відразу за першою. У перебігу цієї фази визначається здатність з'єднання з достатньою якістю транспортувати який-небудь мережевий протокол. Ця фаза не є обов'язковою. LCP повинен затягнути передачу будь-якого мережного протоколу до тих пір, поки ця фаза не буде виконана.
* Встановлення настройок мережевого протоколу — Після того як LCP закінчить визначення параметрів зв'язку, мережні протоколи повинні бути незалежно один від одного налаштовані відповідними NCP, які можуть в будь-який момент часу почати або припинити користуватися.
* Закінчення зв'язку - LCP може в будь-який час перервати встановлений зв'язок. Це може статися на вимогу користувача або через якусь фізичну подію, до прикладу втрати несучої або закінчення допустимого періоду часу невикористання каналу.

Існує три типи LCP пекетів:

* Пакети встановлення- Використовуються для встановлення та налаштування зв'язку
* Пакети переривання — Використовуються для переривання встановленого зв'язку
* Пакети збереження зв'язку — Використовуються для управління та діагностики зв'язку

2.4 PPP relevant RFCs

Це список документів RFC, присвячених PPP. Частина цих документів (obsoleted) застаріла.

* 1717 - Sklower, K.; Lloyd, B.; McGregor, G.; Carr, DThe PPP Multilink Protocol (MP). 1994 р. November; 21 p. (Format: TXT=46264 bytes)
* 1663 - Rand, DPPP Reliable Transmission. 1994 July; 8 p. (Format: TXT=17281 bytes)
* 1662 - Simpson, W., edPPP в HDLC-like Framing. 1994 July; 25 p. (Format: TXT=48058 bytes) (Obsoletes RFC 1549)
* 1661 - Simpson, W., edThe Point-to-Point Protocol (PPP). 1994 July; 52 p. (Format: TXT=103026 bytes) (Obsoletes RFC 1548)
* 1638 - Baker, F.; Bowen, R., eds PPP Bridging Control Protocol (BCP). 1994 р. June; 28 p. (Format:TXT=58477 bytes)
* 1619 - Simpson, WPPP over SONET/SDH. 1994 р. May; 4 p. Формат: TXT = 8893 bytes)
* 1618 - Simpson, WPPP over ISDN. 1994 р. May; 6 p. (Format: TXT=14896 bytes)
* 1598 - Simpson, WPPP in X.25. 1994 р. March; 7 p. (Format: TXT=13835 bytes)
* 1570 - Simpson, W., ed. PPP LCP Extensions. 1994 р. January; 18 p. (Format: TXT=35719 bytes) (Updates RFC 1548)
* 1553 - Mathur, S.; Lewis, M. Compressing IPX Headers Over WAN Media (CIPX). 1993 December; 23 p. (Format: TXT=47450 bytes)
* 1552 - Simpson, W. PPP Internetwork Packet Exchange Control Protocol (IPXCP). 1993 December; 14 p. Формат: TXT=29174 bytes)
* 1551 - Allen, M. Novell IPX Over Various WAN Media IPXWAN). 1993 December; 22 p. (Format: TXT=54210 bytes) (Obsoletes RFC 1362)
* 1549 - Simpson, W., ed. PPP в HDLC Framing. 1993 December; 18 p. (Format: TXT=36353 bytes) Obsoleted by RFC 1662)
* 1548 - Simpson, W. The Point-to-Point Protocol (PPP). 1993 December; 53 p. (Format: TXT=111638 bytes) (Obsoletes RFC 1331; Obsoleted by RFC 1661; Updated by RFC 1570)
* 1547 - Perkins, D. Requirements for Internet Standard Pointto-Point Protocol. 1993 December; 21 p. Формат: TXT=49811 bytes)
* 1378 - PPP AppleTalk Control Protocol (ATCP). Parker, B. 1992 November; 16 p. (Format: TXT=28496 bytes)
* 1377 - PPP OSI Network Layer Control Protocol (OSINLCP). Katz, D. 1992 November; 10 p. (Format: TXT=22109 bytes)
* 1376 - PPP DECnet Phase IV Control Protocol (DNCP). Senum, SJ. 1992 р. November; 6 p. (Format: TXT=12448 bytes)
* 1362 - Allen, M. Novell IPX Over Various WAN Media IPXWAN). 1992 September; 18 p. (Format: TXT=30220 bytes)
* 1334 - PPP authentication protocols. Lloyd, B.; Simpson, W.A. 1992 October; 16 p. (Format: TXT=33248 bytes)
* 1333 - PPP link quality monitoring. Simpson, W.A. 1992 р. May; 15 p. (Format: TXT=29965 bytes)
* 1332 - PPP Internet Protocol Control Protocol (IPCP). McGregor, G. 1992 р. May; 12 p. (Format: TXT=17613 bytes) (Obsoletes RFC1172)
* 1331 - Point-to-Point Protocol (PPP) для переведення multi-protocol datagrams over point-to-point links. Simpson, W.A. 1992 р. May; 66 p. (Format: TXT=129892 bytes) (Obsoletes RFC1171, RFC1172; obsoleted by RFC 1548)
* 1220 - Point-to-Point Protocol extensions for bridging. Baker, F., ed. 1991 р. April; 18 p. (Format: TXT=38165 bytes)
* 1172 - Point-to-Point Protocol (PPP) initial configuration options. Perkins, D.; Hobby, R. 1990 July; 38 p. (Format: TXT=76132 bytes) (Obsoleted by RFC1331, RFC1332)
* 1171 - Point-to-Point Protocol для переведення multi-protocol datagrams over Point-to-Point links. Perkins, D. 1990 July; 48 p. (Format: TXT=92321 bytes) (Obsoletes RFC1134; Obsoleted by RFC1331)
* 1134 — Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links. Perkins, D. 1989 November; 38 p. (Format: TXT=87352 bytes) (Obsoleted by RFC1171)
* 1144 - Compressing TCP/IP headers для low-speed serial links. Jacobson, V. 1990 February; 43 p. Формат: TXT=120959 PS=534729 bytes)

PPP (Point-to-Point-Protocol) – протокол другого рівня моделі OSI, що використовується на WAN лінках. PPP – відкритий протокол, що дозволяє його використовувати при необхідності з'єднання пристроїв Cisco з пристроями інших виробників (на відміну від HDLC, щодо специфікації якого у циски своя думка).

Відразу варто зробити важливе зауваження: протокол PPP – багатофункціональний і широко розповсюджений, водночас у рамках курсу CCNA розглядається лише один спосіб його застосування: підключення двох маршрутизаторів один до одного через serial кабель. Насправді сфера застосування протоколу не обмежується цими випадками. PPP може працювати через нуль-модемний кабель, телефонну лінію, у стільниковому зв'язку. Інші популярні способи використання протоколу PPP – інкапсуляція його до інших протоколів другого рівня. Поясню: сам PPP знаходиться на другому рівні моделі OSI та забезпечує пряме з'єднанняміж двома пристроями, але якщо його інкапсулювати в інший протокол другого рівня – Ethernet (PPP over Ethernet – PPPoE), то ethernet займатиметься доставкою кадрів з мак адреси відправника на мак адресу одержувача, після одержувач декапсулюватиме з Ethernet-а PPP фрейм і далі для загорнутих в PPP протоколів (IPv4, IPX, ...) буде створюватися повна «ілюзія» того, що з'єднання крапка-точка. Сам же PPP у цьому випадку займатиметься такими речами як автентифікація та стиснення трафіку. Існують інші способи використання PPP, наприклад, PPP over ATM – PPPoA, Microsoft Windowsвикористовує для створення VPN протокол PPTP, який є надбудовою над PPP. Але це весь ліричний відступ, щоб було зрозуміло, навіщо взагалі вивчати PPP. У курсі "CCNA Accessing the WAN" PPP - це протокол для з'єднання двох маршрутизаторів через серійний кабель.

Що вміє PPP порівняно з HDLC?

1. Керування якістю лінії (PPP вимикає лінк, якщо кількість помилок перевищить задане значення).
2. Аутентифікація за допомогою PAP чи CHAP.
3. Multilink – технологія нагадує Etherchannel в Ethernet-е: кілька різних лінків об'єднуються в один логічний, зі швидкістю, що дорівнює сумі лінків, що до нього входять.
4. PPP Callback – технологія, що використовується для підвищення безпеки: клієнт встановлює з'єднання із сервером, сервер розриває з'єднання та встановлює зі свого боку нове – до клієнта.

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

1. Перший рівень HDLC – отримує кадр, перевіряє адресу одержувача, контрольну суму і передає корисну інформацію далі.
2. Підрівень LCP (Link Control Protocol), як видно з назви, займається керуванням з'єднанням, відправляє та отримує різні службові прапори, стежить за станом з'єднання (підключено/вимкнено), стежить за якістю лінії, стежить за узгодженістю параметрів конфігурації між точками.
3. Підрівень NCP (Network Control Protocol) складається з великої кількостімодулів, кожен із яких займається зв'язком із якимось конкретним протоколом третього рівня (IPv4, IPv6, IPX, AppleTalk, …). Завдяки цьому, в рамках одного встановленого PPP з'єднання з одним логіном та паролем, можна передавати трафік різних протоколів мережного рівня.

Встановлення зв'язку між двома маршрутизаторами протоколу PPP відбувається за рівнями знизу вгору, розрив зв'язку – зверху вниз.

Тобто встановлюється зв'язок у такому порядку: LCP, NCP, корисні дані третього рівня. А розривається: кінець передачі корисних даних, NCP, LCP. Як видно, HDLC не встановлює і не розриває з'єднання, так як PPP використовуються HDLC кадри без підтвердження доставки.

Структура PPP кадру має такий вигляд:

1. FLAG – ознака початку кадру, спеціальна послідовність нулів та одиниць («01111110»), яка говорить одержувачу, що далі слідуватиме тіло кадру.
2. ADDRESS – адреса одержувача, у протоколі PPP завжди використовується широкомовний «11111111».
3. CONTROL – поле містить значення "00000011"
4. PROTOCOL – поле, яке містить номер протоколу третього рівня, пакет якого «загорнуть» у цей кадр.
5. DATA – поле з корисними даними вищестоящих протоколів.
6. FCS – контрольна сума, Яка вважається при відправленні кадру і порівнюється з отриманим перерахунком, який робиться при отриманні кадру. У результаті, якщо суми не збігаються, кадр вважається «битим» та відкидається.
7. FLAG – ознака закінчення кадру, містить те значення що й ознака початку кадру.

Налаштування PPP на устаткуванні cisco, як уже було сказано, в курсі CCNA не складне. Виконується вона на інтерфесі:

1. Вибираємо алгоритм стиснення командою compress
2. Встановлюємо якість лінії, яка вважатиметься прийнятною (при кількості помилок, більше заданого зв'язок буде розриватися). Для цього служить команда ppp quality.
3. Вибираємо спосіб автентифікації PAP або CHAP (докладніше про це можна дізнатися зі статті «У чому різниця між PAP та CHAP». Спосіб автентифікації задається командною ppp authentication.
4. Необхідно налаштувати користувача, під яким наш маршрутизатор буде підключатися до іншого. Тут команди відрізняються для CHAP та PAP. Сам користувач додається командою username<имя> password<пароль>, причому робити це треба не на інтерфейсі, а в режимі глобальної конфігурації, але у разі використання PAP, ще треба використовувати на інтерфейсі команду ppp pap sent-username <имя> password<пароль>.

Використання PAP у реальних конфігураціях не бажане, тому ми обмежимося прикладом налаштування CHAP. Отже, припустимо, що наступна топологія, необхідно налаштувати PPP з автентифікацією CHAP. Налаштування на першому маршрутизаторі:

Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#hostname R1 R1(config)#username R2 password 123456789 R1(config)#interface serial 0/3/0 R1(config-if)#en R1(config-if)#encapsulation ppp R1(config-if )#ppp authentication chap R1(config-if)#ip address 192.168.0.1 255.255.255.0 R1(config-if)#no shutdown %LINK-5-Changed: Interface Serial0/3/0, змінений стан до down

Налаштування на другому маршрутизаторі:

Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#hostname R2 R2(config)#username R1 password 123456789 R2(config)#interface serial0/3/0 R2(config-if)#encapsulation ppp R2(config-if)#ppp authentication chap R2(config- if)#ip address 192.168.0.2 255.255.255.0 R2(config-if)#no shutdown %LINK-5-CHANGED: Interface Serial0/3/0, змінений стан до %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0 /3/0, changed state to up

Зверніть увагу, що користувач, якого ми заводимо на маршрутизаторі R1, має ім'я R2, ​​а на R2 – R1. Це необхідно, оскільки коли один роутер підключається до іншого, він вказує своє ім'я, відповідно інший повинен знати це ім'я (бачити його в своєму списку локальних користувачів). Ще одна важлива деталь: паролі до користувачів R1 та R2 обов'язково повинні збігатися.

Для перевірки можемо виконати команду:

R2#sh ip inter brief IP-адреса IP-адреси OK? Method Status Protocol … Serial0/3/0 192.168.0.2 YES manual up up …

Якщо status буде «up», а протокол – «down», то це, як правило, означає, що якісь проблеми з PPP – не та аутентифікація, не збіглися паролі, якість лінії нижче за те, що ми замовляли тощо. У цьому випадку доведеться перевіряти конфіги та запускати debug ppp, чого я не побажаю і ворогові.