Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/6643Повний запис метаданих
| Поле DC | Значення | Мова |
|---|---|---|
| dc.contributor.advisor | Чепинога, Анатолій | - |
| dc.contributor.author | Колісніченко, Олександр | - |
| dc.date.accessioned | 2026-01-07T17:13:24Z | - |
| dc.date.available | 2026-01-07T17:13:24Z | - |
| dc.date.issued | 2025 | - |
| dc.identifier.uri | https://er.chdtu.edu.ua/handle/ChSTU/6643 | - |
| dc.description.abstract | Зростаюче навантаження на комп’ютерні і телекомунікаційні мережі вимагає від розробників відповідних методів керування трафіком, різновиди якого постійно додаються і повинні бути оброблені відповідним чином. У сучасних корпоративних мережах дедалі ширше застосовуються сервіси реального часу та мультимедіа, такі як IP-телефонія, відеоконференції, хмарні додатки тощо, що чутливі до затримок, джитера та втрат пакетів. Підприємства швидко переходять на цифрові технології, і мережа стає фундаментом цифрової трансформації – вона повинна підтримувати високу пропускну здатність, низькі затримки та надійність з’єднання для гібридної роботи й віддаленого доступу до хмарних сервісів. Відповідно, гарантоване забезпечення якості обслуговування (QoS) стає ключовим фактором для стабільної роботи корпоративних мереж, що суттєво вирізняються конвергентністю. І хоча на даний час розроблено досить широкий спектр інструментів для класифікації, обмеження, виоремлення різного типу трафіку, все ж і на даний час така задача не є однозначно простою чи тривіальною. У мережевій інженерії використовують різні методи QoS. Зокрема, архітектури IntServ з протоколом RSVP і DiffServ з підтримкою DSCP широко описані в літературі. Модель DiffServ має високу масштабованість, але поділ трафіку на обмежену кількість класів дозволяє лише грубо пріоритизувати дані. Також існують засоби резервування смуги (MPLS-TE), політики пріоритетів на мережевих пристроях Cisco, а також механізми формування і політики трафіку. Водночас сучасні корпоративні мережі обмежені пропускною здатністю та різнорідністю обладнання, тому іноді застосовують надмірне резервування каналів замість гнучких QoS-механізмів. Корпоративні мережі є основою цифрової трансформації бізнесу, тому за ними стоять завдання забезпечення високої якості зв’язку для критичних сервісів. QoS-методи дозволяють пріоритизувати трафік важливих додатків і гарантувати 5 необхідну смугу пропускання та мінімальні затримки. Завдяки цьому досягається надійне функціонування IP-телефонії, відеоконференцій та інших критичних ІТ- сервісів, що відповідає прикладним завданням комп’ютерної інженерії з побудови надійних мережевих систем [1, 2]. Таким чином, актуальність дослідження та удосконалення роботи корпоративних мереж обумовлена потребою бізнесу у високій продуктивності щодо сервісів реального часу, яким не повинен заважати інший тип трафіку, а їх співіснування і проходження в одній мережі повинно бути узгодженим. Метою кваліфікаційної роботи є дослідження методів забезпечення якості обслуговування (QoS) в корпоративних мережах для підвищення ефективності роботи застосунків реального часу. Для досягнення мети поставлені такі завдання: • провести аналіз сучасних підходів до QoS у комп’ютерних мережах та їхні обмеження; • дослідити основні механізми пріоритезації трафіку в мережі; • реалізувати моделі та механізми QoS в корпоративній мережі. Об’єктом досліджень є процеси функціонування корпоративних мереж. Предметом досліджень є моделі і механізми забезпечення QoS. Методи досліджень. Теоретичні дослідження спираються на використання теорії побудови корпоративних мереж, стандарти і підходи до QoS, теорії і практики застосування QoS, методи оптимізації. Практичне значення одержаних результатів. Робота може бути використана для оптимізації будь-якої корпоративної мережі організації, щоб забезпечити безперервність бізнес-процесів, забезпечення клієнтів надійним зв’язком з врахуванням типів трафіку та пріоритетного проходження по мережі потоків реального часу. Робота містить 70 сторінок основного тексту, 5 таблиць та 28 рисунків. | uk_UA |
| dc.title | Методи забезпечення якості обслуговування в корпоративних мережах | uk_UA |
| dc.type | Master Thesis | uk_UA |
| Розташовується у зібраннях: | 123 Комп’ютерна інженерія (Комп'ютерні системи та мережі) | |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| ПЗ_Колісніченко_НА ДРУК-merged.pdf Restricted Access | 2.69 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ КАФЕДРА ІНФОРМАЦІЙНОЇ БЕЗПЕКИ ТА КОМП’ЮТЕРНОЇ ІНЖЕНЕРІЇ ПОЯСНЮВАЛЬНА ЗАПИСКА до кваліфікаційної роботи магістра на тему: «Методи забезпечення якості обслуговування в корпоративних мережах» ЧДТУ.252471.003 ПЗ Виконав: студент 2 курсу, групи МКМ-2405 спеціальності 123 Комп’ютерна інженерія за освітньою програмою – Комп’ютерні системи та мережі Олександр КОЛІСНІЧЕНКО Керівник к.т.н., доцент Анатолій ЧЕПИНОГА Н. контроль Світлана ГРЕСЬКО Рецензент к.т.н., доцент кафедри комп’ютерної інженерії та інформаційних технологій Черкаського державного бізнес коледжум Сергій БУРМІСТРОВ «ЗАХИСТ ДОЗВОЛЯЮ» Завідувач кафедри ІБ та КІ к.т.н., доцент ____ Артем ЛАВДАНСЬКИЙ Черкаси 2025 року 3 ЗМІСТ ВСТУП..............................................................................................................................4 РОЗДІЛ 1 АНАЛІЗ СУЧАСНИХ ПІДХОДІВ ДО QOS...............................................6 1.1 Параметри QoS у мережах..............................................................................6 1.2 Моделі QoS....................................................................................................13 1.3 Базові компоненти QoS.................................................................................19 1.4 Висновки до розділу 1...................................................................................22 РОЗДІЛ 2 МЕХАНІЗМИ ВПРОВАДЖЕННЯ ТЕХНОЛОГІЙ QOS.........................23 2.1 Класифікація та маркування.........................................................................24 2.2 Контроль та формування трафіку................................................................32 2.3 Керування та уникнення перевантаження..................................................36 2.4 Висновки до розділу 2...................................................................................38 РОЗДІЛ 3 ВПРОВАДЖЕННЯ QOS В КОРПОРАТИВНУ МЕРЕЖУ......................39 3.1 Розрахунок одношвидкісного триколірного маркерного відра................39 3.2 Використання модульного фреймворку QoS на пристроях Cisco............44 3.3 Моделювання та налаштування QoS...........................................................48 3.4 Превентивне виявлення перевантажень......................................................55 3.5 Висновки до розділу 3...................................................................................61 ВИСНОВКИ...................................................................................................................62 ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ...........................................64 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ……………………………………….…….65 ДОДАТОК А - Модельні сценарії налаштування проміжних пристроїв 4 ВСТУП Зростаюче навантаження на комп’ютерні і телекомунікаційні мережі вимагає від розробників відповідних методів керування трафіком, різновиди якого постійно додаються і повинні бути оброблені відповідним чином. У сучасних корпоративних мережах дедалі ширше застосовуються сервіси реального часу та мультимедіа, такі як IP-телефонія, відеоконференції, хмарні додатки тощо, що чутливі до затримок, джитера та втрат пакетів. Підприємства швидко переходять на цифрові технології, і мережа стає фундаментом цифрової трансформації – вона повинна підтримувати високу пропускну здатність, низькі затримки та надійність з’єднання для гібридної роботи й віддаленого доступу до хмарних сервісів. Відповідно, гарантоване забезпечення якості обслуговування (QoS) стає ключовим фактором для стабільної роботи корпоративних мереж, що суттєво вирізняються конвергентністю. І хоча на даний час розроблено досить широкий спектр інструментів для класифікації, обмеження, виоремлення різного типу трафіку, все ж і на даний час така задача не є однозначно простою чи тривіальною. У мережевій інженерії використовують різні методи QoS. Зокрема, архітектури IntServ з протоколом RSVP і DiffServ з підтримкою DSCP широко описані в літературі. Модель DiffServ має високу масштабованість, але поділ трафіку на обмежену кількість класів дозволяє лише грубо пріоритизувати дані. Також існують засоби резервування смуги (MPLS-TE), політики пріоритетів на мережевих пристроях Cisco, а також механізми формування і політики трафіку. Водночас сучасні корпоративні мережі обмежені пропускною здатністю та різнорідністю обладнання, тому іноді застосовують надмірне резервування каналів замість гнучких QoS-механізмів. Корпоративні мережі є основою цифрової трансформації бізнесу, тому за ними стоять завдання забезпечення високої якості зв’язку для критичних сервісів. QoS-методи дозволяють пріоритизувати трафік важливих додатків і гарантувати 5 необхідну смугу пропускання та мінімальні затримки. Завдяки цьому досягається надійне функціонування IP-телефонії, відеоконференцій та інших критичних ІТ- сервісів, що відповідає прикладним завданням комп’ютерної інженерії з побудови надійних мережевих систем [1, 2]. Таким чином, актуальність дослідження та удосконалення роботи корпоративних мереж обумовлена потребою бізнесу у високій продуктивності щодо сервісів реального часу, яким не повинен заважати інший тип трафіку, а їх співіснування і проходження в одній мережі повинно бути узгодженим. Метою кваліфікаційної роботи є дослідження методів забезпечення якості обслуговування (QoS) в корпоративних мережах для підвищення ефективності роботи застосунків реального часу. Для досягнення мети поставлені такі завдання: • провести аналіз сучасних підходів до QoS у комп’ютерних мережах та їхні обмеження; • дослідити основні механізми пріоритезації трафіку в мережі; • реалізувати моделі та механізми QoS в корпоративній мережі. Об’єктом досліджень є процеси функціонування корпоративних мереж. Предметом досліджень є моделі і механізми забезпечення QoS. Методи досліджень. Теоретичні дослідження спираються на використання теорії побудови корпоративних мереж, стандарти і підходи до QoS, теорії і практики застосування QoS, методи оптимізації. Практичне значення одержаних результатів. Робота може бути використана для оптимізації будь-якої корпоративної мережі організації, щоб забезпечити безперервність бізнес-процесів, забезпечення клієнтів надійним зв’язком з врахуванням типів трафіку та пріоритетного проходження по мережі потоків реального часу. Робота містить 70 сторінок основного тексту, 5 таблиць та 28 рисунків. 6 РОЗДІЛ 1 АНАЛІЗ СУЧАСНИХ ПІДХОДІВ ДО QOS Додавання якості обслуговування (QoS) в завдання з проектування мереж є необхідним для забезпечення оптимальної продуктивності та надійності, особливо в сучасних середовищах, що базуються на даних. Розуміння QoS є важливим не тільки для теоретичних цілей, але й для практичного застосування. QoS передбачає управління мережевим трафіком для визначення пріоритетності критично важливих додатків, зменшення затримки та підвищення загальної ефективності. Незалежно від того, чи йдеться про трафік у реальному часі, такий як VoIP, чи транзакційний трафік для онлайн-сервісів, добре розроблена стратегія QoS забезпечує безперебійну роботу навіть під час значних навантажень. Не врахування пріоритетності трафіку часто веде до проблем у збалансуванні політик QoS з продуктивністю та масштабованістю мережі [1, 2]. 1.1 Параметри QoS у мережах Якість обслуговування (Quality of Service, QoS) у комп’ютерних мережах характеризується кількома ключовими параметрами, які визначають, наскільки мережа задовольняє вимоги різних сервісів реального часу та даних. До основних показників QoS належать затримка, джитер (тремтіння), втрата пакетів, пропускна здатність, а також додаткові характеристики (наприклад, доступність мережі та MOS). У цьому пункті розглянуто ці параметри: їхню природу, фактори, що впливають, а також орієнтовні граничні значення для різних застосунків (VoIP, відеоконференції, веб-трафік тощо). Наочно проілюстровано вплив затримки, джитера та втрат на якість VoIP/відео, а також наведено рекомендовані значення параметрів QoS. Затримка – це час, необхідний пакету даних для проходження від відправника до одержувача. Вона вимірюється як одностороння (one-way delay, з джерела в пункт призначення) або як кругова (Round-Trip Time, RTT, туди й назад). Затримка 7 складається з кількох компонентів: просторової (пропагаційної) затримки на фізичних лініях (визначається відстанню і швидкістю сигналу), передавальної (серіалізації) затримки на інтерфейсах (розмір пакету/пропускна здатність лінії), обробної (затримка на обробку на комутаторах і маршрутизаторах) та чергової (затримка на накопичення у чергах при перевантаженні). Чим більша відстань або менша пропускна здатність, тим більшою є затримка; також її збільшують вузькі місця (джерела затримки) у мережі. Наприклад, у мережах із якісними каналами передачі (ATM із сталою швидкістю) затримка є стабільною, тоді як у звичайних пакетних мережах вона може відрізнятися залежно від навантаження і конфігурації черг на передачу. Затримка особливо критична для застосунків реального часу. ITU-T Rec. G.114 рекомендує, щоб одностороння затримка для голосових дзвінків залишалася нижчою за 150 мс; при цьому для особливо чутливих розмовних застосунків бажано прагнути до відмітки 100-150 мс, аби користувачі майже не відчували затримки. Для міжнародного VoIP-зв’язку допускається до 300 мс (особливо через супутникові канали), але швидкість передачі голосу падає при перевищенні цих меж. У плануванні мереж зазвичай вважають граничною для всіх сервісів затримку близько 400 мс. Інтерактивні додатки (відеоконференції, онлайн-геймінг, чати) особливо чутливі до затримки: наприклад, для ігор бажано RTT <100 мс. Для потокового відео (несинхронного) дещо вищі затримки терпимі (до ~300 мс), оскільки буфери можуть приховати початкове запізнення. Зате для веб-серфінгу та передачі даних затримка несе меншу критичність: звичайний HTTP-запит все ще сприймається користувачем як швидкий, якщо відповідь надходить за кілька сотень мілісекунд [2]. Приклад впливу явища затримки при передачі даних в комп’ютерних мережах показано на рисунку 1.1. 8 Рисунок 1.1 – Вплив затримки і джитера на передачу даних Загалом рекомендації щодо граничних затримок для різних типів трафіку наведені в таблиці 1.1 нижче. Джитер (або дисперсія затримки) – це варіація затримки пакетів у потоці порівняно з очікуваною регулярністю. Якщо в ідеалі пакети надсилаються з постійними інтервалами, то джитер проявляється, коли в мережі пакети пришвидшуються або гальмуються через нерівномірне навантаження. Cisco визначає джиттер як «варіацію затримки отриманих пакетів»: надсилання пакетів з рівномірним інтервалом переривається, коли на маршрутизаторі виникає перевантаження чи помилка, тому потік завалюється. Унаслідок цього пакети, відправлені рівномірно, прибувають з нерівними інтервалами. Наприклад, один пакет може затримуватися в черзі довше, ніж інші, що призведе до коливання між фактичною та номінальною затримкою. Джиттер критично впливає на застосунки і сервіси реального часу (VoIP, відеодзвінки): велика варіація інтервалів призводить до спотворення потоку. В аудіо-дзвінках надлишкові пакети, що виходять за межі буфера відтворення, відкидаються – в результаті чого виникають пропуски слів і затухання мовлення (рисунок 1.2). Невеликі за обсягом втрати (1-2 пакети) можуть компенсуватись DSP-алгоритмом, але при джитері понад можливості буфера з’являються видимі 9 артефакти. Тобто занадто великий джиттер призводить до переповнення (або виснаження) буфера і видалення запізнілих пакетів, унаслідок чого спостерігаються сильні дефекти звуку [3]. Факторами джитера є перевантаження на маршрутизаторах і з’єднаннях, неузгоджені черги й політики передачі, а також змінні фізичні умови (наприклад, мережеві зміни маршруту). Джиттер зазвичай спричинений затримками через переповнені черги або неправильне налаштування мережі. Для його компенсації застосовують буфери затримки на приймальній стороні, які накопичують вхідні пакети і вивільняють їх рівномірно, згладжуючи нерегулярні інтервали. Водночас буфер сам по собі додає фіксовану затримку – тому його розмір підбирають так, щоб мінімізувати втрати неактуальних пакетів без надмірного збільшення загальної затримки. Також використовують пріоритетні черги (наприклад, Low- Latency Queuing, LLQ) та відстеження діапазону очікуваних інтервалів, щоб пріоритизувати голосовий/відео-трафік і запобігти його затримуванню за іншими потоками. Рисунок 1.2 – Вплив джитера на потокові дані 10 У мережах із високим джитером нерівномірний прийом пакетів викликає розриви у відтворенні голосу чи відео – схожі на показаному випадку. На практиці вважається, що для VoIP-дзвінків джиттер не повинен перевищувати ~30 мс. Рекомендовано утримувати його на рівні ≤30 мс, інакше якість голосу починає помітно погіршуватись. У відеоконференціях аналогічно прагнуть до низького джитера (≈30-50 мс), тоді як для потокового відео (з великим буфером) допускається дещо більша варіабельність – до 50-100 мс. Значення джитера менше 10-20 мс практично непомітні для користувача. Необхідно зазначити, що джиттер менш критичний для нерегулярних мережевих завдань (HTTP, FTP), оскільки для них важливіша загальна затримка та пропускна здатність. Втрата пакетів виникає, коли деякі пакети взагалі не доходять до одержувача. Основні причини втрат – переповнення мережевих пристроїв (черги переповнюються, а пакети відкидаються) або помилки лінійного рівня (бітові помилки на каналі, особливо у бездротових технологіях). У результаті видимі пропуски в аудіо/відеопотоці та повторні запити в TCP. Для різних типів трафіку втрати мають різний вплив: Голос (VoIP). Голосові кодеки чутливі до втрат – при односторонніх дзвінках навіть 1-2% втрат може знизити якість. За даними Cisco, для стандартного G.729 втрата повинна бути значно нижче 1%, а ідеально – практично нульовою. Фактично відсутність втрат (або спеціальні алгоритми компенсації) гарантує максимальну розбірливість голосу. Тобто рекомендується підтримувати втрати ≤1% для VoIP. Відео. Відеокодеки, особливо при потоковому кодуванні (MPEG), також чутливі до втрат: зниклі кадри (особливо I-кадри) можуть спричинити «квадратування» зображення або синхронізаційні проблеми зі звуком. При цьому люди менш сприйнятливі до деяких втрат зображення, ніж мовлення. ITU-G.1010 вказує, що сучасні відеокодеки MPEG-4 забезпечують прийнятну якість навіть при близько 1% втрат кадрів. Оскільки кадри містять залежності 11 між собою, рекомендується підтримувати втрати у відео потоці на рівні не більше 0.5–1%. Найкраще для відео-транспорту орієнтуватися на втрати ≤0.5%, що відповідає найвищим SLA для телеметрії відеоконференцій. Дані (TCP-UDP): Для TCP-додатків втрати призводять до повторної передачі даних, що знижує ефективну пропускну здатність (TCP працює повільніше при втратах). Проте кінцевий користувач зазвичай помічає лише сповільнення завантаження, а не артефакти. Прикладом є HTTP – при втратах деякі запити доведеться перезаписати. Загалом для передачі даних прагнуть до майже нульових втрат: будь-яка втрата потребує повтору, тому бізнес- дані вимагають гарантованої доставки. ITU-G.1010 навіть зазначає, що для інформаційних потоків даних необхідно забезпечити «практично нульову втрату інформації». Підсумовуючи, втрати повинні бути максимально низькими: приблизно 0% для даних, ~1% для голосу (менше 1% для високої якості) і до 0.5-1% для відео (залежно від кодека). Зростання втрат у голосі та відео без компенсації одразу призводить до погіршення якості [3-5]. Пропускна здатність характеризує обсяг даних, який може передаватися через мережу за одиницю часу. Теоретично це максимальна ширина каналу (наприклад, 100 Мбіт/с Ethernet), а фактично – корисна (пропускна) швидкість із урахуванням мережевого накладного трафіку та методів доступу. Важливо відрізняти «ширину каналу» і реальну продуктивну: через накладні заголовки (IP/UDP/RTP, управління) фактичні дані йдуть повільніше. Для оцінки пропускної здатності використовують мережеві тести (наприклад, iperf, NetPerf) або SNMP, але слід враховувати, що пікові швидкості можуть бути недосяжними через затримки та черги. Різні сервіси мають свої потреби по смузі. Голос у звичайному кодеку G.711 потребує ~64 кбіт/с чистого голосу, але із заголовками IP/UDP/RTP реальна потреба зростає до ~80–90 кбіт/с на дзвінок. Для більш стиснутих кодеків, як G.729, достатньо ~8–32 кбіт/с на канал. Відеоконференція потребує орієнтовно від кількох 12 сотень кбіт/с до десятків Мбіт/с, залежно від роздільності і частоти кадрів: HD- відео може потребувати кілька Мбіт/с (наприклад, 2–5 Мбіт/с), 4K – десятки Мбіт/с. Наприклад, для потокового відео Netflix рекомендує ~5 Мбіт/с для HD та ~25 Мбіт/с для 4K. Для веб-серфінгу та передачі файлів достатньо інтернет-каналу від кількох Мбіт/с, але при високих навантаженнях (багато користувачів, великий трафік) потрібна більша смуга, інакше росте затримка та втрати. При цьому мережеві засоби QoS (очікування, передача пріоритетних даних) можуть виділяти полосу критичним потокам, щоб компенсувати обмежену смугу. У підсумку, при плануванні пропускної здатності враховують видані декілька кілобіт (VoIP), мегабіт (відео) і необхідні резерви для пікових навантажень. Всі ці параметри входять до SLA: наприклад, оператори часто обіцяють мінімальну пропускну здатність і гарантоване виділення смуги для голосу/відео. Окрім затримки, джитера, втрат і смуги, QoS може розглядати доступність мережі та якість сприйняття (MOS). Доступність – це частка часу, коли мережа чи канал є працездатним. Зазвичай її вимірюють у відсотках («п’ять дев’яток» = 99.999% часу безвідмовної роботи). У корпоративних мережах прагнуть до 99.9–99.99% на рівні критичних сервісів, щоб забезпечити мінімальні простої. MOS (Mean Opinion Score) – це числова оцінка якості (1–5) на основі суб’єктивного сприйняття. Для голосу MOS ~4.0–4.5 (добре) відповідає майже «телефонній» якості, нижчі значення (1.0–3.5) вказують на помітні дефекти. MOS пов’язана з параметрами QoS (затримка, втрати, шум) через моделі ITU (G.107 E- модель), які перетворюють мережеві показники на прогнозоване сприйняття. Хоча прямого вимірювання MOS у мережі не проводять. Таким чином, повний аналіз QoS враховує доступність і MOS як кінцеві метрики якості користувацького досвіду. Високі значення MOS (близько 4–5) зазвичай досягаються лише за низьких затримок (<150 мс), мізерного джитера (<30 мс) і практично нульових втрат для голосу/відео [4, 6-7]. 13 Таблиця 1.1 - Орієнтовні рекомендовані значення QoS-параметрів Сервіс Одностороння затримка, ≤ Джиттер, ≤ Втрати, ≤ VoIP (голос) 150 мс 30 мс 1 % Відеоконференція 300 мс 50 мс 0.5 % Відеотрансляція 250 мс 100 мс 1 % Веб-дані 400 мс не критичний 0 % Ці дані показують, що VoIP вимагає найжорсткіших параметрів (низька затримка/джитер і майже відсутні втрати). Відеоконференції допускають трохи більшу затримку (до ≈300 мс) і джиттер (до 50 мс), але втрати повинні бути мінімальними (≤0.5%). У потокового відео дещо вища толерантність: буфери приховують частину затримок і коливань, тому затримку можна допускати до кількох сотень мс, а втрати – близько 1% (якщо відеокодек зможе з цим впоратися). Для даних/веб-трафіку критичними є фактично нульові втрати, затримка може доходити до сотень мс без видимого погіршення (тобто 200–400 мс досі забезпечують прийнятну взаємодію), а джиттер не має істотного впливу. 1.2 Моделі QoS Інтегровані сервіси. Архітектура IntServ базується на моделі з кінця 1990-х (RFC 1633) і дозволяє забезпечити наскрізну якість обслуговування для окремих потоків трафіку. Головна ідея – явне резервування ресурсів на кожному етапі шляху передачі. Для цього використовується протокол RSVP (Resource Reservation Protocol): кожен кінцевий вузол надсилає RSVP-запит на резервування смуги пропускання та параметрів затримки, і маршрутизатори в мережі повідомляють про прийняття або відхилення такого запиту. У разі прийняття запиту маршрутизатори фіксують стан ресурсу для конкретного потоку (адреса, порт, кількість виділеної смуги) і забезпечують квалітативні механізми обробки. Типові компоненти в IntServ-маршрутизаторі – це механізм Admission Control (перевірка чи вистачає ресурсів для нового потоку), Classification (класифікація пакету за 14 потоком на основі IP-адрес і портів), Policing (стримування потоку в рамках оголошеного трафіку) та Queuing/Scheduling (розподіл черги відповідно до обраної послуги) [6]. Схема роботи маршрутизатора при застосуванні IntServ показана на рисунку 1.3. Рисунок 1.3 – Схема роботи маршрутизатора при застосуванні IntServ Переваги: IntServ забезпечує гарантовану доставку з необхідними затримками і пропускною здатністю для кожного зарезервованого потоку, що критично для реального часу (наприклад, VoIP, відеоконференції). Недоліки: введення стану для кожного потоку суттєво ускладнює масштабованість. У великих мережах велика кількість потоків потребуватиме великих обсягів пам’яті у маршрутизаторах і постійного оновлення таблиць ресурсів [7-8]. Крім того, багато вузлів не генерують RSVP-запитів, тому IntServ важко застосувати в загальних мережах без спеціального ПЗ на кінцях. Загалом, IntServ вимагає більш складної конфігурації та підтримки. 15 Сфери застосування: IntServ зазвичай використовується в мережах зі строгими SLA, де є потреба у точних гарантіях на передачу (спеціальні корпоративні мережі, VoIP-мережі з вимогами до смуги і затримок). Наприклад, Cisco реалізує функції IntServ через RSVP-агента (Cisco RSVP Agent) для голосових викликів, де на граничних маршрутизаторах встановлюються резерви смуги та маркування DSCP для пріоритезації трафіку. При цьому рекомендується поєднання: використовувати RSVP для управління доступом до ресурсів на прикінцевих маршрутизаторах, а в ядрі мережі застосовувати маркування DiffServ [8-9]. Через необхідність зберігання стану на кожному маршрутизаторі IntServ- модель погано масштабується на великих мережах. Cisco підтримує RSVP і IntServ- реєстрацію на своїх маршрутизаторах, але часто рекомендує використовувати IntServ лише на «краях» мережі (edge), поєднуючи з іншим підходом у ядрі для спрощення. Наприклад, DiffServ і IntServ є взаємодоповнюючими підходами до QoS: перший забезпечує агрегацію і масштабованість, другий – жорсткі гарантії окремих потоків [4]. Архітектура DiffServ визначена стандартами IETF (RFC 2474, RFC 2475) і орієнтована на простоту та масштабованість. Замість управління кожним потоком вона класифікує пакети у кілька службових класів за 6-бітовим полем DSCP у заголовку IPv4/IPv6. На межі (edge) мережі маршрутизатори аналізують пакети (за IP-адресою, портом, протоколом тощо), віднесуть їх до певної категорії і виставляють відповідний код DSCP. Суть – замість багатьох потоків створюється небагато класів з політиками обслуговування. Всередині мережі для кожного DSCP-класу визначається набір Per-Hop Behaviors (PHB) – процедур очікування та відкидання пакетів. Наприклад, EF (Expedited Forwarding) – рівень низьких затримок для VoIP, AF (Assured Forwarding) – декілька пріоритетних класів з різними профілями відкидання, BE – best-effort для фонових сервісів. На рівні ядра маршрутизаторів всі пакети обробляються на основі їх DSCP: порожнини класів мають різні черги й алгоритми (LLQ, WFQ, RED тощо), щоб забезпечити бажану 16 віддачу в умовах черг. Головна перевага DiffServ – висока масштабованість. Оскільки маршрутизаторам не потрібно зберігати стан окремих потоків, системи масштабуються до великої кількості клієнтів і проміжних вузлів. Згідно з документацією Cisco, DiffServ забезпечує «кращу масштабованість», адже позбавлений додаткового обміну сигналами між вузлами і процесів обробки кожного потоку [8-11]. Переваги: DiffServ значно простіше реалізувати – достатньо підтримки класифікації та планувальників черг. Метод придатний до великих мереж (інтернет-провайдери, корпоративні ядра), де важлива гнучка пріоритизація трафіку. Різні класи сервісу дозволяють одночасно задовольняти потреби аудіо-, відео- і даних. Недоліки: DiffServ не надає жорстких кількісних гарантій. Класи забезпечують лише відносне обслуговування: у випадку перевантаження мережі пакети з нижчим пріоритетом можуть втрачатися чи затримуватися. Відсутність централізованого контролю може призводити до суб’єктивних результатів при зонах перекриття адміністративних доменів. Також для ефективної роботи необхідно коректно налаштовувати «обмежувачі» (traffic policing/shaping) на межах домену, щоб пакети кожного класу не перевищували заявлені параметри (наприклад, token bucket для політик [11-12]), як показано на рисунку 1.4. 17 Рисунок 1.4 – Схема алгоритму token bucket Сфери застосування: DiffServ – стандарт для магістральних мереж і великих доменів, де потрібно відокремити трафік за класами. Часто використовується в мережах провайдерів, а також у корпоративних середовищах зі встановленими політиками QoS (ключові сервери, відеоконференції тощо). Взаємодія з іншими моделями: DiffServ добре поєднується з IntServ і MPLS. Наприклад, у гібридних підходах на краях мережі використовується RSVP (для обмеження доступу потоків до ресурсів), а в ядрі застосовується DiffServ- маркування з агрегацією. Крім того, DiffServ трафік можна інкапсулювати в MPLS LSP (DiffServ поверх MPLS), коли IP-пакети маркіруються на вході і при передачі через MPLS ядро обробляються за EXP-бітами міток. Cisco підтримує різні режими інкапсуляції (pipe, uniform тощо) для збереження або перетворення QoS- маркування в MPLS-мережі. Сумарне обмеження трафіку по класах, наприклад при надходженні даних у DiffServ, контролюється подібними механізмами політики (token bucket, leaky bucket), щоб пакети з одного класу не перевищували виділену швидкість. Коли токенів немає (верхня межа), надлишкові пакети скидаються або зменшують пріоритет. Multiprotocol Label Switching (MPLS) – технологія маршрутизації на основі міток, яка має власні засоби передачі QoS. У MPLS заголовок кожного пакету містить мітку (label) з полем EXP (3 біти), яке використовується для збереження інформації про пріоритет обслуговування. Коли IP-пакет інкапсулюється в MPLS LSP, вузол «Ingress LSR» зазвичай копіює DSCP або IP-Precedence у поле EXP, визначаючи відповідний PHB для пакету на всьому шляху. Маршрутизатори (LSR) у середині MPLS-мережі просто виконують переадресацію по мітці та застосовують чергування/відкидання на основі цього EXP. Наприклад, EF-клас може бути відображений на EXP=5 для голосових потоків, що забезпечує низькі затримки. Якщо необхідно, EXP-біт змінюють у кожному вузлі залежно від 18 налаштувань тунелю. Існують різні режимі передачі, які визначають збереження чи зміни DSCP при вході/виході з MPLS-домена. Сучасні мережеві архітектури часто комбінують згадані підходи. Найпоширеніша схема – RSVP на краях і DiffServ в ядрі. У такому сценарії краєві маршрутизатори виконують перевірку доступних ресурсів через RSVP (тобто працюють за схемою IntServ), а після цього трафік пріоритизується й агрегується в DiffServ-класи в магістралі. Такий гібрид дозволяє отримати гарантії для окремих потоків на межах мережі і при цьому зберігає масштабованість в середині: маршрутизатори ядра просто розрізняють DSCP-класи без зберігання стану потоків. За словами Cisco, мережі можуть бути спроектовані так, що RSVP необхідний лише на критичних ділянках, а більша частина каналів обробляється політиками DiffServ [12-14]. Інші приклади комбінування: DiffServ поверх MPLS. IP-пакет отримує маркування DSCP на вході, далі ця інформація передається по MPLS-тунелю у вигляді EXP-маркованого трафіку. У сервіс-провайдерів поширені Pipe та Uniform режими, які визначають, чи переноситься DSCP-маркер на звороті LSP. Для порівняння основних характеристик цих моделей наведено таблицю 1.2. Таблиця 1.2 – Порівняння основних характеристик моделей QoS Модель Масштабованість Точність гарантій Складність впровадження IntServ Низька Висока Висока DiffServ Висока Середня Середня MPLS QoS Висока Висока Висока У наведених схемах враховано сучасні рекомендації стандартів та практик, зокрема RFC 1633 (IntServ), RFC 2474/2475 (DiffServ), RFC 3209 (RSVP-TE), а також відповідні документи Cisco з MPLS QoS і DiffServ. Ці рекомендації показують, що комбінований підхід часто є найбільш оптимальним: наприклад, застосування RSVP для голосових потоків на граничних маршрутизаторах і сервіс- класів DiffServ у магістралі забезпечує як гарантії, так і масштабованість [15]. 19 1.3 Базові компоненти QoS Забезпечення якості обслуговування (Quality of Service, QoS) у корпоративних мережах ґрунтується на низці фундаментальних механізмів, які функціонують узгоджено та формують комплексну систему управління трафіком. До основних компонентів QoS належать: класифікація та маркування пакетів, механізми кондиціонування трафіку (формування і контроль), а також стратегії чергування й планування. Сукупне застосування цих компонентів дозволяє гарантувати пропускну здатність, мінімізувати затримки, підвищувати передбачуваність роботи мережевих сервісів і формувати диференційовані політики обробки трафіку відповідно до потреб. Класифікація пакетів є первинним етапом обробки трафіку в моделі QoS. Вона полягає у відповідному віднесенні мережевих потоків до визначених класів на основі різних параметрів: IP-адрес джерела та призначення, номерів портів, типів протоколів, VLAN-міток, DSCP-бітів, полів транспортного рівня та інших характеристик. У рекомендованому стандарті RFC 2475 зазначено, що коректна класифікація формує основу для подальшої диференціації обслуговування у мережах з підтримкою DiffServ. Контроль якості трафіку у моделі DiffServ реалізується на межах доменів і включає два ключові механізми: формування трафіку та контроль трафіку. Мета цих механізмів – забезпечення відповідності фактичного потоку визначеному профілю трафіку. Після класифікації виконується маркування, яке передбачає проставлення у заголовку пакета визначених значень, що сигналізують обладнанню про клас пріоритету трафіку. Найпоширенішими механізмами маркування є DSCP (Differentiated Services Code Point) для IP-мереж та CoS (Class of Service) для мереж Ethernet (IEEE 802.1p). Маркування відіграє важливу роль у масштабованості QoS, 20 оскільки дозволяє проміжним маршрутизаторам застосовувати політики управління трафіком без необхідності повторної складної класифікації [8, 12]. Варто відзначити, що відповідно до рекомендацій Cisco, маркування слід виконувати на найближчому до джерела трафіку пристрої – так званому вихідному маршрутизаторі або на комутаторі доступу. Це забезпечує узгодженість QoS по всьому шляху проходження трафіку та дозволяє уникати його неправильного трактування всередині мережі. Формування згладжує нерівномірності трафіку шляхом буферизації надлишкових пакетів і випуску їх в мережу рівномірним потоком. Він використовується здебільшого на вихідних інтерфейсах і забезпечує передбачуване навантаження на канал. Формування є корисним при інтеграції мереж з різною пропускною здатністю, особливо коли високошвидкісні сегменти (наприклад, 1-10 GbE) підключаються до каналів із нижчою швидкістю (наприклад, WAN-лінків). Cisco рекомендує застосовувати формування у корпоративних WAN, оскільки воно мінімізує втрату пакетів та покращує роботу сервісів реального часу. На рисунку 1.5 показано послідовність обробки трафіку методами QoS. 21 Рисунок 1.5 – Послідовність і локалізація обробки трафіку методами QoS Черги та алгоритми планування тісно пов’язані з політиками управління навантаженням у мережі та визначають порядок обслуговування пакетів при обмеженій пропускній здатності. Чергування використовується головним чином у вихідному напрямку, де виникає конкуренція за канал передачі. Алгоритми CBWFQ та LLQ рекомендовані Cisco для обслуговування трафіку реального часу, оскільки вони гарантують виділення фіксованого ресурсу та водночас зберігають баланс між класами [3, 5, 11]. Як відомо, в протоколах IPv4 та IPv6 виділені спеціальні поля саме для застосування можливих технологій та механізмів QoS. Причому у протоколі IPv6 технологія QoS вбудована, завдяки якій визначаються чутливі до затримки пакети. На рисунку 1.6 показано заголовки протоколів рівня 3 – IPv4 та IPv6 з позначеними схожими та відмінними полями. 22 Рисунок 1.6 – Заголовки протоколів IPv4 та IPv6 Саме поля Клас трафіку у IPv6 та Тип сервісу у IPv4 будуть відповідати за маркування та обробку пріоритетів механізмами QoS. 1.4 Висновки до розділу 1 У розділі було розглянуто основні теоретичні засади забезпечення якості обслуговування в корпоративних мережах. Параметри QoS, такі як затримка, джиттер, втрата пакетів та пропускна здатність, визначають якість роботи сервісів реального часу та мережевих додатків і виступають критичними показниками продуктивності мережі. Розглянуті моделі QoS – IntServ, DiffServ та MPLS QoS – демонструють різні підходи до надання гарантованих рівнів обслуговування, від індивідуального резервування ресурсів до масштабованої диференціації трафіку. Базові компоненти QoS, зокрема класифікація, маркування, формування, політики та механізми чергування, формують інструментарій адміністратора для управління трафіком і забезпечення відповідності мережі вимогам SLA. Сукупність цих 23 концепцій створює теоретичну основу, необхідну для розроблення ефективних методів QoS та їх подальшого впровадження у корпоративних інфраструктурах. 24 РОЗДІЛ 2 МЕХАНІЗМИ ВПРОВАДЖЕННЯ ТЕХНОЛОГІЙ QOS У сучасних корпоративних мережах затримки, втрата пакетів та обмежена пропускна здатність можуть негативно впливати на критичні додатки (VoIP, відеоконференції, ERP тощо). Тому застосовують механізми Quality of Service (QoS), які дають змогу диференціювати обслуговування різних класів трафіку. Однією з основних архітектур на даний час є модель Differentiated Services (DiffServ), що класифікує та маркує пакети за 6-бітним полем DSCP в IP-заголовку. Поєднання DSCP і ECN полів замінило старе поле IPv4 TOS. У DiffServ кожен пакет належить до одного з обмеженої кількості класів обслуговування, визначених політикою мережі. Класифікація й маркування виконується на межі домену, а ядро мережі застосовує per-hop behavior (PHB) залежно від відмітки пакета. При цьому DiffServ – грубий (coarse-grained) механізм управління трафіком, що масштабовано працює за рахунок спрощення обробки в ядрах мережі. Поведінка на основі вузла (Per-Hop Behavior) містять: Default Forwarding (DF) або Best-Effort (DSCP=0) – найпростіший режим без гарантій; Expedited Forwarding (EF) – забезпечує мінімальні затримки, втрати та варіації затримки (зокрема, для голосового трафіку); Assured Forwarding (AF) – чотири класи з трьома рівнями пріоритету відкидання (drop precedence) у кожному класі. Наприклад, AF дає змогу гарантувати пропускну здатність до підписаної межі, а надлишок трафіку отримує вищу імовірність скидання. Для підтримки сумісності з IP Precedence визначені Class Selector PHB (CS0–CS7) на основі кодування «xxx000» [11, 13-16]. Впровадження DiffServ знижує навантаження на мережеві пристрої і добре масштабується у великих мережах. Воно також дозволяє поєднувати обладнання з різними пристроями QoS і зберігати існуючі схеми ToS/DSCP. Проте обмеженням є відсутність тонкого управління на рівні окремого потоку: DiffServ гарантує обслуговування не для конкретного сеансу, а лише для класу трафіку. Тому необхідні довірені політики на краях мережі (edge) та механізми контролю входу трафіку, щоб уникнути перевантажень. Крім того, DiffServ є крупнозернистим 25 підходом (на відміну від IntServ) – ядро обробляє пакети простими правилами PHB, а не складною класифікацією [15-17]. 2.1 Класифікація та маркування Перш ніж можна буде застосувати будь-який механізм QoS (Якості Обслуговування), IP-трафік спочатку має бути ідентифікований та класифікований на різні класи, ґрунтуючись на бізнес-вимогах. Мережеві пристрої використовують класифікацію, щоб ідентифікувати належність IP-трафіку до певного класу. Після класифікації IP-трафіку можна використовувати маркування для позначення окремих пакетів, щоб інші мережеві пристрої могли застосовувати механізми QoS до цих пакетів під час їхнього проходження мережею. Класифікація пакетів — це механізм QoS, відповідальний за розрізнення різних потоків трафіку. Він використовує дескриптори трафіку для віднесення IP- пакету до певного класу. Класифікація пакетів повинна відбуватися на краю мережі, якомога ближче до джерела трафіку. Після того, як IP-пакет класифіковано, пакети потім можуть бути марковані/перемарковані, поставлені в чергу, контрольовані (policed), сформовані (shaped) або піддані будь-якій комбінації цих та інших дій. Типові дескриптори трафіку, що використовуються для класифікації: Внутрішні: групи QoS (мають локальне значення для маршрутизатора). Рівень 1: фізичний інтерфейс, підінтерфейс або порт. Рівень 2: MAC-адреса та біти класу обслуговування 802.1Q/p (CoS). Рівень 2.5: експериментальні біти MPLS (EXP). Рівень 3: коди диференційованих сервісів (DSCP), пріоритет IP (IPP), а також IP-адреса джерела/призначення. Рівень 4: порти TCP або UDP. Рівень 7: розпізнавання застосунків мережевого рівня нового покоління (NBAR2). 26 Для корпоративних мереж найчастіше для класифікації використовуються дескриптори трафіку рівнів 2, 3, 4 та 7, наведені вище. NBAR2 має два режими роботи [18]: Protocol Discovery (виявлення протоколів): цей режим дає змогу NBAR2 виявляти та отримувати статистику в реальному часі про застосунки, що наразі працюють у мережі. Ці статистичні дані з режиму Protocol Discovery можуть бути використані для визначення класів і політик QoS за допомогою конфігурації MQC. Modular QoS CLI (MQC): за допомогою MQC мережевий трафік, що відповідає певному мережевому протоколу, наприклад Cisco Webex, може бути віднесений до одного класу трафіку, тоді як трафік, що відповідає іншому протоколу, наприклад YouTube, може бути віднесений до іншого класу. Після такої класифікації трафіку до різних класів можуть застосовуватися різні політики QoS. Маркування пакетів – це механізм QoS, який «забарвлює» пакет шляхом зміни певного поля в заголовку пакета або кадру за допомогою дескриптора трафіку, щоб відрізнити його від інших пакетів під час застосування інших механізмів QoS (таких як повторне маркування, застосування політик, керування чергами або уникнення перевантажень) [8, 11, 19]. Для маркування трафіку використовуються такі дескриптори: Внутрішні (Internal): групи QoS. Рівень 2: біти класу обслуговування 802.1Q/p (CoS). Рівень 2.5: експериментальні біти MPLS (EXP). Рівень 3: коди диференційованих сервісів (DSCP) та пріоритет IP (IPP). Стандарт 802.1Q є специфікацією IEEE для впровадження VLAN (віртуальних локальних мереж) у комутованих мережах Рівня 2. Специфікація 802.1Q визначає два поля по 2 байти: ідентифікатор протоколу тегу (Tag Protocol Identifier, TPID) та інформація керування тегом (Tag Control Information, TCI), які 27 вставляються в кадр Ethernet після поля Адреса Джерела (Source Address), як показано на рисунку 2.1. Рисунок 2.1 – 802.1Q рівня 2 з використанням 802.1р CoS Значення TPID є 16-бітовим полем, якому присвоєно значення 0x8100, що ідентифікує його як кадр, позначений тегом 802.1Q. Поле TCI (Tag Control Information — Інформація керування тегом) є 16- бітовим полем, що складається з наступних трьох полів: Поле Код точки пріоритету (Priority Code Point, PCP) (3 біти). Поле Індикатор придатності до відкидання (Drop Eligible Indicator, DEI) (1 біт). Поле Ідентифікатор VLAN (VID) (12 бітів). Специфікації 3-бітового поля PCP визначені специфікацією IEEE 802.1p. Це поле використовується для маркування пакетів як належних до певної CoS (Class of Service – Клас обслуговування). Маркування CoS дозволяє позначати кадр Ethernet Рівня 2 восьма різними рівнями пріоритету, від 0 до 7, де 0 є найнижчим пріоритетом, а 7 – найвищим. Таблиця 2.1 містить стандартне визначення специфікації IEEE 802.1p для кожного CoS. 28 Таблиця 2.1 – Визначення CoS IEEE 802.1p Значення PCP/Пріоритет Акронім Тип Трафіку 0 (найнижчий) BK Фоновий (Background) 1 (за замовчуванням) BE Найкраща спроба (Best effort) 2 EE Відмінна спроба (Excellent effort) 3 CA Критичні додатки (Critical applications) 4 VI Відео з затримкою та джитером <100 мс 5 VO Голос із затримкою та джитером <10 мс 6 IC Керування міжмережевим обміном (Internetwork control) 7 (найвищий) NC Керування мережею (Network control) Основний недолік маркування CoS полягає в тому, що кадри втрачають його при проходженні через не-802.1Q з'єднання або мережу Рівня 3. Для збереження наскрізного маркування, пакети повинні бути позначені маркуванням вищого рівня. Це зазвичай досягається шляхом мапування маркування CoS на інше маркування, наприклад, на значення IP Precedence (пріоритет IP) у Type of Service (ToS) пакетів IPv4. Використання маркування Рівня 3 (наприклад, полів ToS/DiffServ у заголовку IPv4, що показані на рисунку 2.2) забезпечує більш стійкий маркер, який зберігається в наскрізному з’єднанні. DEI (Індикатор придатності до відкидання) – це 1-бітове поле, яке може використовуватися разом із PCP або незалежно, щоб вказати, що кадри придатні до відкидання (значення 1) під час перевантажень. Значення 0 (за замовчуванням) вказує, що кадр не придатний до відкидання. Пакети класифікуються та маркуються для отримання певної поведінки пересилання на один перехід (per-hop forwarding behavior, PHB) (прискорення, затримка або відкидання) на мережевих вузлах [11, 14-15]. Поле DiffServ використовується для маркування пакетів відповідно до їх класифікації в агрегатах поведінки DiffServ (BA). PHB – це зовнішньо спостережувана поведінка пересилання, застосована на DiffServ-сумісному вузлі до сукупності пакетів з однаковим значенням DiffServ (DiffServ BA). 29 Рисунок 2.2 – Поля IPv4 ToS та DiffServ PHB – це прискорення, затримка або відкидання пакетів на основі значення DSCP. Ядро мережі виконує лише просту PHB, а край мережі виконує класифікацію, маркування та контроль, що робить модель QoS DiffServ дуже масштабованою. Визначено чотири основні PHB: PHB селектора класу (CS): перші 3 біти DSCP використовуються для зворотної сумісності з IP Precedence. PHB пересилання за замовчуванням (DF): використовується для сервісу типу без гарантій (best-effort). PHB гарантованого пересилання (AF): використовується для сервісу з гарантованою пропускною здатністю. PHB прискореного пересилання (EF): використовується для сервісу з низькою затримкою. Документ RFC 2474 [14] зробив поле ToS застарілим, представивши поле DiffServ, а PHB CS було визначено для забезпечення зворотної сумісності DSCP з IP Precedence. Рисунок 2.3 ілюструє CS PHB. Пакети з вищим IP Precedence повинні пересилатися за менший час, ніж пакети з нижчим. Останні 3 біти DSCP (біти з 2 по 4), коли встановлені в 0, ідентифікують PHB селектора класу, але саме біти з 5 по 7 є тими, де встановлюється IP Precedence. Біти з 2 по 4 ігноруються пристроями, які не 30 відповідають стандарту DiffServ та виконують класифікацію на основі IP Precedence. Існує вісім класів CS, в діапазоні від CS0 до CS7, які безпосередньо відповідають восьми значенням IP Precedence. Рисунок 2.3 – PHB селектора класу (CS) PHB пересилання за замовчуванням (DF) та CS0 забезпечують поведінку типу без гарантій і використовують значення DSCP 000000. Рисунок 2.4 ілюструє DF PHB. Рисунок 2.4 – PHB пересилання за замовчуванням (DF) PHB пересилання за замовчуванням також застосовується до пакетів, які не можуть бути класифіковані механізмом QoS, таким як постановка в чергу, формоутворення або контроль. PHB гарантованого пересилання (AF) гарантує певний обсяг пропускної здатності для класу AF і дозволяє доступ до додаткової полоси, якщо вона доступна. Пакети з AF PHB маркуються значенням DSCP aaadd0. Aaa – це двійкове значення класу AF (біти 5-7), а dd (біти 2-4) – ймовірність відкидання. Біт 2 завжди 31 встановлено на 0. Існує чотири стандартні класи AF: AF1, AF2, AF3 і AF4. Номер класу AF не позначає пріоритет наприклад, AF4 не має переваги над AF1. Кожен клас слід обробляти незалежно, розміщуючи його в окремій черзі (рисунок 2.5). Рисунок 2.5 – PHB гарантованого пересилання (AF) Реалізація AF повинна виявляти та реагувати на довготривалу перевантаженість у межах кожного класу шляхом відкидання пакетів за допомогою алгоритму уникнення перевантаженості, такого як зважене випадкове раннє виявлення (WRED). WRED використовує значення ймовірності відкидання AF у межах кожного класу – де 1 є найнижчим можливим, а 3 – найвищим – для визначення того, які пакети слід відкинути в першу чергу під час періодів перевантаженості. Вона також повинна мати можливість справлятися з короткочасною перевантаженістю, спричиненою сплесками, якщо кожен клас розміщено в окремій черзі, використовуючи алгоритм чергування, такий як зважене справедливе чергування на основі класів (CBWFQ). Специфікація AF не визначає використання будь-яких конкретних алгоритмів для чергування та уникнення перевантаженості, але вона встановлює вимоги та властивості таких алгоритмів. PHB прискореного пересилання (EF) може використовуватися для створення наскрізного сервісу з низькими втратами, низькою затримкою, низьким джитером (коливанням затримки) та гарантованою пропускною здатністю. EF PHB гарантує пропускну здатність, забезпечуючи мінімальну швидкість відправлення, та надає 32 найнижчу можливу затримку для чутливих до затримки застосунків шляхом впровадження чергування з низькою затримкою. Він також запобігає «голодуванню» інших застосунків або класів, які не використовують EF PHB, шляхом контролю трафіку при виникненні перевантаженості. Пакети, що вимагають EF, повинні бути позначені двійковим значенням DSCP 101110 (46 у десятковій системі). Біти 5–-7 (101) значення DSCP EF безпосередньо відповідають IP Precedence 5 для забезпечення зворотної сумісності з пристроями, що не відповідають стандарту DiffServ. IP Precedence 5 є найвищим значенням IP Precedence, що може бути визначене користувачем, і використовується для чутливого до затримок трафіку в реальному часі (наприклад, VoIP) [8, 14, 19-20]. Клас «Scavenger» надає послуги гірші, ніж без гарантій. Він призначений для розважальних застосунків, які не мають бізнес-цінності (наприклад, Torrent, Netflix) і часто блокуються або обмежуються. Оскільки клас «Scavenger» має бути нижчим за пріоритетом, ніж без гарантій (які використовують DSCP 000000/CS0), для нього було визначено маркування CS1 (RFC 4594). Для забезпечення масштабованої QoS маркування пакетів має відбуватися на межі довіри. Комутатор, до якого підключений кінцевий вузол, може бути налаштований на довіру або недовіру маркуванню (CoS/DSCP), встановленому кінцевою точкою. Якщо комутатор довіряє, він приймає маркування. Якщо не довіряє, він відхиляє його, перекласифікуючи та перемарковуючи пакет сам. Наприклад, IP-телефони маркують голосовий трафік високим пріоритетом (DSCP 46/EF), але за замовчуванням не довіряють трафіку, що надходить від підключеного до них ПК, обнуляючи його CoS та DSCP (встановлюючи 0/0). Це дозволяє комутатору на наступному етапі класифікувати голос як вищий пріоритет. Для масштабованості межа довіри повинна бути якомога ближче до кінцевого вузла (1 і 2 – оптимально; 3 – лише якщо комутатор доступу не підтримує класифікацію). 33 Рисунок 2.6 – Розміщення межі довіри 2.2 Контроль та формування трафіку Контролери (policers) та формувачі (shapers) – це є механізмами QoS упорядкування трафіку, що використовуються для класифікації та застосування інших механізмів QoS, таких як обмеження швидкості. Вони класифікують трафік однаково, але відрізняються у реалізації [19-21]: Контролери (policers) – відкидають або перемарковують вхідний чи вихідний трафік, який перевищує бажану швидкість трафіку. Формувачі (shapers) – буферизують та затримують швидкість вихідного (egress) трафіку, який тимчасово перевищує бажану швидкість, доки швидкість вихідного трафіку не опуститься нижче визначеної швидкості. 34 Якщо швидкість вихідного трафіку нижча за бажану, трафік надсилається негайно. Контролери для вхідного трафіку оптимально розміщувати на краю мережі, щоб запобігти витрачанню трафіком цінної пропускної здатності в ядрі мережі. Контролери для вихідного трафіку оптимально розміщувати на краю мережі або на інтерфейсах мережевих пристроїв, спрямованих до ядра. Недоліком цього механізму є те, що він спричиняє повторну передачу TCP, коли відкидає трафік. Робота обох механізмів показана на рисунку 2.7. Рисунок 2.7 – Контроль та формування трафіку 35 Формувачі використовуються для вихідного трафіку та зазвичай розгортаються корпоративними мережами на інтерфейсах, що з'єднані з провайдерами послуг (ISP). Формування корисне у випадках, коли ISP контролюють вхідний трафік, або коли ISP не контролюють трафік, але мають угоду про рівень обслуговування (SLA) з максимальною швидкістю трафіку, порушення якої може призвести до грошових штрафів. Формувачі буферизують та затримують трафік, замість того, щоб його відкидати, і це спричиняє менше повторних передач TCP порівняно з контролерами. Коли бажана швидкість трафіку перевищена, контролер може: відкинути трафік; перемаркувати надлишковий трафік, знижуючи його пріоритет (markdown). Останнє передбачає перемаркування пакетів на нижчий пріоритет. Наприклад, надлишковий трафік, позначений як AFx1, може бути перемаркований на AFx2 (або AFx3 при дворівневому контролі). Після цього для уникнення перевантаженості використовується WRED (Weighted Random Early Detection), який агресивніше відкидає пакети з нижчим пріоритетом (наприклад, AFx3 агресивніше, ніж AFx2). Контролери та формувачі Cisco IOS базуються на алгоритмах маркерного відра (token bucket). Графічне зображення алгоритму одношвидкісного одномаркерного відра показане на рисунку Рисунок 2.8. Наступний список містить визначення, які використовуються для пояснення того, як працюють алгоритми token bucket [19, 22]. Швидкість передачі інформації (CIR) – швидкість контрольованого трафіку в бітах за секунду, визначена в контракті. Гарантований часовий інтервал (Tc) – часовий інтервал, у мілісекундах (мс), протягом якого надсилається гарантований імпульс (Bc). Tc може бути розрахований за формулою: 36 Гарантований розмір імпульсу (Bc) – максимальний розмір маркерного відра CIR, виміряний у байтах, і максимальний обсяг трафіку, який може бути надісланий протягом Tc. Bc може бути розрахований за формулою: Маркер (token) – один токен представляє 1 байт або 8 бітів. Маркерне відро (token bucket), яке накопичує маркери, доки не буде досягнута максимальна попередньо визначена кількість маркерів (наприклад, Bc при використанні одного маркерного відра). Ці маркери додаються у відро з фіксованою швидкістю (CIR). Кожен пакет перевіряється на відповідність визначеній швидкості і отримує токени з відра, дорівнюючи розміру пакета – наприклад, якщо розмір пакета становить 1500 байт, він забирає 12 000 біт (1500 x 8) з відра. Якщо у відрі токенів недостатньо токенів для передачі пакета, механізм обробки трафіку може виконати одну з таких дій: ■ буферизувати пакети, чекаючи, поки в маркерному відрі накопичиться достатня кількість маркерів (формування трафіку); ■ відкинути пакети (контроль трафіку); ■ позначити пакети (контроль трафіку). Рекомендується, щоб значення Bc було більшим або дорівнювало розміру найбільшого можливого IP-пакета у потоці трафіку. Інакше, у маркерному відрі ніколи не буде достатньо маркерів для більших пакетів, і вони завжди перевищуватимуть визначену швидкість. Якщо відро заповнюється до максимальної ємності, щойно додані маркери відкидаються. Відкинуті маркери недоступні для використання майбутніми пакетами [6, 9]. 37 Рисунок 2.8 – Алгоритм роботи одинарного маркерного відра Алгоритми маркерного відра можуть використовувати одне або кілька маркерних відер. Для алгоритмів з одним маркерним відром виміряна швидкість трафіку може відповідати визначеній швидкості трафіку або перевищувати її. Виміряна швидкість трафіку відповідає нормі, якщо в маркерному відрі достатньо маркерів для передачі трафіку. Виміряна швидкість трафіку перевищує норму, якщо в маркерному відрі недостатньо маркерів для передачі трафіку. 2.3 Керування та уникнення перевантаження Керування перевантаженістю включає поєднання чергування та планування. Чергування (також відоме як буферизація) – це тимчасове зберігання надлишкових пакетів. Воно активується, коли вихідний інтерфейс відчуває перевантаження, і деактивується, коли перевантаження зникає. Перевантаження виявляється, коли апаратна черга Рівня 1 на фізичних інтерфейсах, відома як кільце передачі (Tx-ring або TxQ), заповнена. 38 Коли відбувається перевантаження, пакети можуть бути переупорядковані алгоритмами чергування, щоб пакети з вищим пріоритетом вийшли раніше. Алгоритм планування вирішує, який пакет передавати наступним. Планування завжди активне, незалежно від того, чи відчуває інтерфейс перевантаження. Рекомендовані алгоритми чергування для мереж із насиченим медіаконтентом можуть бути такими: Зважене справедливе чергування на основі класів (CBWFQ): Дозволяє створювати до 256 черг, обслуговуючи до 256 класів. Кожна черга обслуговується на основі призначеної пропускної здатності. Пропускна здатність, призначена класу, є мінімальною гарантованою пропускною здатністю під час перевантаження. CBWFQ не надає гарантії затримки і підходить лише для трафіку даних не-реального часу [15, 19]. Чергування з низькою затримкою (LLQ): Це CBWFQ у поєднанні з пріоритетним чергуванням (PQ) (рисунок 2.9). Рисунок 2.9 – Зважене справедливе чергування на основі класів з низькою затримкою 39 Трафік, призначений черзі суворого пріоритету, обслуговується до своєї призначеної пропускної здатності, перш ніж обслуговуються інші черги CBWFQ. LLQ надає як гарантії затримки, так і пропускної здатності для високо- пріоритетного трафіку реального часу. Під час перевантаження класи пріоритету LLQ контролюються, щоб гарантувати, що трафік без пріоритету не «голодує». 2.4 Висновки до розділу 2 В цьому розділі було розглянуто принципи роботи механізмів QoS, зокрема механізми керування трафіком, такі як чергування, формування, контролювання трафіку і контроль перевантажень. Показано, що ефективне поєднання цих технологій дає змогу забезпечити пріоритетну передачу критично важливих даних, зменшити затримки, втрати пакетів і варіацію затримки. Отримані результати створюють теоретичну основу для проєктування та моделювання систем QoS у корпоративних мережах. 40 РОЗДІЛ 3 ВПРОВАДЖЕННЯ QOS В КОРПОРАТИВНУ МЕРЕЖУ Ефективність механізмів забезпечення якості обслуговування безпосередньо залежить від коректного вибору їх числових параметрів, зокрема швидкостей передачі, розмірів буферів та параметрів алгоритмів керування трафіком. Особливе значення мають параметри алгоритмів маркерного відра та двовідерних контролерів, які визначають допустимі середні та пікові навантаження в мережі. Некоректний розрахунок таких параметрів може призвести до перевантажень, втрат пакетів або неефективного використання пропускної спроможності каналів зв’язку. Тому в даному розділі розглядається методика вибору та розрахунку параметрів механізмів контролю трафіку, а також моделювання роботи корпоративної мережі з підтримкою QoS з метою оцінювання її продуктивності та стійкості до перевантажень. 3.1 Розрахунок одношвидкісного триколірного маркерного відра Алгоритм одношвидкісного триколірного маркерного відра (srTCM) базується на RFC 2697. Цей тип контролера використовує два маркерних відра, і трафік може бути класифікований як відповідний, перевищуючий або порушуючий щодо швидкості надходження маркерів (CIR). Для кожного з трьох станів трафіку виконуються дії з маркування або скидання. Перше маркерне відро працює дуже схоже на одношвидкісну двокольорову систему (рисунок 3.1). Ключова відмінність полягає в тому, що якщо після кожного періоду часу в цьому відрі залишаються невикористані маркери (через низьку або відсутню активність), то замість того, щоб скидати надлишкові (переповнення), алгоритм переміщує їх у друге. Ці маркери, поміщені у друге відро, призначені для використання пізніше для тимчасових сплесків, які можуть перевищувати CIR. Маркери, розміщені у цьому другому відрі, відповідають параметру надлишкового імпульсу (Be). Це 41 максимальна кількість бітів, які можуть перевищувати гарантований розмір імпульсу (Bc), використовуючи маркери з другого відра. Рисунок 3.1 – Алгоритм одношвидкісного триколірного маркерного відра За допомогою механізму двох маркерних відер трафік класифікується у трьох кольорах або станах: Відповідний (зелений) – це трафік, який не перевищує доступний розмір Bc. Відповідний трафік зазвичай передається і може бути опціонально перемаркований (наприклад, встановлено вищий пріоритет). 42 Перевищуючий (жовтий) – це трафік, який перевищує Bc, але не перевищує доступний розмір Bе (тобто використовує маркери з другого відра). Перевищуючий трафік може бути знижений у пріоритеті і переданий. Порушуючий (червоний) – це трафік, який перевищує Bе. Цей тип трафіку зазвичай скидається, але може бути опціонально знижений у пріоритеті та переданий. Для розрахунку роботи алгоритму одношвидкісного триколірного маркерного відра встановлено наступні типові вихідні дані, які часто використовують у корпоративних сценаріях (запас для піків, підтримка голосу + відео): Пропускна здатність інтерфейсу (лінія): 1 Гб/с = 1 000 000 000 біт/с. Швидкість надходження маркерів (CIR): 120 Мб/с = 120 000 000 біт/с. Пікова швидкість передачі інформації (PIR): 200 Mbps = 200 000 000 біт/с. Гарантований розмір імпульсу (Bc): 12 000 000 біт (≈12 Mb). Надлишковий імпульс (Be): 24 000 000 біт (≈24 Mb). Розмір пакета (MTU) для розрахунків: 1500 байт = 12 000 біт. Bc і Be часто задають в бітах на основі очікуваних піків і RTT. Для двовідерного (two-rate) алгоритму використовуються інтервали часу, в яких може бути передано відповідний обсяг: Інтервал часу для Bc: мс. Інтервал часу для Bе: мс. Кількість інтервалів за секунду: інтервалів. 43 інтервалів. Кількість пакетів, які вміщують відповідні відра у межі одного інтервалу: пакетів. пакетів. Максимально дозволені пакети за секунду: пакетів/с. пакетів/с. Час, необхідний для передавання пакетів по лінії 1 Гб/с одного Tc та одного Te для : мс. Це час, за який по фізичній лінії будуть передані 1000 пакетів за умови, що лінія вільна. Пояснення та інтерпретація отриманих результатів: Відповідає (в рамках CIR): за вихідними даними дозволено 10 000 пакетів/с (≈120 Mbps при 1500-байтних пакетах) – це гарантований середній потік. У кожному Тс=100 мс інтервалі можна передати до 1000 пакетів (і таких інтервалів 10 → 10×1000 = 10 000 пакетів/с). Перевищує (понад CIR, але ≤ PIR): за потреби короткочасно дозволяється додатково до ~6 666 пакетів/с (різниця між PIR і CIR у пакетах/с), тобто загалом до ≈16 666 пакетів/с. Це реалізується через Be і PIR: в кожному Те=120 мс інтервалі можна передати до 2000 пакетів; у середньому це дає ті самі ≈16 666 пакетів/с. 44 Якщо трафік перевищує PIR – пакети «Порушує» (відкидаються або знижуються в пріоритеті/маркуванні). Додаткові зауваження і рекомендації в реальних умовах. 1. Округлення і практичність. У реальному обладнанні параметри Bc/Be часто задаються в байтах або як числа пакетів, і їх підбирають так, щоб уникнути дробових пакетів у інтервалі. 2. При надходженні потоку пакетів лічильники маркерів зменшуються по черзі: спочатку використовуються виділені основні токени (Bc/CIR), якщо їх немає – дозволяється використати надлишкові (Be/PIR), якщо і надлишкові вичерпано – пакети вважаються такими, що порушують умови і скидаються або понижуються в пріоритеті. 3. Чим керуватись при виборі CIR/PIR/Bc/Be: вибір CIR залежить від потреб бізнес-сервісів (число одночасних дзвінків × біт/дзвінок + відео), PIR — від очікуваних піків; Bc/Be — від того, наскільки довгі/часті сплески допускаються (часто Bc ≈ CIR × RTT, Be — надлишок для піків). 4. Бізнес-вимоги/SLA – скільки одночасних дзвінків (VoIP), скільки відеоконференцій, які мінімальні MOS, які затримки та втрати допускаються. Це задає мінімальний CIR під сервіси. 5. Моніторинг трафіку (NetFlow/sFlow/IPFIX, SNMP, flow-stats) – реальні пікові та середні швидкості в біт/с визначають PIR (пікові значення), а CIR – гарантовану середню. 6. Виміри IP SLA/synthetic tests – визначають фактичні RTT, джиттер і допомагають підібрати Bc (наприклад Bc ≈ CIR × RTT). 7. Відомі типові величини кодеків і сервісів — наприклад, G.711 ≈ 64 kbps (+ заголовки ≈ 80-90 kbps) на дзвінок; відео HD ≈ 2–5 Mbps; онлайн відео 4K ≈ 15–25 Mbps. Це дає орієнтир для CIR на сервіс. 8. Рекомендації виробника (Cisco QoS guides) і стандарти (IETF RFCs, ITU) – використовують для вибору номінальних параметрів і порогів WRED/черг. 45 3.2 Використання модульного фреймворку QoS на пристроях Cisco Налаштування якості обслуговування (QoS) на пристроях Cisco зазвичай виконується за допомогою модульного фреймворку QoS CLI (MQC). Для цього використовують команди class-map, policy-map, service-policy для увімкнення класифікації та маркування на пристрої (рисунок 3.2). MQC організовує процес налаштування в наступні три кроки: Крок 1. Класифікація пакетів за допомогою команди class-map. Він визначає параметри для узгодження пакетів у класах трафіку. Крок 2. Налаштування політики QoS з діями (позначення, формування, контроль, черга) за допомогою команди policy-map. Вона визначає дію, яку політика вживає до кожного класу трафіку. Крок 3. Приєднання політики QoS до інтерфейсу за допомогою команди service-policy. Рисунок 3.2 – Модульний фреймворк QoS CLI (MQC) 46 Команда class-map зіставляє трафік у клас трафіку. Карта класу має три елементи: ім'я, визначене адміністратором, серія з одного або декількох операторів відповідності, і параметр (match-all або match-any), який повідомляє карті класу, як оцінити оператори відповідності. На наступній діаграмі наведено приклади класів трафіку. Рисунок 3.3 – Діаграми прикладів класів трафіку Команди match визначають критерії класифікації пакетів. Пакети оцінюються, щоб побачити, чи відповідають вони заданим критеріям. Якщо пакет збігається, він вважається учасником класу трафіку. Пакети, які не відповідають будь-яким критеріям, присвоюються класу трафіку за замовчуванням (class- default). Далі показано лістинг налаштування класу трафіку. class-map TRAFFIC-CLASS-1 match statement 1 match statement 2 match statement 3 match statement n Клас трафіку може мати кілька інструкцій про збіги, як показано вище. Отже, пристрій повинен знати, яку логіку потрібно виконати при налаштуванні класу трафіку з декількома критеріями відповідності. Саме тут в гру вступає наступний параметр. Під час налаштування нової карти класів може бути вказано або match-any, або match-all, щоб визначити, як оцінюються критерії відповідності. В першому 47 випадку пакет відповідає класу тільки в тому випадку, якщо він задовольняє всі умови. Це означає, що він використовує "І" логіку. В другому – пакет відповідає класу, якщо він задовольняє принаймні одну з умов. Це означає, що він використовує логіку "OR". Наступний приклад показує, як потрібно налаштовувати карти класів через CLI. ! Notice that IP CEF is required for class-based QoS. ! It is configured by default on all modern platforms. ! However, if not, the device would reject the service-policy command. ip cef ! First class map matches RTP traffic based on an ACL. ! Notice that it is match-all (by default). class-map VOIP-TRAFFIC match access-group name RTP ! ! Second class map matches WEB-TRAFFIC based on two ACLs. ! Notice that it is match-any. class-map match-any WEB-TRAFFIC match access-group name HTTP match access-group name HTTPS ! ! The class maps call one or more access-lists for matching. ip access-list extended HTTP 10 permit tcp any any eq 80 ip access-list extended HTTPS 10 permit tcp any any eq 443 ip access-list extended RTP 10 permit udp any any range 16384 32767 ! Команда policy-map пов'язує карти класів з певними діями, такими як маркування, керування, формування, черги або відкидання трафіку, як показано на рисунку 3.4. Наприклад, співставляється трафік ICMP з картою класу. Потім, всередині команди policy-map, посилаються на карту класу ICMP і налаштовується дія. Наступне виведення показує, як налаштовується карта політики за допомогою CLI. 48 Рисунок 3.4 – Карта політик ! The policy map associates actions each of the two class maps. ! The actions are set, meaning this policy marks traffic. policy-map QOS_POLICY class VOIP-TRAFFIC set dscp EF class WEB-TRAFFIC set dscp AF31 Карта політики сама по собі нічого не робить, якщо вона не прикріплена до інтерфейсу. Команда service-policy використовується для прикріплення карти політики до інтерфейсу або площини керування. Він забезпечує дотримання правил трафіку, визначених у карті політики. Її можна застосувати до вхідного або вихідного трафіку на інтерфейсі. Вона активує такі функції, як маркування, черга, формування або контроль, як вказує карта політики. Switch# conf t Switch(config)# interface GigabitEthernet0/0/1 Switch(config-if)# service-policy ? input Assign policy-map to the input of an interface output Assign policy-map to the output of an interface Switch(config-if)# service-policy input QOS_POLICY Switch(config-if)# end Після того, як політика трафіку прикріплена до інтерфейсу, ми можемо відстежувати трафік, який надходить у кожен клас трафіку. 49 3.3 Моделювання та налаштування QoS В якості прикладу для моделювання корпоративної мережі складено просту схему із використанням маршрутизаторів для формування підмереж. Топологія показана на рисунку 3.5. Попередньо було налаштовано віртуальні локальні мережі для голосу та даних, налаштовано сервіс ІР-телефонії на маршрутизаторах, статичну маршрутизацію, під’єднано телефони та налаштовано номери та лінії виклику [23]. Рисунок 3.5 – Модельна топлогія корпоративної мережі Для налаштування QoS на канальному рівні (відповідає комутатор) потрібно увімкнути trust DSCP/COS на портах, а на маршрутизаторі увімкнути класифікацію VoIP трафіку (NBAR або ACL). Також промаркувати голосовий трафік DSCP EF (46). Перевірити маркування. 50 Налаштування межі довіри trust DSCP/COS відбувається за таким сценарієм. Перш ніж почати роботу з QoS, спочатку потрібно активувати його на комутаторі в режимі глобальної конфігурації командою mls qos. Далі слідує налаштування схеми маркування пакетів на основі значення DSCP, кадрів на значенні CoS (Class of Service) або довіри IP-телефону. Налаштування проводиться на інтерфейсі командою mls qos trust cos, щоб переконатися, що комутатор довіряє значенню CoS всіх кадрів, що входять в цей інтерфейс. Значення, що налаштоване за замовчуванням на комутаторах Cisco для cos=0. За замовчуванням комутатор перезапише значення DSCP пакета всередині кадру відповідно до перетворення cos-to-dscp «CoS в DSCP». Щоб запобігти цьому, на інтерфейсі використовується команда mls qos trust cos pass-through. Довіра до CoS або значення DSCP на інтерфейсі встановить межу довіри на рівні комутатора. Межа довіри (trust boundary) означає, якому пристрою потрібно довіряти маркування пакетів і кадрів Ethernet, що входять в мережу. Якщо в мережі використовуються IP-телефони, їх можна застосувати для маркування, далі налаштувати комутатор на довіру до трафіку з IP-телефону. Якщо IP-телефони відсутні або до них «немає довіри», також можна налаштувати маркування на комутаторі. На рисунках 3.6-3.8. приклади встановлення межі довіри на різних рівнях. Найкращою практикою є встановлення межі довіри найближче до джерела трафіку. А тому для моделі буде встановлено межу довіри для IP-телефону на порту комутатора. Для цього використовується команду mls qos trust device cisco-phone, щоб вказати комутатору довіряти всім значенням CoS, які він отримує від IP- телефону Cisco. 51 Рисунок 3.6 – Межа довіри знаходиться на IP-телефоні Рисунок 3.7 – Виконання маркування на комутаторі доступу Рисунок 3.8 – Виконання маркування на комутаторі доступу 52 CoS виставляє пріоритети від 0 до 7. Якщо граничний пристрій (IP-телефон або додаток) вміє виставляти біти, то планувальник мережі повинен вирішити, «довіряти» даному пристрою чи ні. Команда для цього: mls qos cos [0-7]. Використовуючи рівні довіри для телефонів рекомендовано встановити cos=7, а для ПК, що генерують дані cos=1. Після налаштування технології QoS на комутаторі було проведено імітаційне моделювання черги проходження пакетів через комутатор шляхом генерування трафіку даних протоколу ICMP та здійснення голосового дзвінка із одного телефону на інший. Результат показано на рисунку 3.9. Рисунок 3.9 – Перевага проходження кадрів через комутатор Вже з цього розподілу черги пакетів видно надання пріоритету голосовим пакетам (SCCP) перед даними (ICMP). Результати збору статистики при моделюванні проходження голосового трафіку та даних показано на рисунку 3.9. 53 Він демонструє, що голосовий трафік (VoIP) проходить стабільно з невеликими відхиленнями, що моделює пріоритизацію. Трафік даних має більшу амплітуду коливань, тому що він отримує залишкову смугу після голосу. Рисунок 3.10 – Моделювання проходження голосового трафіку та даних На маршрутизаторах існує доцільність налаштувати схему налаштувати попередньо розглянуту схему одношвидкісного триколірного маркерного відра. Для цього використовується технологія мережевого розпізнавання пакетів додатків. Cisco NBAR (Network-Based Application Recognition) – це технологія, яка дозволяє класифікувати пакети, що важко класифікувати за допомогою ACL. Наприклад, протокол, що використовує динамічні порти та шифрування, важко ідентифікувати за допомогою списку доступу. ACL корисні для зіставлення трафіку TCP/UDP на відомих портах. NBAR може проглядати заголовки рівня 3 і рівня 4 та перевіряти інформацію, специфічну для додатків, таку як SSL- сертифікати, URL-рядки та інші атрибути пакетів. На сьогоднішній день NBAR2 є найновішим поколінням механізму глибокої перевірки пакетів. Він може 54 розпізнавати додатки на основі їх протоколів, навіть якщо вони використовують динамічні порти або шифрування. Для початку на маршрутизаторах необхідно створити карту класів, щоб класифікувати трафік ICMP: class-map ICMP match protocol icmp Для модельного прикладу дія буде встановлена exceed-action встановлена як set-dscp-transmit. При перевищенні інтенсивності трафіку вище граничного значення в 128000 біт/с (128 Кбіт/с), контроль здійснює перемаркування (встановлює значення DSCP в менш пріоритетне, наприклад в нуль), але все одно передає пакет. policy-map POLIC_ICMP class ICMP police 128000 conform-action transmit exceed-action set-dscp-transmit cs1 violate-action drop Таким чином була налаштована узгоджена швидкість CIR (Committed Information Rate). Якщо трафік підпадає під дію відповідності, то передається і зберігає своє значення DSCP, якщо трафік перевищує встановлене значення, він також передається, але в якості штрафу DSCP буде встановлено в менш пріоритетне значення. Остання команда порушення використовується для відкидання пакета. Останнім кроком у процесі MQC є приєднання політики до інтерфейсу. Оскільки потрібно зіставляти та класифікувати трафік, то зазвичай застосовується політику до інтерфейсу, що з'єднує кінцеві вузли у вхідному напрямку, як показано нижче. interface FastEthernet 0/1 service-policy input POLIC_ICMP Нижче подано структуровану практичну таблицю 3.1 класифікації трафіку за DSCP, яку реально використовують у корпоративних мережах, у тому числі при 55 впровадженні Cisco QoS. Вона охоплює основні сервіси: голос, відео, управління, критичні додатки, найкраще зусилля та низький пріоритет [RFC 2474, 2597, 3246]. Таблиця 3.1 – Рекомендовані параметри практичної класифікації трафіку за DSCP Приклади сервісів / DSCP Умовна Призначення / Категорія трафіку додатків значення черга / PHB коментар Мінімальна затримка, Cisco IP Phone, Expedited Голос (VoIP RTP) EF (46) втрати та джитер. softphones, SIP RTP Forwarding Найвищий пріоритет. Потребує низької CS3 (24) або Сигналізація голосу SIP, SCCP, H.323 Call Signaling затримки, але менше AF31 (26) вимог, ніж RTP. Чутливе до джитера, Відео реального часу Webex, Zoom, MS Multimedia AF41 (34) але не настільки (конференції) Teams, Telepresence Real-Time критичне як голос. Потокове відео YouTube, IP-TV, Multimedia Середні вимоги до QoS, AF31 (26) (неконференційне) відеотрансляції Streaming допускає буферизацію. CRM, ERP, банківські AF21 (18) Критичні бізнес- Business- Високий пріоритет, але системи, бази даних, або AF22 додатки Critical Data не чутливі до джитера. SCADA (20) Підтримують роботу DNS, DHCP, Active Network мережі, але не Операційні ІТ-сервіси CS2 (16) Directory, NTP Services вимагають низької затримки. Звичайні бізнес- Web, e-mail, файлові CS0 (0) або Трафік без вимог до Best Effort додатки сервіси Best Effort QoS. Резервування, Найнижчий пріоритет. Scavenger / Фоновий трафік реплікації баз даних, CS1 (8) Не може заважати Low Priority великі завантаження критичним сервісам. 56 Звичайно, що в таблиці вище наведено не вичерпний перелік сервісів та можливостей класифікації трафіку на основі пріоритету. І це звичайно дає гнучкі та широкі можливості керування потоками трафіку в сучасних корпоративних мережах, особливо при збільшенні об’ємів передавання інформації. 3.4 Превентивне виявлення перевантажень Досить важливою складовою QoS є виявлення перевантажень на різного роду мережних пристроях. Проте саме при переході через основний шлюз, де зострічається під’єднання високошвидкісних локальних каналів та менш швидкісних глобальних і можуть утворюватися перевантаження. На розглянутій вище топології (рисунок 3.5) два маршрутизатори підмереж з’єднані повільнішим послідовним каналом, що може призвести до перевантажень. Для їх регулювання використовується зважений алгоритм превентивного раннього виявлення WRED (Weighted Random Early Detection) для QoS на маршрутизаторах Cisco. Алгоритм WRED дозволяє уникати заторів на мережевих інтерфейсах за рахунок надання інструментів управління буферизацією і відкидання трафіку до того, як буфер буде переповнений. WRED допомагає уникнути фактичного переповнення буфера і оптимізує використання мережевих ресурсів. Результат роботи WRED особливо добре проявляється, якщо кінцеві пристрої реагують на перевантаження в мережі. Це, зокрема, стосується затосунків, які в якості протоколу транспортного рівня використовують TCP. У момент встановлення TCP-сеансу здійснюється ініціалізація вікна перевантаження (congestion window – cwnd). Значення вікна перевантаження являє собою максимальний розмір даних, які може переслати TCP-відправник в рамках заданого сеансу без отримання підтвердження про доставку. При отриманні підтвердження про доставку першого пакета, TCP-джерело збільшує розмір вікна перевантаження до 2-х, що вказує на можливість відправки 57 вже двох сегментів. Аналогічно, при отриманні підтвердження про доставку 2-х сегментів TCP-джерело збільшує розмір вікна перезавантаження до 4-х. Описана поведінка джерел TCP-з'єднання підпорядковується алгоритму повільного старту (slow start), відповідно до якого TCP-джерело передає сегменти з інтенсивністю, рівною інтенсивності отримання підтверджень про доставку пакетів від TCP- одержувача. Оскільки відкидання сегмента є сигналом про перевантаження мережі для джерела TCP-з’єднання, механізм «відкидання хвоста» (tail drop policy) повідомляє про перевантаження мережі лише в момент фактичного переповнення черги. Внаслідок відкидання пакета джерело TCP-з’єднання зменшує розмір вікна до одного сегмента та перезапускає алгоритм повільного старту, що призводить до різкого зменшення вихідного трафіку TCP. У результаті виконання алгоритму відкидання хвоста одночасно досить велика кількість TCP-джерел звужує розмір вікна перевантаження до 1 та перезапускає механізм повільного старту. Алгоритми повільного старту великої кількості TCP-джерел синхронізуються між собою, оскільки запускаються в однаковий час. Така стратегія відкидання викликає глобальну синхронізацію TCP. Щоб збільшити загальну продуктивність, можна використати метод під назвою RED (Random Early Detection) – алгоритм випадкового раннього виявлення. Замість того щоб чекати, коли відбудеться відкидання хвоста черги, алгоритм стежить за глибиною черги. Коли черга починає заповнюватися, деякі випадкові пакети відкидаються з метою уповільнення TCP. Зважування WRED означає, що алгоритм контролює середню глибину черги. Коли черга починає заповнюватися, WRED відкидає лише кілька випадкових пакетів. Коли довжина черги збільшується, WRED стає більш агресивним і відкидає ще більше випадкових пакетів, доки не досягне певного порогу. Коли цей поріг досягнуто, відкидаються всі пакети. Відповідно до механізму RED, ймовірність відкидання пакетів зростає прямо пропорційно збільшенню середнього розміру черги від мінімального до максимального порогового значення. 58 WRED використовує профіль трафіку для визначення ймовірності відкидання пакета. Цей профіль базується на трьох ключових значеннях: Мінімальний поріг (Minimum Threshold) – якщо середня довжина черги менша за мінімальний поріг, пакети не відкидаються. Максимальний поріг (Maximum Threshold) – якщо середня довжина черги перевищує максимальний поріг, усі пакети відкидаються. Максимальна ймовірність відкидання (Maximum Drop Probability) – це верхня межа ймовірності відкидання пакета, коли середня довжина черги знаходиться між мінімальним і максимальним порогами. Ймовірність зростає лінійно від 0 (на мінімальному порозі) до цього максимального значення (на максимальному порозі). Деякі пакети є важливішими за інші, тому замість відкидання випадкових пакетів використовуються різні профілі трафіку для різних пакетів. Можна відкидати пакети на основі таких критеріїв, як CoS, IP Precedence, DSCP та деяких інших параметрів. На рисунку 3.11 показана модель із двох профілів трафіку. Рисунок 3.11 – Модель із двох профілів трафіку 59 На рисунку вказано один профіль для пакетів, позначених пріоритетом IPP 3, а інший для пріоритету IPP 5. Пакети з пріоритетом IPP 3 відкидаються раніше (мінімальний поріг 20 пакетів) і частіше (MPD 25%), ніж з пріоритетом IPP 5: Тому налаштування будуть виглядати так: 1. Пріоритет IPP 3: Мінімальний поріг: 20 пакетів. Максимальний поріг: 45 пакетів. MPD: 25%. 2. Пріоритет IPP 5: Мінімальний поріг: 30 пакетів. Максимальний поріг: 60 пакетів. MPD: 20%. Замість пріоритету IPP також можна використовувати DSCP (є найбільш поширеним варіантом, що і показано в таблиці 3.2). Потім WRED встановлює мінімальний поріг на основі ймовірності відкидання. Таблиця 3.3 – Рекомендовані параметри порогу на основі DSCP Відкидання Class 1 Class 2 Class 3 Class 4 Низьке 001010 (AF11) 010010 (AF21) 011010 (AF31) 100010 (AF41) Середнє 001100 (AF12) 010100 (AF22) 011100 (AF32) 100100 (AF42) Високе 001110 (AF13) 010110 (AF23) 011110 (AF33) 100110 (AF43) Для налаштування алгоритму WRED за замовчуванням достатньо однієї команди random-detect. Для початку потрібно створити карти класів з відповідністю на списки контролю доступу ACL, щоб промаркувати два потоки трафіку: access-list 100 permit udp any any eq 2000 access-list 101 permit udp any any eq 3000 60 class-map match-all DATA match access-group 101 class-map match-all VOICE match access-group 100 Наступний крок – створення карти політик і безпосереднє формування двох видів трафіку. У команді shape average потрібно вказати значення узгодженої максимальної швидкості CIR (Committed Information Rate), також налаштування для алгоритму WRED профілю трафіку даних: policy-map WRED class DATA shape average 30000 set precedence 4 Для початку потрібно налаштувати пріоритет IPP. Можна налаштувати профіль трафіку (traffic profile) для кожного значення пріоритету IPP за допомогою команди random-detect precedence. random-detect precedence 4 10 20 4 Перше число – це пріоритет IPP, друге – мінімальний поріг відкидання, третє – максимальний поріг. Останній параметр MPD (mark probability denominator) також налаштований на роботу з кількістю пакетів. MPD визначає частину відкинутих пакетів при досягненні середнім розміром черги максимального порогового значення. Аналогічно налаштування виглядають для трафіку голосу: policy-map WRED class VOICE shape average 30000 set precedence 7 random-detect random-detect precedence 7 20 30 20 Потім активуємо карту політик на інтерфейсі: interface FastEthernet 0/0 service-policy output WRED Результати моделювання проходження трафіку різного типу показані на рисунках 3.12-3.13. 61 Рисунок 3.12 - Проходження трафіку даних через алгоритм WRED Рисунок 3.13 - Проходження трафіку голосу через алгоритм WRED WRED обчислює середню глибину черги, і це середнє значення оновлюється на основі експоненціальної вагової константи. Константа контролює швидкість зміни середньої глибини черги. Якщо значення константи менше, то середня глибина черги змінюється швидше, якщо константа більша, то – повільніше. Мала 62 експоненційна вагова константа змусить WRED швидко реагувати на зміни, а велика експоненційна вагова константа змусить WRED повільно реагувати на зміни. 3.5 Висновки до розділу 3 В розділі було застосовано всі попередні дослідження, які дали змогу надати рекомендації та потужні інструменти для проведення оптимізації роботи корпоративної мережі на основі застосування практик Quality of Service. Сюди ввійшли маркування на основі довіри та пріоритету трафіку на канальному рівні 2, обмеження пропускної полоси для окремих видів трафіку, контроль на основі одношвидкісного триколірного маркерного відра та алгоритм превентивного раннього виявлення перевантажень. Також було розроблено рекомендовані параметри практичної класифікації трафіку за DSCP. 63 ВИСНОВКИ У даній кваліфікаційній роботі магістра виконано комплексне дослідження теоретичних, методичних та практичних аспектів забезпечення якості обслуговування (Quality of Service, QoS) у корпоративних комп’ютерних мережах. На основі аналізу сучасних підходів встановлено, що ключовими параметрами, які визначають якість функціонування мережевих сервісів, є затримка, джитер, втрата пакетів та пропускна здатність. Розгляд моделей IntServ, DiffServ та MPLS QoS продемонстрував різну глибину та масштабованість механізмів управління мережевими ресурсами – від індивідуального резервування каналів до багаторівневої диференціації трафіку у великих корпоративних інфраструктурах. У другому розділі поглиблено механізми керування трафіком, що дозволяють забезпечити стабільну роботу сервісів реального часу та критично важливих застосунків. Показано, що поєднання чергування, формування трафіку, політик контролю та механізмів уникнення перевантажень дає змогу оптимізувати використання мережевих ресурсів, мінімізувати негативні впливи перевантажень та гарантувати необхідний рівень обслуговування відповідно до вимог угоди про рівень обслуговування. У третьому розділі проведено практичне застосування отриманих теоретичних знань для формування рекомендацій щодо оптимізації корпоративної мережі. Зокрема, реалізовано довірене маркування трафіку на канальному рівні, механізми обмеження пропускної здатності, а також контроль трафіку на основі одношвидкісного триколірного маркерного відра. Розроблено рекомендовану схему класифікації трафіку за DSCP, що може бути застосована в реальних корпоративних середовищах для забезпечення справедливого та ефективного розподілу мережевих ресурсів між класами сервісів. Узагальнюючи результати дослідження, можна стверджувати, що застосування механізмів QoS є ключовим чинником підвищення продуктивності, надійності та передбачуваності роботи сучасних корпоративних мереж. Отримані 64 теоретичні висновки, методичні розробки та практичні рекомендації формують цілісну основу для подальшого проєктування, моделювання та впровадження систем QoS, а також можуть бути використані при модернізації існуючих мережевих інфраструктур для забезпечення високої якості надання цифрових послуг. В цілому завдання на кваліфікаційну роботу виконано, мету роботи досягнуто, а її результати мають також суттєве практичне значення. 65 ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ QoS – якість обслуговування. IntServ – інтегровані сервіси. RSVP – протокол резервування мережевих ресурсів. DiffServ – диференційовані сервіси. DSCP – диференційована точка коду послуг. MPLS – багатопротокольна комутація міток. VoIP – технологія передачі голосу через ІР-мережі. MOS – метрика для оцінки якості аудіо/відео на основі суб’єктивного сприйняття. RTT – сумарна затримка в обидві сторони. DSP – цифрова обробка сигналу. LLQ – мінімальний час затримки. TCP – протокол керування передачею. SLA – угода про якість обслуговування. SNMP – простий протокол керування мережею. PHB – поведінка на основі вузла. WAN – глобальні канали зв’язку. CBWFQ – класове зважене справедливе чергування. ToS – умови надання послуг. IPP – пріоритет ІР-адреси. NBAR2 – розпізнавання застосунків мережевого рівня нового покоління. MQC – модульна якість обслуговування. VLAN – віртуальні локальні мережі. TPID – ідентифікатор протоколу тегу. TCI – інформація керування тегом. CS – клас сервісу. ISP – провайдери мережних послуг. 66 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 1. Schober M. Architectures for assuring Quality of Service (QoS) and managing traffic flows: Marshall Plan Scholarship Program Report. Bowling Green: University of Applied Sciences Salzburg, 2011. 29 p. 2. Blake S., Black D., Carlson M., Davies E., Wang Z., Weiss W. An Architecture for Differentiated Service (RFC 2475). USA: RFC Editor, 1998. 36 p. 3. Tsirtsis G., Giarreta G., Soliman H., Montavont N. Traffic Selectors for Flow Bindings (RFC 6088). USA: RFC Editor, 2011. DOI: 10.17487/RFC6088. 14 p. 4. Evans J., Filsfils C. Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice. Burlington, MA: Morgan Kaufmann, 2007. 512 р. 5. Комп'ютерні мережі: навч. посіб. / І. Р. Арсенюк, А. А. Яровий; Вінниц. нац. техн. ун-т. Вінниця: ВНТУ, Ч. 1-3. 2017. 84 с. 6. Bruno A., Jordan S.. CCNP Enterprise Design ENSLD 300-420 Official Cert Guide: Designing Cisco Enterprise Networks. Hoboken: Cisco Press, 2021. 574 p. 7. Cisco Systems. Modify Bandwidth Consumption Calculation for Voice Calls. USA: Cisco, 2023. URL: https://www.cisco.com/c/en/us/support/docs/voice/voice- quality/. 8. Cisco Systems. Implement QoS Policies with Differentiated Services Code Point. USA: Cisco, 2025. 12 p. Document ID: 10103. URL: https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-packet- marking/10103-dscpvalues.html 9. Буров Є.В. Комп’ютерні мережі. Підручник. Том 2. / Є.В. Буров, М.М. Комп'ютерні мережі: навч. посіб. / І. Р. Арсенюк, А. А. Яровий; Вінниц. нац. техн. ун-т. Вінниця: ВНТУ, Ч. 1-3. 2017. 84 с. 10. Kaza R., Asadullah S. Cisco IP Telephony: Planning, Design, Implementation, Operation, and Optimization. Indianapolis: Cisco Press, 2005. 500 p. 11. Auda Y.R. Introduction to QoS CCIE & CCSI. USA: Cisco Learning Network, 2020. 50 p. URL: https://learningnetwork.cisco.com/s/article/introduction-to-qos. 67 12. Berger L., Le Faucheur F., Narayanan A. RSVP ASSOCIATION Object Extensions (RFC 6780). USA: RFC Editor, 2012. 24 p. DOI: 10.17487/RFC6780. 13. Wallace K. Implementing Cisco Unified Communications Voice over IP and QoS (CVOICE): Foundation Learning Guide. – 4th ed. – Indianapolis: Cisco Press, 2011. – 736 p. 14. Nichols K., Blake S., Baker F., Black D. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (RFC 2474). USA: RFC Editor, 1998. 20 p. DOI: 10.17487/RFC2474. 15. Davie B., Charny A., Bennett J.C.R., Benson K., Le Boudec J.Y., Courtney W., Davari S., Firoiu V., Stiliadis D. An Expedited Forwarding PHB (Per-Hop Behavior) (RFC 3246). USA: RFC Editor, 2002. 16 p. DOI: 10.17487/RFC3246 16. Основи побудови локальних комп’ютерних мереж Ethernet на базі керованих комутаторів компанії Cisco: навчальний посібник. / А.А. Єфіменко. Житомир: Державний університет «Житомирська політехніка», 2021. 116 с. 17. Тарнавський Ю. А., Кузьменко І. М. Організація комп’ютерних мереж / Ю. А. Тарнавський, І. М. Кузьменко. Київ: КПІ ім. Ігоря Сікорського, 2018. 259 с. 18. Cisco Systems. Release Notes for Cisco Protocol Pack 65.0.0. USA: Cisco, 2023. URL: https://www.cisco.com/c/en/us/td/docs/ios- xml/ios/qos_nbar/prot_lib/config_library/pp6500/release-notes-cisco-protocol-pack-65- 0-0.html. 19. Cisco Systems. Compare Traffic Policy and Traffic Shape to Limit Bandwidth. USA: Cisco, 2025. URL: https://www.cisco.com/c/en/us/support/docs/quality-of- service-qos/qos-packet-marking/10103-dscpvalues.html. 20. Організація комп’ютерних мереж. Підручник: для студ. спеціальності 121 «Інженерія програмного забезпечення» та 122 «Комп’ютерні науки» / КПІ ім. Ігоря Сікорського; Ю. А. Тарнавський, І. М. Кузьменко. Київ: КПІ ім. Ігоря Сікорського, 2018. 259 с. 21. Odom Wendell. CCNA 200-301 Official Cert Guide. Volume 1. Hoboken: Cisco Press, 2020. 1095 p. 68 22. Комп’ютерні мережі. Частина 1-2: навч. посіб. для студ. спеціальності 121 «Інженерія програмного забезпечення» та 126 «Інформаційні системи та технології»/ Б. Ю. Жураковський, І.О. Зенів. Київ: КПІ ім. Ігоря Сікорського, 2020. 336 с. 23. IP Addressing: DHCP Configuration Guide, Cisco IOS XE Everest 16.6. San Jose: Cisco Press, 2018. 266 p. 24. ДСТУ 3008-2015. Державний стандарт України. Документація. Звіти у сфері науки і техніки. Структура і правила оформлення. К: УкрНДНЦ, 2016. 26 с. ДОДАТОК А Модельні сценарії налаштування проміжних пристроїв Маршрутизатор Router1(2) no service timestamps log datetime msec no service timestamps debug datetime msec no service password-encryption hostname Router ip dhcp excluded-address 192.168.30.1 192.168.30.5 ip dhcp excluded-address 192.168.40.1 192.168.40.5 ip dhcp pool data40 network 192.168.40.0 255.255.255.0 default-router 192.168.40.1 ip dhcp pool voice30 network 192.168.30.0 255.255.255.0 default-router 192.168.30.1 option 150 ip 192.168.30.1 no ip cef no ipv6 cef license udi pid CISCO2811/K9 sn FTX101738GQ- spanning-tree mode pvst interface FastEthernet0/0 no ip address duplex auto speed auto interface FastEthernet0/0.30 encapsulation dot1Q 30 ip address 192.168.30.1 255.255.255.0 interface FastEthernet0/0.40 encapsulation dot1Q 40 ip address 192.168.40.1 255.255.255.0 interface FastEthernet0/0.60 encapsulation dot1Q 60 native no ip address interface FastEthernet0/1 no ip address duplex auto speed auto shutdown interface Serial0/0/0 ip address 10.0.0.1 255.255.255.0 interface Serial0/0/1 no ip address clock rate 2000000 shutdown interface Vlan1 no ip address shutdown ip classless ip route 192.168.20.0 255.255.255.0 10.0.0.2 ip flow-export version 9 telephony-service max-ephones 3 max-dn 3 ip source-address 192.168.30.1 port 2000 ephone-dn 1 number 2010 ephone-dn 2 number 2020 ephone-dn 3 number 2030 ephone 1 device-security-mode none mac-address 000B.BE7E.2CA0 type 7960 button 1:1 ephone 2 device-security-mode none mac-address 000A.418E.8974 type 7960 button 1:2 line con 0 line aux 0 line vty 0 4 login end Комутатор Switch1(2) no service timestamps log datetime msec no service timestamps debug datetime msec no service password-encryption hostname Switch mls qos spanning-tree mode pvst spanning-tree extend system-id interface FastEthernet0/1 switchport trunk native vlan 60 switchport mode trunk interface FastEthernet0/2 switchport mode access switchport voice vlan 30 mls qos cos 7 mls qos trust cos mls qos trust device cisco-phone interface FastEthernet0/3 switchport mode access switchport voice vlan 30 mls qos cos 7 mls qos trust cos mls qos trust device cisco-phone interface FastEthernet0/4 switchport mode access switchport voice vlan 30 interface FastEthernet0/5 switchport access vlan 40 switchport mode access mls qos cos 1 mls qos trust cos interface FastEthernet0/6 interface FastEthernet0/7 interface FastEthernet0/8 interface FastEthernet0/9 interface FastEthernet0/10 interface FastEthernet0/11 interface FastEthernet0/12 interface FastEthernet0/13 interface FastEthernet0/14 interface FastEthernet0/15 interface FastEthernet0/16 interface FastEthernet0/17 interface FastEthernet0/18 interface FastEthernet0/19 interface FastEthernet0/20 interface FastEthernet0/21 interface FastEthernet0/22 interface FastEthernet0/23 interface FastEthernet0/24 interface GigabitEthernet0/1 interface GigabitEthernet0/2 interface Vlan1 no ip address shutdown line con 0 line vty 0 4 login line vty 5 15 login end