Cisco qos для самих маленьких, twistedminds
З чим корисний і з чим допомагає впоратися QoS?
- Маленька пропускна здатність каналу - не завжди у нас на руках виявляється той канал, який дозволить і youtube в HD подивитися і корпоративних додатків працювати адекватно.
- Втрата критичних пакетів в слідстві заторів.
- Затримки (delay) - час, який потрібен пакету щоб потрапити від джерела до одержувача. Так, наприклад, 400ms RTT для голосу ще туди-сюди, а ось з значеннями, які перевищують цей поріг ви отримаєте ефект накладається голосу.
- Джиттер (jitter) або зміна затримки з плином часу. Зараз у вас 100ms, а через хвилину 200ms. Вітаю, у вас тепер 100ms jitter, який перетворюється в затримку просто тому, що залізок потрібно тримати пакет в буфері якийсь час для забезпечення плавності того ж розмови.
Методи налаштування QoS
- Command Line Interface (CLI) - per interface конфігурація.
- Modular QoS CLI (MQC) - аки ZBF дозволяє групувати class map в policy map, policy map прив'язувати до service policy, а ось вже останнє можна і на інтерфейс застосувати.
- Auto QoS - генерує якийсь усереднений конфиг, який, звичайно, не one size fit all, але в деяких випадках виявляється цілком працездатним.
- QoS Policy Manager (QPM) - централізована підтримка QoS у вашій мережі. Вбудована в CiscoWorks.
Інструменти QoS
- Класифікація і групування різних типів трафіку.
- Маркування трафіку за тим, щоб інші пристрої в мережі могли б розпізнати його.
- Policing shaping. Policing дозволяє або відкидати пакети при перевищенні якого-небудь значення, або змінювати маркування. Shaping - метод розміщення пакетів в чергах (i.e. FIFO, WFQ, CBWFQ) при досягненні ліміту.
З метою уникнення заторів (congestion avoidance)
- First-in First-out - як зрозуміло з назви - хто перший встав, того і тапки. Пакети поміщаються в чергу, поки не буде вичерпана пропускна здатність каналу. При її вичерпання заповнюється буфер. Ну а якщо і він закінчився, то пакети просто відкидаються - tail drop.
- Random Early Detection (RED) - RED займається цікавою штукою: як тільки ваш буфер починає заповнюватися - "БАМ!" - в ньому гине випадковий пакет. І чим швидше заповнюється буфер, тим агресивніше працює цей механізм. На скільки я знаю Cisco не підтримує його роботу.
- Weighted Random Early Detection (WRED) - займається тим же, що і RED, але замість содомії з випадковими пакетами цей механізм вибирає жертв на підставі маркування пакетів і позначених заздалегідь правил. "БАМ!" - і замість пакета з voice трафіком гине шматок картинки з redtube'a. Якщо пакети заздалегідь не були марковані, то WRED перетворюється в RED.
управління заторами
Управляти заторами можна поміщаючи пакети в черзі, дозволяючи найбільш пріоритетному трафіку залишати інтерфейс в першу чергу, а найменш пріоритетний трафік може і включення WRED дочекатися, всяке буває.
збільшення ефективності
- Стиснення (data compression).
- Фрагментація каналу і чергування (link fragmentation interleaving) - припустимо у нас є повільний канал (serial, ага) в який готується проникнути соковитий пакет, що містить не особливо важливі дані. На момент коли передача буде розпочато буде в принципі не важливо чи налаштований QoS - соковитий пакет з радістю займе всі надані йому 1500 байт і не пустить крихітний голосовий пакет не дивлячись ні на що. LFI говорить приблизно наступне - більше у нас не буде великих пакетів, крихітний пакет голосу, упакований g.711 повинен пролізти no matter what.
Modular QoS CLI
Class map - відповідають за класифікацію трафіку, дозволяючи відокремити трафік і великим пріоритетом від трафіку з меншим. i.e. я хочу виділити http трафік в окремий клас class-map 2.
Policy map - говорить що робити з трафіком, включеним в входять в нього class map. i.e. я хочу маркувати http трафік певним тегом в policy-map 1 і я хочу лімітувати смугу пропускання для http трафіку в 64kbps в policy-map 2.
Service policy - застосовує policy map на інтерфейсі для вхідного або вихідного трафіку. i.e. я хочу щоб policy-map 1 маркірувала вихідний http трафік на fa0 / 1, а policy map 2 лімітувала входить на fa0 / 2. Одна і тільки одна service policy може існувати для кожного з напрямків на кожному інтерфейсі.
Налаштування class map
Для class map існують 2 критерію, за яким вони будуть працювати - match-all (логічне І) і match-any (логічне АБО). За замовчуванням створюється class-map match-all, що означає що всі умови, занесені в такий class map повинні совпасіть одночасно для того, щоб class-map спрацювала.
Під дію цієї class map потрапить ICMP трафік з розміром пакета від 200 до 400 байт.
Самі спостережні з вас встигли помітити, що крім створеної class map ICMP існує ще одна - default, під дію якої потрапляє весь трафік - це class map за замовчуванням. Наприклад ми можемо описати голосовий трафік і написати для нього певне правило A, а весь інший трафік, який нам не цікавий, відправиться автоматом в class-default і для нього буде застосовано правило B.
Крім протоколів можна допускати або не допускати до фільтрації мережі, хости, а так само гнучко їх поєднувати в одній class-map за допомогою ACL. i.e .:
Під дію такої class map потраплять ваші поштові сервера і SMTP трафік. І на 25 і на 587 порт. Розумний IOS сам розбереться завдяки Network Based Application Recognition (NBAR).
Налаштування policy map
Прийшов час розповісти бездушною залізницею що робити з класифікованих таким чином трафіком. Єдина корисна річ, яку можна зробити з policy map відразу після створення це додати до нього class map:
А ось після застосування class map якраз і починається все веселощі:
Зверніть увагу на змінилося запрошення.
Побіжно пробіжимося по опціях:
Хотілося б ще раз повторити - це короткий опис опцій, докладні розмова про які є темою не для однієї статті.
Застосування policy map
Немає нічого простішого. В режимі конфігурації інтерфейсу за допомогою команди service-policy вкажіть напрямок і назва policy map. Не так вже й важко, чи не так? ;)
Для того, щоб розбавити сумну теорію давайте зберемо невеликий стенд, заборонивши на r2 ICMP пакети більше 700 байт у напрямку до r3 з 192.168.1.0/24 мережі, для ICMP пакетів розміром від 300 до 700 виставимо обмеження 8000bps.
і перевіримо емпіричним шляхом на R1:
дійсно, ICMP пакети до 299 включно без проблем пролазять, минаючи всю маркування через class map, ICMP пакети від 300 до 700 байт починають зазнавати труднощів, в результаті встановленого ліміту »не більше 8000 біт в секунду", а ICMP пакети понад 701 байта просто і без викрутасів відкидаються.
На R2 з роботою вашої політики можна ознайомитися в такий спосіб:
Вихідну інформацію про трафік для складання QoS політик можна зібрати в реальному часі c допомогою того ж nbar:
Але куди кошерні робити це за допомогою netflow.
Питання таке.
які ще протоколи клас мап розуміє, коли пишеш. після клас мап то чіска мовчить ....
R2 (config) # class-map ICMP
R2 (config-cmap) #match protocol icmp
якщо icmp написати. буде різатися трафік icmp. незрозуміло тільки на всіх портах чи ні. опиши будь ласка більш детально "для дурня))"
а якщо я хочу http нпіастаь наприклад що буде тоді.
ніби й сам відповів)
3750G-24 (config) #class
3750G-24 (config) # class-map ICMP
3750G-24 (config-cmap) #match
3750G-24 (config-cmap) #match pro
3750G-24 (config-cmap) #match protocol?
arp IP ARP
bridge Bridging
cdp Cisco Discovery Protocol
clns ISO CLNS
clns_es ISO CLNS End System
clns_is ISO CLNS Intermediate System
cmns ISO CMNS
http HTTP
ip IP
ipv6 iPV6
) Ну тоді питання.
якщо icmp написати. буде різатися трафік icmp. незрозуміло тільки на всіх портах чи ні. опиши будь ласка більш детально "для дурня))"
а якщо я хочу http написати наприклад що буде тоді. що відразу ж станеться з комутатором. або до створення полісі мап і сервіс полісі на інтерфейсі ніяких змін не буде.
Тимур, на мій погляд все і так гранично докладно описано, перечитайте розділ Modular QoS CLI.